18F27K42 et Interruptions Vectorisees, RX UART 115200

[paulfjujo]

bonjour,

Je suis resté sur ma derniere version 18F27K2 MLPABX XC8 , et usage de MCC

J'ai enlevé la partie générée par MCC UART1 pour utliser une façon plus classique ...
mais cet UART Hardware se complique aussi
La partie Transmit UART est OK
la partie I2C1 Hw presence device, Ecr/lec RTC , OLED SSD1306, capteur ADXL345 est OK ..
mais je veux gerer la reception UART via interrupt .. remplir un buffer jusqu'à detecter un CR ( 0x0D=\r=13)

autant ça marche bien sous MikroC ! que là ça coince

J'ai mis des "drapeaux" dans chaque interrupt pour verifier/voir ce qui se passe
drapeau= usage de U1TX , registre transmit UART qui envoi un caractere donné sur mon terminal YAT..
ce qui n'interfere donc que tres peu (voir pas du tout)
easy to debug !

je peux voir que lorsque j'envoi mon message via le terminal (couleur bleue) , l'interrupt UART1 RX réagit bien
vu l'apparition des * (en réponse au message envoyé)

terminal_envoi.jpg

Code : Tout sélectionner



if ( (PIR3bits.U1RXIF==1) && (PIE3bits.U1RXIE ==1) )
  {   
    c1=U1RXB;  // lecture registre UART Recepetion
      U1TXB='*'; // ----------------  pour debug only ------------------------------------------------
    if ((c1==13) || (i1>8))
     { 
      Flag_Buffer1=1;
      Buffer1[i1]=0;
      Index1=i1;
      i1=0; 
     PIE3bits.U1RXIE =0;
     }
     else
     {
       Buffer1[i1]=c1;
       i1++;
       Index1=i1;
     } 
   }   //---- RX UART

 

La boucle principale tourne à ~1,2sec
via un delay d'attente de 1Sec
permettant la capture de l'interruption UART
la mesure ADXL345 solicite surtout les interrupts I2C (bien visible si on valide les drapeaux U1TX='3' et U1TX='4')
L'OLED est desactivé pour ce test principalement axé en ce moment sur l'UART RX...

mais impossible de recuperer le contenu dans le buffer1, puisque le Flag_buffer1 n'est pas à 1 dans le main program.
j'ai meme rajouté une validation du flag sur compte de byte >8

variables Buffer1, Flag_Buffer1 ... declarées en volatile dans le main
et en externe dans le traitement interrupt ...
probleme de portée de variables entre main et Interrupt_manager ?

Nota : d'habitude je met mes traitements d'interruptions dans le main ...

mon projet MPLABX

ADXL345_18F27K42_2021_0408.zip

J'aimerai quand meme savoir POURQUOI ça coince,
avant de passer sur un autre projet tout neuf , exclusivement réservé à l'usage des Interruptions Vectorisées VIT
qui in fine sera peut etre plus simple à gerer , avec ce PIC prévu pour.

je mets le ciel de coté, qu' est-ce qui reste ... Fantaspic et ses acolytes ( j'ai pas dis alcoliques !)

[satinas]

Bonjour

Pourquoi 2 variables i1 et Index1 qui semblent faire la même chose, ça complique la lecture du programme.
J'aime pas trop ta remise à 0 de U1RXIE, je préfère le laisser à 1, cela n'empêche pas de gérer un buffer de réception. Et si tu reçois des octets non voulus, faut t'en prendre au programme qui les envoie, le pic n'y est pour rien :)

Si tu dumpes les octets reçus, tu verras bien pourquoi la trame reçue n'est pas complète, non ?

[paulfjujo]

bonjour Satinas et à tous,

Pourquoi 2 variables i1 et Index1 qui semblent faire la même chose, ça complique la lecture du programme.

j'utilise 2 index : i1 et Index1 pour conserver la derniere position dans le buffer1 ,
i1 est mis à 0 quant CR ou Nb de bytes sont atteints.
ça m'a deja servi dans d'autre applis ... mais effectivement superfétatoire dans ce cas là.
on est loin du 16F84 ou il fallait vraiment compter le nb de variables utilisées..

De meme je mets U1RXIE=0 quand j'ai receptionné un message .. pour avoir le temps de le traiter sans qu'aucune perturbation
ou autre message survienne entre temps . Par exemple pour la remise à la date et heure RTC
sinon, un protocole XON XOFF ou CTS RTS autre serait necessaire si l'envoi (sur PIC RX) devait etre aleatoire.


