Répondre à la discussion
Affichage des résultats 1 à 21 sur 21

Bug!!!!!!



  1. #1
    aabdoos

    Question Bug!!!!!!


    ------

    salut a tous, ( je crois que g besoin d'une retraite.. ) .
    voila mon code :
    j'utilise comme outil de developpement le logiciel PICC (PCM/PCW/PCH).
    //---------------------------------------------------
    #include<16F84A>

    #FUSES XT,NOWDT,NOCP,NOPUT

    void led()
    {
    int i;
    for (i=0 ; i <= 5 ; i++)
    {
    input_a(0xf1) // 0xf1 ou 0xff
    delay_ms(100);
    input_a(0x00);
    delay_ms(100);
    }
    }

    void main()
    {
    SET_TRIS_A(0x00); // mettre le port a en sortie
    SET_TRIS_B(0xFF); // mettre le port b en entree

    while(TRUE)
    {
    if (input_b()) // si un signale intervien
    led(); // sur le port b, appeler led()
    }

    }
    //-----------------------------------------------
    je voulais par ce code programmer mon PIC16F84A que chaque fois quand un signal intervien sur l'une des broches du port B que toutes les broches du PORT A emettent a la fois 5 impultions de 100ms. mais apparament mon PIC reagis autrement,( je dispose d'une maquette d'essay pour PIC16f84a que g consu .... genre des LEDs par chaque sortie/entree pour visualiser les signaux entrants/sortants).alors
    quand j'envois un signal sur l'une des broches du PORT B les LEDs du port A commence a clignoter sans s'arreter (ils depassent 5 fois), mais... just apres que le signal que j'emet sarrete ( etat logique 0) les LEDs s'arretent aussi de clignoter (tant que j'emet le signal ,les LEDs clignotent).
    ce que je voulais moi.....c quand un signale intervien sur le port B que le port A (tt les broches)envoi 5 impultions de 100ms ....et que si jamais un autre signal intervien sur l'une des broches du port B, que le programme l'ingnore , et quand qu'il termine ( sort de la fonction LED()) , qu'il ecoute/lit le port B en permanance jusqu'a ce qu'un autre signal intervien.
    ALORS.....ai-je comis une erreur quelque pars dans mon code ?
    svp si quelqu'un peux m'aider, j'en serai reconaissant.
    merci d'avance pour vos reponses .

    -----

  2. Publicité
  3. #2
    nams2590

    Re : Bug!!!!!!

    Salut,

    Je manque de temps pour terminer, mais c'est c'est plutôt de cette manière la qu'il faut que tu écrive ton programme :

    // Déclaration des sous programmes
    void led(void);
    void delay_ms(char millisec);

    // Programme principale
    void main()
    {
    TRISA=0x00; // mettre le port a en sortie
    TRISB=0xFF; // mettre le port b en entree

    while(1)
    {
    while((PORTB==1)||(PORTB==2)|| (PORTB==4)...)
    { // si un signale intervien
    led(); // sur le port b, appeler led()
    }
    }

    }

    void led(void)
    {
    int i;
    for (i=0 ; i <= 5 ; i++)
    {
    PORTA=0xf1; // Allume LEDS portA
    delay_ms(100);
    PORTA=0; // Eteint LEDS portA
    delay_ms(100);
    }
    }

    void delay_ms(char millisec)
    {
    OPTION=2;
    do
    {
    TMR0=0;
    while(TMR0<125);
    }
    while(-- millisec>0);
    }
    namselectro

  4. #3
    aabdoos

    Red face Re : Bug!!!!!!

    Citation Envoyé par nams2590
    Salut,

    Je manque de temps pour terminer, mais c'est c'est plutôt de cette manière la qu'il faut que tu écrive ton programme
    merci pour votre reponse, mais mon code est juste , je ne sais pas avec quel outil de developpment vous travaillez mais il parais que le votre aussi et just sauf que les deux codes n'utilisent pas ni le meme syntaxe ni le meme mode de declarations des fonctions.
    pour bien preciser, par expl vous ete besoin de declarer une fonction void deay_ms() dans votre code , alors monsieur, mon compilateur connais la fonction delay_ms() sans la lui declaree car elle est deja declaree dans ces libreries.
    vous avez mis TRISA = 0XFF alors que mon compilateur connais SET_TRIS_A(0XFF) .
    vous avez mis PORTA = 0XFF alors que mon compilateur conais input_a(0XFF) .
    vous voyez ce que je veux dir, nous sommes completement daccor mais nos compilateurs sont differents.
    a ce qui concerne les prototypes des fonctions, je c pas mais , je vais essayer quand meme.......meme si je ne vois pas l'utilite de declarer les prototypes seuls au debut ...car ca revien en meme ou presque.
    bon je confirmerais plustard le truc des prototypes.
    merci pour votre temps

  5. #4
    aabdoos

    Smile Re : Bug!!!!!!

    ahh....
    et a ce qui concerne la fonction "input_b()", elle retourne l'octet du port B, donc pas la pein de mentionner tout les cas possibles, seulement si elle retourne une valeur supperieur a 0 alors le programme sais qu'il ya un signal sur une des broches du port B sinon le programme retest l'octet....et ainsi de suite

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

    Question Re : Bug!!!!!!

    re , nnnnon.....ca n'a pas marcher comme j'ai mdoute, il a donne le meme resultat.
    quelqu'un svp a une brillante idee ?
    merci

  8. #6
    nams2590

    Re : Bug!!!!!!

    En fait, les fonctions que tu utilises sont déja compris dans le fichier "16F84.h". Mais apparement, ce n'est pas cela qui te pose problème. Je ne vois pas ce qui te pose problème dans ton programme.

    Est-ce que la compilation s'effectue correctement ou pas?

    Est-ce que tu simule ton programme après compilation, pour vérifié son fonctionnement?

    ...
    namselectro

  9. Publicité
  10. #7
    Gérard

    Re : Bug!!!!!!

    Je pense que ton prog fonctionne comme tu veux si la durée de l'évènement sur le port d'entrée dure moins longtemps que le clignotement de tes LED, en effet, quand la séquence du clignotement est terminée ET l'entrée est vue active, le clignotement reprend.
    J'espère que mon explication est claire.
    Gérard.

  11. #8
    aabdoos

    Question Re : Bug!!!!!!

    re les gars, merci dabord pour vos reponses.
    bon.., oui j'ai simule mon code et ca ete encore pire , quand je met le simulateur en marche, ce dernier simule un power up reset, alors les LEDs clignottent sans arret, g associer un boutton a une entree du port B , meme si je click dessu sa ne change rien, ce qui prouve que le problem reside dans le code.
    et pour le truc de la periode de l'impultion sur le port B qu'elle doit etre inferrieur au delay de la fonction led(),je peux dir que je peux meme augmenter le delay dans les iterations de la boucle for ( expl : delay_ms(1000)), chui pas oblige de respecter les 100ms donc ce que je veux , quand j'emet une impultion < delay_ms( delais ) que les leds clignottent 5 fois a une frequance de mon choix ( delay_ms( )) .
    quand j'ai uploader mon code dans mon PIC , quand je met le pic en marche, touts les LEDs sont eteintes, et quand j'envoi une impultion ya deux cas:
    1) quand j'envois un impultion ,les LEDs clignotent tant que l'impultion est mintenue en etat logique hot ( 1 logique)
    et je veux dir par "tant que" qu'ils clignottent sans arret .
    2) quand j'enleve la boucle while ,le code devien ainsi :
    void main()
    {
    bla
    bla
    ...
    ..

    if(input_b)
    led();
    }

    alors la , quand je met mon pic sous tension, quand j'emet une impultion, la reaction et pareil au premier cas, mais quand je mintien le signal sur le portB, les LEDs clignotent exactement 5 fois et puis ils s'arretent.
    puis je reemet un autre signal......et ainsi de suite
    mais le pb c'est je doit mintenir le signal, et moi je ne veux pas de ca.
    que direz vous de ca ?

  12. #9
    PA5CAL

    Re : Bug!!!!!!

    Bonjour

    J'en dis qu'après les 5 clignotements, il faudrait tester l'état du port B et s'assurer qu'il a été modifié avant de continuer.
    Dernière modification par PA5CAL ; 21/05/2006 à 08h59.

  13. #10
    PA5CAL

    Re : Bug!!!!!!

    Du style:

    Code:
    b=input_b();
    if (b) {
      led();
      while(b==input_b())
        { }
    }

  14. #11
    aabdoos

    Thumbs up Re : Bug!!!!!!

    bravo PA5CAL, ca marche mtn comme je le veux, aussi en simulateur que en reele,merci pour votre aide. mais il rest une toute ptite chose , votre code n'ignore pas les autres signaux intervenant, quand j'envois une impultion les LEDs au porta clignottent exactement 5 fois mais si lors du clignottment j'envois une autre impultion la fonction led() et re-appeler.expl :
    - impultion sur portb
    - LEDs au porta clignottent
    - 1 foie
    - 2 fois
    - j'envois maintenant une autre impultion.
    - LEDs au porta clignottent
    - 1 foie
    - 2 fois
    ......
    - 7 fois
    (on constate donc que la fonction led() est re-appele ),puis elles s'arretent.
    ou reside le pb donc ?

  15. #12
    PA5CAL

    Re : Bug!!!!!!

    Ça fait ça même quand la deuxième impulsion se termine avant l'extinction du cinquième clignotement des leds ?

  16. Publicité
  17. #13
    aabdoos

    Question Re : Bug!!!!!!

    bahh oui !!! justement c'est ca le probleme, meme si l'impultion ne dure que 1ms et que le systeme et meme lors l'extinction du premier clignottement des LEDs , la fonction led() et re-appelee c dingue.....le code parait logique et devrais foctionner correctement.
    des suggestions ??
    Dernière modification par aabdoos ; 21/05/2006 à 15h41.

  18. #14
    PA5CAL

    Re : Bug!!!!!!

    Il y a un effet de mémoire quelque part...

    Comment est réalisé le dispositif qui fournit l'impulsion ?

    Si c'est un bouton-poussoir branché entre +Vcc et l'entrée du port, y a-t-il bien une résistance de pull-down qui draine les charges vers GND quand on a relâché le bouton ?

  19. #15
    aabdoos

    Question Re : Bug!!!!!!

    oui j'envois une impultion avec un simple boutton pousoir qui prend le courant du VCC .
    et non je n'utilise pas de resistances de pull-down entre les entrees du prortB et le GND, si je doit en avoir c qu'elle valeur de resistance dois -je choisir ( sachant que j'envois des impultions de 5volts )?
    et y'at il une relation avec la configuration des tirages au plus (pull-up) dans le code?
    merci

  20. #16
    aabdoos

    Exclamation Re : Bug!!!!!!

    ca resemble un px pres a ca mon testeur de PIC, je crois que la resistance joue le role de la resistance de pull down non ?
    ya le meme branchement pour chaque broches des deux port ( A & B) pour les de modes (lecture ou ecriture).
    ya pas d mal en ca non ?
    merci
    Images attachées Images attachées  

  21. #17
    aabdoos

    Exclamation Re : Bug!!!!!!

    dsl voici le chemat correct, mais juste une chose...soyant logique je ne crois pas que cette resistance qui fais le bug car si c'a ete le cas , il ne fera pas de meme dans le simulateur.
    que dites vous ?
    Images attachées Images attachées  

  22. #18
    Gérard

    Re : Bug!!!!!!

    La LED ne devrait-elle pas être branchée sur le portA ?
    Gérard.

  23. Publicité
  24. #19
    PA5CAL

    Re : Bug!!!!!!

    Le problème, c'est qu'en l'absence de résistance de pull-down, l'entrée du port, si elle ne reste pas à un niveau logique indéterminé, du moins présente une impédance tellement élevée que sa capacité parasite met un temps non négligeable à se décharger. Et donc après avoir relâché le bouton, l'entrée tarde à revenir au niveau logique 0.

  25. #20
    aabdoos

    Thumbs up Re : Bug!!!!!!

    PA5CAL mais vs mairitez vraiment un badge. effectivement oui c t cette resistance qui faisait le bug, j'ai laisse le chemat telquel et j'ai ajoute une resistance de 1K entre la sortie de l'interrupteur et la masse GND.
    et ca a marche impec merci vous m'avais vraiment aider.
    merci aussi a tt ceux qui ont pris de leur temps pour m'aider.
    a tres bientot.

  26. #21
    PA5CAL

    Re : Bug!!!!!!

    [Mode "j'me la pète" on]
    De rien. Ça me paraissait évident.
    [Mode "j'me la pète" off]

Discussions similaires

  1. un bug ?
    Par kevolgros dans le forum Logiciel - Software - Open Source
    Réponses: 2
    Dernier message: 19/01/2007, 16h33
  2. un bug ?
    Par hotto dans le forum Logiciel - Software - Open Source
    Réponses: 6
    Dernier message: 07/01/2007, 23h08
  3. bug
    Par DB2TE dans le forum Internet - Réseau - Sécurité générale
    Réponses: 7
    Dernier message: 13/07/2006, 09h09
Découvrez nos comparatifs produits sur l'informatique et les technologies.