Interruptions : changement de RB4-7 sur P16F84A

[invited82a1853]

Bonjour à tous,

Je me suis mis au PIC il y a peu de temps et je galère avec les interruptions qui doivent normalement se déclencher lors du changement d'état de l'une des broches RB4-7.

J'ai créé un programme de test tout simple que j'ai joint à ce message. Le programme devrait faire changer d'état une LED branchée sur la broche RA0 à chaque changement d'état de l'une des broches RB4-7. Le problème c'est qu'après la ligne 39, le bit 0 du registre INTCON reste à 1 :

bcf INTCON,RBIF ; Remise à zéro du flag

Donc une autre interruption est appelée dès le retfie, et la LED clignote tout le temps sans se stabiliser même s'il n'y a plus aucun changement sur RB4-7.

Le problème se produit aussi bien dans le simulateur qu'en vrai.

Fichier source : ici.

Merci.
-----

[invite98c276f8]

b4-b7 doivent être forcé à une valeur par une résistance. Sinon, tu recois canal plus sur tes 4 pattes

[invited82a1853]

Bonjour,

Oui j'y ai pensé mais ça n'a pas l'air d'être ça, d'autant que j'ai les mêmes problèmes dans le simulateur qui lui n'est pas sujet à ce genre de chose.

J'ai apporté une légère modification au programme : ici.

J'ai ajouté une temporisation avant de quitter la routine d'interruption, et je n'utilise plus que le port RB7 en entrée.

Avec ce programme, si je mets RB7 à l'état haut alors la LED sur RA0 clignote au rythme de la temporisation (donc l'interruption tourne en boucle alors que je laisse RB7 à l'état haut donc sans changement). Si je mets RB7 à l'état bas, la LED reste dans l'état où elle était quand le changement d'état s'est produit.

J'ai le même résultat avec le simulateur sauf que l'interruption tourne en boucle même quand RB7 est bas.

Avec le debugger je vois que l'instruction : bcf INTCON,RBIF n'a aucun effet sur le bit0 de INTCON, et ce n'est pas un problème de bank0.

J'ai essayé le même genre de programme avec un autre type d'interruption et ça marche. Bref je ne comprends pas pourquoi je n'arrive pas à utiliser les changements d'état...

[invited82a1853]

Bon alors j'ai trouvé la solution à cette adresse : http://www.phanderson.com/PIC/16C84/...pt_change.html

Je résume ici pour ceux qui auraient le même problème et qui ne voudraient pas lire tout ça.

En fait pour déclencher cette interruption le PIC compare l'état du port B avec une sauvegarde qu'il fait à chaque lecture du port. Donc quand l'interruption est appelée si on ne lit pas le port la sauvegarde reste la même tout le temps et l'interruption est appelée tant que l'état réel du port est différent. Il faut donc à tout prix lire le port dans la routine d'interruption pour mettre à jour cette sauvegarde !

[A voir en vidéo sur Futura]

[invited82a1853]

Bonsoir,

Je ne refait pas un nouveau sujet car même si le problème est un peu différent il touche quand même les µC et les i/o sur mon port B...

