[JJE]

Bonjour à tous,
c'est plus pour ma culture, il est grand temps, parce que devant la difficulté, j'ai changé de méthode dans un projet de développement d'automate.
L'IT est armée dès qu'un changement est observé sur une broche du processeur. Si un changement sur une autre broche intervient avant qu'on ait eu le temps de désarmer le flag RBIF, ce changement ne sera pas vu. Il faut, a minima, 5 ou 6 micro-cycles.
Microchip le signale bien dans son datasheet (ici, page 49 du datasheet des 16F884 et consort).

Changes on one pin may not be seen when servicing changes on other pins

Pour palier ce problème, serait-il possible de concevoir un "circuit retard" qui, par exemple, sur front montant d'un pulse sur une patte, serait déclenché et retarderait un tel front montant sur une autre patte, voire plusieurs, quelques micro-secondes suffiraient et il faudrait que ce soit réciproque.
Merci

[Temps-x]

Bonjours JJE, et tout le forum,

Source du message Si un changement sur une autre broche intervient avant qu'on ait eu le temps de désarmer le flag RBIF, ce changement ne sera pas vu.

Exacte, j'ai peu être une solution à ton problème, qu'il faudrait vérifier par la suite.....mettre un condensateur sur les broches.

Si il y a un temps de retard ça devrait être pris en compte, c'est qu'une idée, il faut voir en pratique c'est fois-ci.

A+

[JJE]

merci temps-x,
j'y ai un peu pensé mais il faudrait que ce condensateur soit activé par front montant sur une autre broche.
et quel condo, on rejoint une autre question posée par ailleurs, ici

[Temps-x]

Re

En réfléchissant, pour la valeur du condensateur, je dirais 0,5 nF (faire des essais), il faut que ton condensateur garde sa charge, puis logiciellement quand tu traites la broche tu le décharges, ce qui permets d'avoir des pins en attente de traitement.

Source du message j'y ai un peu pensé mais il faudrait que ce condensateur soit activé par front montant sur une autre broche.

Rien ne t'empêche en sorti d'interruption de contrôler les broches

A+

[paulfjujo]

bonjour JJE et à tous,


si tu est à quelques cycles MCU pres pour voir des changements d'etats , ce n'est plus un automate
mais un analyser logique ou scrutateur d'etat .

il est vrai qu'ne milieu industriel, il m'est arrivé de devoir installer un scrutateur d'etat entre differents equipements dont des automates
pour resoudres des problemes pointus , du genre qui fait la poule et qui fait l'oeuf..
particulierement vrai avec par exemple des retours contacteurs (plusieurs mS de decalage) et des evenements rapides. .

il me semble qu'on doit relire l'etat du PORTB pour desactiver RBIF ?

si l'automatisme est chatouilleux à quelques cycles pres, il faut effectivement rajouter des monostables quelques part ..
circuit R + Capa si on traite le front descendant sur des entrees trigger , au lieu du front montant , pour allonger l'info ?
mais dans ce cas là .. c'est toutes les entrees qu'il faut traiter, afin d'eviter des decalages temporels entre les infos.

A ma connaissance , les entrees automates ont toujours un filtrage minimum de l'ordre de la ms voir plus sur les anciens automates (>=10 mS)
ne serait-ce que pour les rebonds mecaniques ..
ou alors entree rapide pour comptage ..

j'en etais resté sur un cycle de recopie image entree/sortie automate de l'ordre de la ms sur un SIEMENS 400
(et 50 à 100mS sur un vieux SMC600)

[JJE]

Salut temps-x

Source du message l me semble qu'on doit relire l'etat du PORTB pour desactiver RBIF ?

c''est tout à fait vrai.