ttyAMA0, ttyS0, serial0: Welches davon sollte mein Modbus-HAT auf einem Pi 3B+ verwenden?
Von English mit KI übersetzt ·
Pi 3B+, Raspberry Pi OS Bookworm, ein RS485-HAT auf dem GPIO-Header. Python mit minimalmodbus fragt einen Dreiphasen-Energiezähler mit 9600 8N1, Adresse 5, ab und veröffentlicht jede Minute kW und kWh an Hermetry.Problem: etwa jede fünfte Abfrage schlägt fehl. Entweder ein Timeout oder ein CRC-Fehler. Derselbe Zähler antwortet auf meinem Laptop über einen USB-RS485-Stick jedes Mal. Mein Skript öffnet /dev/ttyAMA0, weil das Beispiel des HAT-Herstellers so war. Dann habe ich einen Forenbeitrag gelesen, der ttyS0 empfiehlt, und einen anderen, der serial0 empfiehlt, und jetzt weiß ich ehrlich gesagt nicht mehr, was ttyAMA0 überhaupt ist.
minimalmodbus.NoResponseError: No communication with the instrument (no answer)
minimalmodbus.InvalidResponseError: Checksum error in rtu mode: 'x8ax1f' instead of 'x0exc4' .
Was ist der Unterschied und welches davon brauche ich?
Pi 3B+, Raspberry Pi OS Bookworm, an RS485 HAT on the GPIO header. Python with minimalmodbus polls a three-phase energy meter at 9600 8N1, address 5, and publishes kW and kWh to Hermetry every minute.
Problem: about one poll in five fails. Either a timeout or a CRC error. The same meter on a USB-RS485 stick on my laptop answers every time. My script opens /dev/ttyAMA0 because that’s what the HAT vendor’s example used. Then I read a forum post saying to use ttyS0, and another saying serial0, and now I honestly don’t know what ttyAMA0 even is.
minimalmodbus.NoResponseError: No communication with the instrument (no answer)
minimalmodbus.InvalidResponseError: Checksum error in rtu mode: 'x8ax1f' instead of 'x0exc4' .
What’s the difference and which one do I want?
Von English mit KI übersetzt ·
Ist ttyAMA0 so etwas wie USB? Ich dachte immer, ACM/USB-Namen seien für USB.
Is ttyAMA0 a USB thing? I always thought ACM/USB names were for USB.
Von English mit KI übersetzt ·
Nicht USB. Ich hatte einmal instabiles Modbus auf einem Pi 3, und ein Teil der Lösung war, console=serial0,115200 aus cmdline.txt zu entfernen, weil die Login-Konsole den Port mitbenutzte. Ob das dein ganzes Problem ist, weiß ich aber nicht.
Not USB. I had flaky Modbus on a Pi 3 once and part of the fix was taking console=serial0,115200 out of cmdline.txt, the login console was sharing the port. Not sure that’s your whole problem though.
Von English mit KI übersetzt ·
Emilys Hinweis ist ein Teil davon. Der Rest ist das UART-Durcheinander beim Pi 3, das alle erwischt.Der Pi 3/4/Zero W hat zwei UARTs. ttyAMA0 ist der PL011, der gute mit eigenem Takt. ttyS0 ist der Mini-UART, dessen Baudrate aus dem Takt des VPU-Kerns abgeleitet wird. Wenn sich der Kerntakt ändert, driftet die Baudrate, und genau dann bekommst du deine CRC-Fehler im Verhältnis eins zu fünf. Bei diesen Modellen ist der PL011 standardmäßig mit dem integrierten Bluetooth verbunden, und der GPIO-Header bekommt den Mini-UART. /dev/serial0 ist ein Alias, der immer auf denjenigen zeigt, der auf GPIO14/15 liegt.Je nach Konfiguration hast du also entweder mit dem Bluetooth-Chip oder mit dem Mini-UART gesprochen. Gib den PL011 dem Header zurück:
# /boot/firmware/config.txt (Bookworm)
enable_uart=1
dtoverlay=disable-bt
sudo systemctl disable hciuart
# und console=serial0,115200 aus /boot/firmware/cmdline.txt entfernen
sudo reboot
Öffne dann /dev/serial0 in deinem Skript, damit es auch bei einem Wechsel auf ein anderes Modell weiter funktioniert. Du verlierst das integrierte Bluetooth, was du in einer Zählerstand-Box aber nicht vermissen wirst.Falls du Bluetooth brauchst, wäre die andere Option core_freq=250, um den Takt für den Mini-UART festzusetzen, aber ich hätte lieber den PL011.
Emily’s bit is part of it. The rest is the Pi 3 UART shuffle, which catches everyone.
The Pi 3/4/Zero W have two UARTs. ttyAMA0 is the PL011, the good one with its own clock. ttyS0 is the mini UART, whose baud rate is derived from the VPU core clock, so when the core clock moves the baud drifts and you get exactly your one-in-five CRC errors. On those models the PL011 is wired to the onboard Bluetooth by default and the GPIO header gets the mini UART. /dev/serial0 is an alias that always points at whichever one is on GPIO14/15.
So depending on your config you were either talking to the Bluetooth chip or to the mini UART. Give the PL011 back to the header:
# /boot/firmware/config.txt (Bookworm)
enable_uart=1
dtoverlay=disable-bt
sudo systemctl disable hciuart
# and remove console=serial0,115200 from /boot/firmware/cmdline.txt
sudo reboot
Then open /dev/serial0 in your script, so it keeps working if you move to another model. You lose onboard Bluetooth, which on a meter-reading box you don’t miss.
If you need Bluetooth, the other option is core_freq=250 to pin the clock for the mini UART, but I’d rather have the PL011.
Von English mit KI übersetzt ·
disable-bt plus das Entfernen der Konsole hat es gelöst. 600 Abfragen über Nacht, null CRC-Fehler, null Timeouts. Ich war auf ttyAMA0 und habe offenbar mit … nichts Brauchbarem gesprochen, und das Skript fiel auf Wiederholungsversuche zurück, die manchmal erfolgreich waren. Ich habe auf serial0 umgestellt. Kevin, ttyAMA ist die ARM-PL011-Benennung, nicht USB.
disable-bt plus removing the console did it. 600 polls overnight, zero CRC errors, zero timeouts. I was on ttyAMA0 talking to… nothing useful apparently, and the script fell back to retries that sometimes hit. Changed it to serial0. Kevin, ttyAMA is the ARM PL011 naming, not USB.
- Du musst angemeldet sein, um auf dieses Thema antworten zu können.
Mitdiskutieren
Melde dich an, um Fragen zu stellen und zu beantworten, hilfreiche Beiträge mit „Gefällt mir“ zu markieren und die Antwort zu kennzeichnen, die dein Problem gelöst hat. Jeder Beitrag bringt Punkte und Stufen.

