ESP32 + Modbus RTU: Was die Doku verschweigt

Als ich anfing, den ESP32-S3 als Modbus RTU Master einzusetzen, dachte ich: "Protokoll lesen, Library einbinden, fertig." Die Realität sah anders aus.

Das Timing-Problem

Modbus RTU verlangt eine Pause von mindestens 3,5 Zeichen zwischen Frames. Bei 9600 Baud sind das ca. 4 Millisekunden. Klingt trivial — bis FreeRTOS dazwischenfunkt. Ein Task-Switch zur falschen Zeit, und der Slave interpretiert zwei zusammenhängende Frames als getrennte Nachrichten.

Lösung: Dedizierter UART-Task mit höchster Priorität und vPortEnterCritical() für zeitkritische Sequenzen. Nicht schön, aber zuverlässig.

Half-Duplex ist tückisch

RS485 teilt sich eine Leitung für Senden und Empfangen. Der ESP32 muss den DE/RE-Pin (Driver Enable) exakt zum richtigen Zeitpunkt umschalten — nach dem letzten gesendeten Byte, aber vor der Slave-Antwort.

Das Problem: Der UART-TX-Buffer meldet "fertig", obwohl das letzte Byte noch im Shift-Register steckt. Schaltet man sofort auf Empfang, geht das letzte Byte verloren.

Lösung: Nach dem TX-Complete einen kurzen Delay einfügen (abhängig von der Baudrate), bevor auf RX umgeschaltet wird.

247 Geräte, ein Bus

In der Theorie unterstützt Modbus 247 Slaves. In der Praxis wird es ab 30 Geräten eng — nicht wegen des Protokolls, sondern wegen der elektrischen Signalqualität. Terminierungswiderstände, Kabellänge und Stichleitungen machen den Unterschied.

Fazit

Modbus RTU ist ein robustes Protokoll — wenn man die Fallstricke kennt. Die offizielle Doku beschreibt das "Was", aber selten das "Warum". Für produktive Systeme braucht es Erfahrung, Geduld und ein gutes Oszilloskop.