Mélange port série, C++ et boost::asio

Mélange port série, C++ et boost::asio - C++ - Programmation

Marsh Posté le 01-05-2009 à 18:41:58    

Bonjour :hello:  
 
J'ai un problème un peu compliqué vu que ca mélange l'accès au port série sous Windows, du C, et tout ca avec Matlab. Je ne sais d'ailleurs pas trop dans quelle catégorie poster :/
Je vais donc essayer d'etre le plus clair possible.
 
Contexte :
Le but c'est de piloter un robot à partir d'un ordinateur embarqué (EeePC).  
L'ordinateur communique avec un microcontroleur qui gère les moteurs (pour lire le déplacement du robot et envoyer des consignes) via un port série (COM3).
On utilise Matlab pour faire tout ca parceque c'est pratique pour développer/debugger.
 
Le problème :
Les fonctions de lecture/ecriture sur port série de Matlab sont trop longues. On a peu de données à transmettre mais les appels aux fonctions de lecture/écriture sont fréquent. L'idéal serait de pouvoir lire et écrire toutes les 5ms, actuellement la durée d'execution des fonctions empeche de descendre sous les 10ms par cycle lecture/écriture.
 
J'ai d'abord réécrit les fonctions de lecture/écriture en C avec les fonctions WriteFile et ReadFile d'après une source trouvée et à l'aide de la MSDN (Outre les fonctions "mex" propres à Matlab c'est du C normal) :

Code :
  1. #include <mex.h>
  2. #include <Windows.h>
  4. // serial_write.c
  5. // Simple Matlab command to write to a serial port
  6. // This is needed because Matlab's serial commands frequently crash
  7. //
  8. // Originally written 2009 April 15 by Kevin Barry
  9. // This code is entered into the Public Domain and may be freely used for
  10. // any purpose.
  11. // This code is provided "AS IS", without express or implied warranty
  12. // of any kind.
  14. HANDLE hCom = NULL;
  16. void closeSerial()
  17. {
  18.     CloseHandle(hCom);
  19.     hCom = NULL;
  20. }
  22. void openSerial(char *portname, int baud)
  23. {
  24.     char portname_w32[255];
  25. /*COMMCONFIG lpCC;
  26.     COMMTIMEOUTS lpTo;
  27.      
  28. */
  29.     DCB parametres;
  30.     COMMTIMEOUTS timings;
  31.    
  32.     // Win32 can't open >= COM10 with "COM10"
  33.     // Needs to be \\.\COM10
  34.     sprintf(portname_w32, "\\\\.\\%s", portname);
  35.    
  36.     if (hCom != NULL) {
  37.         mexWarnMsgTxt("Already have an open port, closing first" );
  38.         closeSerial();
  39.     }
  41.     hCom = CreateFile(portname_w32, GENERIC_READ | GENERIC_WRITE,
  42.                         0, NULL, OPEN_EXISTING, 0, NULL);
  44.     mexAtExit(closeSerial);
  46.     if (hCom == INVALID_HANDLE_VALUE) {
  47.         hCom = NULL;
  48.         mexErrMsgTxt("Could not open serial port" );
  49.     }
  50.    
  51.     parametres.DCBlength = sizeof(DCB);
  52.     GetCommState(hCom, &parametres);
  53.    
  54.     parametres.fBinary = TRUE;
  55.     parametres.fParity = TRUE;
  56.     parametres.fOutxCtsFlow = FALSE;
  57.     parametres.fOutxDsrFlow = FALSE;
  58.     parametres.fDtrControl = DTR_CONTROL_DISABLE;
  59.     parametres.fRtsControl = RTS_CONTROL_DISABLE;
  60.     parametres.fOutX = FALSE;
  61.     parametres.fInX = FALSE;
  62.     parametres.fErrorChar = FALSE;
  63.     parametres.fAbortOnError = FALSE;
  64.    
  65.     parametres.BaudRate = baud;
  66.     parametres.ByteSize = 8;
  67.     parametres.Parity = 3; //0-4=no, odd, even, mark, space
  68.     parametres.StopBits = 2; //0,1, 2=1,1.5, 2
  69.            
  70.     SetCommState(hCom, &parametres);
  71.    
  72.     GetCommTimeouts(hCom, &timings);
  73.    
  74.     timings.ReadIntervalTimeout = 2;
  75.     timings.ReadTotalTimeoutMultiplier = 1;
  76.     timings.ReadTotalTimeoutConstant = 0;
  77.     timings.WriteTotalTimeoutMultiplier = 0;
  78.     timings.WriteTotalTimeoutConstant = 2;
  79.    
  80.     SetCommTimeouts(hCom, &timings);
  81.    
  82.     SetupComm(hCom, 1024, 1024);
  83. }
  85. void mexFunction (int nlhs, mxArray *plhs[],
  86.                               int nrhs, const mxArray *prhs[])
  87. {
  88.     char action;    //0 Ouvrir, 1 Lire, 2 Ecrire, 3 Fermer
  89.     char data[1024];
  90.     int num;
  91.     int i;
  92.     unsigned char *sortie;
  93.                    
  94.     action = (char)mxGetScalar(prhs[0]);
  95.    
  96.     switch(action)
  97.     {
  98.         case 0 : //Ouvrir             
  99.            /* eg. openSerial("COM3", 262144) */
  100.             openSerial(mxArrayToString(prhs[1]), (int)mxGetScalar(prhs[2]));
  101.             break;           
  102.         case 1 : //Lire
  103.             num = (char)mxGetScalar(prhs[1]);
  104.             num = readSerial(data, num);
  105.            
  106.             plhs[0] = mxCreateNumericMatrix(1, num, mxUINT8_CLASS, mxREAL);
  107.             sortie = mxGetData(plhs[0]);
  108.             for (i=0; i<num; i++)
  109.                 sortie[i] = data[i];
  110.             plhs[1] = mxCreateDoubleScalar(num);
  111.             break;           
  112.         case 2 : //Ecrire
  113.             num = (int)mxGetScalar(prhs[2]);
  114.             mxGetString(prhs[1], data, num+1); //Récupère letableau de char à envoyer
  115.             plhs[0] = mxCreateDoubleScalar(writeSerial(data, num)); //Renvoi le nb d'octets écrits à Matlab
  116.             break;
  117.         case 3 : //Fermer
  118.             closeSerial();
  119.             break;
  120.         default :
  121.             mexWarnMsgTxt("Mauvais code,\n0:Ouvrir\n1:lire\n2:Lire\n3:Fermer" );
  122.             break;
  123.     }
  124.     return;
  125. }
  127. int writeSerial(char *str, int n)
  128. {
  129.     DWORD bytesWritten;
  131.     if (hCom == NULL)
  132.         mexErrMsgTxt("Cannot write. Open serial port first" );
  134.     if ( WriteFile(hCom, str, n, &bytesWritten, NULL) ) {
  135.         return bytesWritten;
  136.     } else {
  137.         char err_str[128];
  138.         sprintf(err_str, "Could not write %d", GetLastError());
  139.         mexErrMsgTxt(err_str);
  140.     }
  141.     return 0;
  143. }
  145. int readSerial(char *buffer, int num)
  146. {
  147.     DWORD nLus;
  148.    
  149.     if (hCom == NULL)
  150.         mexErrMsgTxt("Cannot write. Open serial port first" );
  152.     ReadFile(hCom, buffer, num, &nLus, NULL);
  153.     //return nLus;
  154. }


 
J'ai énormément gagné en vitesse d'écriture (~1ms pour executer la fonction), par contre en lecture ca a explosé, dans les 14ms en moyenne pour lire.
 
Je me suis dit que je pourrais passer sur un Windows CE (qui est "temps réel" ) pour gagner en rapidité mais je ne pense pas que je vais gagner grand chose.
 
Question :
Qu'est-ce que je peux faire pour réduire le temps de lecture ?
Aussi, la lecture a un comportement étrange, une fois que tout le buffer a été lu, ca me renvoit quand même des valeurs plus ou moins aléatoires :??:  
 
Et question pour les connaisseurs :
Le fichier C est compilé par Matlab qui en fait un fichier binaire serialrw.mex. Pour l'utiliser j'écrit quelque chose comme ca dans la commande de Matlab :

Code :
  1. serialrw(0, 'COM3', 262144)
  2. serialrw(2, char([65 66 67]), 3)
  3. serialrw(1, 3)

Mais comment il se passe le handle du port COM entre les appels  :??:


Message édité par Dagnir le 08-05-2009 à 13:13:52

---------------
Nous vous souhaitons de beaux rêves, c'est le cinéma gratuit.
Reply

Marsh Posté le 01-05-2009 à 18:41:58   

Reply

Marsh Posté le 01-05-2009 à 18:54:08    

boost::asio fourni une base propre pr la gestion de ce genre d epériphérique. J'ai posté un bout de code C++ pr l'attaque du port série.

Reply

Marsh Posté le 08-05-2009 à 00:26:01    

D'abord un grand merci  :jap:  
J'aurai mis le temps mais j'ai réussis à utiliser boost::asio pour communiquer avec mon microcontrolleur par le port série, en utilisant le code que tu a posté fin 2008.
 
J'ai quand même quelques questions :whistle: (qu'il vaut peut etre mieux que je pose sur ton topic ?)
 
