Encore en proie à des difficultés de communication sur port sériel/USB

Version imprimable

Voir 40 message(s) de cette discussion en une page

29/06/2022, 15h45
hary66

1 pièce(s) jointe(s)

Encore en proie à des difficultés de communication sur port sériel/USB

Bonjour

Pour communiquer avec certaines machines, j'ai une liaison RS232/USB physique entre une linux box (RPi) et les dites machines.
Un exemple de protocole peut être trouvé dans la doc en PJ :

Je suis quasiment certain avoir utilisé depuis un terminal une commande du style :

Code:

cat < /dev/ttyUSB0

ou quelque chose de très approchant pour lire ce qui m'arrivait sur ce port

Idem pour y écrire des commandes style commandes AT depuis un autre terminal:

Code:

echo S > /dev/ttyUSB0

Or, je n'arrive à rien lire en retour pour le moment.

J'ai pu faire quelques tests concluant depuis le serialmonitor de l'IDE Arduino, mais je voudrais ne pas dépendre de cet IDE car je ne sais pas comment est mis en forme ce que j'envoie et comment est décodé ce qui est reçu.

A la fin, je souhaite envoyer/recevoir des commandes/réponses depuis un script Python et cela refuse de fonctionner. Je pense qu'il y a des histoires d'encodage qui interfère dans la mise en forme correcte des messages.
29/06/2022, 16h11
Sve@r

Salut

Citation:

Envoyé par hary66

A la fin, je souhaite envoyer/recevoir des commandes/réponses depuis un script Python

Ouais, je crois me souvenir...

Citation:

Envoyé par hary66

Je suis quasiment certain avoir utilisé depuis un terminal une commande du style cat < /dev/ttyUSB0 ou quelque chose de très approchant pour lire ce qui m'arrivait sur ce port

Alors à priori ta commande est bonne (une redirection en inférieur permet de récupérer les données d'un fichier). Toutefois en lisant la doc que tu joins, le truc demande d'abord une commande avant de répondre (page 3 paragraphe 1.C "Responses are sent from the scale each time a command is received."). Donc il faut d'abord envoyer une commande avant de récupérer la réponse. Et la commande doit être je pense formatée nickel.

De plus, là c'est pas indiqué, mais je présume que la réponse se fait sur une ligne. Or pour lire une ligne, on n'utilise pas "cat" mais "read".
Donc au lieu d'appeler cat </dev/tyUSB0, je pense qu'il vaudrait mieux appeler read reponse </dev/tty/USB0 et ce, après lui avoir envoyé une commande.
Par ailleurs, là encore dans la doc, je vois "Each command must end with CR LF characters.". Donc ton echo ... ne peut pas fonctionner ; enfin ne peut pas être vu comme "commande" car sous Linux, une ligne se termine par LF et non CRLF. La solution serait de convertir ce que tu envoies via "unix2dos".

Donc pour résumer, il faudrait d'abord envoyer la commande de cette façon: echo commande |unix2dos >/dev/tty/USB0 avant de lire la réponse via read reponse </dev/tty/USB0...
29/06/2022, 16h49
hary66

Et oui, je peine vraiment pour arriver à mes fins !

Il semble y avoir une réaction en effet avec ces nouvelles commandes.
Cependant si je prends une commande simple "SI" qui doit renvoyer une pesée de la balance, je reçois ES qui signale que la commande n'a pas été comprise par la balance.

Qu'y a t-il en caractère de fin de commande ?
Si j'envoie

Code:

echo SI | unix2dos >/dev/tty/USB0

, la balance dois recevoir SI\n\r pour comprendre la commande.(Each command must end with CR LF characters)
Si elle ne comprend pas, elle renvoie ES. Et c'est ce que je reçois.

Avec

Code:

echo SI >/dev/tty/USB0

, idem, la réponse est ES !

Un autre appareil avec lequel je communique par l'intermédiaire d'un microcontrôleur que j'ai programmé (et qui répond correctement à mes requête lors des tests avec le serialMonitor de l'IDE Arduino) me renvoie des caractères incompréhensibles ! Je suis en train de penser que c'est peut être une histoire de baud rate Je suis en 115200 avec de micro ! Peut on paramétrer le baud rate au niveau de la commande read ?
29/06/2022, 17h38
Sve@r
Citation:

