[LP_2]

Bonjour

Page 66, détermination de la cause d'un reset, l'état non déterminé d'un bit est noté soit x soit u.
u comme unchanged, mais pour la détermination de la cause on le considère comme noté x, c'est à dire "n'importe quelle valeur".

Exact ?

[satinas]

Hello,
Le 2ème tableau permet de déterminer la cause du reset, et il n'y a qu'un seul x, qui voudrait dire que lors d'un Power-on Reset, la valeur du bit /BOR est indéterminée. Dans ce cas je ne vois pas comment différencier les POR et BOR resets. Il devrait être à 1 pour indiquer que ce n'est pas un BOR reset. C'est peut être infaisable au niveau hardware, ou lié au fait que le BOR peut être inhibé dans la config hardware du pic.
On peut quand même les différencier car lors de la mise sous tension on a bien le bit /POR à 0, ensuite il faut mettre par soft 1 dans les bits /POR et /BOR, et au prochain reset si le bit /POR est à 0 c'est un POR reset, et si c'est le bit /BOR qui est à 0 c'est un BOR reset.

[LP_2]

Merci

Je pensais, à chaque reset, stocker les bits concernés en mémoire programme pour traiter tous les cas.
Pour moi c'est un exercice, mais est-ce que c'est utile dans la vraie vie en-dehors du débuggage ?
Utilisé par un superviseur qui détecte un nombre croissant de BOR (hop -> remplacer l'alim) ?

De toute façon ça n'avancera pas vite, il fait un peu froid dans la pièce où je "travaille".

[satinas]

Mon métier n'était pas l'électronique, et dans tout ce que j'ai pu faire en amateur, je ne me suis jamais préoccupé du BOR. Je n'ai donc pas d'expérience en la matière.