Gestion autonome d’un afficheur led 7 segments 4 caractères

[Jeec]

Bonjour

Dans un système basé sur un Arduino, je souhaite utiliser un afficheur led 7 segments 4 caractères. J’ai prévu un registre à décalage 74HC595 par caractère, que l’Arduino pourra alimenter en fonction de l’évolution de l’information à afficher (affichage en continu), mais je ne veux pas utiliser ses ressources pour piloter en plus l’affichage circulaire des caractères. En effet, il sera occupé à une tâche temps réel très contraignante en bande passante.
J’envisage donc un dispositif électronique autonome, capable d'envoyer en permanence, et à tour de rôle, chaque caractère contenu dans son registre à l'afficheur. Connaissez-vous des CI capables de réaliser cette fonction?
-----

[Qristoff]

Tu peux reprendre la même idée et l'étendre à 4 digits
https://forums.futura-sciences.com/e...-segments.html

[Jeec]

Je n'ai peut être pas été très clair, mais pour ces raisons de bande passante, je ne veux pas commander les latch par des broches de l'Arduino, mais par un dispositif autonome.

[mag1]

Je n'ai peut être pas été très clair, mais pour ces raisons de bande passante, je ne veux pas commander les latch par des broches de l'Arduino, mais par un dispositif autonome.

Bonjour,
Comprends pas. Les latch permettent justement de mémoriser le caractère et de rafraichir l'affichage par un pulse bref uniquement quand c'est nécessaire. On évite le balayage continu. La ressource µC est très limitée.
J'ai dû rater quelque chose...
http://electromag1.wifeo.com/command...t-segments.php

MM

[A voir en vidéo sur Futura]

[Jeec]

et pour être encore plus clair, par lach je veux entendre les broches DIG1 à DIG4 de l'afficheur.

[Jeec]

Bon, je crois que j'ai trouvé le moyen d'activer mes broches d'afficheur les unes après les autres avec un HC4017, qui permet de produire des signaux successifs sur ses broches de sortie, et qui prend en entrée un montage de type oscillateur.
Reste plus qu'à m'en procurer et faire un essai.

[mag1]

et pour être encore plus clair, par lach je veux entendre les broches DIG1 à DIG4 de l'afficheur.

Et comme on ne sait toujours pas de quel afficheur il s'agit.....
MM

[carcan]

J'avais conçu il y a quelques temps un petit PCB qui supporte un afficheur 4x7 segments, un PIC pour le gérer, et je rentrais les valeurs à afficher en I²C... Le but était d'avoir plusieurs afficheurs dans un même appareil et de n'avoir que 2 IO et que très peu de ressources allouées sur le µC principal. C'est ce genre de chose que tu recherches ?

A+
Laurent

[Qristoff]

Je n'ai peut être pas été très clair, mais pour ces raisons de bande passante, je ne veux pas commander les latch par des broches de l'Arduino, mais par un dispositif autonome.

T'as peu être pas compris le principe du latch ? t'envoie une impulsion uniquement lorsque tu as besoin de changer la valeur du digit ! à un moment donné autonome ou pas, il faudra indiquer à l'afficheur qu'il doit changer et pour quelle valeur !

[Jeec]

Et comme on ne sait toujours pas de quel afficheur il s'agit.....
MM

Il s'agit de cet afficheur: gotronic.fr/art-afficheur-7-segments-rouges-4-digits-22872.htm2x Afficheur simple

[Jeec]

T'as peu être pas compris le principe du latch ? t'envoie une impulsion uniquement lorsque tu as besoin de changer la valeur du digit ! à un moment donné autonome ou pas, il faudra indiquer à l'afficheur qu'il doit changer et pour quelle valeur !

Je suis d'accord, à chaque changement de valeur, je programme un envoi en série pour l'affichage des segments de chaque caractère, puis une impulsion par caractère pour mettre à jour les registres, et pour cela, j'utilise les ressources du micro. Ce que je ne veux pas, c'est continuer à utiliser les ressources du micro pour assurer l'allumage en boucle des caractères de l'affichage.

[Jeec]

