Traduit de English par IA ·
Pi 3B+, Raspberry Pi OS Bookworm, un HAT RS485 sur le connecteur GPIO. Un script Python avec minimalmodbus interroge un compteur d’énergie triphasé en 9600 8N1, adresse 5, et publie les kW et kWh vers Hermetry toutes les minutes.Problème : environ une requête sur cinq échoue. Soit un timeout, soit une erreur CRC. Le même compteur, connecté à mon ordinateur portable via une clé USB-RS485, répond à chaque fois. Mon script ouvre /dev/ttyAMA0 parce que c’est ce que l’exemple du fabricant du HAT utilisait. Ensuite, j’ai lu un message sur un forum conseillant ttyS0, un autre conseillant serial0, et honnêtement je ne sais plus ce qu’est ttyAMA0.
minimalmodbus.NoResponseError: No communication with the instrument (no answer)
minimalmodbus.InvalidResponseError: Checksum error in rtu mode: 'x8ax1f' instead of 'x0exc4' .Quelle est la différence et lequel dois-je utiliser ?
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?
Traduit de English par IA ·
ttyAMA0, c’est un truc USB ? J’ai toujours pensé que les noms ACM/USB étaient réservés à l’USB.
Is ttyAMA0 a USB thing? I always thought ACM/USB names were for USB.
Traduit de English par IA ·
Pas l’USB. J’ai eu une liaison Modbus instable sur un Pi 3 une fois, et une partie de la solution a été de retirer console=serial0,115200 de cmdline.txt, car la console de connexion partageait le port. Je ne sais pas si cela explique tout ton problème.
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.
Traduit de English par IA ·
Le point d’Emily fait partie du problème. Le reste, c’est le jeu de permutation des UART du Pi 3, qui piège tout le monde.Les Pi 3/4/Zero W disposent de deux UART. ttyAMA0 est le PL011, le bon, avec sa propre horloge. ttyS0 est le mini UART, dont le débit en bauds est dérivé de l’horloge du cœur VPU ; quand l’horloge du cœur varie, le débit dérive, et c’est exactement ce qui provoque vos erreurs CRC une fois sur cinq. Sur ces modèles, le PL011 est par défaut relié au Bluetooth intégré et l’en-tête GPIO reçoit le mini UART. /dev/serial0 est un alias qui pointe toujours vers celui qui se trouve sur GPIO14/15.Donc, selon votre configuration, vous parliez soit à la puce Bluetooth, soit au mini UART. Rendez le PL011 à l’en-tête :
# /boot/firmware/config.txt (Bookworm)
enable_uart=1
dtoverlay=disable-bt
sudo systemctl disable hciuart
# et supprimez console=serial0,115200 de /boot/firmware/cmdline.txt
sudo rebootEnsuite, ouvrez /dev/serial0 dans votre script, pour que tout continue de fonctionner si vous passez à un autre modèle. Vous perdez le Bluetooth intégré, ce qui, sur un boîtier de relevé de compteurs, ne vous manquera pas.Si vous avez besoin du Bluetooth, l’autre option est core_freq=250 pour figer l’horloge du mini UART, mais je préfère nettement le 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 rebootThen 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.
Traduit de English par IA ·
disable-bt plus la suppression de la console ont réglé le problème. 600 interrogations pendant la nuit, zéro erreur CRC, zéro timeout. J’étais sur ttyAMA0 et je communiquais apparemment avec… rien d’utile, et le script basculait sur des tentatives qui réussissaient parfois. Je suis passé à serial0. Kevin, ttyAMA est la désignation ARM PL011, pas 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.
- Vous devez être connecté pour répondre à ce sujet.
Rejoignez la discussion
Connectez-vous pour poser et répondre à des questions, aimer les messages utiles et marquer la réponse qui a résolu votre problème. Chaque contribution rapporte des points et des niveaux.