Problème d'interruption sur PIC18

[invite6c061599]

Bonjour, je suis en train de travailler sur un PIC18 et le programme contient une interruption externe sur la pin RB0.

J'utilise le PIC18F2680 et le compilateur C Hi-Tech C Compiler.

A chaque interruption, l'état d'une pin (RB1) devrait changer de niveau.

Voici donc le programme en question :

#include <p18F2680.h>
#pragma config OSC = HSPLL
#pragma config FCMEN = OFF
#pragma config IESO = OFF
#pragma config MCLRE = ON
#pragma config PBADEN = OFF
#pragma config XINST = OFF

void interrupt it_sur_rb0(void)		
{
	if (INTCONbits.INT0IF)			// vérifie que l'IT est INT0, origine PB0=0 (bouton S3)
			{
				PORTBbits.RB1=!(PORTBbits.RB1);
				PORTC=0b11111110;
				INTCONbits.INT0IF=0;	//efface le drapeau d'IT*/
			}
}


void main (void)
{
	PORTB=0b00000000;
	PORTE=0b00000000;
	ADCON1=0x0F;
	TRISB=0b00000001;
	INTCON2bits.RBPU=0;
	INTCON2bits.INTEDG0=1;
	INTCONbits.INT0IE=1;	// INT0 activée
	RCONbits.IPEN=1;
	INTCONbits.GIEH=1;
	INTCONbits.GIEL=1;
	while(1){
	}	
}

En simulant sur proteus ISIS, avec un schéma assez simple :
- avec un boutton-poussoir relié au pin RB0 et une LED reliée au pin RB1.

Et j'ai constaté le problème suivant : L'état du pin RB1 change de niveau au premier interruption, mais reste bloqué sur cet état pour les interruptions suivantes.

Est-ce que l'interruption ne marche qu'une fois? Y-a-t-il un problème de boucle infini?

Je vous remercie d'avance et fais appel à votre lumière afin de m'éclairer la-dessus.
-----

[flyingrock]

Bonjour,

C'est pas plutôt PORTBbits.RB1=~(PORTBbits.RB1);

[jls28]

Salut,

Je suis presque sur qu'avec :

LATBbits.RB1 = ! LATBbits.RB1;
au lieu de PORTBbits.RB1

ça marchera beaucoup mieux
mais ça serait un peu long à expliquer pourquoi.

[invitedc9da242]

Bonjour,

non il complémente à chaque passage donc rb1 s'allume à la première interruption et s'éteint à la seconde et ainsi de suite. compilo gratuit ou acheté ? car il ya quand même moins de possibilité avec un gratuit qu'un acheté quoi que là ça devrait marcher.
je sais que microchip à arrêter le compilo C hi-tech, peut être plusieurs problèmes de trouvés, télécharges le XC8 dernière mouture et réessaies. N'oublie pas de changer de compilo dans ton projet.
Je te dis car pour moi là ça devrait marcher ( bon je suis pas un spécialiste).
Pourquoi configures tu ADCON1 ?
je travailles sur pickit3 et non sous isis pour tester mes programmes peut être vais je être obligé de passer sous isis car mon PC que je vient de changer marche en USB3 ce qui fous la merde avec le pickit carte cible toujours occuper alors que non.

[A voir en vidéo sur Futura]

[invite6c061599]

Donc, avant tout, je vous remercie de vous intéresser à ce problème.

C'est pas plutôt PORTBbits.RB1=~(PORTBbits.RB1) ;

Avec le compilateur Hi-tech C, les opérateurs != et =~ m'ont l'air d'être équivalents. Donc j'ai obtenu le même résultat.
Le Led s'allume à la première interruption, mais ne s'éteint plus pour les interruptions qui suivent.

LATBbits.RB1 = ! LATBbits.RB1;
au lieu de PORTBbits.RB1

En effet, le registre LATB me semble plus approprié que le registre PORTB. Mais des erreurs empêche le programme de fonctionner. Y-a-t-il des bits à activer pour accéder aux registres LAT?
Mais à titre d'information, j'arrive quand même à obtenir le changement de niveau avec de interruptions Timers et toujours en utilisant le syntaxe :
PORTBbits.RB1 = ! PORTBbits.RB1;
Donc je crois que ce problème concerne spécialement les interruptions externes.

non il complémente à chaque passage donc rb1 s'allume à la première interruption et s'éteint à la seconde et ainsi de suite. compilo gratuit ou acheté ?

télécharges le XC8 dernière mouture et réessaies.

