Discussion :

[hary66]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[Sve@r]

Salut

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

Ouais, je crois me souvenir...

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...

[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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 ?

[Sve@r]

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.

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 bash :

Sélectionner tout - Visualiser dans une fenêtre à part

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

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...

[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.

[Flodelarab]

Bonjour

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[Sve@r]

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...
Mais printf lui il est de moi

[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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 !

[Sve@r]

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 )

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.

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")...

[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 !


Ces 2 commandes fonctionnent pareil !

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[Sve@r]

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

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

[hary66]

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 ?

[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]

[hary66]

[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 !

[Sve@r]

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 )...

[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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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/

[Sve@r]

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

Tant qu'à faire, autant faire complet

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.

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?

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.

[Flodelarab]

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[N_BaH]

peut-on "corriger" automatiquement ainsi :

Code BASH :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[disedorgue]

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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