J'avais conçu il y a quelques temps un petit PCB qui supporte un afficheur 4x7 segments, un PIC pour le gérer, et je rentrais les valeurs à afficher en I²C... Le but était d'avoir plusieurs afficheurs dans un même appareil et de n'avoir que 2 IO et que très peu de ressources allouées sur le µC principal. C'est ce genre de chose que tu recherches ?

A+
Laurent

C'est un peu ça, mais mon afficheur n'est pas I2C. Actuellement, je le fais fonctionner comme j'ai dit, avec des registre à décalage 74HC595. Pour assurer l'allumage en boucle des caractères de l'affichage, j'active par programmation les broches DIG1 à DIG4. C'est ce dernier point que je veux changer pour le rendre autonome.

[mag1]

C'est un peu ça, mais mon afficheur n'est pas I2C. Actuellement, je le fais fonctionner comme j'ai dit, avec des registre à décalage 74HC595. Pour assurer l'allumage en boucle des caractères de l'affichage, j'active par programmation les broches DIG1 à DIG4. C'est ce dernier point que je veux changer pour le rendre autonome.

J'ai pas encore compris ce que tu cherches à économiser, du code ou des broches?

MM

[Jeec]

J'ai pas encore compris ce que tu cherches à économiser, du code ou des broches?

MM

Je ne cherche à économiser ni des broches, ni du code. Mon appli est en grande partie du temps à l'écoute de trames provenant d'un réseau externe, je ne veux pas perturber cette écoute en gérant l'allumage circulaire, par programme, des caractères de l'afficheur.

[mag1]

Je ne cherche à économiser ni des broches, ni du code. Mon appli est en grande partie du temps à l'écoute de trames provenant d'un réseau externe, je ne veux pas perturber cette écoute en gérant l'allumage circulaire, par programme, des caractères de l'afficheur.

Ok, je comprends mieux.
Dans ce cas, pourquoi ne pas dédier l'écoute à un µC qui ne fait que ça, et transmet les infos quand il les reçoit.
C'est juste une idée, avec les infos disponibles (trames ?, réseau ? traitement ?)

MM

[Jeec]

Ok, je comprends mieux.
Dans ce cas, pourquoi ne pas dédier l'écoute à un µC qui ne fait que ça, et transmet les infos quand il les reçoit.
C'est juste une idée, avec les infos disponibles (trames ?, réseau ? traitement ?)

MM

Oui, mais dans mon cas un seul micro suffit pour, en boucle
-être à l'écoute des trames,
-puis être à l'écoute d'autres événements (boutons...)
-enfin réaliser une action, avec fourniture d'une information vers les 4 registres.

C'est avec un HC4017 que je vais probablement gérer en autonome l'afficheur

[Qristoff]

Je ne cherche à économiser ni des broches, ni du code. Mon appli est en grande partie du temps à l'écoute de trames provenant d'un réseau externe, je ne veux pas perturber cette écoute en gérant l'allumage circulaire, par programme, des caractères de l'afficheur.

Et l"écoute ne peut pas être gérée par interruptions ?

[mag1]

Oui, mais dans mon cas un seul micro suffit pour, en boucle
-être à l'écoute des trames,
-puis être à l'écoute d'autres événements (boutons...)
-enfin réaliser une action, avec fourniture d'une information vers les 4 registres.
C'est avec un HC4017 que je vais probablement gérer en autonome l'afficheur

Ok, mais je suppose que l'affichage dépend des infos reçues. La réception interrompt l'attente.
Je ne connais pas l'arduino, ni le C, interruption prioritaire sur l'attente info? Timeout sur la fonction attente ?
Mais on ne sait pas ce qui est mis à jour dans l'affichage, alors...

MM

[Jeec]

Et l"écoute ne peut pas être gérée par interruptions ?

Je pense que c'est une excellente piste, à laquelle je n'avais pas pensé lorsque j'ai développé l'appli. Il faudrait alors revoir la structure du logiciel, déjà assez conséquent, et qui fonctionne bien. Je vais y réfléchir.

[Jeec]

Ok, mais je suppose que l'affichage dépend des infos reçues. La réception interrompt l'attente.
Je ne connais pas l'arduino, ni le C, interruption prioritaire sur l'attente info? Timeout sur la fonction attente ?
Mais on ne sait pas ce qui est mis à jour dans l'affichage, alors...

