ESS3H32 FAQ

Betreff: ESS3H32 Handbuch und Beispielcode — Abweichung der RS485-Pins, Eingangsunterbrechungen, Entprelllogik und N16R8-Kompatibilität
Sehr geehrtes Eletechsup-Supportteam,
Wir integrieren ein ESS3H32-Board mit einem ESP32-S3 N16R8-Modul. Nach Durchsicht der bereitgestellten ESS3H32-HANDBUCH-Dokumente und der Arduino-Beispiele haben wir mehrere Punkte gefunden, die geklärt werden müssen.
1. Die RS485-Pinbelegungen unterscheiden sich zwischen Handbuch und Schaltplan
Die Pin-Tabellen in Read before use.txt und ESS3H32 16DI-16DO ESP32 S3 Expansion Board.pdf listen:
RS485-Port: GPIO1, GPIO3, GPIO17
Der Schaltplan Schematic_ESS3H32.pdf zeigt jedoch:
RS485-Funktion    Schaltplanverbindung
Senden    GPIO43 / TX0 → Transceiver DI
Empfangen    GPIO44 / RX0 ← Transceiver RO
Richtungssteuerung    GPIO1 / RS485_RD → DE und /RE

Das Beispiel ESS3H32_RS485_RW.ino definiert:
const int RS485RD = 1;
Serial0.begin(115200);
Es weist TX- und RX-Pins nicht explizit zu.
Bitte bestätigen Sie:
- Sind die korrekten RS485-Pins GPIO43 für TX, GPIO44 für RX und GPIO1 für die Richtungssteuerung?
- Ist der Eintrag GPIO1/GPIO3/GPIO17 im Handbuch ein Tippfehler oder beschreibt er eine andere Board-Revision?
- Da MO5 GPIO17 zugewiesen ist, gibt es eine tatsächliche elektrische Teilung zwischen MO5 und RS485?
- Welche Arduino-Board-Auswahl und ESP32-Core-Version sollte verwendet werden, damit Serial0 die korrekten Pins auswählt?
Der Titelblock der Schaltplan-Datei lautet ebenfalls „ES30F27“, REV 1.0, datiert 2024-11-19, obwohl der Dateiname Schematic_ESS3H32.pdf lautet. Bitte bestätigen Sie, dass dieser Schaltplan für unser ESS3H32-Board gilt.
2. Hardware-Interrupt und Unterstützung für kurze Impulse für IN1–IN16
Der Schaltplan und die Beispiele zeigen zwei 74HC165-Shiftregister, die folgende Pins verwenden:
GPIO9  — CLK
GPIO10 — LOAD
GPIO21 — DATA
Die bereitgestellten Eingangsbewertungsbeispiele verwenden Polling. Wir haben keinen Interrupt-Handler für Eingangsänderungen oder eine separate Interruptverbindung von der Eingangsschaltung zum ESP32-S3 gefunden.
Bitte klären Sie:
- Kann eine Änderung an einem der Eingänge IN1–IN16 einen Hardware-Interrupt auslösen? Wenn ja, welche Schaltung und welcher GPIO stellt diesen bereit?
- Gibt es ein Hardware-Ereignis-Latch oder einen Impulzzähler, der Impulse zwischen den Abfragen speichert?
- Wenn die Erfassung nur per Polling erfolgt, welche minimale Impulsbreite und maximale Impulsfrequenz können zuverlässig erkannt werden, einschließlich Optokoppler-Verzögerungen und des erforderlichen Abfrageintervalls?
- Was empfehlen Sie für Anwendungen, die eine zuverlässige Impulszählung oder eine individuelle Erkennung von steigenden/fallenden Flanken erfordern?
Unsere Sorge ist, dass ein zwischen zwei parallelen Ladevorgängen beginnender und endender Impuls möglicherweise vollständig übersehen wird.
3. Der Vergleich der Eingangs-Entprellung hat keinen Einfluss auf den Rückgabewert
Sowohl in ESS3H32_16DI.ino als auch in ESS3H32_16DI_16DO.ino enthält Get_Input_Value():
Value1 = Read_74HC165();
delay(20);
Value2 = Read_74HC165();

