Interrupt INT0 RB0 et IOCBF problemo

[paulfjujo]

Bonjour,

sur le projet Chaudiere de Babar64

je decouvre ce probleme :
Aleas de reconnaissance sur l'etat d'un Switch particulier par rapport à la detection d'un appui de touche (SW0 ..SW4)
permettant un aiguillage vers des menus , aiguillages conditionnés aussi par la duree d'appui sur le BP (switch)
lien
schema

J' ai refait un autre projet simplifié pour montrer ce probleme
18F27K42_xc8_test_INT0_5_BP_Uart1_2022-07.X (package et *.hex dans le zip joint)
AUCUN probleme sur SW0,SW1,SW3,SW4 , probleme uniquement sur SW2

par ailleurs j'ai fait un autre test simple , en mode pooling du portB .. AUCUN probleme sur SW2 (RB3)
J' ecarte donc un probleme Hardware.

le suivi sur terminal montre bien les aleas sur SW2 ....
or la valeur de k represente bien l'état correct de SW2
c'est donc l'image issue de IOCBF qui est altérée ... est censé representé le bit qui est passé à Zero...
IOCBN=0b00111111; // detection front descendant sauf RB6 RB7 affecté à ICSP


Projet MPLABX : 18F27K42_xc8_test_IT_Uart1
Version : 2023-0716
Compile le Jul 16 2023 a 11:26:09 UTC
avec version XC8 : 2360

Verif. chronometre SMT1_Init(4); (500Khz) résolution+-2µS avec delay 1000mS
# Duree = 999
Via UART1 sur Port Virtuel sur Terminak YAT COM35 115200bds
Test Interrupt INT0 sur 5 BP PORT B b1=SW0,b2=SW1,b3=SW2,b4=SW3, b5=SW4
via un OU à diodes sur PIN RB0
TMR0 initialise sur 10 sec , en mode pooling !
00000
00001
00002
*# 00003
Duree = 1300 mS , BP=0X01, Menu=0 k=0X0001 SW0
00004
00005
*# 00006
Duree = 1900 mS , BP=0X02, Menu=1 k=0X0002 SW1
SW1 Menu 1
SW1 Toogle Change Mode CONFORT / ECO
mode : Ec et MOD_frc desactive

10 sec ecoulée ..
00007
*# 00008
Duree = 1800 mS , BP=0X0C, Menu=0 k=0X000 <----- BAD
00009
00010
00011
00012
*# 00013
Duree = 2000 mS , BP=0X02, Menu=1 k=0X0002 SW1
SW1 Menu 1
SW1 Toogle Change Mode CONFORT / ECO
mode : Cf et MOD_frc desactive

10 sec ecoulée ..
00014
00015
00016
*# 00017
Duree = 1600 mS , BP=0X04, Menu=2 k=0X0004 SW2 <------ OK
SW2 Menu 2
SW2 Incr consigne forcee CFT : 19.50
*# 00018
Duree = 1600 mS , BP=0X08, Menu=3 k=0X0008 SW3
SW3 Menu 3
SW3 Decr consigne forcee CFT : 19.00

10 sec ecoulée ..
00019
*# 00020
Duree = 2200 mS , BP=0X10, Menu=4 k=0X0010 SW4
SW4 Menu 4
00021
00022
00023
00024
00025

10 sec ecoulée ..
00026
00027
00028
*# 00029
Duree = 1500 mS , BP=0X0C, Menu=0 k=0X0004 <----- BAD
00030
00031
*# 00032
Duree = 1500 mS , BP=0X0C, Menu=0 k=0X0004 <----- BAD

10 sec ecoulée ..
00033
00034
*# 00035
Duree = 1600 mS , BP=0X0C, Menu=0 k=0X0004 <----- BAD
00036
*# 00037
Duree = 1500 mS , BP=0X04, Menu=2 k=0X0004 SW2 <------ OK
SW2 Menu 2
SW2 Incr consigne forcee CFT : 19.50
00038
*#
10 sec ecoulée ..
00039
Duree = 1200 mS , BP=0X04, Menu=2 k=0X0004 SW2 <------ OK
SW2 Menu 2
SW2 Incr consigne forcee CFT : 20.00
00040
00041


Je conçois bien que je n'utilise pas ici, les interrupt individuelles (non validée car IOCIE=0)
mais INT0 puisque RB0 reçoit le front descendant de n'importe quel switch parmi SW0..SW4

