Changer mode parité RS232

[invite983e93dd]

Bonjour,

J'ai besoin de modifier la valeur du bit de parité au cours de mes échanges via le port RS232 avec un périphérique particulier.
Le développement est réalisé en visual C++.

Le principe que je dois mettre en place est que je dois communiquer sur 9 bits, le bit de parité pouvant servir de 9ème bit étant donné qu'il porte l'information du mode d'adressage du périphérique.

Je dois donc envoyer une information en mode adresse (avec le 9ème bit positionné à 1), puis une trame d'information en mode data (avec le 9ème bit positionné à 0).

J'ai donc essayé après l'ouverture du port com de modifier à la volée le bit de parité en utilisant MARKPARITY (9ème bit à 1) et SPACEPARITY (9ème bit à 0) avec la fonction SetCommState.

Comme cela n'était pas concluant, j'ai regardé le résultat à oscilloscope et je constate que lorsque je change de mode de parité via SetCommState, l'envoi se fait sur la base du dernier mode SetCommState paramétré. J'ai fait plusieurs essais, si j'envoie deux données en mode adresse avec change du SetCommState entre les deux envois se font bien en mode adresse, si je fais la même chose en mode data, les deux envois sont en mode data.

Si je change de mode entre les deux, l'envoi des deux données se fait avec le dernier mode positionné.

J'ai donc tenté une pause, de réduire le buffer déclaré, une purge (PurgeComm), cela ne donne rien, j'ai toujours le même comportement au final.

Existe-t-il une fonction particulière ou une méthode pour faire cela ? Je pensais à ouvrir et fermer le port com entre chaque envoi.

Avez-vous une piste ?

Merci de votre aide.
-----

[invite983e93dd]

J'ai avancé.

En faisant un Ouvrir port et fermer port lorsque j'ai besoin de changer le mode de parité, cela fonctionne.
Par contre j'ai 18 ms de délais entre mes deux messages, je ne sais pas encore si c'est bloquant pour mon matériel.
J'ai tenté de réduire au minimum ce temps mais il semble que ce soit incompressible sauf s'il existe une astuce pour faire prendre en compte ce changement sans cette ouverture / fermeture.

J'ai vu un programme en Delphi qui savait le faire sans ouverture / fermeture, y a-t-il une librairie de port com dédiée ?

[bisou10]

Salut Furbean,

Longtemps que je n'ai pas utilisé de port COM sous Visual C++, tu es a quelle baudrate ? 18ms, ca me parait logique, mais ca ne sera par exemple pas gênant si tu es à 9600 bds. Par contre effectivement à 115k...

[polo974]

Le pb est que la data passe par la fifo, mais la commande de changement de parité, non, donc c'est une bidouille infâme qui va fonctionnouiller durant le développement et risquer de lamentablement planter lors du déploiement en production...
A moins de disposer d'une commande pour connaître l'état de la fifo de sortie pour contrôler la chose...

[A voir en vidéo sur Futura]

[invite983e93dd]

Merci pour vos retours.

Je suis à 9600 baud.
Merci pour l'information sur la fifo, je vais creuser dans ce sens là.

[inviteb9f49292]

donc c'est une bidouille infâme