Le microcontroleur à qui j'envoi des valeurs ne voit pas passer les codes ascii des lettres que j'envoie mais des valeurs déacalées.
Exemple, si j'envoi  
Aa'\n'
le microC voit 193 225 138 au lieu de 65 97 10 13.
 
Par contre si le microC envoie 193 225 138 asio l'interprète bien comme "Aa\n" dans la console.  
D'où peut venir ce décalage ?
 
 
Pour le fonctionnement en général, j'ai du mal à saisir quand s'effectuent les lecture/écriture.
 
Le programme attend que j'aie rentrée une chaine (cin.get(ch)), la met dans ch et envoie ch au port série (c.write(ch)).
Mais ch est déclaré comme simple char donc comment il peut transmettre toute la chaine ?

Message cité 1 fois
Message édité par Dagnir le 08-05-2009 à 12:09:30

---------------
Nous vous souhaitons de beaux rêves, c'est le cinéma gratuit.
Reply

Marsh Posté le 08-05-2009 à 05:46:05    

cin >> ch mange un caractére et rend la main sans bufferisation. Tu boucle la dessus tant que la conenction ets up. la chaine est donc passé char par char.
 
j'ai peu d'xp avec les mC je pourrais pas t'aider plus :€

Reply

Marsh Posté le 08-05-2009 à 11:48:35    

