[PIC]gestion des interruptions
Répondre à la discussion
Affichage des résultats 1 à 10 sur 10

[PIC]gestion des interruptions



  1. #1
    invitec35bc9ea

    bonjour,
     Cliquez pour afficher


    j'utilise la fonction:
    Code:
    Delay10KTCYx(0);
    dans deux fonctions differentes (c'est le probleme de gestion des interruptions ou qqch comme ça non? enfin c'est ce que j'ai cru comprendre).
    ce qui fait que ce programme marche:
     Cliquez pour afficher

    mais pas celui-ci:
     Cliquez pour afficher

    donc si j'essaie de commander un moteur ça va mais deux non.
    comment resoudre ça? (ça equivaut à faire clignoter deux LEDs endependemment l'une de l'autre).

    **************

    deuxieme probleme:
    meme pour un seul moteur, je n'obtiens pas le fonctionnement voulu. certe il tourne mas pas de la facon que je veux:
    Code:
    /* Fonction init *///initialisation des positions des moteurs
    
    void init(){
    	if(PORTCbits.RC2){// action sur le bouton init
    		while(PORTCbits.RC0!=1){//tant que le moteur 1 ne rencontre pas le fin de course	
    			PORTDbits.RD1=1;//sens de rotation
    			while(1){//Step
    				PORTDbits.RD2 = 1;
    				Delay10KTCYx(0);
    				PORTDbits.RD2 = 0;
    				Delay10KTCYx(0);
    				posr1=posr1+1;//incrementation de la position du moteur 1
    			}
    		}
    		
    	posr1=0;//initialiser la position du moteur 1
    	posr2=0;//initialiser la position du moteur 2
    }
    
    /*****************/
    à RC0 et RC2 j'ai connecté deux boutons poussoirs avec des resistances de pull-down.
    donc au demarrage du pic RC0 et RC2 sont à niveau bas. et tout le port BD est à niveau haut.
    je veux avoir le fonctionnement suivant:
    une impulsion sur le BP de RC2 fait osciller RD2.
    meme en lachant le BP, RD2 continue à osciller.
    une impulsion sur RC0 (RC2 n'est plus appuié) arrete l'oscillation de RD2 qui garde le niveau de sa derniere oscillation.
    avec le bout de code ci-dessus, j'arrives à respecter les deux premiers points mais pas le 3eme: une implusion sur RC0 laisse le PIC indifferent.

    merci

    -----
    Dernière modification par gienas ; 03/05/2008 à 09h28. Motif: Demande auteur

  2. #2
    RISC

    Re : [PIC]gestion des interruptions

    Einstein,

    Je n'ai pas analysé tout ton code mais voici peut être une piste :
    1/ Supposons que ton programme principal utilise la fonction1
    2/ Supposons que ton interruption utilise aussi la fonction1

    Pendant l'exécution du programme principal, fonction1 est appelée ET manque de chance (merci Murphy) pendant que fonction1 s'exécute, ton interruption arrive.
    Ton interruption utilise aussi fonction1. Les paramètres de fonction1 vont donc être écrasés par l'appel dans l'interruption et au retour dans le programme principal, fonction1 finira de s'exécuter avec les paramètres de l'interruption qui auront écrasés ceux de que fonction1 avait dans l'appel du programme principal.

    Ce cas est "facile" à détecter (et à résoudre voir ci-dessous) mais parfois c'est beaucoup plus vicieux...

    A/ Suppose que fonction1 dans le prog principal ait besoin d'une "sous-fonction" fonction2 qui ait elle même besoin de fonction3.
    B/ Suppose maintenant que fonctionA dans ton interruption utilise la "sous-fonction" fonctionB qui elle même utilise la "sous-fonction" fonction3
    Tu es alors en présence du même PB que précédemment mais c'est beaucoup plus difficile de détecter cela.

    C'est pourquoi il faut connaitre ce qu'on appelle les "dépendances" des fonctions (dependencies en anglais).
    Telle fonction utilise telle fonction qui elle-même utilise...

    Comment résoudre ce genre de PB :
    1/ Le compilateur analyse automatiquement tous les appels pour détecter ces PB potentiels : très compliqué car le compilateur doit alors être capable d'analyser simultanément tous les fichiers du projet....Le C18 n'est pas capable de faire cela. Par contre je crois que le compilateur HiTech possède cette faculté (analyse de tous les fichiers) mais je ne sais pas s'il analyse les dépendances...
    2/ Si tu as créé les fonctions toi-même, il suffit de dupliquer la fonction commune et de changer son nom ET ses arguments : fonction1 devient fonction1a et fonction1b
    fonction1a sera appelé par le prog principal et fonction1b sera appelé par l'interruption
    3/ Tu gardes la même fonction appelée par le programme principal et l'interruption mais alors tu dois prévoir dans la sauvegarde du changement de contexte, la préservation de l'espace de travail de cette fonction et sa restoration à la sortie de l'interruption.
    La conséquence de cela est bien sur un temps de latence allongé pour l'interruption qui peut évidemment entrainer des PB de temps-réel (cela dépend purement des temps de réponse dont tu as besoin).
    4/ La solution la plus simple est de ne PAS faire le traitement dans l'interruption mais plutôt dans le prog principal (quand c'est possible) et de dialoguer au travers de sémaphores.

    J'espère que cette explication un peu longue "éclaire" certains PB potentiels du C lorsque les interruptions utilisent des fonctions communes.

    a+

  3. #3
    invitec35bc9ea

    Re : [PIC]gestion des interruptions

    bonsoir,
    J'espère que cette explication un peu longue "éclaire" certains PB potentiels du C lorsque les interruptions utilisent des fonctions communes.
    à mois que l'ais mal compris, je n'ai pas l'impression que ça repond à ma question.
    Je n'ai pas analysé tout ton code mais voici peut être une piste :
    imaginons un programme qui ait le fonctionnement suivant:
    l'appui sur une bouton 1 fait clignotter une LED1
    independemment de ce qui precede, l'appui sur une bouton 2 fait clignotter une LED2.
    j'ecris le programme suivant:
    Code:
    void main(){
                    [...]
                    if(PORTCbits.RC0){
    			while(1){
    				PORTDbits.RD2 = 1;
    				Delay10KTCYx(0);
    				PORTDbits.RD2 = 0;
    				Delay10KTCYx(0);
    			}
    		}
    		if(PORTCbits.RC1){
    			while(1){
    				PORTDbits.RD6 = 1;
    				Delay10KTCYx(0);
    				PORTDbits.RD6 = 0;
    				Delay10KTCYx(0);
    			}
    		}
                    [...]
    }
    et c'est là qu'est le problème: tel que fait maintenant j'ai un niveau indéfini pour RD2 et RD6

  4. #4
    invite2562e666

    Re : [PIC]gestion des interruptions

    Salut,

    Ton problème peut parfaitement être résolu par l'emploi d'un RTOS.

    th.

  5. A voir en vidéo sur Futura
  6. #5
    invitec35bc9ea

    Re : [PIC]gestion des interruptions

    tu peux developper stp?
    merci

  7. #6
    invite2562e666

    Re : [PIC]gestion des interruptions

    ton problème est assez typique, tu veux faire plusieurs choses en même temps. Par exemple avec un RTOS, tu as une "tache" qui commande un moteur, une seconde "tache" qui commande un aute moteur, une troisième qui scrute un clavier,...Le RTOS attubue successivement des fractions du temps CPU à chaque tâche, le CPU ne perds pas son temps à faire du "pooling"...

    Je ne vais pas développer (il faudrait plusieurs pages)mais te revoyer vers une intro que j'avais écrite :
    http://www.68hc08.net/modules/smarts...php?itemid=115

    cela doit aussi exister pour des pics.

    th.

  8. #7
    Seb.26

    Re : [PIC]gestion des interruptions

    RTOS = scheduler ...

    C'est ce que j'avais déjà essayé de t'expliquer ... fait toi une boucle qui exécute des taches ( drivers, appli ... ect ... )

    Et surtout : ne jamais bloquer le CPU, n'utilise que des automates d'états ...
    << L'histoire nous apprend que l'on apprend rien de l'histoire. >>

  9. #8
    RISC

    Re : [PIC]gestion des interruptions

    Bonsoir,

    Je n'ai pas vu de gestion d'anti-rebond dans ton logiciel...

    Si tu as des boutons poussoir ou des contacts mécaniques de fin de course, il faut impérativement gérer les rebonds par matériel ou par logiciel.

    Si les rebonds ne sont pas gérés cela produit des fonctionnements imprédictibles.

    a+

  10. #9
    invitec35bc9ea

    Re : [PIC]gestion des interruptions

    il faut impérativement gérer les rebonds par matériel ou par logiciel.
    entendu, mais je resoudrais ça un peu plus tard.
    C'est ce que j'avais déjà essayé de t'expliquer ... fait toi une boucle qui exécute des taches ( drivers, appli ... ect ... )

    Et surtout : ne jamais bloquer le CPU, n'utilise que des automates d'états ...
    desolé mais j'ai pas compris(ou peut etre oublié?).
    merci

  11. #10
    invite2d21c929

    Re : [PIC]gestion des interruptions

    Bonjour,

    je veux avoir le fonctionnement suivant:
    une impulsion sur le BP de RC2 fait osciller RD2.
    meme en lachant le BP, RD2 continue à osciller.
    une impulsion sur RC0 (RC2 n'est plus appuié) arrete l'oscillation de RD2 qui garde le niveau de sa derniere oscillation.
    avec le bout de code ci-dessus, j'arrives à respecter les deux premiers points mais pas le 3eme: une implusion sur RC0 laisse le PIC indifferent.
    A mon avis ce problème viens de ta boucle infinie "while(1)", essai de l'enlever et de tout mettre dans ton "while(PORTCbits.RC0!=1)"; avec peut être une gestion du sens de rotation conditionnelle.
    plus

Discussions similaires

  1. Quand s'executent les interruptions d'un PIC 16F877???
    Par invite483d8df8 dans le forum Électronique
    Réponses: 11
    Dernier message: 02/05/2008, 23h07
  2. PIC : Du retard sur les interruptions I2C
    Par invite828f1f07 dans le forum Électronique
    Réponses: 3
    Dernier message: 20/04/2008, 21h44
  3. Gestion des interruption avec un PIC
    Par schneiderj dans le forum Électronique
    Réponses: 3
    Dernier message: 08/03/2008, 17h26
  4. interruptions PIC 18F452
    Par invite86ad2abe dans le forum Électronique
    Réponses: 3
    Dernier message: 09/03/2005, 20h37
  5. interruptions portB PIC
    Par invitebf62768c dans le forum Électronique
    Réponses: 6
    Dernier message: 02/05/2004, 11h12
Dans la rubrique Tech de Futura, découvrez nos comparatifs produits sur l'informatique et les technologies : imprimantes laser couleur, casques audio, chaises gamer...