Il y a un grumaux dans la Francine ...

un coup d'oeil , une idée , un bug ?

Files_Projet_18F27K42_xc8_test_INT0_5_BP_Uart1_2022-07.jpg

18F27K42_xc8_test_INT0_5_BP_Uart1_2022-0716.zip

Pas assez clair , ce diagramme
Quid de l'entrée Q2 ?
le Flag IOCBFx , monté si detection front descendant sur RB3, devrait etre une sortie ?

Diagram_InterruptOn_ChangePortB.jpg

[satinas]

Bonjour Paul,
Je penche pour un problème de conception hardware, car après essai de ce câblage il y a bien des problèmes sur les flags IOC. chez moi en appuyant sur un switch autre que B1 le flag associé monte bien, mais parfois le flag IOCBF1 monte lui aussi. cela se produit avec l'interruption INT0 mais aussi si on utilise l'interruption IOC. En enlevant la diode sur B1 le problème IOCBF1 disparaît, donc cela ne vient pas du pic.
En simplifiant au max, c'est à dire aucune résistance, aucune diode, et pull-up sur le port B, l'interruption IOC marche parfaitement, et elle permet aussi le wake-up from sleep. Pourquoi faire compliqué ? :)

Code : Tout sélectionner

void __interrupt(high_priority) highIsr(void)
{
  if (IOCIF) {
    unsigned char i, p = IOCBF;
    delay_ms(500);
    for (i=0; i<8; i++) {
      while (!U1TXIF) { }
      U1TXB = p&0x80 ? '1' : '.';
      p <<= 1 ;
    }
    IOCBF = 0x00;
  }
}

[paulfjujo]

bonjour Satinas,

Merçi pour ton implication..

Curieux que tu trouves un probleme sur RB1 au lieu de RB3 ?
Peux-tu poster ton Test Pak du projet (zip)
pour que je le test dans les memes conditions software....

Nota :
je ne peux pas rester longtems dans l'interrupt de traitement
hormis un delay mini INDISPENSABLE mini Anti-rebonts de contact
car il y a a d'autres choses à faire ensuite ... dans l'application Chaudiere.

tu as utilisé ( 1 seule) interrupt High priorité NORMALE , non IVT .

Nota :
je n'ai constaté AUCUNE interférence sur un test pur Pooling des Switches PORTB
chaque switch individuel est bien vu ..
ou combinaison de switch comme SW1+SW3 ..ok


Je ne pense pas que la capa parasite de la bread board 1,2 à 1,8pF entre collonne ( donc entre chaque switch, me fasse des siennes)
ça ne le ferait pas que sur SW2 !
mais je vais quand meme donner un coup d'oscillo sur les signaux Switches SW0..SW4
... la loi de murphy !

[satinas]

Bonjour,
Je vais refaire le montage sur la breadboard et préparer un petit projet. En attendant :
Cela ne se produisait pas que sur B1, c'est un peu aléatoire, j'ai pris B1 comme exemple. Cela dépend peut être de la tension de seuil des diodes.
Comme cela semble marcher sans les diodes, le problème doit venir de là. Il n'y a pas de miracle, si la pin déclenche c'est que le niveau est bas. C'est un problème purement électronique. Comme tu le dis, il faudrait mettre un oscillo rapide sur les pins, le problème doit être visible.
Au niveau de l'appli, à quoi sert l'info INT0 ?

[paulfjujo]

il me semblait avoir vu une source de probleme ....

partie init hardware dans le main

ligne 594
IOCEN=0;// invalide toutes interrup IOC
IOCBP=0; //pas de detection front Montants sur PORTB
// modif 18-07-2023
// IOCBN=0b00111111 RB0 etait inclus !
IOCBN=0b00111110; //detection front descendant (Negatif) sauf RB7 RB6 ICSP et RB0 !

AUCUN alea constaté sur SW2 sur une vingtaine de test

par contre je ne vois pas comment le bit 1 IOCBF (RB0) pourrait intervenir avec un poids de 8 ?
Ca tombe en marche ou c'est vraiment résolu ?...

ben, NON
un test plus long montre que l'Alea est toujours présent ...

un contre essai : au niveau Hardware :

Mes 5 BP sont sur une platine en carton ... ( pas la valise en carton !)
tous les fils passent par un trou (+Vcc 0V, SW0..SW4)
avant d'aller sur ma mini bread board de connection vers le PIC Port B
OR les fils formaient un toron compact de 8 cm de long

