[Guest]

Bonsoir

Je viens de jeter un coup d’œil a ton programme et notamment a int

Je ne comprend pas cela il y a amha un non sens

Code : Tout sélectionner

if ((PIR1.RC1IF) && (RC1IE_bit)

comment tu peux être dans int si elle n'est pas validé si tu es dans l'int c'est que forcement tu as validé l'autorisation d'y être.et tu dois tester uniquement le flag.

Il y aussi le faite toujours dans l'int un 2eme non sens tu lis le buffer avant de tester tes bits d'erreur.
la procédure est,si je ne me trompe pas.
Déclenchement de int
Vérification des bits erreurs il y a aussi éventuellement le bit RX9
Lecture du buffer RAZ du flag.

Ce qui ici me parait assez logique

Pour d'autres tests, tu as aussi,mais a mon avis c'est finit cela le mode multiprocesseur avec le bit ADDEN ( réseau)

A+

[Jérémy]

Je ne comprend pas cela il y a amha un non sens
Code : Tout sélectionner
if ((PIR1.RC1IF) && (RC1IE_bit)
comment tu peux être dans int si elle n'est pas validé si tu es dans l'int c'est que forcement tu as validé l'autorisation d'y être.et tu dois tester uniquement le flag.

Effectivement cette option est facultative. Sur ce coup k'ai suive le conseil de Paul:

Code : Tout sélectionner

RCIF suffit pour detecter l'interrupt, on peut y rajouter RC1IE pour verif si autorisé
precaution pour la suite .. si on rajoute d'autres sources d'interruptions..

Il y aussi le faite toujours dans l'int un 2eme non sens tu lis le buffer avant de tester tes bits d'erreur.

Oui tu as raison . je change ça tout de suite tu as l’œil.

Pour d'autres tests, tu as aussi,mais a mon avis c'est finit cela le mode multiprocesseur avec le bit ADDEN ( réseau)

??? j'ai pas compris

[paulfjujo]

bonjour ,

.....tu dois tester uniquement le flag.

tu as tout à fait raison si on ne traite que RX interrupt,

pas besoin de mettre "ceinture et bretelles "
j'ai repotassé la logique d'interruption et effectivement,il y a bien une fonction ET logique combinatoire
au niveau Hardware pour ne laisser passer le flag d'interrupt RCIF QUE si le flag AUTORISATION RCIE est à 1..
Le Flag IPRx étant à 1 au reset , on est aussi en mode High Level interrupt PAR DEFAUT.
Comme quoi, je ne me dispense pas d'apprendre et me corriger tous les jours.(pas avec le fouet !)

Interrupt_logique.jpg

par contre , si je rajoute dans le traitement d'interrupt

Code : Tout sélectionner

 
 if (TMR0IF_bit)
  {
   TXREG2='?';
   TMR0IF_bit=0;
  }


le traitement interrupt Timer0 sera effectué ,via l'interrupt RX UART, bien que je n'ai pas armé le bit TMR0IE !
C'est donc peut etre une bonne habitude de rajouter le test autorisation d'interrupt, en cas de multiples causes d'interruption
Qu'en penses-tu ?

Il y aussi le faite toujours dans l'int un 2eme non sens tu lis le buffer avant de tester tes bits d'erreur

Si je le lis avant, il ne devrait pas y avoir d'erreur FERR .. puisque la lecture de RCREG efface cette erreur
mais je ne range pas cette lecture immediatement dans le buffer (table) de recepetion
puisque c'est fait, apres le traitement des erreurs.
et je n'ai pas observé ,à ce jour, meme à 115200bds , des pertes de carateres .


Question : Pourquoi faudrait t-il traiter RX9, si on est en mode 8 bits data ?

[Jérémy]

Bonjour ,

Bon je pense avoir dégrossit , un peu la com RS-232 . Je pense que j'ai assez d'info pour communiquer avec mon transceiver maintenant.

Je remercie tout les intervenants .

Si vous le souhaitez on pourrais faire un tuto collaboratif ! JE me charge de la partie chiante , mise en page et écriture , et vous le corrigez ! Dans un but purement simpliste de savoir comment réaliser une com RS-232, entre deux équipements .

Je vais déballer mon écran

[Guest]

Bonjour

Pour la lecture du RCREG je ne sais pas, mais la on lit, ou on lit pas, le buffer extrait de son #39

Code : Tout sélectionner

   if ((PIR1.RC1IF) && (RC1IE_bit)) // On check le FLAG de l'INT et si elle est autorisée
      {
        Registre=RCREG1;     // On enregsitre le buffer, qui a pour effet de RAZ le flag RC1IF

        if (OERR1_bit)       // Gestion des erreurs ici over run erreur est traité


je pense que OUI!

Pour ce qui est de l'int avec plusieurs INT pas bien compris ? POUR moi, Chaque test sur bit int doit renvoyer au traitement qui lui est propre et puis SORTIR DE INT

Exemple
test bit int TMR0IF
si oui mise a 1 d'un flag effacement flag TMR0IFet sortir INT

test bit RCIF
si oui mise a 1 d'un flag effacement flag RCIF et sortir de INT
ECT...

SINON sorti int

Donc aucun mélange dans les int après a toi de définir l'ordre de priorité

Pour bit 9 c'est de l'ordre du global, quand faire lecture du bit 9 bien sur avant lecture du registre RCREG

Tient pour répondre a jeremy sur CREN et le bit 9 http://www.mikroe.com/chapters/view/16/ ... ontroller/ le 3.8 tu as tout pour le mode multiprocesseurs JEREMY JEREMY

[mazertoc]

Bon je pense avoir dégrossit , un peu la com RS-232 . Je pense que j'ai assez d'info pour communiquer avec mon transceiver maintenant.

Le µC élabore une communication série type Rx/Tx (avec un UART ou autre appellation).
Elle devient RS232 lorsqu'on adapte les niveaux de tensions, avec par exemple un MAX232.
La "norme" RS232 définit aussi les commandes de dialogue, absentes de l'UART, et éventuellement à réaliser avec le µC.

Joyeux Noël et bon pâté !

[Jérémy]

Merci mazertoc , pour cette précision .
Je dois donc dire , j'ai un peu dégrossis la com série, grâce au protocole RS-232

Joyeux Noël et bon pâté !

et chocolat

[mazertoc]

Merci mazertoc , pour cette précision .
Je dois donc dire , j'ai un peu dégrossis la com série, grâce au protocole RS-232

Joyeux Noël et bon pâté !

et chocolat

Le RS232 n'est pas concerné dans un échange
UART_PIC <-> UART/USB <-> PC

Ton programme PIC gère une communication UART (Rx/Tx), si on suppose que la conversion USB est transparente.

Je sais pas pourquoi j'ai envie de manger des huitres.

[Guest]

Bonjour

Pour PAUL une explication peut-être plus lisible avec un bon organigramme sur les INT toujours si j'ai bien compris

INT.png

. Encore une chose qui se perd les organigrammes, il n'arrive encore, de prendre papier crayon pour en dessiner un .Cela permet des fois de remettre les idées en place

A+

[paulfjujo]

J'ai bien compris l'usage des interruptions, je les utilise à chaque application.
mais je veux simplement (tenter d' ) expliquer un contexte qui necessite de tester aussi, les bits d'autorisation d'interruption
dans des cas specifiques, je n'affirme pas que c'est une regle immuable, mais que cela peut etre necessaire
moi, je l'applique en permance, par défaut, pour ne pas me retouver dans un cas libidineux.
( meme si je perds quelques cycles CPU)

si RC1IE est armé et que TMR0IE ne l'est pas
(Par exemple on utilise timer0 en mode pooling pour faire une tempo.. ou autre ..comptage)
dans ma boucle principale de programme
ou si on ne veut pas valider une interrupt à un moment donné
car Timing critique..

l'entree dans l'interrupt causée par l'arivée d'un caractere (RC1IF),
sera perturbé par le timer0 lorsqu'il deborde
et de meme mon usage du timer0 le sera par l'arrivéee d'un caractere
alors que si je teste les autorisations RCIE et TMR0IE ,il n'y aura pas d'interference.

J'ai deja vecu ce cas de figure, ou on peut subir des effets de bords
(aleas de comportement) dans un programme ,par interference au niveau des interrupts
..non desiree! et resolu en gérant et testant les flags d'autorisation.


Bonne fetes !