Pourquoi configures tu ADCON1 ?

Oui, c'est bel et bien le résultat que je recherche : RB1 s'allume, puis s'éteint et ainsi de suite à chaque interruption. Et j'aurais préféré que ce problème ne soit pas du au compilateur. Mais je le redoutais quand même.
C'est un logiciel acheté et c'est celui qui m'a fais le plus avancé après avoir essayé : mikroC PRO (V.6.0.0) et MPLAB C18 (V.3.47), en fait je ne suis pas doué avec l'utilisation des linkers. Mais si c'est vraiment nécessaire j'essaierai le XC8.

Sinon l'erreur pourrait provenir de Proteus Isis? J'utilise la version 7.5, qu'en pensez-vous?
Ou bien d'autres séquences obligatoires pour les interruptions externes : Temporisation? Niveau Boutton-poussoir? réinitialisations INT0IF,INT0IE?Errata?

[RISC]

Salut,

Concernant les compilateurs utilises XC8 plutôt que C18 qui n'est plus mis à jour depuis 3 ans.
Ton problème n'est pas lié au compilateur.
L'erreur ne vient je pense pas non plus de Proteus.

Autre chose, il faut absolument utiliser LATx plutôt que PORTx pour les SORTIES. PORTx doit être utilisé pour les ENTREES.

Pourquoi utilises-tu les priorités ?
Il n'y a qu'une interruption dans ton programme. Fais un essai en utilisant IPEN=0.

As-tu une vraie carte et un debogueur ou tu travailles sur Proteus ?

a+

[RISC]

Salut,

Un excellent cours pour les PIC18 : http://www.ece.msstate.edu/courses/e...dex_pic18.html
En particulier pour les interruptions : http://www.ece.msstate.edu/courses/e...interrupts.pdf

a+

[jiherve]

Bonsoir,
Bizarre ce nombre de problèmes avec les PICs et rien sur les Atmega ou autres Atmel !
Provoc gratuite car il est tard et je suis d'humeur taquine.
JR

[invite6c061599]

Salut,

Ton problème n'est pas lié au compilateur.
L'erreur ne vient je pense pas non plus de Proteus.

Ça donne de l'espoir ça. Actuellement je travaille sur comment utiliser les registres LATx car apparemment il ne suffit pas d'écrire LATBbits.RB1 = ! LATBbits.RB1;

Je suis encore en attente de la livraison de la vraie carte. Donc je suis dans l'obligation de le faire fonctionner sur Proteus.

[invitedc9da242]

@ jiherve

ça c'est parce que tu es le seul a te servir d'un atmega

vbon courage

[jiherve]

Bonjour,
non j'utilise les deux mais beaucoup plus les Atmel car ce sont des architectures 'carrées'.
JR

[RISC]

Salut,

Actuellement je travaille sur comment utiliser les registres LATx car apparemment il ne suffit pas d'écrire LATBbits.RB1 = ! LATBbits.RB1;

Regardes bien la documentation de ton PIC et tu vas voir que le nom des bits des les registres LATx sont LATx0 : exemple LATA0, LATA1...(les RA0, RA1,..sont les bits du registre PORTA)

Donc pour inverser le bit 1 du port B :

LATBbits.LATB1 = !LATBbits.LATB1 ;

Cette ligne de code est tout à fait correcte mais elle génère pas mal de code car l'inversion du bit passe à travers une structure de champ de bits.
Si ton soft n'est pas critique utilise ce type de notation car il est facile à lire et à modifier. Sinon il vaut mieux faire des masques classiques sur le registre complet.

a+

[invite6c061599]

Suite à vos remarques et vos recommandations, j'ai réécris le programme et ça donne le code suivant :

#include <p18F2680.h>
#pragma config OSC = HSPLL
#pragma config FCMEN = OFF
#pragma config IESO = OFF
#pragma config MCLRE = ON
#pragma config PBADEN = OFF
#pragma config XINST = OFF

void interrupt it_sur_rb0(void)		
{
	if (INTCONbits.INT0IF)			
			{
				LATBbits.LATB1=!LATBbits.LATB1;
				INTCONbits.INT0IF=0;	
			}
}


void main (void)
{
	LATB=0b00000000;
	TRISB=0b00000001;
	INTCON2bits.RBPU=0;
	INTCON2bits.INTEDG0=1;
	INTCONbits.INT0IE=1;	
	INTCONbits.GIE=1;
	while(1){
	}	
}

