Comme notre ami davidif semble opaque à la lecture .... voilà en dessin (pour la réception en interruption) :
-----
Comme notre ami davidif semble opaque à la lecture .... voilà en dessin (pour la réception en interruption) :
Ca y est , ça fonctionne ...
J'arrive donc bien à transmettre mes infos d'un côté comme de l'autre, et en faite c'est un peu la chat qui ce mordait la queue.
car sur la télécommande, j'affiche une valeur qui est susceptible de bouger via le clavier de celle-ci (transmis aussitôt en tx) et également la réception de cette même valeur via l'UART rx et donc l'un prenait le pas sur l'autre, je sais pas si je suis claire désolé.
Côté carte principal (PIC32MX795F512L, équipé d'un module wifi stack tcpip) sous harmony, j'ai commencé par mettre des interruptions sur mon UART rx et tx, seulement ça me bloquait tout je ne sais pas pourquoi, j'ai très certainement pas fait tout dans les règle de l'art n'étant pas un programmeur née (mais j'y travail ( , en fin de compte, j'ai donc inibé les interruptions et la tout fonctionne correctement, désolé ça va faire grincé quelques dents .
Puis du côté de ma télécommande filaire ( PIC18F26K20 sous "code configurator" ) J'ai donc utilisé les interruptions
Donc maintenant, je change donc mes valeurs dans les deux sens
Le lien n'est apparemment pas bon, maintenant désolé pour l'opacité, j'essai pourtant d'être claire mais tout ne les déjà pas pour moi (:Comme notre ami davidif semble opaque à la lecture .... voilà en dessin (pour la réception en interruption) :
Pièce jointe 320957
Bonjour, Je reviens sur cette fonction qui malgré tout présente quelques bug, quand j'envoi une valeur celle-ci est bien pris en compte d'un côté comme de l'autre, seulement la notion de règles de communication doit m'échapper quelque peu, mon problème vient du faite que quand j'échange une valeur ça marche, mais quand j'ai plusieurs valeurs différentes seulement quelques une sont prise en compte, et là ça bug.
mes trame pour une valeur, sont de cette ordre : FA 01 32 F0
FA : marque mon début de trame d'une valeur
01 : ID de la valeur
32 : la valeur
F0 : fin de trame
Donc quand j'envoi ou reçois cette trame, celle-ci est bien comprise, le problème est quand j'envoi plusieurs valeurs
FA 03 46 F0 FA 02 23 F0 FA 01 19 F0
en mode debug, j'arrive bien à tout réceptionner dans un tableau placé dans une interruption de réception mais quand il s'agit de récupérer les valeurs une a une pour les traiter, il y a certainement quelque chose dans ma condition qui fonctionne pas et je ne sais pas quoi pour l'instant
Code:else if(PIE1bits.RCIE == 1 && PIR1bits.RCIF == 1) { EUSART_Receive_ISR(); buffer_rx[j]=RCREG; // pour essai et voir tout ce qui est reçu dans un tableau j++; // boucle de récupération par valeur if (RCREG==debut) flag_debut=1; if (flag_debut) { i++; if (i==2) ID_buffer=RCREG; if (i==3) val_buffer=RCREG; if (i==4) { i=0; flag_debut=0;} } }
et là je prend en compte mes valeurs et les attribu en fonction de les ID
Code:void rx_data (void) { ID=ID_buffer; val_rx=val_buffer; switch(ID) { case 0x01 : val.Gdome = val_rx; break; case 0x02 : val.Pdome = val_rx; break; case 0x03 : val.tempo = val_rx; break; case 0x04 : val.securite = val_rx; break; default : break; } }
Merci pour votre aide
sauf que ta valeur peut prendre la valeur 0xFA ou 0xF0 donc : cacophonie !
Il faut envoyé ta valeur en BCD :
0xFA 0x31 0x33 0x32 0xF0
Et utiliser 0xF0 et 0xFA comme start/stop, c'est pas futé. il faut utiliser 0x0A et 0x0D
Je n'ai pas regardé ton soft, je me déclare incompétent depuis 2005
Merci de ta contribution à mon problème,sauf que ta valeur peut prendre la valeur 0xFA ou 0xF0 donc : cacophonie !
Il faut envoyé ta valeur en BCD :
0xFA 0x31 0x33 0x32 0xF0
Et utiliser 0xF0 et 0xFA comme start/stop, c'est pas futé. il faut utiliser 0x0A et 0x0D
Je n'ai pas regardé ton soft, je me déclare incompétent depuis 2005
En fait, j'ai fait un starte/stop FA et F0 , car mes valeurs ne peuvent pas prendre FA et F0.
Mes valeurs vont de 0 à 100 max et n'iront pas jusqu'à FA=250 et F0=240
et qu'effectivement sans raisonner en BCD mais en hexa j'ai donc construit ma trame en hexa pour cette raison.
Je pense mal raisonner sur ma récupération,
C'est dommage ...
Avec du BCD, tu visualisais directement sur un espion (HyperTerminal par exemple) ce qui se passait sur tes trames. le seul inconvénient? la vitesse pour transmettre 0x32 il faut deux octets 0x33 et 0x32 . Mais vu la densité d'infos que tu transmets ...
ok, mes j'ai un soft qui récupère directement mes trames, certes en en hexa, mais je visualise
Et comment gères-tu le flux de données? La gestion de flux peut passer par les signaux RTS (Request TO Sens) et CTS (Clear To Send) s'ils sont gérés. Si non il faut le faire dans le protocole, le destinataire devrait renvoyer un code pour indiquer qu'il est prêt à accepter le message suivant.
Bonjour,Et comment gères-tu le flux de données? La gestion de flux peut passer par les signaux RTS (Request TO Sens) et CTS (Clear To Send) s'ils sont gérés. Si non il faut le faire dans le protocole, le destinataire devrait renvoyer un code pour indiquer qu'il est prêt à accepter le message suivant.
je ne gère pas les autres informations du bus (cts, rts,...) juste le rx et tx .
J'arrive à échanger une trame d'une valeur pour la traiter, mais quand j'ai plusieurs valeurs qui arrivent j'ai quelques problèmes de réception, je fais pourtant la détection et réception des valeurs buffer (ID, Valeurs), puis dans mon main réattribue les valeurs dans un "switch case".
Tu utilises la méthode du FIFO (voir #61) ? Non .