Envoyé par hary66

Si j'envoie echo SI | unix2dos >/dev/tty/USB0, la balance dois recevoir SI\n\r pour comprendre la commande.(Each command must end with CR LF characters)
Si elle ne comprend pas, elle renvoie ES. Et c'est ce que je reçois.

Déjà c'est pas '\n\r' mais '\r\n'. Ensuite il existe la commande "od" qui te montre ce qu'elle reçoit sous forme "dump" (pratique pour debugguer). Et enfin tu peux passer par "printf" beaucoup plus fin que "echo" => printf "%s\r\n" "SI" |od -c => 0000000 S I \r \n => printf "%s\r\n" "SI" >/dev/ttyUSB0.

Citation:

Envoyé par hary66

Peut on paramétrer le baud rate au niveau de la commande read ?

Absolument pas. Ca se paramètre via "stty" qui est un outil de configuration => stty 115200 ou stty -i 115200 (la seconde ne modifie que l'input). Mais c'est un coup à te foutre en l'air ta console (après si t'es en environnement de bureau c'est pas grave, tu la fermes et tu en ouvres une nouvelle).
Donc d'abord récupérer le speed courant via stty speed puis le modifier, lire la réponse et remettre le speed tel qu'il était.
Code:

1 2 speed=$(stty speed) stty -i 115200; read reponse </dev/ttyUSB0; stty -i speed
Citation:

Envoyé par hary66

Cependant si je prends une commande simple "SI" qui doit renvoyer une pesée de la balance

D'après la doc, cette commande "send" (donc pour moi "envoie") une info, elle n'est pas prévue pour demander une réponse en retour. Tu pourrais essayer "BN" qui est "donne le type de balance" et qui, là, semble donc demander un truc...
29/06/2022, 17h46
disedorgue

On peut spécifier le device à configurer avec stty --file=/dev/tty/USB0 par exemple.

Et on peut voir déjà la config du device via stty -a --file=/dev/tty/USB0.

Bonjour :coucou:

Code:

1
2
3
4
5
6
7
8
9
$ printf "%s\r\n" "SI" |od -c
0000000   S   I  \r  \n
0000004
$ echo -e "SI\r" |od -c
0000000   S   I  \r  \n
0000004
$ echo -en "SI\r\n" |od -c
0000000   S   I  \r  \n
0000004

Tout ça, sans unix2dos.

30/06/2022, 09h37
Sve@r

Citation:

Envoyé par Flodelarab

Tout ça, sans unix2dos.

Ah "echo -e" j'y avais pensé mais je ne savais pas qu'il intégrait le "\r" (remarque après coup, pourquoi ne l'aurait-il pas intégré ???). "echo -en" je ne connaissais pas...8-)
Mais printf lui il est de moi ;)
30/06/2022, 09h51
hary66

Bon, il y a vraiment des subtilités avec ces histoires de CR et LF

En fait la doc du fabriquant indique bien : "Each command must end with CR LF characters"

Sauf que : pour que ma balance comprenne mes commandes, je dois lui envoyer :

Code:

printf "%s\n" "S" > /dev/ttyUSB0

Comme vous le voyez, je dois supprimer le \r ou CR, sinon la balance me répond avec un ES qui veut dire qu'elle n'a pas compris la commande

En clair, la commande printf "%s\r\n" "SI" > /dev/ttyUSB0 sensée être correctement mise en forme ne semble pas l'être ! Il y a semble t-il un caractère fantôme supplémentaire envoyé !

Un soucis supplémentaire est que selon ce que j'utilise pour communiquer sur /dev/ttyUSB0, entre terminal, IDE Arduino ou mon code Python, je n'ai jamais les mêmes comportements !
Avec Arduino par exemple, je fais fonctionner la balance et mon microcontrôleur avec le même paramétrage.
Depuis le terminal, j'ai réussi à faire fonctionner la balance mais pas le micro, même en tripatouillant les paramètres !
30/06/2022, 10h24
Sve@r

Citation:

Envoyé par hary66

En fait la doc du fabriquant indique bien : "Each command must end with CR LF characters"

Exact, je l'ai vu aussi (et quand Svear dit qu'il l'a vu, alors c'est que cela est 8-))