J'ai pus mettre mon probleme mis en evidence avec l'envoi de 'H' sur l'evenement "entrée du traitement IT High"
sur le terminal YAT, bloquant tout si envoi de caractere sur RX UART
(17:04:10.742)HHHHHHHHHHHHHHHHHHHHHHHHHHH..etc ..HHHHHHHHHHHHHHHHH<Warning: Maximal number of bytes per line exceeded!>
interruption parasite ( non identifiée avec tout le code présent lié à l' I2C OLED, RTC, ADC, NCO1 , SMT1, ..etc
Meme en inhibant 1 par un les modules ...no way ! )

j'en suis arrivé à SUPPRIMER tout le code généré par MCC
et reduire le code ( DIVISER POUR MIEUX REGNER )
revenir à une init classique (sans MCC) et avec
UART1 en IT High et Timer 2 en Init Low ISR
tout en gardant ma gestion habituelle de l' UART RX avec un buffer à remplir.

Cependant , j'ai un doute :
à savoir si dans la meme IT RXIF, il faut lire le byte suivant dans la FIFO ou laisser
l'interrupt revenir TANT que RXIF est à 1
j'ai testé les 2 cas .. OK
mais en cas d'interrupt multiples en High ISR ????
Attendre une 2em interrupt RXIF pour recuperer le 2em byte , cela pourrait penaliser d'autres interrupts en mode High ISR!
bon à 19200 bds et FOSC 64MHz , c'est peu probable ...
Qu'en pensez vous ?

Par contre je n'ai pas (encore) testé la gestion des erreurs Frame et OVerflow
encore faut-il pouvoir les generer (les erreurs ... via OSCTUNE ? )...
je ferais des essais à 115200 bds ...
où vont_elles survenirt à 115200 bauds ( probablement via la precision limitée de FOSC interne , et OSCTUNE ..et VCC.. et Temperature )

J'en ai profité pour tester Timer2 en mode libre ..
le Timer2 est initialisé avec un tick de 8192µS
T2CLKCON = 0x01; // T2CS 0x01=>FOSC/4
T2HLT = 0x00; // MODE=0 => free runing software gate
T2PR = 0xFF; // PR2 255;
T2TMR = 0x00; // TMR2 0;
T2CON = 0x60 | 0x07 ; // Prescaler =1/64 Poscaler=1/8 => 1/128 ticks= 8192µS
et interrupt compte Cpt_T2> 122 => 999 424 µS .. presque la seconde !

je note ici, que l'interrupt se fait bien BIEN APRES le POSTCALER ..

diagram timer2

TMR2_18F27K42_interrupt.jpg

sur terminal

(18:07:44.000) (0.042) Projet MPLABX :18F27K42_UART1_RX_ITH_TMR2_ITL_2021
(18:07:44.000) (0.000) Compile le Apr 10 2021 a 18:07:00 UTC
(18:07:44.032) (0.031) avec version XC8 : 2100
(18:07:44.032) (0.000) Hardware : BASE 18F27K42 FOSC interne =64MHz
(18:07:44.075) (0.042) Test UART1 RX High Interrupt et Timer2 Low Interrupt
(18:07:46.068) (1.993) IT High et Low armées
(18:07:46.099) (0.030) Init and Start Timer2
(18:07:46.099) (0.000) Raz Buffer1, Arme RX UART IT
(18:07:47.107) (1.008) Timer2 Cp_T2= 1
(18:07:48.116) (1.008) Timer2 Cp_T2= 2
(18:07:49.125) (1.008) Timer2 Cp_T2= 3
(18:07:50.133) (1.008) Timer2 Cp_T2= 4
(18:07:51.141) (1.008) Timer2 Cp_T2= 5
(18:07:52.148) (1.007) Timer2 Cp_T2= 6
(18:07:53.156) (1.008) Timer2 Cp_T2= 7
(18:07:54.165) (1.008) Timer2 Cp_T2= 8
(18:07:54.995) (0.829) Help
(18:07:55.174) (0.178) Timer2 Cp_T2= 9
(18:07:55.189) (0.014)
(18:07:55.189) (0.000) Recu :
(18:07:55.259) (0.069) Help Commandes :
(18:07:55.259) (0.000) MAJ RTC
(18:07:55.259) (0.000) ex: U;03;03;21;15;14;03;# pour 03 mars 2021 , 15H14 Mercredi
(18:07:55.259) (0.000) Help
(18:07:55.259) (0.000) Help
(18:07:56.245) (0.986) Timer2 Cp_T2= 10
(18:07:57.253) (1.008) Timer2 Cp_T2= 11
(18:07:58.261) (1.007) Timer2 Cp_T2= 12
(18:07:59.270) (1.009) Timer2 Cp_T2= 13
(18:08:00.278) (1.008) Timer2 Cp_T2= 14
(18:08:01.286) (1.008) Timer2 Cp_T2= 15
(18:08:02.295) (1.008) Timer2 Cp_T2= 16
(18:08:03.303) (1.008) Timer2 Cp_T2= 17
(18:08:04.103) (0.799) U;18;03;21;18;45;05;#
(18:08:04.312) (0.208) Timer2 Cp_T2= 18
(18:08:04.331) (0.018)
(18:08:04.331) (0.000) Recu :
(18:08:04.331) (0.000) MAJ RTC
(18:08:04.432) (0.100) U;18;03;21;18;45;05;#
(18:08:04.432) (0.000)
(18:08:05.344) (0.912) Timer2 Cp_T2= 19
(18:08:06.352) (1.008) Timer2 Cp_T2= 20
(18:08:07.360) (1.008) Timer2 Cp_T2= 21

