Un octet transmis, c'est environ 11 bits UART en sérieEnvoyé par davidif
Une trame, c'est autant d'octet que tu veux en série
Maintenant, pour identifier ce à quoi se rapporte la trame, tu as X solutions qui sont appropriées à différentes configurations de datas .
Tes datas, c'est du binaire pur et dur ou des caractères ASSCI ?
Tu as combien de data à transmettre ?
J'aime pas le Grec
Bit avec un e c'est très vulgaire....
Le nombre de bits de données c'est généralement 7 ou 8 (pas 9). On peut ajouter un bit de parité et élargir le bit de stop à 1,5 ou 2bits.
Le RS232 est la couche physique d'une communication asynchrone et l'intervalle entre les octets transmis est libre.
La suite ne concerne pas le RS232 mais le protocole utilisé (protocle Xon/Xoff par exemple). Il existe différents types de protocoles.
Merci daudet, d'avoir répondu aussi rapidement
Effectivement comme tu dis une trame c'est 11 à 12 bits à transmettre dont un octet.
Mais que veux tu dire par "une trame c'est autant d'octet que je veux" justement ?
Pour le moment, je n'ai pas beaucoup de données à transmettre, aux nombre de 4 données (celle descrites plus haut), maintenant à l'avenir il ce pourrait que je souhaite transmettre d'autres données, donc peut-être pas me limité.
Informations à transmettre :
puissance 1 dont la valeur varie de 0 à 100
puissance 2 dont la valeur varie de 0 à 100 également
tempo dont la valeur varie de 0 à 60
info de sécurité : binaire 0 ou 1
après sous quel formes les transmettre, ça dépendra du protocole d'échange à mettre en place
Autant pour moi pour la faute
Pour moi, une trame, c'est un bloc d'information composé de X octets
A priori, tu n'as pas grand chose à transférer. Par contre, il faut faire des choix . Soit à transmettre la valeur 69 en décimal ( soit 0x45 en Hexa)
Binaire pur 0 à 255
Un octet : 01000101
Hexa 0 à 255
Deux octets : 01000100 01000101
BCD 0 à 99
Deux octets : 01000110 01001001
Je te déconseille le binaire pur (qui est plus compact), mais donne du chinois si tu mets une console ASCCI sur ta ligne (genre HyperTerminal)
les deux autres méthodes sont similaires. Par contre elles permettent de mettre un caractères "début de trame" (par exemple 0x0D) et un caractères "fin de trame" (par exemple 0x0A)
Donc sur ta console espion, tu auras des belles lignes claires et bien positionnées sur l'écran
De plus, ton soft attend 0x0D (Cr) pour mettre la suite dans un buffer et 0x0A (Lf) pour dire au "main" qu'il a reçu un buffer complet à traiter
Maintenant, tu as intérêt à avoir une trame de longueur fixe. Par exemple
0x0D [deux octets d'identification ] [deux octets data1] [deux octets data2] ..... [deux octets dataN] [Parité ou CRC] 0x0A
Dernière modification par DAUDET78 ; 18/08/2016 à 09h38.
J'aime pas le Grec
HA ok, je comprend !!
en fait, si j'ai bien compris, on va envoyer un octet de début et un octet de fin , ce qui permet d'avoir la longueur de data que l'on souhaite.
et j'évite de prendre en compte les temps entre trames.
merci
Oui, mais ce n'est valable qu'en Hexa ou en BCD . Les caractères 0x0D et 0x0A ne peuvent pas apparaitre au milieu d'une trame
Par contre, en mode Binaire pur , une data qui vaut 10 ou 13 (en décimal) te plante le soft de détection début/fin (on peut contourner le problème. Par exemple les caractères Xon et Xoff dans la transmission d'un FAX qui fonctionne en Binaire pur car on n'a pas 107 ans pour transmettre des centaines de milliers d'octets ! Mais on sort du sujet de base)
J'aime pas le Grec
Merci Daudet pour tes infos très intéressantes.
Par contre , j'ai question :
J'ai ma carte principal qui discute donc avec une télécommande filaire (en RS232), les données transite bien en aller et retour seulement ce que je remarque c'est que ma télécommande filaire n'émet une trame que si elle en a reçu une auparavant sinon elle n'émet pas de trame.
Donc ce principe, qui peut être une éventualité envisageable, ma carte principal dois interroger régulièrement sur le bus en attendant un retour pour savoir si la télécommande est bien branchée et communiquer.
Est-ce un fonctionnement normal ... après tout est relatif (:
En fait , sur ma télécommande ;
lors que je fais ça
tx_data();
rx_data();
avec
c'est le cas, mais quand je faisCode:void tx_data (void) { EUSART_Write(0x75); tempo=500; while(tempo){ tempo--;} } void rx_data (void) { val.Gdome=EUSART_Read(); }
tx_data();
//rx_data();
Bah là je transmet continuellement
télécommande maison ou achetée ?
Si c'est acheté, tu n'es plus maitre du protocole de la trame
Si la télécommande demande une interrogation régulière pour causer, ben faut lui envoyer un coup de pied au cul régulièrement pour la réveillerDonc ce principe, qui peut être une éventualité envisageable, ma carte principal dois interroger régulièrement sur le busIl n'y a pas à attendre !en attendant un retour pour savoir si la télécommande est bien branchée et communiquer.
Le programme d'interruption en réception UART attend une réponse :
- Elle arrive, quand son buffer est plein, il préviens par un flag "BufferOK" le "main" qu'il y a du travail
- Elle n'arrive pas assez vite. Le WatchDog (un timer) que tu as initialisé lors de l'interrogation se termine et lève un flag "NoTelecommande" pour prévenir le "main" qu'il faut relancer une interrogation
J'aime pas le Grec
J'ai développé la télécommande également, et j'essai de faire communiqué les deux (télécommande et carte principal) je dois avoir un problème d'interruption , de plus, sur le soft de la télécommande, si j'active la réception
je ne peux pas utilisé le clavier pour changer mes valeurs :
Dans mon "main"
lorsque je retire la fonction rx_data() je peux à nouveau utilisé mon clavier pour changer mes valeursCode:while (1) { switch( bStateMachineState ) { case INITIALISATION: //InitApplication(); EUSART_Write(0x73); tempo=500; while(tempo){tempo--;} bStateMachineState = RUN; break; case RUN: application(); affichage(); rx_data(); bStateMachineState = RUN; break; } } }
Comme je te l'ai déjà expliqué, je ne pisse plus de ligne de soft depuis 2005.
Je ne peux que t'expliquer l'organigramme que j'eusse utiliséDonc, il n'y a aucune raison que ta télécommande ne transmette que si elle a reçu une trame ?????
Je ne sais pas ce que tu as comme touche mais si tu tapes 1, 2 , 3 ,4 et une validation (OK, Enter ou autres), ta télécommande doit envoyer automatiquement une trame avec le 1234, plus des info sur le type de paramètre que tu veux modifier ...etc ...etc
La réception est toujours active ! C'est un programme en interruption qui te bourre un buffer avec ce qu'il reçoit de l'UART . Ce programme d'interruption est appelé par chaque caractère qui arrive.et j'essai de faire communiqué les deux (télécommande et carte principal) je dois avoir un problème d'interruption , de plus, sur le soft de la télécommande, si j'active la réception je ne peux pas utilisé le clavier pour changer mes valeurs :
J'ai vaguement l'impression que pour envoyer ou recevoir des données UART tu fais ça dans le "main" en poolling ?????
J'aime pas le Grec
je sais pas ce que tu appel en polling, je fais ma réception et émission dans le main effectivement, seulement je n'envoi pas de données continuellement seulement lors de changement de valeurs par l'utilisateur.
Et bien voilà !tu fais du polling sans le savoir (comme Mr Jourdain faisait de la prose) ! Et comme la réception d'un caractère est une tache bloquante, tu ne fais plus rien d'autreje sais pas ce que tu appel en polling,
Un UART se gère en interruption
Tant que tu n'auras pas pigé et mis en pratique ce concept de programmation, tu feras uniquement des programmes scolaires et inefficaces en pratique .
J'aime pas le Grec
Mais j'utilise des interruptions en tx et rx
avecCode:void interrupt INTERRUPT_InterruptManager (void) { // interrupt handler if(INTCONbits.TMR0IE == 1 && INTCONbits.TMR0IF == 1) { TMR0_ISR(); } else if(PIE1bits.TXIE == 1 && PIR1bits.TXIF == 1) { EUSART_Transmit_ISR(); } else if(PIE1bits.RCIE == 1 && PIR1bits.RCIF == 1) { EUSART_Receive_ISR(); } else if(PIE1bits.TMR1IE == 1 && PIR1bits.TMR1IF == 1) { TMR1_ISR(); } else { //Unhandled Interrupt } }
et dans mon main, je suis biens obligé de récupérer la valeur du buffer de l'uart au moment ou celui-ci est pleinCode:void EUSART_Transmit_ISR(void) { // add your EUSART interrupt custom code if(sizeof(eusartTxBuffer) > eusartTxBufferRemaining) { TXREG = eusartTxBuffer[eusartTxTail++]; if(sizeof(eusartTxBuffer) <= eusartTxTail) { eusartTxTail = 0; } eusartTxBufferRemaining++; } else { PIE1bits.TXIE = 0; } } void EUSART_Receive_ISR(void) { if(1 == RCSTAbits.OERR) { // EUSART error - restart RCSTAbits.SPEN = 0; RCSTAbits.SPEN = 1; } // buffer overruns are ignored eusartRxBuffer[eusartRxHead++] = RCREG; if(sizeof(eusartRxBuffer) <= eusartRxHead) { eusartRxHead = 0; } eusartRxCount++; }
Code:void rx_data (void) { val.Gdome=EUSART_Read(); }
avec la fonction de lecteur de l'uart
Je ne vois pas à quel moment récupérer la valeurCode:uint8_t EUSART_Read(void) { uint8_t readValue = 0; RCSTAbits.SREN = 1; while(0 == eusartRxCount) { } PIE1bits.RCIE = 0; readValue = eusartRxBuffer[eusartRxTail++]; if(sizeof(eusartRxBuffer) <= eusartRxTail) { eusartRxTail = 0; } eusartRxCount--; PIE1bits.RCIE = 1; return readValue; }
Dernière modification par davidif ; 19/08/2016 à 16h35.
en fait, le rx me bloque tout, je sais pas pourquoi, dès que je l'enlève je peux émettre tout le temps , changer mes valeurs via mon clavier
Et pourtant, sauf erreur, j'utilise l'interruption en réception et vient tester le flag, je ne reçois pas tout le temps
ce que je ne comprend pas, c'est que l'interruption survient lors que le buffer est plein ce qui vient mettre le flag à 1 or je n'envoi pas des données tout le temps donc pourquoi la réception serait bloquante
En reception ?le buffer interne de l'UART ? Il fait quelle taille ? Voir dans la datasheet du µC . Classiquement c'est un ou deux octetssurvient lors que le buffer est pleinTant qu'aucun caractère n'est reçu ton "main" en polling bloque sur ce flag qui est à "0" -> rien reçuce qui vient mettre le flag à 1 or je n'envoi pas des données tout le temps donc pourquoi la réception serait bloquante
Dernière modification par DAUDET78 ; 19/08/2016 à 17h51.
J'aime pas le Grec
mes problème sont en réception, tant sur la carte principal que sur la télécommande
tant qu'il y a rien sur le bus y n'y a pas lieu d'avoir une interruption, donc les autres instructions peuvent ce faire;
Oui le buffer de l'Uart fait 1 octet
Tu veux dire qu'il est en permanent en attente ? dans mon main, ok mais quand récupère t-on la valeur envoyé si c'est pas dans le main ? je suis bien obligé d'interroger le buffer de uart pour avoir la valeur.
Par contre , quand j'inibe l'interruption de réception ce n'est plus bloquant
NON ! je t'ai déjà expliqué .... Je recommence :
Quand l'UART reçoit 11 bits, il en prend 8 et les met dans un buffer d'un octet et il y a un flag OctetReçu qui passe à "1"
Si tu as validé l'interruption en réception UART
ce flag appelle le programme d'interruption que tu as écrit
Que fais ce programme ?PS : suivant le µC, il y a des flags à positionner pour dire que tu as lu l'UART et faire retomber la demande d'interruption
- Il regarde cet octet
- BufferDispo="1", j'en ai rien à foutre, j'ai pas de RAM . On perd l'octet Ireturn
- C'est 0x0D ? il met un pointeur IndexRAM à 0000 Ireturn
- C'est 0x0A ? il positionne un flag BufferDispo="1" pour indiquer au "main" qu'il y a un buffer dispo Ireturn. Le "main" vient tester ce flag réguliérement et si il passe à "1" il recopie le buffer RAM et tu en fais ce que bon te semble. Tu fais BufferDispo="0" pour dire que le buffer RAM peut être réutilisé par le programme en interruption
- C'est un caractère autre ? Je le met dans la RAM à l'adresse pointée par IndexRAM . J'incrémente IndexRAM Ireturn
C'est plus clair ?
J'aime pas le Grec
L'interruption est générée une fois le caractère reçu et rangé dans le buffer. Donc tu as juste à lire le caractère quand tu rentres dans la routine d'interruption.
Merci Daudet pour les détails, maintenant je pense faire comme tu l'explique
lors de l'interruption, donc au remplissage du buffer je viens récupérer les octets présent dans le buffer RCREG
Comme montré sur ma fonction de lecture.
Code:uint8_t EUSART_Read(void) { RCSTAbits.SREN = 1; while(!PIR1bits.RCIF) { } if(1 == RCSTAbits.OERR) { // EUSART error - restart RCSTAbits.SPEN = 0; RCSTAbits.SPEN = 1; } return RCREG; }
Y a certainement une erreur dans mon code si ça fonctionne pas , seulement les interruptions tout du moins sur la réception est pour le moment bloquant et je ne sais pas pourquoi.
Sur ma carte principal, pour le moment, j'ai retiré les interruptions et ça fonction correctement, sans vouloir dire que c'est un fonctionnement normal (sans vouloir révolter Daudet, c'est pour l'instant un constat).
Ce qui était bloquant était dans mon case, à la fin de celui-ci, je ne faisait pas de revoie au début du case(ou le renvoi était dans un if, donc parfois ne passait pas).
Par contre, sur ma télécommande, je n'arrive toujours pas à recevoir correctement, avec interruption c'est bloquant et sans, mon main ce déroule mais ne parvient pas à recevoir.
Pour résumer, mes valeurs passe dans un sens télécommande -->carte principal et
mais pas dans l'autre sens carte principal --> télécommande
Merci de votre implication et patience à mon problème
Je t'ai expliqué que le C et moi, on fait une allergie mutuelle et une incompatibilité congénitale. Donc ton programme, j'ai du mal à le lire
Mais :
Un While dans un programme d'interruption me semble incongru
RCIF indique une data reçu et RCIE un registre de transmission vide ?
Donc tu testes si c'est une interruption d'émission ou de réception
If RCIF==1 then goto réception en interruption
if RCIE==1 then goto émission en interruption
J'aime pas le Grec
L'interruption en émission est là pour te dire que ton caractère est parti et que l'uart est disponible pour l'émission du caractère suivant. Donc si tu n'as rien à émettre tu quittes la routine.
Tu quittes en masquant la demande d'interruption en émission ... sinon, c'est reparti pour un tour !
J'aime pas le Grec
Daudet, j'ai bien compris, seulement bien que tes conseils soit précieux, je met mon code pour que d'autres plus averti puisse y voir une erreur qui m'aurai échappé
quoi qu'il en soit, merci pour ton analyse, je vais faire fumer mes méninges déjà pas mal atteinte (:
ce qui me crée des difficulté c'est la réception, donc le flag RCIF, celui-ci est donc testé dans la lecture avec un while effectivement, maintenant on rentre dans le while que si seulement le flag est différent de 0 , donc 1, une fois lu on remet ce flag à 0 donc ne rentre plus dans le while ...
D'autres plus compétents en C !
C'était le but de mon message
Moi, j'ai fait des interruptions sur des µPs, des µCs en assembleur pendant 30 ans, donc je connais. Mais je ne connais pas (et ne veux pas connaitre) ton µC et le C . Par contre, les µC, c'est comme les femmes ou les voitures. Quand tu as appris sur une, c'est similaire pour les autres, le mode d'emploi est identique. Il faut simplement adapter à la particularité de chacune (les flags et les modes d'acquittement peuvent être différents !)
PS : je ne vois pas la gestion en réception du Buffer en RAM avec son Index
PS : La gestion des erreurs (OverRun=perte de data, Parité=erreur de parité), tu laisses tomber dans un premier temps
J'aime pas le Grec
Je suis comme Daudet en C.
En survolant le code je ne vois pas le masquage de demande d'interruption RCIE quelque part et je m'étonne de voir une tempo après l'écriture dans l'EUART.
Bonjour,
Où est il visible que ce code fonctionne en interruption ?
un peu de lecture :http://extremeelectronics.co.in/micr...handling-in-c/
JR
l'électronique c'est pas du vaudou!
Évoqué par l'auteur en #45.
