interruption sur pic 18f452

[mp3dux]

bonjour,
j'ai une carte picdem de microchip et j'ai un peu de mal pour réaliser sur rb0 une interruption.
Le flag INT0IF n'est jamais positionné quelqu'un a une idée ?

par contre si en mode débuggeur je mets ce flag manuellement à 1 il rentre dans l'interruption.

#include<p18f452.h>

unsigned int cpt=0;// compteur d'interruption

//sous prog d'int
#pragma interrupt it_sur_rb0
	void it_sur_rb0(void)
		{
		if (INTCONbits.INT0IF)
			{cpt++;
				PORTBbits.RB2 = !PORTBbits.RB2; //on inverse rb2
				INTCONbits.INT0IF=0;}
		}
		
		//code asm pour gestion des int en c
#pragma code vecteur_d_IT=0x08 
	void une_fonction(void)
		{_asm
			 goto it_sur_rb0
		_endasm}
#pragma code 
         void main (void)
			{
			TRISBbits.TRISB0=1;//rb0 en entree
			TRISBbits.TRISB2=0;//rb2 en sortie
			INTCONbits.INT0IE=1;//activation d'int sur  rb0
			 INTCONbits.GIE=1;//autorisation globale d'interruption
			 
			 while(1);// boucle  infinie
			 }

-----

[Gérard]

As-tu cablé un BP sur RB0 pour créer le changement d'état ?

[mp3dux]

As-tu cablé un BP sur RB0 pour créer le changement d'état ?

oui y'a pas de problème de ce coté, j'ai une carte picdem2 de microchip déjà tout fait.

Mais j'ai quand même vérifié, le rb0 fonctionne très bien en entrée comme en sortie.

En mode débuggeur il change bien d'état, je le vois dans les registre du portB en plus
ce code fonctionne

#include <p18f452.h>


void main()
{

	TRISB = 0x01;// portb en sortie sauf le port rb0 en entree
	PORTB = 0xFE ;//j'initialise en allumant les  leds

	

	while(1)
	{
		if(PORTBbits.RB0==1)//si RB0 n'est pas appuiyé
		PORTB = 0xFE ;//les leds du port sont allumées 
		else                   //si  j'appuis RB0 (mets à la masse)
		PORTB = 0x00 ;// elle s'eteignent 
		
	}
	;					
}

Quand j'appuie les leds s'éteignent et quand je relâche elles s'allument.

c'est juste en interruption int0if ne bronche pas ! incroyable ça peut venir d'où?

[Gérard]

N'y a-t-il pas une histoire de priorité d'interruption sur les 18F ?

Fais un essai sur un 16F, je ne vois pas ce qui ne marche pas.

[A voir en vidéo sur Futura]

[mp3dux]

je crois que en 16f on peux que programmer en asm non?

[invite5637435c]

Bonsoir,

il faut préciser le front (montant ou descendant) du déclenchement.
Cela se gère par INTCON2 bit6.

@+

[invite5637435c]

je crois que en 16f on peux que programmer en asm non?

En C aussi, pourquoi pas.

[mp3dux]

pour le front j'avais préféré le laisser à la valeur par défaut, là je l'ai rajouté ça n'a rien changé.

si quelqu'un a un code simple qui fonctionne avec RB0 sur picdem j'aimerais le tester .

voilà mon code

#include<p18f452.h>

unsigned int cpt=0;// compteur d'interruption

//sous prog d'int
#pragma interrupt it_sur_rb0
void it_sur_rb0(void)
{
if (INTCONbits.INT0IF)
{cpt++;
PORTBbits.RB2 = !PORTBbits.RB2; //on inverse rb2
INTCONbits.INT0IF=0;}
}

//code asm pour gestion des int en c
#pragma code vecteur_d_IT=0x08
void une_fonction(void)
{_asm
goto it_sur_rb0
_endasm}

#pragma code


void main (void)
{
TRISBbits.TRISB0=1;//rb0 en entree
TRISBbits.TRISB2=0;//rb2 en sortie(led)


RCONbits.IPEN=1; //Interruption prioritaires activées
INTCON2bits.INTEDG0=0;//front descendant sur RB0
INTCONbits.GIEH = 1;// Toutes les IT démasquées hautes priorités autorisées
INTCONbits.GIEL = 1;// Toutes les IT démasquées basses prirités autorisées
INTCONbits.INT0IE=1;//activation d'int sur rb0

while(1);// boucle infinie
}

[invite5637435c]

Non, ce n'est pas la bonne démarche, il faut toujours essayer de comprendre pourquoi ça ne marche pas.

Comment est câblé le B.P, bref un petit schéma du montage même si il est simple est nécessaire, on croit toujours que ça ne sert à rien de faire un schéma...

Et c'est quoi le compilateur, bref merci de donner TOUS les "détails", pourquoi faut-il que ce soit ceux qui aident, qui tirent toujours les vers du nez?

La variable cpt doit être déclarée en volatile, même si ce n'est pas la cause de non fonctionnement.
@+

[invite5637435c]

Il faut vérifier dans la doc de ton PIC, mais je ne serai pas étonné que RB0 soit partagée avec une autre fonction de type A/D, auquel cas il faut déclarer le port en digital et dévalider les fonctions analogiques.
@+

[mp3dux]

Non, ce n'est pas la bonne démarche, il faut toujours essayer de comprendre pourquoi ça ne marche pas.

Comment est câblé le B.P, bref un petit schéma du montage même si il est simple est nécessaire, on croit toujours que ça ne sert à rien de faire un schéma...

Et c'est quoi le compilateur, bref merci de donner TOUS les "détails", pourquoi faut-il que ce soit ceux qui aident, qui tirent toujours les vers du nez?

La variable cpt doit être déclarée en volatile, même si ce n'est pas la cause de non fonctionnement.
@+

merci pour les réponses super rapides, en effet je suis d'accord avec toi, dans la mesure où il faut essayer de comprendre pourquoi ça marche pas.
c'est ce que je fais toujours quand je programme en c++ par exemple, quand j'ai un bug je sais que ce n'est pas matériel et je suis sur à 99,99% que c'est dans mon code l'erreur.

Mais dans cette situation ce n'est pas le cas , il y a des contraintes matérielles, un faux contact,un mauvais cablage, etc... donc je ne sais pas où peut se touver ce bug.
si un autre code marche je saurais que c'est une config qui ne prend pas dans mon code par exemple.

-pour les details : j'utilise mplab ide avec MCC18 pour le c.
la programmation se fait à travers un module ICd2.
la carte picdem est une carte de microchip deja cablée,
j'ai joint la doc pdf de ma carte picdem en fichier joint.
personnellement je ne crois pas que ça vienne du compilo ou du contact avec rb0.
parce que je programme sans soucis avec rb0 en entrée : comme on peut le voir avec ce code qui fonctionne

 #include <p18f452.h>


void main()
{

	TRISB = 0x01;// portb en sortie sauf le port rb0 en entree
	PORTB = 0xFE ;//j'initialise en allumant les  leds

	

	while(1)
	{
		if(PORTBbits.RB0==1)//si RB0 n'est pas appuiyé
		PORTB = 0xFE ;//les leds du port sont allumées 
		else                   //si  j'appuis RB0 (mets à la masse)
		PORTB = 0x00 ;// elle s'eteignent 
		
	}
	;					
}

pour d'autres détails je suis à votre disposition

[mp3dux]

juste une petite précision, le schéma exact est en page 20.

[Gérard]

je crois que en 16f on peux que programmer en asm non?

Ca marche en C, Basic et Pascal !

[mp3dux]

ok, dès que je trouve un16f je vais essayer.

pour l'instant j'ai que le 18f452 et je suis bloqué pour mon projet à cette petite interruption depuis 3 semaines.

[invite5637435c]

Je ne sais pas sur votre compilateur comment il gère le bit du registre du portB en interruption, j'ai un sérieux doute sur ce point.

Pouvez-vous essayer de mettre plutôt un flag dans l'interruption et remettre dans le while une condition relative à ce flag, on en aura le coeur net.

Je ferai quelque chose comme ça:

#include<p18f452.h>

volatile unsigned int cpt=0;// compteur d'interruption
volatile unsigned char flag;

//sous prog d'int
#pragma interrupt it_sur_rb0
void it_sur_rb0(void)
{
if (INTCONbits.INT0IF)
{cpt++;
flag = ~flag; // toggle
INTCONbits.INT0IF=0;}
}

//code asm pour gestion des int en c
#pragma code vecteur_d_IT=0x08 
void une_fonction(void)
{_asm
goto it_sur_rb0
_endasm}

#pragma code 


void main (void)
{
flag = 0;
TRISBbits.TRISB0=1;//rb0 en entree
TRISBbits.TRISB2=0;//rb2 en sortie(led)


RCONbits.IPEN=1; //Interruption prioritaires activées
INTCON2bits.INTEDG0=0;//front descendant sur RB0
INTCONbits.GIEH = 1;// Toutes les IT démasquées hautes priorités autorisées
INTCONbits.GIEL = 1;// Toutes les IT démasquées basses prirités autorisées
INTCONbits.INT0IE=1;//activation d'int sur rb0

while(1)// boucle infinie
 {
  if(flag == 1) 
   {
   PORTBbits.RB2 = !PORTBbits.RB2; //on inverse rb2
   Delay_ms(600); // anti-rebonds du B.P
   flag = 0;
  }
 }
}

[mp3dux]

je viens d'essayer ton code, et j'ai fais une capture d'écran du compilo.
je pense qu'une image est mieux que 100 descriptions.

3 captures pour être précis:

1- rb0 relâché
2-rb0 appuyé
3-puis jai aussi essayé un point d'arrêt (B en rouge) pour que l'execution se bloque dés que flag passe à '1'.

constat:

-rb0 est bien détecté sur le portB, c'est le bit le plus à droite.
- le flag n'est pas passé à 1.
-l'exécution reste bloqué au if parce que la condition n'est jamais réalisé.

[mp3dux]

alors personne n 'a un vieux code svp?

[invite5637435c]

Bonsoir,

vous pouvez poster votre code tel que vous l'essayez actuellement svp?
Bizarre que RBIF soit positionné à 1 dans INTCON vue RBIE est à 0, vous avez un autre BP sur le portB?

[invite5637435c]

Pour pouvoir vous aider efficacement il faut que je vois votre schéma et notamment comment et ce que vous avez branché d'autres sur le portB.

Votre compilateur accepte-il cette directive:

#pragma config PBADEN = OFF

J'essaierai également avec:

if(INTCON.INT0IF == 1)

[mp3dux]

Pour pouvoir vous aider efficacement il faut que je vois votre schéma et notamment comment et ce que vous avez branché d'autres sur le portB.

#pragma config PBADEN = OFF

bonjour, merci encore pour l'aide;

ma carte est un module de microchip .
le schéma est en page 20. Je l'ai déjà ajouté au message #11.
c'est un pdf en fichier joint.

--entre autres j'ai reçu d'autres conseils :
-mettre aussi une routine d'interruption basse
-mettre les bits de config dans le code

j'ai essayé l'un et l'autre sans succès, là je vais faire les deux

pour le rbif à 1

- j'essai #pragma config PBADEN = OFF ?
ou plus simple si tu veux je peux mettre ces broches en sortie.


ps: voici le code en fichier joint.

Cela aurait été plus simple pour la consultation d'y ajouter l'extension txt.
JPL, modérateur

[invite5637435c]

Je viens de prendre la doc du 18F452, je ne l'utilise pas, et je vois qu'il n'a pas de A/D sur portB donc pas non plus de registre PBADEN.
Le probléme n'est donc pas là.

Essayez avec la condition d'égalité à 1 (==1) dans le if de l'interruption pour commencer.

Si ça ne donne rien il faut comprendre pourquoi l'interruption n'est pas détectée, il doit y avoir un détail qui m'échappe encore.
Je vais regarder de plus près la doc et je reviens.

[invite5637435c]

Il faut activer uniquement GIE (bit7 de INTCON) pour l'instant, j'ai enlevé la ligne activant le bit 7 de IPEN, il est donc à 0 par défaut (compatibilité midlerange 16Cxxx).
Quand IPEN est à 0 il n'y a plus de notion basse et haute priorité pour les interruptions, vous êtes par défaut dirigé en 0x08.
Le soucis de votre code est simplement qu'il manquait PEIE=1, si on ne déclare pas actif les interruptions périphériques ça marchera tout de suite moins bien.

Essayez ce code qui doit tourner maintenant:

#include<p18f452.h>
#include <delays.h>
volatile unsigned int cpt=0;// compteur d'interruption
volatile unsigned char flag;

//sous prog d'int
#pragma interrupt it_sur_rb0
void it_sur_rb0(void)
{
if (INTCONbits.INT0IF == 1)
{cpt++;
flag = ~flag; // toggle
INTCONbits.INT0IF=0;}
}

//code asm pour gestion des int en c
#pragma code vecteur_d_IT=0x08
void une_fonction(void)
{_asm
goto it_sur_rb0
_endasm}

#pragma code 


void main (void)
{
flag = 0;
TRISBbits.TRISB0=1;//rb0 en entree
TRISBbits.TRISB2=0;//rb2 en sortie(led)

INTCON2bits.INTEDG0=0;//front descendant sur RB0
INTCONbits.GIE = 1;// Toutes les IT démasquées hautes priorités autorisées
INTCONbits.PEIE = 1; // C'est ça qui a été oublié !!!
INTCONbits.INT0IE=1;//activation d'int sur rb0

while(1)// boucle infinie
 {
  if(flag == 1) 
   {
   PORTBbits.RB2 = !PORTBbits.RB2; //on inverse rb2
   Delay10KTCYx(10);
  // Delay_ms(600); // anti-rebonds du B.P
   flag = 0;
  }
 }
}

[mp3dux]

vous avez testé le code ça a fonctionné ?

j'ai changé

INTCONbits.PEIE = 1; GIE=1;

et pris votre code mais INT0IF n'est jamais positionné et le prog ne rentre toujours pas dans l'interruption .

je sais plus où chercher; là vraiment je vois pas.
les interruptions périphériques fonctionnent très bien( timer, usart sauf ) ce int0.


je viens de voir un passage de la doc 18f452; "power on reset" qui peut inverser l'etat analogue/ digital du portB et je crois que ça a rapport avec
PBADEN dont tu m'as parlé;

déja que pour

#pragma config PBADEN= OFF

il met erreur.
j'ai ajouté la capture d'écran en fichier joint.

[invite5637435c]

Non pas testé mais ce code devrait tourner.
PBADEN on l'oubli, pas de A/D sur le portB du 18F452 et ce registre n'existe pas sur ce PIC.

La raison n'est pas liée au PIC ni au code qui est écrit ici, qu'avez vous mis pour les bits de config par exemple?

[mp3dux]

pour les configs bits je reglais tout dans le compilo mpab.

mais on m'a conseillé de le faire dans le code, donc hier j'ai essayé avec les configs suivantes:

//reglages  importants
//------------------------------------------------------

#pragma config OSC =HS // oscilateur à quartz 4 Mhz
#pragma config DEBUG = ON // mode debug activé
#pragma config BOR = OFF  //Brown-out Reset
#pragma config WDT = OFF   // pas de chien de garde
#pragma config PWRT = OFF		//Power Up Timer Disabled
#pragma config LVP = OFF //Low Voltage Programming Disabled


//#pragma config MCLRE = OFF     // MCLR disabled                //me mets erreur
//#pragma config PBADEN = OFF    /* PORTB<4> and PORTB<1:0> Configured as Digital I/O Pins on Reset */ //me mets erreur
//------------------------------------------------------

//c'est aussi important  ça ?
//-------------------------------------------------------
#pragma config	CP0 	= OFF
#pragma config	CP1 	= OFF
#pragma config	CP2 	= OFF
#pragma config	CP3 	= OFF
#pragma config	CPB 	= OFF
#pragma config	CPD 	= OFF
#pragma config	WRT0 	= OFF
#pragma config	WRT1 	= OFF
#pragma config	WRT2 	= OFF
#pragma config	WRT3 	= OFF
#pragma config	WRTB 	= OFF
#pragma config	WRTC 	= OFF
#pragma config	WRTD 	= OFF
#pragma config	EBTR0	= OFF
#pragma config	EBTR1	= OFF
#pragma config	EBTR2	= OFF
#pragma config	EBTR3	= OFF
#pragma config	EBTRB	= OFF
//-----------------------------------------------------------------

[mp3dux]

petite bonne nouvelle;

en fouillant ,j'ai trouvé un exemple de code qui fonctionnait en interruption sur rb0, mais au lieu d'allumer la led sur le port rb1,
un buzzer est activé sur le port C rc2.


au début du code le buzzer somme et l'interruption de rb0 inverse a chaque fois l'état.

1- j'ai compilé le code ;
j'ai fais run:
le buzer somme ,j'appuis rb0,
le buzzer sonnait toujours.

donc ça n'a pas fonctionné (comme d'hab )

2-je me suis dis tiens j'ai plus besoin des leds sur le bort B je les enlève.
(j'enleve le connecteur des leds sur portB)

3- je relance le code, j'appuie sur rb0 le buzzer s'arrête ,j'appuie encore il sonne etc...

conclusion je crois que le code que tu m'a modifié devrait fonctionner mais le connecteur des leds sur portb relie tout à la masse ou un truc du genre.

je vais maintenant essayer notre code.
voici l'image du connecteur des leds sur portb.
en fichier joint

[invite5637435c]

Bonjour,

il faudrait faire l'essai sans le mode debug, tous les bits de config ne sont pas nécessairement à paramétrer, seuls les plus importants doivent l'être:

1/ #pragma config OSC =XT // oscilateur à quartz 4 Mhz
2/ #pragma config DEBUG = OFF // mode debug désactivé
3/ #pragma config WDT = OFF // pas de chien de garde
4/ #pragma config PWRT = OFF //Power Up Timer Disabled
5/ #pragma config LVP = OFF //Low Voltage Programming Disabled

Et je répète encore qu'il n'y a pas de registre PBADEN dans ce PIC!

Je testerai aujourd'hui quand j'aurai 5 mn le prog sur une carte EASYPIC et je vous dirai ce que ça donne.
@+

[invite5637435c]

Dernière chose, je viens de revoir le schéma de votre carte, et je vois quelque chose qui ne va pas.

Il n'ont pas prévu de pull-up sur le portB, sauf sur RB0, et que seul un cavalier ne permet d'activer les leds branchées sur les autres port de ce même portB y compris RB0 .
C'est vraiment pas malin de la part de Microchip d'avoir procédé de la sorte...

Ce que vous pouvez essayer c'est d'enlever ce cavalier de manière à ce que le portB soit totalement en entrée (pensez à modifier votre soft en conséquence -> TRISB=0xFF), puis vous déclenchez non plus une led mais votre buzzer comme dans votre dernier post.
Ainsi vous serez dans une config normal pour cette interruption, et cela doit fonctionner désormais.
@+

[mp3dux]

Dernière chose, je viens de revoir le schéma de votre carte, et je vois quelque chose qui ne va pas.

Il n'ont pas prévu de pull-up sur le portB, sauf sur RB0, et que seul un cavalier ne permet d'activer les leds branchées sur les autres port de ce même portB y compris RB0 .
C'est vraiment pas malin de la part de Microchip d'avoir procédé de la sorte...

Ce que vous pouvez essayer c'est d'enlever ce cavalier de manière à ce que le portB soit totalement en entrée (pensez à modifier votre soft en conséquence -> TRISB=0xFF), puis vous déclenchez non plus une led mais votre buzzer comme dans votre dernier post.
Ainsi vous serez dans une config normal pour cette interruption, et cela doit fonctionner désormais.
@+

vous avez bien vu ! c'est le coup du cavalier je n'ai jamais pensé que c'était possible!
regardez par vous meme : le port fonctionne en entrée normalement. Il change en 1 et 0 rb0 , les actions liées à ces conditions fonctionnent dans le code(main)!

Donc pour moi il n'y avait pas de problème lié à l'état 1 ou 0.

Mais l'interruption ne réagissait pas à ce changement d'état comment est ce possible ?

A chaud je dirais que c'est parce que l'interruption fonctionne sur un front (montant ou descendant) et non pas sur un état (1 ou 0) ce qui est le cas du fonctionnement en entrée.

donc s'il y a front il y a seuil de tension et c'est là que intervient le cavalier j6 sur le schéma (post#26). car le cavalier relie les leds à la masse donc 0.7v max sur rb0, ou un truc du genre...

Dites moi si c'est plutôt dans cette approche qu'il faut considérer le problème ?

Je pourrais le mettre dans le rapport de mon projet,
(j oublierai pas d'ajouter votre nom à remerciements )

merci aussi

1/ #pragma config OSC =XT // oscilateur à quartz 4 Mhz
2/ #pragma config DEBUG = OFF // mode debug désactivé
3/ #pragma config WDT = OFF // pas de chien de garde
4/ #pragma config PWRT = OFF //Power Up Timer Disabled
5/ #pragma config LVP = OFF //Low Voltage Programming Disabled

pour m'avoir précisé les plus importants, ça m'a été très utile, j'étais il faut l'avouer confus sur ce point .Me demandant si c'etait pas de là que venait mon problème.

[invite5637435c]

Globalement c'est ça.
On se retrouve avec une charge non prévue sur le port B0 à savoir une résistance et une led reliée à la masse.
Si on fait un schéma de tout ça, on a une pull-up de 4,7K (je néglige la 470 Ohms qui protège l'entrée du port et de l'autre coté une résistance de 470 Ohms à la masse lorsque la led est éteinte (Vd<Vseuil) puisque le courant est insuffisant, donc un joli pont diviseur qui fait que vous n'avez jamais plus de 0.5V sur l'entrée RB0 et le front montant n'est jamais détecté puisque pour cela il faut qu'il atteigne au moins Vcc/2 ou à peu prés si c'est une entrée trigger (faut regarder la doc).

Comme quoi on a bien fait d'insister, je suis sûr que vous ne vous ferez plus reprendre avec ce piège, et vous avez dû relire la doc en long, en large et en travers, donc bien intégré le fonctionnement de INT0 dans ses moindres détails.