Citation:

Envoyé par hary66

Sauf que : pour que ma balance comprenne mes commandes, je dois lui envoyer :
"printf "%s\n" "S" > /dev/ttyUSB0"
Comme vous le voyez, je dois supprimer le \r ou CR, sinon la balance me répond avec un ES qui veut dire qu'elle n'a pas compris la commande

Intéressant, d'autant plus que printf "%s\n" "truc" est totalement équivalent à echo "truc" (printf "%s\n" "truc" |md5sum et echo "truc" |md5sum) sauf qu'il me semblait à tes premiers posts que ça ne fonctionnait pas.

Citation:

Envoyé par hary66

Il y a semble t-il un caractère fantôme supplémentaire envoyé !

Pas possible (regarde l'exemple de Flodelarab et tente tes propres essais avec "od -c")...
30/06/2022, 10h49
hary66

@ Sve@r
J'ai édité ma réponse précédente (ajout)

En fait, la commande "echo "S" > /dev/ttyUSB0" fonctionne.
Je pense que je n'avais pas réglé le BAUD rate du terminal correctement lors des premiers essais ! Arf !:oops:

Ces 2 commandes fonctionnent pareil !

Code:

pi@raspberrypi:~ $ printf "%s\n\r" "SI" > /dev/ttyUSB0pi@raspberrypi:~ $ printf "%s\n" "SI" > /dev/ttyUSB0

Par contre celle-ci renvoi que des "ES" (commande non comprise !

Code:

printf "%s\r\n" "PC" > /dev/ttyUSB0
30/06/2022, 11h26
Sve@r

Citation:

Envoyé par hary66

Je pense que je n'avais pas réglé le BAUD rate du terminal correctement lors des premiers essais ! Arf !:oops:

Ouais, c'est pas un truc auquel on pense forcément au départ.

Pour tes soucis Python, tu devrais essayer la même solution (entre un envoi echo shell et un print() Python il y a peu de différence). Accessoirement va voir ici. Après faudra poster dans le fofo Python 8-)
30/06/2022, 11h50
hary66

1 pièce(s) jointe(s)

Par contre, je me demande pourquoi je reçois tant de "ES" indiquant des commandes mal comprises alors que je n'envoie qu'une seule commande à la fois, et que je reçois une réponse au format prévu de la doc de la balance.

C'est comme si ma commande était suivie de caractères parasites ?

Pièce jointe 621629
30/06/2022, 12h02
Flodelarab

[hypothèse] C'est un port série. Il lit une commande à intervalles réguliers. Quand tu n'envoies rien, il ne comprend pas et te renvoie "ES\r\n". [/hypothèse]
30/06/2022, 12h06
hary66

Citation:

Envoyé par Flodelarab

[hypothèse] C'est un port série. Il lit une commande à intervalles réguliers. Quand tu n'envoies rien, il ne comprend pas et te renvoie "ES\r\n". [/hypothèse]

Que neni !
Après chaque commande, je reçois la réponse et et en suivant quelques '"ES" dont le nombre semble aléatoire !
30/06/2022, 12h14
Sve@r

Citation:

Envoyé par hary66

C'est comme si ma commande était suivie de caractères parasites ?

Ca pourrait pas être le "manque de \r" ??? Si la doc en parle (avec un gros signe "warning" devant) c'est que quelque part c'est important...
Tu veux pas réessayer un unique printf "%s\r\n" "SI" ? Après avoir réglé le baud ça devrait être plus sympa (peut-être aussi avec un RAZ préalable pour purger /dev/usb de tes 500 milliards de tests précédents 8-))...
30/06/2022, 12h21
hary66
Qu'entends tu par un RAZ ?
Sur le terminal ou sur la balance ?

