Bonjour!!
 
Je suis toujours sur la création d'un petit logiciel embarqué, et je dois faire en sorte de scruter en permanence le port série afin de reagir lorsque quelque chose arrive dessus, mais en même temps je dois réaliser d'autres fonction.. en gros le "scrutage" du port serie doit etre comme une tache de fond... faut-il pour ceci créer un thread ou y a t'il d'autres solutions??  
 
si on doit faire un thread, comment fait-on pour le créer et l'utiliser???
 
 
Merci!!
 
 
ps: je suis sous windows et je code sous turbo C++
 
barucca

oui crée un thread. c'est quoi ta plateforme ?

http://www.google.fr/search?hl=fr& [...] %3Dlang_fr ?

je suis sous windows .. merci pour le lien, je vais voir, mais j'avais deja regarde et je trouve que c'est pas tres bien expliqué et souvent les exemples sont sous linux... je ne sais pas si c'est different pour windows ou pas..

euh.. question bete... ou puis-je telecharger pthread.h?? apparemment je l'ai pas sur mon ordi.. sinon savez vous où il est sensé se trouver sur l'ordi???

tu peux utiliser un portage des pthreads (posix threads) sous windows
http://sources.redhat.com/pthreads-win32/
 
ou utiliser directement l'api windows
http://msdn.microsoft.com/library/ [...] hreads.asp

arf... en fait je me suis mal exprimée .... le programme que je fais doit fonctionner sous un environnement dos.... c'est toujours possible ou pas du tout?? si oui avec quoi?

lol ! non c'est trop vieux dos, pas de multitache
 
bienvenu dans le present

lol.. ben j'ai pas trop de choix sinon ca serait pas celui la c'est sur!! donc pas de thread sous dos?? en fait je ne fais que charger l'exe sur le module en dos, je programme sous windows avec turbo C++..

Et avec les interruptions ? Sous Dos, ça serait élégant ça non ?
 
Dès qu'un truc arrive sur le port série, le programme s'interrompt, on exécute ce qu'il faut exécuter pis le programme reprend ! Pas besoin de scruter en permanence comme cela !

j'y avais pas pensé..... pkoi pas!! je vais chercher des infos la dessus!! merci!!

 
Plus qu'élégant, c'est indispensable

salut!
 
je ne sais pas trop comment faire avec les interruptions... imaginons que l'interruption int86 soit dans la fonction comm_in, comment je peux faire pour réaliser en même temps ma fonction d'analyse : analyse_trame et la fonction comm_in??
 
en gros, il faudrait que même quand j'analyse ma trame la port série soit "scruté" da facon a réagir s'il reçoit quelque chose...
 
 
merci!!

He ben fais l'analyse et la reception dans deux threads différents

ben justement si j'ai bien compris les interruptions c'est pour pas utiliser de thread car le module de reception est sous DOS, non??

Ha oui exact, au temps pour moi, je m'étais fié au premier post.
http://www.beyondlogic.org/serial/serial1.htm#30

En fait, tu as 2 problèmes   !
- Il est *obligatoire* de traiter l'interruption déclenchée lors de chaque réception de caractère (COM1 : IRQ 4 - Int 0x0C / COM2 : IRQ 3  - Int 0x0B). Les fonctions offertes par l'Int 0x14 sont inutilisables en pratique. Ceci compris, soit tu écris toi-même la routine de traitement de l'interruption, soit tu recherches une bibliothèque de fonction.
- Le traitement de l'interruption n'est pas suffisant ! Lorsque le CPU sous DOS se trouve en traitement d'interruption, il faut faire très attention à ce que l'on fait. Beaucoup de traitements sont interdits sous peine de planter le PC (ou bien la machine virtuelle DOS de Windows). Sous interruption on se contente généralement de stocker les caractères reçus dans un buffer (fifo) pour le traitement par la boucle principale du programme.
 
En (très) simplifié, le programme ressemblerait à ça :

Les noms "serial.h, SERIAL, ComOpen(), ...etc." sont fictifs. Je ne sais pas comment ils s'appelleront dans la bibliothèque que tu aura trouvée en finale (soyons optimistes !).
L'exemple montre que :
(1) On initialise le port série. Cette fonction installe un gestionnaire pour les interruptions
(2) Boucle principale du soft (quelque part, il faudra un "break" ou un "exit()" )
(3) A chaque passage dans la boucle, on vérifie si des caractères sont en attente (mémorisés par le gestionnaire d'interrupt)
(4) Sur une condition de ton soft, tu émets des caractères (buf et nbr à affecter dans ton soft)
(5) Les autres tâches de ton soft sont exécutées ici.
N.B : Les autres taches ne doivent jamais garder le contrôle trop longtemps sinon le buffer interne de réception des caractères risque de déborder !
 
En conclusion, écrire "à la main" un gestionnaire d'interrupt est assez balaise (l'adresse donnée par Ace17 en donne une idée) et je recommande de chercher des fonctions déjà écrites.
Qqu'un sait où en trouver ?

j'en ai un sous dos, mais pour rs485 ecrit avec mes mimines - c'est pas super super; cela dit, il n'y a que peu de différence avec le rs422, et il fonctionne (testé).
 
Si ça interesse...

ben je veux bien , tout exemple est bon a prendre!!