Et "Build successful" avec 0 erreurs mais l'interruption ne marche toujours qu'une seule fois.
Le rapport d'erreurs et warning a quand même signalé les éléments suivants :
- Advisory[1233] Employing 18F2680 errata work-arounds:
- Advisory[1234] * Corrupted fast interrupt shadow registers

Est-il possible que ces éléments soient la cause de mon problème? (Ces problèmes ont également été rapportés dans l'ancien programme mais j'ai oublié de les mentionner). Si c'est le cas comment m'en débarrasser?

En tout cas vos remarques sur les registres LATx m'ont été d'une grande aide et je vous en remercie.
En fait j'ai écris un autre programme qui au lieu de tester l'interruption INT0 permet de tester l'interruption Timer 2.
Si ça vous intéresse le code que j'ai utilisé est le code suivant :

#include <p18F2680.h>
#pragma config OSC = HSPLL
#pragma config FCMEN = OFF
#pragma config IESO = OFF
#pragma config MCLRE = ON
#pragma config PBADEN = OFF
#pragma config XINST = OFF

void interrupt Deb_Timer2 (void)		
{
	if (PIR1bits.TMR2IF)			
			{
//Permet d'obtenir une nouvelle interruption après l'écoulement du même délai
				TMR2=0x00;				
				PR2=155;
				T2CON=0b01111111;
				LATBbits.LATB1=!LATBbits.LATB1;
				PIR1bits.TMR2IF=0;	
			}
}


void main (void)
{
	LATB=0b00000000;
	TRISB=0b00000001;
	T2CON=0b00000000;
	PIR1bits.TMR2IF=0;
	PIE1bits.TMR2IE=1;
	IPR1bits.TMR2IP=1;
	INTCONbits.PEIE=1;
	INTCONbits.GIE=1;
	TMR2=0x00;
	PR2=155;			//Délai au hasard
	T2CON=0b01111111;	
	while(1){
	}	
}

Et ce programme marche à merveille, on voit clairement qu'une interruption survient après l'écoulement du même délai.
Et à chaque interruption le bit B1 change de niveau.

On a presque le même programme que le premier, sauf que la nature de l'interruption est différente. Donc je peux en déduire que mon problème se trouve dans ma gestion de l'interruption INT0. Il y a encore d'autres eaux que je n'ai pas exploré : le watchdog, le mode DEBUG, la temporisation, l'utilisation partielle de langage d'assemblage (.asm) et le changement de compilateur (que je réserve en dernier recours). Donc si cette liste vous a donné un petit déclic sur la question, n'hésitez pas à partager vos avis.

[RISC]

Salut Mitch,

Les messages avec advisory sont des BONNES CHOSES. Cela signifie que certains des bugs du PIC sont directement pris en charge par le compilateur.
Tu ne peux rien y changer (c'est forcé par le compilateur) et il ne faut SURTOUT pas essayer. En admettant que tu écrirais en assembleur, il faudrait tenir compte de ces bugs, comme le fait automatiquement le compilateur, pour s'assurer que le PIC évite ces bugs. C'est très courant dans les microcontroleurs et il faut toujours lire l'erratasheet de chaque PIC pour éviter de ce faire piéger..Certains bugs architecturaux (au niveau du coeur ou de l'exécution de certaines séquences d'instructions) sont pris directement en charge par le compilateur car il concerne tous les produits de la famille. C'est le cas des messages que tu as vus.
D'autres bugs, la plus grosse partie, doivent être gérés par l'utilisateur en utilisant la procédure décrite dans l'erratasheet.

Tu es en simulation ou sur une vraie carte ?Il se peut que le PB soit lié au simulateur.
Je vais essayer ton morceau de code sur une carte PIC18 (PICDEM 2 PLUS) pour voir comment cela réagit. En debug on voit beaucoup plus vite les problèmes.
J'ai déjà mis en oeuvre INT0 par le passé sur un PIC18F4520 sans aucun problème, mais je n'ai pas pu retrouver un projet.

a+

Avec un peu de chance Paulfujo aura un morceau de code pour toi ;=)

[RISC]

Salut,

Je viens de tester ton code avec une toute petite modif sur le PIC18F46K22 sous Proteus et il fonctionne.
J'utilise le schéma de la carte PICDEM 2 PLUS qui a un bouton poussoir avec une pull-up externe sur INT0.
Je génère l'interruption par le bouton poussoir et la led RB1 change d'état .