Sans entrer dans les détails j'ai un système d'alarme qui est géré par un 16f84. On a donc sur les entrées : des capteurs (de mouvements, d'ouvertures, etc) et sur les sorties : des sirènes ou des témoins lumineux par exemple. Le problème est que de temps en temps sans qu'on ne touche à rien, j'ai l'alarme qui s'active ou se désactive toute seule et même pire, qui se met à crier des fois toute seule alors même qu'elle n'est pas activée ! Tout se passe comme si mes entrées se mettaient à la masse toute seule de temps en temps. J'ai fait un petit programme test tout simple, sans interruption ni rien et juste avec les fonctions de base, qui enregistre dans l'eeprom tous les évènements (activation, désactivation, passage, ouverture de telle porte, etc) ainsi que l'heure courante pour chaque évènement afin de voir un peu ce qui se passe. Après une journée de test il y avait à peu près n'importe quoi dans l'eeprom. Je compte refaire ce test pour être sur que je ne me suis pas trompé parce que quand même ça me semble très bizarre...

Alors bien sur vous allez me dire que mes programmes sont "buggués" de partout lol, mais apparement non puisque quand je teste le système en remplaçant les sirènes par des leds et les capteurs par des poussoirs, et que je mets tout ça sur une plaque de test tout fonctionne très bien. Tout a l'air de fonctionner aussi avec le simulateur (sur PC) même si j'avoue ne pas l'avoir testé dans la durée. J'avoue que je ne comprends pas... il n'y a pas 36 solutions :

• Problème d'alimentation mais je ne pense pas vu que le pic est alimenté par un LM317 qui régule tout ça.
• Problème de faux contacts (soit dans les raccordements, soit sur la plaque électronique elle-même).
• J'ai aussi pensé que la longueur des fils pouvait poser des problèmes si le pic est trop sensible (parasites). J'utilise le tirage au + interne pour les entrées du port B. Quand on appuie sur un poussoir pour activer l'alarme par exemple, ça met l'entrée correspondante à la masse. Je ne sais pas s'il peut y avoir un problème avec tout ça ???
• Est-il possible que le pic soit endommagé et qu'il adopte des comportements aléatoires par moment ??
• Autre chose ??? Problème de quartz ? Manque un condo quelque part ??

Je compte tester tout ça bien sur. Je vais regarder la tronche de ma tension d'alim à l'oscillo. Je vais tester en branchant ma plaque test à la place du circuit actuel. Je vais refaire le test avec l'enregistrement en eeprom. Je vais tester avec le circuit électronique définitif mais en ne branchant que des leds et des poussoirs sur les i/o à la place des vrais témoins et capteurs (pour éviter les problèmes de longueur de fils et de faux contacts dans les raccordements). Bref je vais faire tout ça et je vous tiendrai au courant dans ce fil, mais si en attendant quelqu'un pouvait avoir une idée de génie ou me dire, sachant un peu où j'en suis, si je suis les bonnes pistes ou pas, ce serait formidable.

Merci et à bientôt pour la suite...

(Désolé pour toute la lecture mais c'est pas facile d'expliquer sans s'étendre de trop.)

[invite98c276f8]

bon, si tu utilises un treès long cable et que tu utilises le weak pullup, tu risques de chopper des parasites suffisants pour déclancher.

Je te conseille :
1 de placer une résistance de (1k à 10k) vers le 5V sur les pattes d'entrée.
2 De placer un condensateur assez sympa (100nF) entre les pattes d'entrée et la masse.

En fonctionnement normal, ta résistance débite dans le pic (5V/1k = 5mA par patte, 5V/4.7k~1mA). Si un parasite arrive, il est en partie absorbé par le courant. (c'est schématique). D'autre part comme tu as mis un condensateur, le parasite décharge la capa mais le 5V reste suffisament présent pour que tout se passe bien.

Du côté de ton contact, si tu fais contact, ca descend la patte du pic directement sur la masse, ca vide le condensateur "violement".... Et lorsque tu relaches le contact, le PIC voit la tension remonter lentement en 1k*100n= 100µs...
De même une perturbation qui ne soit pas un contact direct à la masse doit durer environ ce même temps...
Si tu montes la valeur du condensateur, ca aide aussi...



1 :

[invited82a1853]

Ok merci.

Je vais essayer ça.

Sinon entre temps j'ai refait le test avec mon programme qui enregistre tout ce qui se passe en eeprom. Je l'ai fais tourner sur un pic avec la plaque de test, des leds et des poussoirs, et d'un autre côté sur un autre pic avec les vrais capteurs etc. Je l'ai laissé tourner environ 15 heures. Sur le pic "de test" tout a bien été enregistré, j'ai l'historique de tous mes appuis sur les poussoirs avec l'heure et tout alors que sur le pic "en condition réelle" l'eeprom contient n'importe quoi. Je veux dire des trucs pas très cohérents voire même des trucs qu'il n'est pas possible d'inscrire dedans (aucune branche du programme ne permet ça). Donc l'hypothèse des parasites sur les entrées me semblait bonne aussi, mais là... je ne vois pas comment ça pourrait faire faire des trucs qui ne sont pas programmés. Il faut que je reteste en échangeant les deux pics pour voir s'il n'y en a pas un qui est défectueux mais à priori je ne pense pas...

A suivre donc...

[invite98c276f8]

Ah, oui, SI c'est pas fait :
ajoutes une capa de 100nF sur le Vss/Vdd de ton pic (au plus près du pic)
et une capa de 100µ au niveau de l'entrée de l'alim de ta carte...

[invited82a1853]

Il semblerait que les condos et les résistances sur les entrées améliorent déjà nettement les choses (avec un programme de test très simple qui ne supporte pas toutes les fonctionnalités et pendant 3h de fonctionnement seulement). Je préfère rester prudent pour l'instant et attendre quelques heures supplémentaires de fonctionnement pour être bien sur qu'il n'y a plus de problème. Si demain ça n'a toujours pas déconné alors je pense que ce sera réglé, dans le cas contraire... on verra bien...

Plus tard je rajouterai quand même des capas sur les broches vss/vdd au cas où. Merci.

[invite5aee2b41]

Je dirais même que les capas de découplage d'alim entre Vss et Vdd sont nécessaires. Quelque soit le CI je met toujours des capas de découplage.

[invited82a1853]

C'est bon j'ai mis des condos partout et ça tourne au poil.

Merci.