Hihg Interrupt

Code : Tout sélectionner


void __interrupt(high_priority)  High_Isr(void)
{  
   unsigned char c1;
  //   U1TXB='H';  // for debugging  incomming of High  interrupt
  /*
  if ( (PIR3bits.U1IF==1 ) && (PIE3bits.U1IE ==1) ) 
  {
   if(U1ERRIRbits.FERIF==1)
    {
       c1= U1RXB; 
       U1ERRIRbits.FERIF=0;
       U1TXB='I';
    }
    //overflow
    if( U1ERRIRbits.RXFOIF==1)
    {
      c1= U1RXB; 
      U1ERRIRbits.RXFOIF=0;
      U1TXB='J';
     }
   */
     
  if ( (PIR3bits.U1RXIF) && (PIE3bits.U1RXIE) )
  {   
     c1=U1RXB; 
    if ((c1==13) || (i1>BUFFER1_LEN )  )
     { 
      Flag_Buffer1=1;
    // 2em byte du Fifo ? ou LF suivant le CR
   //   if(PIR3bits.U1RXIF) Buffer1[i1]=U1RXB;
      Buffer1[i1]=0;
      Index1=i1;
      i1=0; 
      PIE3bits.U1RXIE =0;
      }
     else
     {
       Buffer1[i1]=c1;
       i1++;
       Index1=i1;
   //  2em byte du Fifo ?
   //   if(PIR3bits.U1RXIF)
   //    {
   //    Buffer1[i1]=U1RXB;
   //   i1++;
   //   Index1=i1;  
   //   }
     } 
   }   
 }  // void Hig interrupt   

 

Low Interrupt

Code : Tout sélectionner


void __interrupt(low_priority)  lowIsr(void)
{  
 
    if(PIE4bits.TMR2IE == 1 && PIR4bits.TMR2IF == 1)
    {
      //  U1TXB='$';
         tick2_count++;   // tick=8192µS
         if (tick2_count>122)
         {    tick2_count=0;
              Cpt_T2++;
         }
        PIR4bits.TMR2IF=0;
    }
   } 

le projet MPLABX XC8

18F27K42_UART1_RX_ITH_TMR2_ITL_2021.zip

[satinas]

Bonsoir Paul

Ma méthode c'est de faire une int uart qui avale tous les octets reçus quels qu'ils soient, afin de ne pas provoquer d"overflow. Dès qu'un message reçu est complet, on lève un bit BUSY, et tant que ce bit est haut, l'int uart lit le registre mais ne stocke pas. Quand le programme principal a traité le message, il resette l'index de stockage et le flag BUSY.

Comme l'int ne fait que stocker, il n' y aura jamais de congestion, elle a largememt le temps de travailler même à 115200 bauds. Il n'y pas de raison qu'il y ait des erreurs frame ou overflow, celle d'overflow bloque la communication, mais encore faut-il qu'elle se produise :) Bien sûr il faut le prendre en compte si cela peut être critique pour l'appli.
Les derniers pic ont des oscillateurs internes à +/- 2%, ok pour l'uart.

[paulfjujo]

Bonjour à tous,