en écartant les fils du toron ..et en plaçant les connections sur la breadboard avec une colonne vide
entre chaque colonne de raccordement
pour diminuer la capa parasite entre les pins
...... plus de problemes constatés sur SW2
sur un test bien plus long .. voir fichier log

La réactivité du PIC sur un evenement porte sur quelques cycles MCU seulement soit x fois 0,0625µS
Il importe alors que chaque PIC de tension pouvant transiter par une capa aussi faible que 1,2pF peut mettre la pagaille ..
( à ces frequences FOSC=64/4=16Mhz )
sur d'autres entrées non concernées directement...


ex: ne pas mettre une sortie PWM à coté d'une entrée UART ! avec une breadboard...


mesure sur SW2 avec oscillo numerique TDS2002C 70Mhz
On voit bien aussi, la necessité d'un delay anti-rebonds

Appui_sur_SW2.jpg

Le montage final sur circuit imprimé devrait eliminer ce genre de probleme.

log de test :

18F27K42_XC8_test_Switch_INT0_IOCBF_2023-0718-1556.log

Je vais verifier maintenant avec l' appli CHAUDIERE ....

[satinas]

Je l'avais laissé aussi, cela devrait juste lever le flag IOCBF0, ce qui fait double emploi avec l'INT0.
A quoi sert dans l'appli le fait de regrouper les appuis avec INT0 ?

[satinas]

J'ai toujours le problème sur B1 avec le projet ci-dessous. Avec l'interruption INT0, B1 déclenche un coup sur deux si j'appuie sur B3 ou B2, appuyer c'est un bien grand mot, je fais toucher 2 fils :)
En enlevant la diode sur B1, là c'est ok mais l'appui sur B1 ne répond plus car plus de lien avec l'INT0.

Test_Paul.zip

[paulfjujo]

merçi pour le zip ..je vais tester ça.

voir situation post #5
J'attend de tester aussi la version sur le programme Chaudiere ...

[paulfjujo]

Bonjour Satinas et à tous,

Ca va nettement mieux qu'avec des BP sur breadboard ..
Test avec la Carte CHAUDIERE ( montage des BP sur PCB double Face (c) Babar64 )

J'ai rajouter la mesure de durée d'appui via SMT1
mais une simple boucle de comptage à 100µS devrait faire aussi l'affaire
la précision de SMT1 à +-2µS n'apportant rien de plus.
La reconnaissance des PB et groupement de BP est fiable .....

il me reste à l'intégrer dans l'Application CHAUDIERE avec tout son environnement pour vérifier
cette fiabilité...

Code : Tout sélectionner



 PIC18F27K42 + Test interrupt INT0 pour test Appui sur 6 BP portB
 Directory :C:\MPLABX_Projects\Test_Paul
 Project :  Test_Paul
 Source :  main.c _2028-0820
 Config  Internal Fosc 64MHz
 Autres :  UART1_Functions.h 
 Eeprom : No 
 RA4=led,RA3=SQA,RC6=TX UART1 RC7=RX UART
 RB0 interrupt pin,BP SW0...SW5 + BP SW6 sur RC5


 Compile le Aug 20 2023 a 15:35:37 UTC
 avec version XC8 :  2360 

 Test SMT1 avec delay 100mS , Nb Tics 49997 L2=99994 uS

 OK
 Etats_BP :  SW0    =0X01  duree k= 1211  via SMT1 L2=122 mS
 Etats_BP :  SW1    =0X02  duree k= 1420  via SMT1 L2=143 mS
 Etats_BP :  SW0  SW1    =0X03  duree k= 4827  via SMT1 L2=488 mS
 Etats_BP :  SW2    =0X04  duree k= 1148  via SMT1 L2=116 mS
 Etats_BP :  SW0  SW2    =0X05  duree k= 4910  via SMT1 L2=496 mS
 Etats_BP :  SW1  SW2    =0X06  duree k= 5873  via SMT1 L2=594 mS
 Etats_BP :  SW1  SW3    =0X0A  duree k= 4999  via SMT1 L2=505 mS
 Etats_BP :  SW4    =0X10  duree k= 5384  via SMT1 L2=544 mS
 Etats_BP :  SW5    =0X20  duree k= 8003  via SMT1 L2=809 mS




Test_Paul_rev_2023-0820.zip