Je ne suis donc pas le seul à qui ça fait dresser les cheveux sur la tête... Bricoler (là c'est même détourner) des standards est très rarement une bonne idée, et mène très souvent à des solutions foireuses, fallait que ça sorte...

Je ne connais absolument pas l'univers microsoft, donc je ne développerai pas dans ce sens. En revanche, sous *ix (linux, macos...), l'interface "termios" est plus souple car tu configures ta liaison lorsqu'elle est ouverte. Maintenant je ne suis pas certain que:
- le délais disparraisse, si il est dû à la configuration effective de la parité et non à l'ouverture du pilote
- comme le souligne Polo974, il y aura un problème de synchonisation entre le basculement de ton bit de parité et le caractère / trame auquel il intervient, c'est peut être solvable grâce tcdrain / tcflow

[polo974]

Je ne suis donc pas le seul à qui ça fait dresser les cheveux sur la tête... Bricoler (là c'est même détourner) des standards est très rarement une bonne idée, et mène très souvent à des solutions foireuses, fallait que ça sorte...

... c'est peut être solvable grâce tcdrain / tcflow

C'est peut-être ce que fait implicitement le close, qui fait que ça marchouille, mais c'est à vérifier (mais comment ???)...
Bref, c'est une galère...

[invite0bbe92c0]

Je ne suis donc pas le seul à qui ça fait dresser les cheveux sur la tête... Bricoler (là c'est même détourner) des standards est très rarement une bonne idée, et mène très souvent à des solutions foireuses, fallait que ça sorte...

Je ne connais absolument pas l'univers microsoft, donc je ne développerai pas dans ce sens. En revanche, sous *ix (linux, macos...), l'interface "termios" est plus souple car tu configures ta liaison lorsqu'elle est ouverte. Maintenant je ne suis pas certain que:
- le délais disparraisse, si il est dû à la configuration effective de la parité et non à l'ouverture du pilote
- comme le souligne Polo974, il y aura un problème de synchonisation entre le basculement de ton bit de parité et le caractère / trame auquel il intervient, c'est peut être solvable grâce tcdrain / tcflow

La question de l'OS me semble peu impactante, la gestion de la parité se faisant au niveau du chips de controle de l'interface RS232C (j'en susi resté au 8253, mais il doit y avoirt plus moderne de nos jours).

J'aimerai bien que le posteur initial nous explique le pourquoi de son bidouillage sur le bit de parité car je n'arrive pas vraiment à comprendre le besoin fonctionnel ici.

[invite0bbe92c0]

J'ai donc essayé après l'ouverture du port com de modifier à la volée le bit de parité en utilisant MARKPARITY (9ème bit à 1) et SPACEPARITY (9ème bit à 0) avec la fonction SetCommState.

Je ne me suis jamais amusé à ce genre de bricole (si je devais le faire, je pense que je me dirais à la base que le problème est sans doute mal posé ....) mais as tu essayé avec SetCommConfig ? (dans ce cas, il me semble que les buffer sont purgés).

Je maintiens ma question initiale : c'est quoi cette transmission à 9 bits de données ?

[Jack]

La question de l'OS me semble peu impactante, la gestion de la parité se faisant au niveau du chips de controle de l'interface RS232C (j'en susi resté au 8253, mais il doit y avoirt plus moderne de nos jours).

J'aimerai bien que le posteur initial nous explique le pourquoi de son bidouillage sur le bit de parité car je n'arrive pas vraiment à comprendre le besoin fonctionnel ici.

Ah, la mémoire ...
Le 8253 est un timer. Pour la liaison série, c'est plutôt 8250/8251 chez intel. Enfin, ce sont des circuits qui commencent un peu à dater

[inviteb9f49292]

La question de l'OS me semble peu impactante,

Je ne sais pas, si Windows impose de fermer le port avant de pouvoir reconfigurer le contrôleur... ce que j'avais cru comprendre mais j'ai peut-être lu trop vite. Mais si c'est le cas, sous linux la gestion est différente puisqu'il faut que le port soit ouvert pour le configurer...

Pour la liaison série, c'est plutôt 8250/8251 chez intel. Enfin, ce sont des circuits qui commencent un peu à dater

Pas forcement, je croise des coeurs ARM avec des contrôleurs type 8250 ou 16550 (sont descendant): les registres sont aux mêmes adresses et je pense que c'est cette famille sur les PC classiques, j'irai jeter un oeil... En gros l'API n'a pas changée, mais c'est sûr que l'implémentation s'est améliorée (conso / vitesse...)

[bisou10]

Oui ce sont des 1655x sur les PCs... qui en ont encore un: les ports série ont disparus de la plupart des cartes mères

[Jack]

Pas forcement, je croise des coeurs ARM avec des contrôleurs type 8250 ou 16550 (sont descendant): les registres sont aux mêmes adresses et je pense que c'est cette famille sur les PC classiques

Je sais bien, je faisais juste référence au circuit cité précédemment (8253) qui ne correspondait pas à la bonne fonction.

[invite0bbe92c0]

Je sais bien, je faisais juste référence au circuit cité précédemment (8253) qui ne correspondait pas à la bonne fonction.

Le pire est que je pense pourtant que tu te trompes : si on excepte le cas très particulier des RS232C des PC/Mac, incomplètes car n'opérant qu'en mode asynchrone, je suis presque sur que les machines avec lesquelles j'ai travaillé pendant une dizaine d'années (des Convergent Technologies) utilisaient bien des 8253 (ou 8254 ?) pour gérer les RS232C : le coté timer est indispensable pur une RS232C normale puisqu'elle peut opérer des protocoles synchrones (encore une fois le cas des PC/Mac est particulier et constitue une réduction de la norme - la meilleure preuve étant que certains PC avaient des RS232C sur des connecteurs DB9 alors qu'une RS232C complète ne peut pas être opérée avec seulement 9 signaux).

[invite0bbe92c0]

Je ne sais pas, si Windows impose de fermer le port avant de pouvoir reconfigurer le contrôleur...

Non.

ce que j'avais cru comprendre mais j'ai peut-être lu trop vite.

Sans doute.

Mais si c'est le cas, sous linux la gestion est différente puisqu'il faut que le port soit ouvert pour le configurer...

Je ne connais pas Linux; ce fil m’a permis d'apprendre qu'il ne s'agit pas uniquement du firmware un peu léger qui équipe les écrans sondeur/gps/radar de mon bateau; mais je pensais que la reconfiguration du port impliquait un cold start de la machine suivi d'un bon coup de pied dedans, je suis content d'apprendre que ce n'est pas le cas.

[Jack]

si on excepte le cas très particulier des RS232C des PC/Mac, incomplètes car n'opérant qu'en mode asynchrone

???? Tu connais une RS232 qui fonctionne en mode synchrone? Ca irait à l'encontre de la norme.

suis presque sur que les machines avec lesquelles j'ai travaillé pendant une dizaine d'années (des Convergent Technologies) utilisaient bien des 8253 (ou 8254 ?)

La présence d'un timer n'est pas très surprenante, mais pour faire de la liaison asynchrone ça l'est plus.

le coté timer est indispensable pur une RS232C normale puisqu'elle peut opérer des protocoles synchrones

Encore une fois, tu as un problème avec la norme. La 232 travaille en asynchrone uniquement.

la meilleure preuve étant que certains PC avaient des RS232C sur des connecteurs DB9 alors qu'une RS232C complète ne peut pas être opérée avec seulement 9 signaux

Il est vrai qu'un UART ne peut gérer tous les signaux de la norme. Je n'ai d'ailleurs jamais eu l'occasion de voir l'électronique gérant une RS232 complète. Je serais intéressé par un exemple.

[polo974]

C'est pas dur de voir que les 8253 et 54 sont des timers (vive le net...). et le 8250 est l’ancêtre des uarts de la galaxie du PC, on retrouve même ce nom dans les drivers linux, ou si on veut déclarer plus de 4 uarts au boot, il suffit d'ajouter 8250.nr_uarts=8 pour en avoir 8 (si le hard est derrière, bien sûr).

Le rs232 complet sur 25 broches comporte en théorie 2 liaisons séries, je n'en ai jamais rencontré...
Mais c'est asynchrone, pas de transport d'horloge de prévu...

Le truc spécifique sous dos et windows est qu'ils ont tordu la norme pour faire une sorte de contrôle de flux avec dsr/dtr, alors qu'il y avait rts/cts qui n'attendaient que ça pour le faire...

D'un autre coté, l'usage du rs232 a aussi été détourné dès le début, vu qu'il était sensé faire le lien entre un mode et un télétype (une sorte de machine à écrire connectée).

Les 8250 n'avaient pas de fifo, les suivants (16550A, etc...) en ont très souvent, et c'est ça qui peut poser problème ici...

[invite0bbe92c0]

???? Tu connais une RS232 qui fonctionne en mode synchrone? Ca irait à l'encontre de la norme.

Non, le RS232 c'est synchrone; la RS232C "réduite" c'est une habitude des architectures PC (d'ailleurs une RS232 compléte ne peut pas utiliser un connecteur DB9).

Concernant les puces, je me suis trompé compltement, (la mémoire......) c'était des 8259A.

Encore une fois, tu as un problème avec la norme. La 232 travaille en asynchrone uniquement.

Encore une fois c'est faux. Quelle était la connectique des modems syncrhone jusqu'à 19200 Bauds ? Du rS232 "normal", pas PC. (connectiques utilisée pour le X25, le BSC 2780/3780, le SNA3270, etc .... tout ça utilisait du RS232 et opérait en synchrone).

[Jack]

Je viens de jeter un œil sur des articles de référence, notamment de l'avis V24 qui caractérise la définition des circuits. Cet avis laisse en effet la possibilité de transmettre en synchrone et en asynchrone. On avait donc tort tous les deux.

Pour le 8259, c'est un contrôleur d'interruption. De mémoire, c'est celui qui était implanté sur les cartes mères des premiers PC, du temps où il fallait affecter les interruptions lorsqu'on ajoutait un nouveau périphérique.