La principale erreur dans ton dernier programme (qui n'était pas dans ton premier code) est qu'il faut absolument configurer la broche RB0/INT0/AN10 en digital.

Il faut ajouter cette ligne :

        ADCON1 = 0x0F;          // AN0 à AN10 en digital

a+

[invite6c061599]

En effet, il marche sur la carte PICDEM 2+, mais avec d'autres PIC (J'ai testé avec le PIC18F452). Donc le problème vient des bugs de mon PIC.
Mes dernières options :
- Les directives de l'errata.
- Changer de Simulateur : Quelle est la version de Proteus la plus récente (qui peut traiter ce genre de bug)?
Existe-t-il d'autres logiciels qui permettent de bien simuler les cartes à bases de PIC?

[RISC]

Salut,

Tu as une carte PICDEM + ? Couleur rouge, verte ou noire ?
Quel debogueur ? Pickit3 ? ICD3 ?

Ne tire pas de conclusions hatives....chaque PIC est different et il faut vérifier en détail la datasheet du PIC que tu utilises.

J'ai remarqué un problème de Proteus avec le PIC18F46K22 : les anciens PIC18 (PIC18F452, PIC18F4520,..) utilisent le registre ADCON1 pour choisir le mode digital ou analogique.
Les PIC18 récents comme le PIC18F46K22 utilisent le registre ANSELA, ANSELB,... :

ANSELBbits.ANSB0 = 0; // RB0 en digital
ANSELBbits.ANSB1 = 0; // RB1 en digital

Cependant PROTEUS a simulé correctement la fonction digitale sur la broche RB1 alors que j'avais oublié d'utiliser ANSELx plutot que ADCON1...

conclusion :attention aux simulateurs...même PROTEUS qui est sans doute le meilleur simulateur pour les PIC.

Je te recommande d'utiliser ta carte et de développer dessus c'est la bonne méthode.

a+

[invite6c061599]

Donc finalement ça a marché, ouf, merci infiniment pour les différents conseils. Mais il reste un point non résolu.

C'était surtout un problème de montage.

J'ai essayé avec ce premier montage :

FlancMontant.JPG

Et ça a donné le fameux bug dont je vous ai parlé.

Mais avec le schéma suivant, qui est similaire à celui du PICDEM2+ (de proteus : je n'ai pas de vrai carte), ça a bien marché.

FlancDescendant.JPG

Le seul problème est le suivant : Le premier montage envoie un signal initialisé à 0 donc le premier flanc est un flanc montant, pour le schéma du PICDEM, on a un signal initialisé à 1 donc on a d'abord un flanc descendant et l'interruption n'a lieu que lorsque le signal revient à son niveau initial.

J'ai donc une préférence pour cette première configuration. Donc s'il y a une explication à cela j'aimerai le savoir.

[RISC]

Salut,

Au vu du problème que j'ai eu avec Proteus (que j'ai expliqué), il y a peut-être d'autres PB.
Tel que tu as fait ton montage, le port de sortie et probablement la led seraient instanément grillés car tu as oublié une résistance série. Dans ton programme il semble que cela fonctionne...

Je répète...la vraie vie c'est le vrai circuit électrique. Cela ne m'intéresse pas de chercher pourquoi Proteus ne simule pas tout correctement.
Le gros risque c'est de faire du développement sur Proteus et de croire que tout marche. Ensuite tu utilises une vraie maquette et plus rien ne marche et la plupart des utilisateurs en déduisent que la carte est HS...
Et tu repasses encore autant de temps à développer.

Tu risques de chercher pourquoi ton soft ne marche pas alors que c'est seulement un PB de simulation...

Précise toujours quand tu postes si c'est de la simulation ou un vrai circuit, cela évitera de chercher dans la mauvaise direction...

a+

[invitee05a3fcc]

Moi, je suis un homme de hardware.... le soft, j'ai laissé tombé en 2005

C'était surtout un problème de montage.

Non ...
Que tu actionnes ton entrée par un niveau haut ou bas, c'est kif kif. Par contre, tu n'as pas d'antirebond hard . Donc il faut le faire par soft avec un timer à 50ms (par exemple) qui vient lire tes boutons.
- Si il le trouve à "1" à T et T+50ms , c'est un "1" stable . Si avant, c'était un "0" stable, on positionne un flag "ouais il est passé à "1"
- Si il le trouve à "0" à T et T+50ms , c'est un "0" stable . Si avant, c'était un "1" stable, on positionne un flag "ouais il est passé à "0"

Et dans le main, on viens regarder ces flags pour savoir ce qu'il faut faire