MM

Affichage très sommaire (4 caractères à mettre à jour à l'issue de certains cycles) mais qui doit rester visible en permanence.

[Qristoff]

T'inquiètes pas, ton œil n'aura pas le temps de réagir. L'interruption est faite pour ça. Durée du traitement de l'info reçue ? si < 40ms (on en fait des choses en 40ms !) -> invisible à l'oeil.

[Jeec]

T'inquiètes pas, ton œil n'aura pas le temps de réagir. L'interruption est faite pour ça. Durée du traitement de l'info reçue ? si < 40ms (on en fait des choses en 40ms !) -> invisible à l'oeil.

Je suis tout à fait d'accord avec toi, mon problème, c'est de reprendre sérieusement la structure d'une appli qui fonctionne, et là il y a du boulot. En fait, quand je l'ai développée, je n'avais pas prévu d'affichage.

[mag1]

Affichage très sommaire (4 caractères à mettre à jour à l'issue de certains cycles) mais qui doit rester visible en permanence.

En fait, le problème est le choix de l’afficheur, il faudrait un latch sur chaque digit (4 CD4511) . Ou peut être un afficheur TM1637.

MM

[invitead6c50a3]

Quitte à utiliser un microcontrôleur, nul besoin d'autres composants inutiles.
La solution de Qristoff est la bonne, un code ça se modifie.
Au pire tu peux utiliser un tout petit µC dédié uniquement à cet affichage (il coutera moins cher que 4x CD4511), le premier µC envoie les données au second qui affiche.
Tu peux aussi utiliser un module bluetooth sur le µC que tu as déjà, module qui se pilote avec un UART et ton affichage sera ton portable.

[jiherve]

bonsoir,
pour des applications contraintes en temps réel il faut toujours passer par les interruptions et l'assembleur.
Le pilotage d'un 7 segment , sans rien d'autre que le µC et 4 MOS pour piloter l’électrode commune demande moins de 100 instructions (j'ai un code ou le noyau hors push/pop qui tourne entre 29 et 38 cycles sur Atmega8), ce qui avec une horloge standard à 8MHz fait 12,5µS par digit, il faut une interruption à 200Hz pour éviter le papillotement ce qui conduit à utiliser le µC pendant 50 millionième de son temps de calcul.
JR

[Qristoff]

En fait, quand je l'ai développée, je n'avais pas prévu d'affichage

c'est souvent un point à ne pas négliger. S'il faut le rajouter après, ça peut être fait élégamment surtout pour des afficheurs 7S. Il faut juste tester s'il y a quelque chose à modifier sur l'afficheur, si rien ne change, ça ne coute qu'une instruction !

[DAT44]

Bonjour,
proposition de câblage avec un 4017, ici, j'ai ajouté un temps mort sur la commande des OE des 74HC595, avec des portes NAND (74HC132) :



Edit : houps !, j'ai permuté la commande de OE de U2 et U3 ...

[Jeec]

Merci pour l'ensemble de vos interventions.
Mon système est maintenant fonctionnel, et je m'en suis sorti en remplaçant mon afficheur 7S à 4 caractères par 4 afficheurs 7S individuels.
Chacun de ces afficheurs est alimenté par un registre à décalage 74HC595 qui conserve en permanence les caractères à afficher, et qui alimente également en permanence
les segments de chacun des afficheurs. Je n'ai donc pas eu grand chose à changer.
Avec mon ancien afficheur à 4 caractère (dont la référence est indiquée plus haut dans fil), cela n'était pas possible à cause du multiplexage, il fallait que je fasse tourner en permanence l'affichage, seul un caractère pouvant être allumé à la fois. Ce n'était manifestement pas un bon choix.
Dorénavant, je n'interviens sur l'afficheur que lorsque mes données à afficher changent, et ça change tout!
Jean

[Jeec]

Bonjour,
proposition de câblage avec un 4017, ici, j'ai ajouté un temps mort sur la commande des OE des 74HC595, avec des portes NAND (74HC132) :

Pièce jointe 427675

Edit : houps !, j'ai permuté la commande de OE de U2 et U3 ...

Merci pour ta proposition, c'est effectivement ce que j'avais envisagé avant ... de simplifier!