C'est ce que j'aurais pensé, mais j'ai une lumière qui s'allume quand des données passent sur le port série, et elle ne s'allume pas quand j'appuie sur une touche quelconque mais seulement quand j'appuie sur entrée (ce qui a aussi pour effet d'envoyer un 138, au lieu d'un 10 ou 13).  
Je vais investiguer  [:columbo2]  
 
Bon sinon c'était plus pour comprendre le programme vu qu'en vrai je vais juste envoyer des séries d'entiers calculées par un autre programme, j'aurai pas besoin de l'i/o de la console.
Edit : à ce propos, le c.write(ch) n'aceppte donc q'un char à la fois. Il y aurait pas un truc pour envoyer un tableau de valeurs d'un coup ? J'ai pas encore benché le ce code mais il faut vraiment que je gratte des millisecondes sur les appels de fonction.
 
Ce qui m'interesserait plus ce serait de savoir si je peux ouvrir le port en partageant, pour faire la lecture dans un programme et l'écriture dans un autre. Je vais déjà aller voir la doc pour ca :)
 
Edit 2 :
J'ai testé ce code

Code :
  1. #include "stdafx.h"
  2. #include <iostream>
  4. using namespace std;
  5. int _tmain(int argc, _TCHAR* argv[])
  6. {
  7. char ch;
  8. cin.get(ch);
  9. printf("%d\n", ch);
  11. return 0;
  12. }

et ca donne quelquechose comme :

Code :
  1. ABCD
  2. 65
  3. 66
  4. 67
  5. 68
  6. 10

Meme résultat avec cin >> ch
Ca me parait surprenant mais bon. A noter que ca donne bien les valeurs ascii.
Edit 4 ( :D ) :
Y avait ca dans le code

Code :
  1. // on Unix POSIX based systems, turn off line buffering of input, so cin.get() returns after every keypress  
  2. // On other systems, you'll need to look for an equivalent  
  3. #ifdef POSIX
  4. termios stored_settings;
  5. tcgetattr(0, &stored_settings);
  6. termios new_settings = stored_settings;
  7. new_settings.c_lflag &= (~ICANON);
  8. new_settings.c_lflag &= (~ISIG); // don't automatically handle control-C  
  9. tcsetattr(0, TCSANOW, &new_settings);
  10. #endif

Que j'ai enlevé. Mais je veux quand meme bien qu'on m'explique comment un char peut stocker la chaine retournée.
 
Ce qui me gène plus c'est le décalage de qui donne +128 aux valeurs ascii dans le programme asio.
J'ai testé aussi, si le port COM recoit 193 (65+128), ca affiche "A"
S'il recoit 65, il affiche "A^" (où ^ est en fait un triangle fermé).
 
Edit 3 : Ou alors c'est un problème de bit de parité qui perturbe tout  [:columbo2]


Message édité par Dagnir le 08-05-2009 à 13:18:39