Ces 2 commandes fonctionnent pareil ! Notez l'inversion du \n\r par rapport à la doc ! Et quand j'utilise l'IDE Arduino pour envoyer mes commande je demande d'ajouter NL et CR. Je ne peux observer dans quel ordre c'est rajouté, mais c'est présenté comme cela !
Code:

1 2 3 pi@raspberrypi:~ $ printf "%s\n\r" "SI" > /dev/ttyUSB0 pi@raspberrypi:~ $ printf "%s\n" "SI" > /dev/ttyUSB0
Par contre celle-ci renvoi que des "ES" (commande non comprise !

Code:

printf "%s\r\n" "PC" > /dev/ttyUSB0

Ces info nous sont données pour travailler depuis une machine Windows à priori (touche return = CR+LF)
Or je suis sur un *nix dont la touche return = LF
N'y a t-il pas un truc à voir dans cette direction ? https://danielmiessler.com/study/crlf/
30/06/2022, 12h52
Sve@r

Citation:

Envoyé par hary66

Qu'entends tu par un RAZ ?
Sur le terminal ou sur la balance ?

Tant qu'à faire, autant faire complet

Citation:

Envoyé par hary66

Notez l'inversion du \n\r par rapport à la doc !

Attention, la doc dit "CRLF". CR c'est Carriage Return ou '\r'. LF c'est "Line Feed" ou '\n'. CRLF c'est bien '\r\n'. Et c'est aussi comme ça que le positionne dos2unix.

Citation:

Envoyé par hary66

Ces info nous sont données pour travailler depuis une machine Windows à priori (touche return = CR+LF)

Oui, ça c'est une hypothèse à prendre en considération. Tu n'aurais pas un zindow disponible par hasard?

Citation:

Envoyé par hary66

N'y a t-il pas un truc à voir dans cette direction ? https://danielmiessler.com/study/crlf/

C'est juste un peu de vulgarisation historique. Tu as la même chose en français ici https://fr.wikipedia.org/wiki/Carriage_Return_Line_Feed. Il donne certaines astuces pour transformer les terminaisons d'un monde dans l'autre (sans les compléter car il n'y a pas NIX->ZINDOW) mais rien de nouveau (ah si, sous mac c'est ni CRLF ni LF mais CR et ça je savais pas). Mais printf est assez fin pour tout gérer correctement.
30/06/2022, 14h04
Flodelarab
Pour rappel, un résumé. (cliquez ici)
Code:

1 2 3 4 $ echo -en "SI\r\n" |od -c -tx2 0000000 S I \r \n 4953 0a0d 0000004
Notez que l'organisation en 32 bits fait apparaître 0A0D, alors qu'on sait que l'ordre réel est 0D0A. Et 0D, c'est \r; 0A, c'est \n.

:question: peut-on "corriger" automatiquement ainsi :

Code:

1
2
3
4
5
6
$ read end < <(echo -n I | od -o)
$ ((${end:${#end}-1:1})) && end=big || end=little
$ printf 'SI\r\n' |od -cx --endian=$end
0000000   S   I  \r  \n
           5349    0d0a
0000004

:question:

30/06/2022, 17h05
disedorgue
Citation:
Envoyé par Flodelarab

Pour rappel, un résumé. (cliquez ici)

Code:

1 2 3 4 $ echo -en "SI\r\n" |od -c -tx2 0000000 S I \r \n 4953 0a0d 0000004

Notez que l'organisation en 32 bits fait apparaître 0A0D, alors qu'on sait que l'ordre réel est 0D0A. Et 0D, c'est \r; 0A, c'est \n.
-c c'est du caractère pas du long, donc son équivalent en hexa est -tx1 et non pas -tx2 :
Code:

1 2 3 4 $ echo -en 'SI\r\n' | od -c -tx1 0000000 S I \r \n 53 49 0d 0a 0000004

Voir 40 message(s) de cette discussion en une page