"ça tombe en marche "
Je pense que tu as pensé 'call' et écris 'goto'
Oui, c'est bien un CALL , .....Call Trait_IT_High .. retour avec le return
Code : Tout sélectionner
ORG H'08'
call Traite_IT_High
retfie
reception
....
...
return <- retour à l'appel du sosu programme
par contre effectivement
un "return" aurait été plus judicieux au lieu du "retfie" (situé dans le sous programme)
En fait ,c'est plutot ceci que j'aurais du faire
Code : Tout sélectionner
Traite_IT_High
...
btfsc PIR1,RC1IF
goto reception
return <-- un retour normal à l'appelant au lieu du retfie
mais si le retfie assume la restitution des registres empilé au moment de l'appel de l'interrupt
il ne devrait pas y avoir de probleme avec retfie au lieu de return.
Nota:
je n'ai pas verifié si le pointeur de pile fait partie des registres sauvegardes
sinon cela pourrait creer un plantage à plus long terme.
Tu ne peux pas envoyer tes caracteres dans le main, parceque justement
tu as armé l'interuption TX
qui deroute le main.. vers le traitement IT interrupt..
Je ne vois aucun interet à utiliser TX interrupt dans cet exemple .
Sur une reception tendue ( un bon paquet de caracteres à recevoir , sans espaces temporel entre les caracteres)
l'envoi de plusieurs caracteres dans le traitement IT RX, pourrait serieusement celle ci.
( meme si on suppose quand meme qu'on utilise un buffer pour receptionner un paquet de caractere)
car bouffe du temps CPU . dans le traitement meme de l'IT RX.
l'envoi de F6FC0 CR,LF 10 cars à 9600bds va bouffer > 10mS , ou RX IT est aveugle pendant ce temps.
D'ailleurs, j'aimerai bien qu'on me montre un exemple utile d'usage IT TX ..
les seuls cas que j'envisage pour l'instant serait basé sur une retransmission quasi automatique :
on recoit sur UART1 RX et on Retransmet par IT TX sur UART2 TX
ou un recoit un byte par SPI ou I2C et le RETRANSMET par UART11 TX IT.
ou IT sur mesure ADC => envoi automatique valeur sur UART1 TX IT.