[Structure] Conseils pour l'implementation d'un protocole sur RS232 ?

Version imprimable

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

14/07/2008, 09h01
Tymk

[Structure] Conseils pour l'implementation d'un protocole sur RS232 ?
Salut,

Je dois implementer, sous windows XP, un protocole de securite a partir des specifications fournies par le constructeur. Mon programme se limite a la communication avec un validateur d'acces (interface supportant scanners retiens, scanners d'empreintes, ...)

La communication se fait par liaison serie RS232 mais je devrais apres la porter sur reseau Ethernet (pour controler plusieurs validateurs d'acces).

Suite a la lecture des 700 pages de specifications et aux tests realises, je peux dire que le protocole n'a plus de secrets pour moi :

Les paquets sont de tailles variables mais l'en-tete contient la longueur du paquet. Bien qu'il semble y avoir un type de paquets qui n'a pas d'en-tete mais dont la taille est fixe. :?
Les paquets de donnees sont relativement petits. (fixons le relatif a 100 octets)

La connexion est un "3 ways handshake" avec echange de paquets de synchronisation et d'acknowledgement.
Avant de me lancer dans l'implementation, j'aimerais savoir par ou commencer et comment structurer le programme :
:fleche: Dois-je utiliser une liaison serie en mode synchrone/asynchrone ? Avec ou sans thread de reception ?

:fleche: La manipulation des paquets via basic_string<unsigned char> est-elle viable ?

:fleche: Cette structure vous semble-t-elle correcte :
- Une classe RS232 responsable des fonctions de lecture/ecriture sur le peripherique serie. (+/- couche physique)
- Une classe STREAM responsable de la recuperation de l'integralite d'un paquet. (+/- couche liaison de donnees)
- Une classe PROTOCOL responsable de l'exctraction/insertion des informations a recevoir/envoyer. (+/- couche application)
Merci de me faire part de vos conseils.

Bonjour,

quelques conseils en vrac:

-> de façon générale, le mode asynchrone pour le port série est déconseillé car trop difficile à gérer et le mode synchrone est suffisant dans l'immense majorité des cas.

-> généralement, la méthode pour l'écriture/lecture utilisée est la suivant:
--> on envoie une trame (écriture)
--> on lit la réponse dans une boucle avec un nombre d'essai déterminé pour éviter la boucle infinie.

Cette méthode a l'avantage déviter d'utiliser un thread (comme toujours, si on peut faire simple, c'est mieux).

-> pour l'utilisation des string, je ne vois pas de problème, au contraire. Au niveau le plus bas, tu es tout de même obligé de manipuler des tableaux de char, mais la classe string de la SL fourni tout ce qu'il faut pour passer de l'un à l'autre.

-> ton design me semble bien à première vue. Il est cependant difficile d'en dire plus avec si peu de détails.

Si ça peut aider, je te copie une classe que j'utilise souvent pour la couche basse (lecture/écriture sur le port série). Ne fonctionne que pour Windows:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 // SerialPortManager.h #include <windows.h> class SerialPortManager { public: SerialPortManager(){} ~SerialPortManager(); bool OpenPort( int port ); void FlushPort(); int Read( unsigned char * buffer, int buffLen ); void Write( const unsigned char * buffer, const int buffLen ); void ClosePort(); private: HANDLE m_hCom; };
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 #include "SerialPortManager.h" #include <sstream> SerialPortManager::~SerialPortManager() { ClosePort(); } bool SerialPortManager::OpenPort( int port ) { std::stringstream device; device << "COM"; device << port; m_hCom = CreateFile ( device.str().c_str(), GENERIC_READ | GENERIC_WRITE, 0, NULL, OPEN_EXISTING, 0, NULL ); if ( m_hCom == INVALID_HANDLE_VALUE ) { //TODO: gestion erreur return false; } DCB dcb; ZeroMemory(&dcb, sizeof(DCB)); COMMTIMEOUTS timeouts; dcb.DCBlength = sizeof(DCB); dcb.ByteSize = 8; dcb.Parity = NOPARITY; dcb.StopBits = ONESTOPBIT; dcb.BaudRate = CBR_38400; dcb.fRtsControl = RTS_CONTROL_DISABLE; dcb.fDtrControl = DTR_CONTROL_DISABLE; if ( GetCommTimeouts( m_hCom, &timeouts ) == 0 ) { //TODO: gestion erreur return false; } timeouts.ReadIntervalTimeout = MAXDWORD; if ( SetCommTimeouts( m_hCom, &timeouts) == 0 ) { //TODO: gestion erreur return false; } if ( SetCommState( m_hCom, &dcb) == 0 ) { //TODO: gestion erreur return false; } return true; } void SerialPortManager::FlushPort() { DWORD nChar = 1; BYTE cInBuf [8]; while ( nChar >0 ) ReadFile( m_hCom, cInBuf, 1, &nChar, NULL); } int SerialPortManager::Read( unsigned char * buffer, int buffLen ) { int nbRetry = 5; int nbCharRead = 0; int countFailed = 0; DWORD nChar = 0; while ( countFailed < reintentos ) { ReadFile( m_hCom, &buffer[nbCharLeido], 1, &nChar, NULL ); if ( nChar > 0 ) { nbCharRead +=nChar; } else { countFailed++; Sleep( 100 ); } } return nbCharRead; } void SerialPortManager::Write( const unsigned char * buffer, const int buffLen ) { DWORD nChar = 0; if ( WriteFile( m_hCom, buffer, buffLen, &nChar, NULL) == 0 ) { // TODO: gestion erreur } } void SerialPortManager::ClosePort() { std::cout << "ClosePort" << std::endl; CloseHandle( m_hCom ); }
Hope it helps.

14/07/2008, 12h54
yan

Citation:

Envoyé par r0d

Bonjour,

quelques conseils en vrac:

-> de façon générale, le mode asynchrone pour le port série est déconseillé car trop difficile à gérer et le mode synchrone est suffisant dans l'immense majorité des cas.

:koi:
le mode asynchrone est plustôt conseillé...
Avec Qt ça se fait comme une lettre à la poste. Ça à surtout l'avantage de ne pas bloquer l'application lors de la lecture du port.
14/07/2008, 12h57
Tymk

Merci, pour ces precisions.

J'ai regarde ta classe et elle est similaire a celle que je viens tout juste de terminer. Il y a quand meme deux differences que je ne comprends pas :

:fleche: Quelle est l'utilitee du ZeroMemory dans le renseignement de la strucutre DCB ?

:fleche: Quelle est l'utilite de la fonction FlushPort() ? Elle semble lire des octets tant qu'elle en recoit.
14/07/2008, 13h04
Tymk

Citation:

Envoyé par Mongaulois

:koi:
le mode asynchrone est plustôt conseillé...
Avec Qt ça se fait comme une lettre à la poste. Ça à surtout l'avantage de ne pas bloquer l'application lors de la lecture du port.

Pourquoi, le mode asynchrone serait plus indique ? Si je suis les conseils de r0d en faisant n essais de lecture le port se liberera forcement.
14/07/2008, 13h19
yan

Citation:

Envoyé par Tymk

Pourquoi, le mode asynchrone serait plus indique ? Si je suis les conseils de r0d en faisant n essais de lecture le port se liberera forcement.

la lecture sur le port est bloquante, c'est à dire que si il n'y as rien à lire, la lecture va bloquer l'exécution. Donc si tu utilise une thread, tous ton programme est bloqué. Utiliser un thread qui fera la lecture permet de ne pas bloquer le reste. Que la thread se bloque, c'est pas grave puis qu'elle sert à ca.
Si tu as une IHM, c'est pas terrible d'avoir l'ihm qui ne repond plus.

De la même manière, si tu lit beaucoup de donnée, ton application ne fera que ça et va laisser peu de ressource pour le reste=> même problème.
14/07/2008, 13h41
Tymk

Ok, mais je suis plutot de l'avis de r0d : rester simple si possible.

Je pense que je peux m'en sortir de la sorte :

:fleche: Je sais exactement ce que je dois obtenir en lecture car c'est le PC qui interroge l'interface. L'interface ne fait que repondre. Donc, j'envoie mon message et je passe en lecture sur le peripherique pour recuperer la reponse.

:fleche: Si l'interface repond plus vite que le temps necessaire au programme passe de l'ecriture en lecture (ce dont je doute), le driver bufferise les octets.

:fleche: Ensuite, je lis les octets correspondant a l'en-tete de mon paquet. Je connais maintenant la taille exacte du paquet. Je recupere donc le nombre d'octets restants.

:fleche: Pendant ce temps, le programme ne peut rien faire d'autre sans la reponse de l'interface. D'ou l'inutilite du threading.

Fonctionnement non-nominal :

:fleche: Si le programme attend des octets que l'interface n'envoie pas, un timeout sort de la lecture et la requete est renvoyee.

:fleche: Si le programme recupere moins d'octets que ce qu'a envoyee l'interface, le crc permet de detecter l'erreur.

[edit] Mon application n'interagit pas avec un utilisateur [/edit]
14/07/2008, 13h58
yan

Citation:

Envoyé par Tymk

:fleche: Je sais exactement ce que je dois obtenir en lecture car c'est le PC qui interroge l'interface. L'interface ne fait que repondre. Donc, j'envoie mon message et je passe en lecture sur le peripherique pour recuperer la reponse.

:fleche: Pendant ce temps, le programme ne peut rien faire d'autre sans la reponse de l'interface.

:fleche: Si le programme attend des octets que l'interface n'envoie pas, un timeout sort de la lecture et la requete est renvoyee.

Et que pense tu qui va se passé à ton interface pendant c'est periode(en gras)???
=>interface bloqué, non répondante, qui deviens blanc ou autre jusqu'a la recuperation des ressources
Bien sur que tu peut te passé d'une thread pour faire simple. Mais simple ne correspond pas toujours à performant et ce qu'il faut faire...
Aprés ce n'est que mon avis ;)
a toi de voire
14/07/2008, 14h21
Tymk

Pardon, je me suis mal exprime.

Je parlais d'interface pour signifier "validateur d'acces". C'est une interface electronique qui se situe a l'autre bout du cable et a laquelle je ne touche pas. Il ne s'agit pas d'interface graphique. Mon application est autonome.
14/07/2008, 14h59
r0d

Ooops oui pardon, je voulais dire l'inverse :oops:

de façon générale, le mode synchrone pour le port série est déconseillé car trop difficile à gérer et le mode asynchrone est suffisant dans l'immense majorité des cas.

pardon :oops:

Au sujet d'un thread ou non, effectivement tout dépend de savoir si le "blocage" de ton appli est un problème ou non. Dans certains cas, il peut même être souhaitable.

Citation:

Envoyé par Tymk

Quelle est l'utilitee du ZeroMemory dans le renseignement de la strucutre DCB ?

Dans certains cas (en fait je crois presque tout le temps), ça ne fonctionnera tout simplement pas si tu ne le fais pas. Le standard c++ ne précise pas comment doit être initialisée une structure. Ce que je veux dire, c'est que lorsque déclar une structure (lorsque tu en créé uns instance donc), les compilateurs la remplissent n'importe comment. Le ZeroMemory la rempli de 0 (zéro).

Citation:

Envoyé par Tymk

Quelle est l'utilite de la fonction FlushPort() ? Elle semble lire des octets tant qu'elle en recoit.

C'est exactement ça. Cette fonction sert à vider le buffer d'entrée du port serie. Elle est indispensable dans certains cas, mais pas toujours. Par exemple, en ce moment je travail sur une machine qui m'envoie une "preuve de vie": toute les 10 secondes, elle m'envoie un octet (0x00 dans mon cas précis). Je suis donc obligé de vider le buffer (flush) avant chaque envoi/réception de trame. Il y a aussi des machines qui envoie des parasytes, c'est à dire qu'ils envoient de temps en temps des octets "poubelle" sur le port. J'en avais rencontré lorsque je bossait dans la RFID.
14/07/2008, 15h08
Tymk

Ok

Pour le mode asynchrone, il suffit de renseigner le flag ldOverlap ou il y a d'autres modifications a faire dans le code ?

Au passage, r0d, ta classe ouvre un port en mode synchrone, il me semble. :roll:
14/07/2008, 15h31
r0d

Citation:

Envoyé par Tymk

Pour le mode asynchrone, il suffit de renseigner le flag ldOverlap ou il y a d'autres modifications a faire dans le code ?

Je ne sais pas.

Citation:

Envoyé par Tymk

Au passage, r0d, ta classe ouvre un port en mode synchrone, il me semble. :roll:

Mhh, je ne sais plus. Il me semble effectivement qu'il y a deux façon d'utiliser le mot synchrone/asynchrone quand on parle du port serie. Mais je ne sais plus là, vous m'avez perdu :aie:
14/07/2008, 19h01
yan

http://www.developpez.net/forums/sho...d.php?t=582572
14/07/2008, 19h38
wiztricks

protocol -> stream -> RS232
J'aime bien un découpage en 3 couches:

application (7) -> session (4) -> liaison de données (2)

Lorsqu'on va passer de RS232 à Ethernet, ce sera pour supporter plusieurs connexions.
1. Que peut-on faire côté "design" pour limiter les changements à la couche "liaison de données"?
2. Et autoriser la gestion de plusieurs sessions à la fois?
Le fantôme threads ou pas traine toujours dans le décors ;-(
- W

Citation:

Envoyé par Tymk

La manipulation des paquets via basic_string<unsigned char> est-elle viable ?

Attention à être bien sûr que les données qui transitent sur ta liaison RS232 sont sous forme ASCII et non binaire. En effet, en ASCII le '\0' = NULL = 0 terminera la chaîne et ira très bien avec ce container. Mais en binaire, ta trame pourra très bien contenir un 0 qui fera tomber le reste de ta trame aux oubliettes.:D
Attention également aux trames UNICODE, car chaque caractère ASCII imprimable chez nous sera précédé d'un 0 et n'ira donc pas avec ton container.

Sinon, j'ai appris par expérience que l'utilisation d'un nom de flux de type "COMX" pour le CreateFile d'une liaison série est limitée jusqu'au COM9. Si tu veux utiliser un port COM supérieur (possible jusqu'à 255 il me semble), il faut utiliser la notation complète du périphérique série:
Code:

1 2 3 4 5 6 7 8 wsprintf( sz, "\\\\.\\COM%d", portnumber); m_hCom = CreateFile( sz, GENERIC_READ | GENERIC_WRITE, 0, NULL, OPEN_EXISTING, FILE_FLAG_OVERLAPPED, NULL );
Mais soyons honnêtes, tout le monde n'a pas 36 ports COM :D

Enfin, pour ce qui est du thread ou non, tu connais déjà mon avis...:mrgreen:

15/07/2008, 09h56
3DArchi

Quelques conseils a adapté ensuite selon tes envies et besoins:
-> Si ton système est asymétrique (un émetteur et un récepteur), je spécialiserais les classes RS323 et PROTOCOL en deux: une pour l'émission et une pour la réception,
-> Si tu penses ensuite aller sur du IP, tes sockets pourront se situer à ce niveau (PROTOCOL pour TCP, RS232 pour UDP),
-> Personnellement, je préfère le mode asynchrone. Cela permet de garder une certaine dynamique à ton programme: ton système peut encore réagir à l'environnement (IHM, signaux, etc...),
-> Je préfère découper les systèmes avec des flux réseaux en plusieurs thread: un pour la communication, un pour le traitement principal et en poussant le vice, un spécifiquement à l'IHM. Ca semble plus compliqué mais au final c'est plus souple, notamment pour la gestion des erreurs.
Tout ceci est ensuite à adapter aux spécificités de ton système et au temps dont tu disposes pour le développer.
Cordialement.
16/07/2008, 07h14
Tymk

Citation:

Envoyé par spoutspout

Attention à être bien sûr que les données qui transitent sur ta liaison RS232 sont sous forme ASCII et non binaire. En effet, en ASCII le '\0' = NULL = 0 terminera la chaîne et ira très bien avec ce container. Mais en binaire, ta trame pourra très bien contenir un 0 qui fera tomber le reste de ta trame aux oubliettes.:D

Il me semblait que la classe string ne contenait pas de caractere de fin de chaine. En tout cas, j'arrive a envoyer/recevoir des tames en affectant a certains unsigned char la valeur 0x00.

Citation:

Envoyé par spoutspout

Enfin, pour ce qui est du thread ou non, tu connais déjà mon avis...:mrgreen:

Oui, je sais que ce sujet a deja ete discute. Je me suis permis de reposer la question pour collecter plus d'avis. :oops:
16/07/2008, 09h24
Spout
Citation:

Envoyé par Tymk

Il me semblait que la classe string ne contenait pas de caractere de fin de chaine.

Si l'on parle bien de la classe string de la STL, un 0 est placé à la fin de la chaîne du buffer interne. Tu peux le vérifier avec le code suivant:
Code:

1 2 3 4 5 6 7 std::string sEssai; sEssai.push_back('a'); sEssai.push_back('b'); sEssai.push_back(0); sEssai.push_back('c'); sEssai.push_back('d'); sEssai.push_back('e');
En debug, si tu regardes le buffer du string sEssai, tu verras qu'il y a un 0 à la fin des caractères de la chaîne.

Citation:

Envoyé par Tymk

En tout cas, j'arrive a envoyer/recevoir des tames en affectant a certains unsigned char la valeur 0x00.

OK je me suis mal exprimé. Avec l'exemple que je t'ai donné, tu verras qu'effectivement le buffer continue de se remplir après l'ajout du 0. Mais si tu utilises par exemple le code suivant:
Code:

1 2 char sBuffer[10]; sprintf(sBuffer, sEssai.c_str());
tu verras que le .c_str() renvoie une chaîne de caractère qui s'arrête au 0, donc "ab".
L'important es d'être conscient de cette subtilité :D
16/07/2008, 09h53
Tymk

Le point que tu souleves est tres important puisque les fonctions WriteFile et ReadFile demande des pointeurs sur des types constants. (Donc, necessite la conversion vers des chaines C).

Mais, j'ai contourne le probleme en parcourant mon basic_string<unsigned char> et en envoyant/recevant les octets un par un.
16/07/2008, 10h08
wiztricks
Citation:

Envoyé par Tymk

Le point que tu souleves est tres important puisque les fonctions WriteFile et ReadFile demande des pointeurs sur des types constants. (Donc, necessite la conversion vers des chaines C).

Mais, j'ai contourne le probleme en parcourant mon basic_string<unsigned char> et en envoyant/recevant les octets un par un.

ne serait-il pas plus sage de définir une "trame" comme:
Code:

1 2 unsigned char length; // la longueur unsigned char data[MAX_TRAME]; // le contenu.
plutôt que de canibaliser un type qui n'est qu'un tableau de caractère dans lequel 0 à un sens assez particulier?
-W

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