Je commence à m'habituer à MPLABX , meme si c'est plus compliqué que MikroC ..
Voila la suite, test des interruptions Vectorisées..
En fait c'est beaucoup plus faciles avec une IT pour chaque fonctionalité ... et oublier aussi le
pre-machage fait par MCC .. qui en fait des tonnes pour pas grand choses..
MCC est surtout utile pour la configuration des pins ..
J'ai conservé surtout la partie I2C MCC où la gestion des Interrupts est assez ardue .

un résumé ici

Test Accelerometre ADXL345 et autres fonctionalités du PIC 18F27K42 (dip28)
Version avec IT classiques mode LEGACY
*SMT1 compteur 24 bits résolution +-1cycle
*NCO1 numerical Controled Oscillateur 10Khz
*Pulse Width Modulation s PVM5 10bits 1Khz avec Timer4
*ADXL345 accelerometre 3 axes I2C
Version avec IVT Interruptions vectorisées

Pour moi, ce PIC18F27K42 remplace maintenant avantageusement le PIC18F26K22 ..
plus de RAM, plus de ROM, plus de fonctions ..
malgré une prise en main assez laborieuse et beaucoup de lecture datasheet et autres docu Microchip
nota : il faut un Pickit4 de préference ... trop d' aleas avec pickit3

Question :
Pourquoi la fonction ultoa ( transforme un long non signé en asccii) n'est pas reconnue avec la version C99 XC8
mais uniquement en version C90 ?
sinon => usage de sprintf ou faire sa propre routine ?

[satinas]

Le PicKit3 à 10 sous marche pas mal sur les nouveaux pics, quand ils sont reconnus.
itoa, utoa, ltoa, ultoa disparaissent en C99, fonctions non standard C.
Pour les entiers, sprintf permet de sortir en hexa, décimal ou octal.

[paulfjujo]

bonjour,

Je viens de charger la version XC8 2.32 64bits ... (remplace la version 2.10)
mais compilation moins rapide ! et taille programme plus grande !

XC8 V2.10
Memory Summary:
Program space used 3E88h ( 16008) of 20000h bytes ( 12.2%)
Data space used 293h ( 659) of 2000h bytes ( 8.0%)
Configuration bits used 5h ( 5) of 5h words (100.0%)
EEPROM space used 0h ( 0) of 400h bytes ( 0.0%)
ID Location space used 10h ( 16) of 10h bytes (100.0%)
Data stack space used 0h ( 0) of 1D40h bytes ( 0.0%)

make[2]: Leaving directory 'C:/MPLABX_Projects/IVT_Test_18F27K42.X'
make[1]: Leaving directory 'C:/MPLABX_Projects/IVT_Test_18F27K42.X'

BUILD SUCCESSFUL (total time: 12s)
Loading code from C:/MPLABX_Projects/IVT_Test_18F27K42.X/dist/default/production/IVT_Test_18F27K42.X.production.hex...
Loading completed
-----------------------

XC8 V2.32
Memory Summary:
Program space used 3C88h ( 15496) of 20000h bytes ( 11.8%)
Data space used 293h ( 659) of 2000h bytes ( 8.0%)
Configuration bits used 5h ( 5) of 5h words (100.0%)
EEPROM space used 0h ( 0) of 400h bytes ( 0.0%)
ID Location space used 10h ( 16) of 10h bytes (100.0%)

make[2]: Leaving directory 'C:/MPLABX_Projects/IVT_Test_18F27K42.X'
make[1]: Leaving directory 'C:/MPLABX_Projects/IVT_Test_18F27K42.X'

BUILD SUCCESSFUL (total time: 14s)
Loading code from C:/MPLABX_Projects/IVT_Test_18F27K42.X/dist/default/production/IVT_Test_18F27K42.X.production.hex...
Loading completed

mis à jour du programme ...
à noter : UART à 115200 bds avec usage FOSC interne 64 MHz .. no problemo

[paulfjujo]

Bonjour,


je viens de decouvrir ce document TRES INTERRESSANT , enfouis dans un directory lointain
C:\Program Files (x86)\Microchip\MPLABX\v5.30\packs\Microchip\PIC18F-K_DFP\1.4.87\xc8\docs\chips\ 18f27k42.html

[satinas]

Hello
Il est aussi dans "C:\Program Files\Microchip\xc8\docs\chips"
Le dossier docs, on devrait le lire en premier et en détail, on gagnerait beaucoup de temps :)