Tu peux effectivement faire comme tu proposes : 2 threads, un specialisé dans la gestion de ttyS, l'autre dans la GUI. Eviter d'envoyer des trames ttyS a partir de la GUI : preferer une bonne vieille synchro pour reveiller le thread ttyS a partir de la GUI afin de lui faire transmettre les donnees sur le port serie (message queue posix, ou plus simplement write dans la GUI / select au niveau du thread ttyS). Comme ca le thread GUI ne s'occupe que des fenetres et pas des subtilites de l'acces au ttyS, le thread ttyS gere tout seul comme un grand le port serie, et il n'y a de facto pas de probleme de synchro sur le port serie puisque c'est le thread ttyS qui centralise et regule tous ces acces.
Mais c'est un peu lourdingue, il n'y a pas besoin de sortir l'artillerie lourde pour ca. Une GUI, c'est ni plus ni moins qu'une boucle d'evenements. Il suffit donc de faire entrer les evenements ttyS dans cette boucle. En plus comme on est en multitache cooperatif dans ce cas, on n'a pas a craindre les acces concurrents sur le port serie. Par exemple, si la gui est en gtk, on utilisera g_main_add_poll/g_source_add de la glib. Presque tous les toolkits graphiques permettent de rajouter des file descriptors dans la boucle.
# Un classique...
Posté par David Decotigny . En réponse au message Port serie, Asynchrone, Thread. Évalué à 1.
Mais c'est un peu lourdingue, il n'y a pas besoin de sortir l'artillerie lourde pour ca. Une GUI, c'est ni plus ni moins qu'une boucle d'evenements. Il suffit donc de faire entrer les evenements ttyS dans cette boucle. En plus comme on est en multitache cooperatif dans ce cas, on n'a pas a craindre les acces concurrents sur le port serie. Par exemple, si la gui est en gtk, on utilisera g_main_add_poll/g_source_add de la glib. Presque tous les toolkits graphiques permettent de rajouter des file descriptors dans la boucle.