---------------
Nous vous souhaitons de beaux rêves, c'est le cinéma gratuit.
Reply

Marsh Posté le 08-05-2009 à 14:52:26    

je penche pr la parité en effet

Reply

Marsh Posté le 08-05-2009 à 16:55:09    

Heu, je soupconne que passer stopbits à 2 pourrait aider, j'ai trouver ca http://think-async.com/Asio/boost_ [...] _bits.html, mais je vois pas du tout quoi écrire dans le code, C plus plus caÿ dur [:ramones]
Juste pour etre sûr, c'est ce code là que j'ai repris  
http://forum.hardware.fr/forum2.ph [...] w=0&nojs=0


---------------
Nous vous souhaitons de beaux rêves, c'est le cinéma gratuit.
Reply

Marsh Posté le 09-05-2009 à 00:38:06    

Dagnir a écrit :


Aa'\n'
le microC voit 193 225 138 au lieu de 65 97 10 13.
 
Par contre si le microC envoie 193 225 138 asio l'interprète bien comme "Aa\n" dans la console.  
D'où peut venir ce décalage ?


 
char != unsigned char
 
De rien  [:fanou]

Reply

Marsh Posté le 09-05-2009 à 01:18:28    

J'y ai pensé ( :o ), mais la fonction write d'asio prend un char donc de ce coté c'est fixé.
De l'autre coté si je met les données dans un unsigned char 'A' me donne 193, si je met dans un char ca me donne -65. Donc je suis toujours bloqué, sauf si je retranche 128 systématiquement à tout ce que lit le microC, mais ca fait pas vraiment propre.
 
J'ai regardé avec le debugger, la valeur que prend ch avant d'etre envoyé par c.write(ch) c'est bien le code ASCII de ce que je tape dans la console donc c'est pas un problème de cout/cin.
 
Je crois que mon microC prend deux bits de stop exclusivement alors que la valeur par défaut en général c'est 1, ca pourrait expliquer un bit de poids fort toujours à 1. Mais j'aarrive pas à trouver de tutoriel/exemple qui montre comment le changé.
J'ai tenté de mettre

Code :
  1. boost::asio::serial_port_base::stop_bits::stop_bits  (one)

en début de main mais il me dit "one : undeclared identifier". J'avoue que j'ai un peu de peine avec le C++, j'ai encore du mal à comprendre comment certaines lignes peuvent fonctionner.


Message édité par Dagnir le 09-05-2009 à 01:19:08

---------------
Nous vous souhaitons de beaux rêves, c'est le cinéma gratuit.
Reply

Marsh Posté le 09-05-2009 à 01:47:07    

le stop_bit est une option a apssé à set_option ...

Reply

Marsh Posté le 09-05-2009 à 01:47:07   

Reply

Marsh Posté le 09-05-2009 à 01:50:23    

C'est quoi comme micro ? Quel compilateur/libc ?  
Tu utilises un "OS" ou tu joues directement avec les registres de l'uart ?
 
 

Reply

Marsh Posté le 09-05-2009 à 01:51:38    

on s'en tape un peu. Monsieur a juste à apprendre à appeler une méthode sur un objet, ASIo fera le reste :o

Reply

Marsh Posté le 09-05-2009 à 01:59:19    

Je ne pense pas qu'asio tourne sur les PIC 8 bits, que je soupçonne le monsieur d'utiliser :o

Reply

Marsh Posté le 09-05-2009 à 02:00:47    

asio est utilisé du coté du PC [:prozac] ...

Reply

Marsh Posté le 09-05-2009 à 02:07:16    

Le problème ne se situe plus que probablement pas côté pc [:spamafoote]

Reply

Marsh Posté le 11-05-2009 à 13:14:26    

Bon, après tatonnement j'ai trouvé une syntaxe qui a l'air de marcher.
J'ai rajouté

Code :
  1. boost::asio::serial_port_base::parity par(boost::asio::serial_port_base::parity::none);
  2. serialPort.set_option(par);
  4. boost::asio::serial_port_base::character_size taille(boost::asio::serial_port_base::character_size::character_size(8));
  5. serialPort.set_option(taille);
  7. boost::asio::serial_port_base::stop_bits  stopbits_option(boost::asio::serial_port_base::stop_bits::two);
  8. serialPort.set_option(stopbits_option);

dans la classe minicom_client  
 
Apparemment c'était plus le character size qui posait problème, il devait pas être à 8 par défaut.


---------------
Nous vous souhaitons de beaux rêves, c'est le cinéma gratuit.
Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed