[PIC]-Interruptions / Timer : Déclenchement aléatoire

[invite3c35244f]

Bonjour,

alors voila, j'ai réalisé une petite carte autour d'un PIC, et j'utilise les 2 modules: interruptions et timer 0, mais je rencontre un souci, au début de mon programme, j'utilise l'interruption sur INT1 par appui sur un BP, et mon programe se lance, et je désactive donc l'interruption sur INT1, mais j'initialise un timer0, qi tourne tout au long de mon programme, mais quelques fois, lorsque j'appui sur mon BP durant le déroulement de mon programme, il prend en compte une interruption...comment faire pour éviter cela??
voila comment j'initialise et inhibe les int sur le BP:

//Autorise
GIE_GIEH=1;
INTEDG1=0;                                                      
INT1IE=1; 
INT0IE=0;
INT2IE=0;

//Interdit
GIE_GIEH=0;
INT1IE=0;

et pour mon timer:

T0CON = 0x87;		// Initialisation timer0 - Enable Timer0/16bits timer/
  GIE_GIEH = 1;         // Autorise toutes les interruptions
  IPEN=1;
  //TMR0H = 0xE1;         // Fixe la valeur du registre TMR0H
  //TMR0L = 0x7C;         // Fixe la valeur du registre TMR0L
  TMR0IF = 0;           // Initialise le flag TMR0IF d'IT du Timer 0
  TMR0IE = 1;           // Autorise les interruptions de TMR0
  INT1IE=0;             //Interdiction des interruptions sur INT1

J'imagine que c'est lorsque j'initialise mon timer qu'il autorise les IT sur INT1, et pourtant j'ai mis INT1IE=0...

Avez vous une petite idée??
Merci d'avance
-----

[invite067d8d6c]

Coucou,

As-tu essayer d'interdire les interruptions avec de modifier les registres
GIE_GIEH=0;
puis
TMR0IF = 0; // Initialise le flag TMR0IF d'IT du Timer 0
TMR0IE = 1; // Autorise les interruptions de TMR0
INT1IE=0; //Interdiction des interruptions sur INT1
puis
GIE_GIEH=1;

[invite3c35244f]

Je te remercie...
mais après avoir essayé, j'ai toujours des interruptions sur INT1 suite à l'appui sur mon BP, mais cela toujours aléatoirement...
voila mon initialisation du timer...

  T0CON = 0x87;		// Initialisation timer0 - Enable Timer0/16bits timer/
  GIE_GIEH = 0;         // Autorise toutes les interruptions
  TMR0IF = 0;           // Initialise le flag TMR0IF d'IT du Timer 0
  TMR0IE = 1;           // Autorise les interruptions de TMR0
  INT1IE=0;             //Interdiction des interruptions sur INT1
  GIE_GIEH = 1;         // Autorise toutes les interruptions

Merci davance

[Gérard]

Bonjour,
Il y a un truc qui m'échappe : tu interdis INT et tu as quand même l'interruption ?

[A voir en vidéo sur Futura]

[invitef26bdcba]

Salut,

Montre ton code d'interruption d'INT1...

A mon avis, dans la routine d'interruption, tu ne vérifies pas INT1IE.
Il faut suivre la procédure suivante :

INT1IE = 1 -> oui, continuer test; non tester autre interruption possible.

INT1IF = 1 -> oui, exécuter code d'interruption INT1; non, sortir d'INT.

P.S. : l'interruption d'int1 n'est pas aléatoire, c'est l'interruption du timer0 qui permet d'exécuter le code de l'int1...

David.

[invite5637435c]

Salut,

tu pourrais préciser quel PIC tu utilises.

Je ne vois pas d'autorisation du genre PEIE=1 (?!) qui gère les interruptions périphériques.
@+

[invitef26bdcba]

Salut Hulk,

Comme il y a le bit IPEN, c'est au minimum un 18F.

Sinon, pour le timer0 et INT1, ce n'est pas nécessaire de gérer PEIE. Elles sont toutes les deux en haute priorité vu qu'il n'y a pas de gestion des bits de priorité pour INT1 et TMR0 dans ce bout de code.

David.

[invite3c35244f]

Bonjour,

voila les routines d'IT

#pragma vector=8
__interrupt void DEMARRAGE (void)
{
  if(INT1IF)                                                                    //Présence d'un interruption sur INT1
  {
  myState = START;                                                              //Démarrage du programme
  INT1IF=0;                                                                     // Effacement du flag d'interruption
  }

  if(TMR0IF)                                                                    //Présence d'un interruption sur Timer0
    {
    TMR0H = 0xE1;                                                               // Valeur pour obtenir un Timer de 400ms
    TMR0L = 0x7C;                                                               // Valeur pour obtenir un Timer de 400ms
    flagIT_Backlight++;
    flagIT_ScreenStandby++;
    TMR0IF = 0;                                                                 // Effacement du flag d'interruption
    }
}

Et en ce qui concerne le PIC, il s'agit d'un 18f4685...
Merci d'avance pour votre aide

[invitef26bdcba]

Salut,

Bien oui, c'est bien ce que je disais au post#5...

Dans la routine d'int, il faut tester INT1IE avant d'autoriser l'accès à la routine de gestion INT1...

Donc rien d'aléatoire, c'est bien l'entrée en INT du tmr0 qui donne accès à l'int INT1!

Ce n'est pas du fait que tu désactives INT1IE que le flag INT1IF ne se positionne pas...
Le flag INT1IF se positionne même si tu désactives INTIF.

David.

[invite3c35244f]

Ok,
je dois donc écrire comme routine d'IT:

#pragma vector=8
__interrupt void DEMARRAGE (void)
{
  if(INT1IF)                                                                    //Présence d'un interruption sur INT1
  {
    if(INT1IE)
      {
       myState = START;                                                              //Démarrage du programme
       INT1IF=0;                                                                     // Effacement du flag d'interruption
      }  
}

  if(TMR0IF)                                                                    //Présence d'un interruption sur Timer0
    {
      if(TMR0IE)
        {
         TMR0H = 0xE1;                                                               // Valeur pour obtenir un Timer de 400ms
         TMR0L = 0x7C;                                                               // Valeur pour obtenir un Timer de 400ms
         flagIT_Backlight++;
         flagIT_ScreenStandby++;
         TMR0IF = 0;                                                                 // Effacement du flag d'interruption
        }
}
}

Es ce bien cela??
Merci encore...

[invitef26bdcba]

Oui, c'est cela...

Mais inverse le test, en premier INT1IE et ensuite INT1IF : c'est bien plus logique.

David.

[invite3c35244f]

Et donc la meme chose pour le timer, d'abord TMR0IE et ensuite TMR0IF??

[invitef26bdcba]

Oui...

Même principe pour tous les types d'INT dans la routine d'interruption, on ne vérifie le flag d'int qu'à la condition que l'interruption soit autorisée.

David.

[invite3c35244f]

Je te remercie pour tes conseils...j'en prends note...
Bonne journée

[RISC]

SAlut,

J'ai vu une erreur plus haut dans ton code.
On ne DOIT pas tester le flag d'autorisation d'interruption dans la routine d'interruption !!!!
Comment pourrais-tu venir dans l'interruption si ce bit n'était pas activé (le test sera toujours vrai) ????

Il suffit de tester le flag de status exemple INT1IF

============================== ===========================
#pragma vector=8
__interrupt void DEMARRAGE (void)
{
if(INT1IF) //Présence d'un interruption sur INT1
{
// if(INT1IE) --> non nécessaire...TOUJOURS VRAI !!
// {
myState = START; //Démarrage du programme
INT1IF=0; // Effacement du flag d'interruption
// }
}

if(TMR0IF) //Présence d'un interruption sur Timer0
{
// if(TMR0IE) --> non nécessaire toujours vrai
// {
TMR0H = 0xE1; // Valeur pour obtenir un Timer de 400ms
TMR0L = 0x7C; // Valeur pour obtenir un Timer de 400ms
flagIT_Backlight++;
flagIT_ScreenStandby++;
TMR0IF = 0; // Effacement du flag d'interruption
// }
}
}

a+

[Seb.26]

Comment pourrais-tu venir dans l'interruption si ce bit n'était pas activé (le test sera toujours vrai) ????

Pourquoi donc ???

La même routine est appelée par plusieurs sources d'IT et certains périph positionnent leurs "IT flag bit" même si le "IT enable bit" est à 0 ... ... donc dans certains cas, cela semble en effet prudent de tester d'abord le "IT enable bit" pour être certain que l'on doive traiter ce "IT flag bit" ...

Non ?

[invite3c35244f]

Tout ce que je peux dire, c'est que sans le test d'autorisation avant le flag d'interruption, mon programme était parfois aléatoire, pourtant il me semblait logique mais depuis que j'ai rajouté ce test, tout fonctionne correctement,...du moins la partie interruption, car je rencontre des problèmes d'affichage du a un changement de microcontrolleur (je suis passé du 18F4620 au 18F4685, et depuis l'envoie des données est faussé...)donc si vous avez une idée sur ce sujet, j'ai déjà crée un sujet sur cela...
http://forums.futura-sciences.com/thread238054.html

Bonne fin de journée

[invite5637435c]

Salut,

seb26, je ne comprends pas ton explication, j'aurai donné la même réponse que RISC.

Pour moi pour que INT1IF soit prise en compte il faut nécessairement que INT1IE soit activée.
A la limite tu peux modifier l'activation (INT1IE=0) une fois dedans pour bloquer un futur passage une fois ce passage fait.
Ou utiliser cette condition mais dans une autre source d'interruption.
@+

[invite5637435c]

Par contre il faut regarder comment tu as déclaré ta variable qui est modifiée dans l'IT.
Il faut lorsque une variable est modifiée en arrière plan (interruption par exemple), la déclarer par "volatile", sans quoi le programme ne fonctionnera pas correctement.
Cette déclaration indiquera au compilateur de ne pas optimiser cette variable car celle ci peut être modifiée à tout instant.
Refait un essai en déclarant "mystate" comme "volatile char mystate;".

[invite3c35244f]

Bonjour,

merci pour ces petits conseils, et en ce qui concerne mes flagIT... dois je aussi les déclarer en volatile??
Merci d'avance

[invite5637435c]

Non, uniquement les variables que tu crées et qui sont susceptibles d'être modifiées par l'IT et utilisées dans le programme principal.

[invite3c35244f]

Donc mes variables flagIT_Backlight et flagIT_ScreenStandby sont aussi a mettre en volatile...car je les incremente a chaque IT...
Non??
Merci encore

[invite5637435c]

Oui c'est ça.

[invite067d8d6c]

Bonjour,

Comme l'as dis Seb.26 il peut y avoir un problème si on ne teste pas le bit Enable.
Si on prend un compteur, il n'y a pas de soucis. Le fait de mettre le Enable à 0, fera que le flag Overflow, ne sera pas mis à 1!!
Par contre pour l'interruption externe, le flag peut passer à un même si l'interruption n'est pas active. Du coup, lorsqu'une interruption va arriver, ici c'est le timer0, le seul test du flag ne suffit pas!
Une autre solution est de traiter en premier le flag du timer puis un return (si c'est bien une interruption due au timer). Du coup le flag INT0 n'est pas traité si l'interruption est due au timer!

[Seb.26]

Salut,
seb26, je ne comprends pas ton explication, j'aurai donné la même réponse que RISC.

Ce que je veux dire, c'est que par exemple l'UART positionne RCIF que RCIE soit à 1 ou à 0 ...

Donc si pour une raison x ou y, les IT Rx de l'UART sont désactivée dans certaines portions de code, il faut absolument tester RCIE avant d'effectuer le traitement, car on ne peut pas savoir quelle est la cause de l'IT avec seulement les flags ...

[invitef26bdcba]

Salut,

Salut,

seb26, je ne comprends pas ton explication, j'aurai donné la même réponse que RISC.

Pour moi pour que INT1IF soit prise en compte il faut nécessairement que INT1IE soit activée.
A la limite tu peux modifier l'activation (INT1IE=0) une fois dedans pour bloquer un futur passage une fois ce passage fait.
Ou utiliser cette condition mais dans une autre source d'interruption.
@+

Vous m'étonnez fortement pour des programmeurs aguerris...

Quand il y a plus d'une source d'interruption pour le vecteur haute priorité (ou basse priorité), il est impératif (et même obligatoire) de tester le flag d'autorisation d'interruption avant de tester le flag d'interruption lui-même sous peine de bug majeur!

Je reprends l'exemple de Jorgin :

Il interdit l'accès à l'interruption du BP sur l'INT1 et ensuite il appuie sur le BP; donc le flag INT1IF se positionne mais n'entre pas en interruption car il vient de l'interdite. Jusque là, tout est normal et va pour le mieux.

Ensuite, survient une INT du timer0 et donc on passe au vecteur d'interruption haute priorité.

Dans l'ordre du programme de Jorgin :
- On traite l'interruption d'INT1IF qui est interdite mais dont le flag est positionné, car au préalable on n'a oublié de faire un test élémentaire sur le flag d'autorisation d'interruption. Et oui, voilà un Bug monumental !
- On traite l'interruption du Timer0 dont le flag d'INT est positionné.
- On sort d'interruption.

Ici, c'est le cas typique du traitement d'une interruption que l'on a interdite au par avant...

Maintenant, si on fait systématiquement un test sur le flag d'autorisation d'interruption, il devient impossible de traiter le flag d'interruption, même si celui-ci est positionné.

Cette description rapide, fait partie des bases de l'Assembleur, mais je vois qu'en C, ces bases incontournables on tendance à disparaître...

David.

[Seb.26]

Vous m'étonnez fortement pour des programmeurs aguerris...

C'est un forum d'électronique ici, les gens sont des "hardeux" qui touche au soft ...
... Perso, c'est le contraire : je suis un softeux-pisseur-de-code qui touche (de loin) au hard ...

Mais pour des "hardeux", certains se débrouillent pas si mal je trouve !
( En tout cas nettement mieux que moi en hard !!! )

[invitef26bdcba]

Si on prend un compteur, il n'y a pas de soucis. Le fait de mettre le Enable à 0, fera que le flag Overflow, ne sera pas mis à 1!!

Je ne l'avais pas lue cette affirmation...

Heureusement que c'est inexact, car il serait impossible de détecter le débordement par simple polling périodique du flag...
Qu'il y ait activation ou non de l'interruption, le flag de débordement se positionne au moment du débordement.

La seule exception qui me revienne pour le moment, quant au positionnement d'un flag d'indication (mais qui ne concerne pas les interruptions) est :

Le flag TXIF (buffer tampon vide pour une transmission USART) qui ne se positionne qu'à la condition unique d'avoir TXEN actif (interface UART en service).
Tant que TXEN est inactif, même si le buffer tampon est vide, TXIF ne se positionne pas...

Une autre solution est de traiter en premier le flag du timer puis un return (si c'est bien une interruption due au timer). Du coup le flag INT0 n'est pas traité si l'interruption est due au timer!

Attention avec ce genre de pratique, car l'ajout d'une nouvelle source d'interruption pourrait être cause de bug suivant l'emplacement de cette nouvelle routine...

Sinon, pour sortir d'INT en principe c'est un RETFIE et non un return.

David.

[invite067d8d6c]

oui désolé des approximations

mais en général, pour le timer, quand je coupe l'interruption, je coupe aussi le compteur
Pour le return, c'est une chose à laquelle je n'avait pas pensé! J'en prend note