Value = Value1;
if (Value1 == Value2)
{
    Value = Value1;
}
Da Value vor dem Vergleich Value1 zugewiesen wird, gibt die Funktion die erste Probe zurück, selbst wenn die beiden Proben unterschiedlich sind. Der Vergleich lehnt einen instabilen Eingang daher nicht ab und ändert auch das Ergebnis nicht.
Bitte bestätigen Sie:
- Ist dies ein Programmierfehler in den bereitgestellten Beispielen?
- Sollte bei einer Abweichung der vorherige akzeptierte Wert beibehalten, eine weitere Probe ausgelöst oder eine andere Richtlinie befolgt werden?
- Sollte die Entprellung für jeden Eingangskanal unabhängig funktionieren?
- Können Sie korrigierten Code für die Eingangserfassung und Entprellung bereitstellen?
Diese Beispiele enthalten außerdem delay(100) in der Hauptschleife. Zusammen mit der 20ms-Verzögerung zwischen den Abfragen fügt dies 120ms explizite Verzögerung pro Schleife hinzu, ohne die Verarbeitungs- und Kommunikationszeit. Bitte erklären Sie die beabsichtigte Reaktionszeit und die Einschränkungen der Impulserkennung dieser Beispiele.
4. MO10–MO12 kollidieren mit den N16R8-Octal-PSRAM-Pins
Die bereitgestellten Ausgangsbewertungsbeispiele weisen folgende Pins zu:
ESS3H32-Ausgang    GPIO
MO10    GPIO37
MO11    GPIO36
MO12    GPIO35

Die Dokumentation von Espressif für den ESP32-S3-WROOM-1/1U identifiziert GPIO35, GPIO36 und GPIO37 als mit dem Octal-PSRAM verbunden und für andere Zwecke auf dem entsprechenden N16R8-Modul nicht verfügbar.
Bitte bestätigen Sie:
- Wird das N16R8-Modul unterstützt, wenn alle 16 ESS3H32-Ausgänge verwendet werden?
- Wie sind diese Ausgangsschaltungen von der PSRAM-Aktivität isoliert, falls überhaupt?
- Welches genaue Modulmodell unterstützt alle 16 Ausgänge ohne diesen Konflikt?
- Ist eine Hardware-Änderung oder eine andere Carrier-Revision erforderlich?
Bitte stellen Sie die korrigierte Pin-Tabelle, den für die aktuelle ESS3H32-Revision geltenden Schaltplan, die unterstützten Modulmodellnummern und korrigierte Arduino-Beispiele bereit.
Vielen Dank für Ihre Hilfe.
Mit freundlichen Grüßen,

Antwort:

1. Der Schaltplan hat Vorrang. Es gibt keine Konflikte zwischen den RS485-Pins und den MOSFET-Pins.

2. "Schematic_ESS3H32.pdf" ist der korrekte Schaltplan.

Sie meinen, ich kann DO10,11,12 und PSRAM gleichzeitig verwenden, richtig? Trotz der ESS3H32-Ausgang    ESP32-S3 GPIO    Konflikt
MO10    GPIO37    Wird vom Octal SPI PSRAM verwendet
MO11    GPIO36    Wird vom Octal SPI PSRAM verwendet
MO12    GPIO35    Wird vom Octal SPI PSRAM verwendet

Ich habe es gerade getestet. Sie können nicht gleichzeitig verwendet werden, das müssen Sie beachten. Es ist ein großes Problem

Ja, wir haben dies ebenfalls bemerkt; jedoch hat der ESP32 eine begrenzte Anzahl von Pins, und viele davon sind multiplexed.

Multiplexed ist okay. Aber vermeiden Sie PSRAM-GPIO-Pins.

Ich entwickle derzeit eine neue Steuersprache, die als SPS fungiert, aber nicht für Menschen, sondern für KI. Das Zielsystem ist der ESP32.  Das erste Entwicklungsboard ist das Waveshare 8DI 8RO Modell.  Ihr ESS3H32 ist das zweite Entwicklungsboard, das ich wähle.  

Wie Sie wissen, wählt Waveshare einen anderen Ansatz für Eingang und Ausgang.  Eingang benötigt mehr Timing-Genauigkeit oder die Verzögerungszeit im Notfall kann kritisch sein, daher muss meiner Meinung nach ein unterbrochener Eingang diese Funktion haben.

 Ich werde Ihnen zeigen, wenn unser KI-natives, auf MCU basierendes SPS-System bereit für den Betatest ist.

 https://callin2.github.io/farm_studio_frontend/pig/#en/ch01

 Der Ausführen-Beispiel-Button  bringt Sie zur Beispielquelle und Simulationsseite.