Modifier un afficheur LCD parallèle en Série
Modifier un afficheur LCD parallèle en Série
1 Considérations général
es
1.1 Réduire les fils logiques de commande
1.2 L'organe de commande de l'afficheur
1.3 Le brochage général d'un afficheur //
1.4 Réduction des signaux
2 Le CI à monter sur l'afficheur
2.1 Choix des modes
2.2 Schéma et fonctionnement
2.3 Réalisation et connectique
2.4 Le montage d'essai avec PIC
3 Le driver et le programme d'essai
3.1 Comparaison des temps mode 4 bits et série (8 bits)
3.2 Restriction READ
4 Encore mieux ?
5 Conclusions
Si vous arrivez directement sur cette page par un moteur de recherche, vous pouvez avoir accès à la table des matières et à chaque article, en page d'accueil. L'accès se fait par l'un des deux liens en tête de colonne de droite ----->
ATTENTION à compter du 15/09/2019 les commentaires ne seront plus possibles à causes de quelques imbéciles qui font du spam pour le plaisir de nuire ! désolé !
Préambule
Il ne s'agit pas de fabriquer un afficheur LCD, mais seulement d'adapter un modèle parallèle 4 et 8 bits en modèle série Synchrone, de façon très simple.
Il est peu "normal" aujourd'hui de faire un petit montage à base de PIC et de n'avoir aucun visuel d'informations chiffrées diverses. (Température, vitesse, sens, débit, pression etc…)
Aussi les afficheurs à cristaux liquides LCD tiennent une grande place dans ces montages.
Seul inconvénient, il faut entre 11 et 6 I/O pour les commander. A 6 on se prive en plus de la fonction de lecture, qui, il faut l'avouer, ne sert pas à grand chose pour un périphérique de sortie !
Il existe des afficheurs LCD dits "Série", mais le prix (Hors série) est pratiquement multiplié par 4. Cela n'est pas acceptable.
Aussi pour garder un potentiel d'I/O suffisant dans un montage, (I/O de process) il est le plus souvent nécessaire de "grimper" dans les modèles de PIC (Quand on les trouve localement ce qui est une autre affaire).
Je me suis intéressé aux tout petits PIC 10F202 et 12F629, et j'aurais bien aimé pouvoir y "coller" un afficheur, mais avec au minimum 4 I/O, seul le 12F629 pouvait y prétendre avec seulement 2 I/O libres de plus. Pour le 10F202 avec 4 I/O, il n'y aurait plus rien d'autre ! A quoi servirait-il donc ?
Voilà ma base de réflexion : diminuer à tout prix (Pardon, à faible coût) le nombre d'I/O nécessaires. On devra utiliser seulement un Afficheur normal 4 et 8 bits.
La réalisation est-elle possible ? C'est tout l'objet de cet article.
On verra également qu'il fallait trouver aussi une solution généraliste plus économe et ne diminuant pas les performances d'un fonctionnement 4 bits, et pouvant s'appliquer à tous les montages.
D'avance la réponse est OUI, c'est possible et pour le prix d'un tout petit circuit imprimé et d'un seul circuit CMOS de moins de 0.4 € de prix. Pourra-t-on encore faire mieux ? Peut-être !
Il faut également considérer qu'utiliser la seule fonction série (du Port TX) d'un PIC pour travailler avec un afficheur est pénalisante, car il n'y a alors plus de dialogue possible et simple avec l'extérieur en RS232 et/ou Radio par exemple.
Je ne suis donc pas dans cette vision RS232 pour la raison d'une utilisation différente du seul port RS232 (Dans les PIC 16F, ou qui ne disposent que d'un seul port sérialisateur).
Connaissant un peu mieux la structure des PIC, et suivant les infos de mon copain "Riri" adepte des transmissions SYNCHRONES, je me suis donc rangé après réflexion, à sa vision très pointue sur l'intérêt de ce type de communications internes dans les montages à base de PIC.
J'ai conclu à l'extrême intérêt de ce mode de transmission avec les PIC, très économique en I/O et facile d'emploi tant en émission qu'en réception, et peu délicat sur les précisions d'horloge.
1 Considérations générales
Le but premier est de gagner des I/O (Input/output) ce qui permet de ne pas augmenter artificiellement de taille de PIC seulement pour cause d'utilisation d'afficheur LCD.
1.1 Réduire les fils logiques de commande
Il n'y a pas de miracle, tout ce qui est en parallèle doit passer en SÉRIE ! Cela s'adresse principalement aux DATAS et plus difficilement aux commandes !
En série, il y a deux possibilités qui sont les transmissions Synchrones et Asynchrones.
D'emblée on serait tenté d'utiliser les communications Asynchrones, car elles ne véhiculent pas de signal d'horloge. Ce serait donc le gain d'un fil de plus ?
- Travailler à une vitesse élevée en RS232 ne servirait à rien car entre chaque caractère il faudra réserver un temps d'attente de l'ordre de 50 µS. Ceci implique que les trames ressembleront à un chapelet dont les "grains" seront très éloignés. Il faudra de plus lire un signal donnant l'information que l'afficheur est "Ready" pour envoyer le caractère suivant. Cela nécessiterait donc de pouvoir utiliser le fil de lecture/écriture (Voir ci-après)
- La deuxième raison qui est certainement la plus importante est le blocage de la (Seule) liaison RS232 du PIC à cette seule fin. C'est dommage car on se prive alors d'une réelle possibilité d'échanges avec l'extérieur cette fois (Communications radio par exemple ou avec un PC)
Le choix est il donc maintenant entre Horloge ou fil Read/Write…Pas vraiment !
1.2 L'organe de commande de l'afficheur
Le premier point est de considérer que dans son contexte réel, l'afficheur sera toujours piloté par un PIC ou autre processeur, ne disposant que d'un nombre limité d'I/O (Input/Output). De plus beaucoup de ces processeurs n'ont pas toujours de possibilité de sérialisation "Hard" et que générer START et STOP en plus des datas est toujours une contrainte de temps i
mportante lorsque c'est à réaliser en I/O, sur la base, de temps calculés, et que le PIC tourne souvent à vitesse "normale" de 4 Mhz.
Il faudrait donc se passer de la sérialisation automatique du PIC ! Ça complique un peu le sujet si on veut maintenir un "baud rate" précis.
Les afficheurs dits "Série", outre le prix élevé, mobilisent donc de fait un port RS232 sur le PIC et sont donc peu intéressants pour cette raison et principalement dans le cas de PIC à un seul port RS232.
(De plus l'organe qui enverra les données RS232 devra respecter au mieux un baud rate standard).
(Ici, un petit CI équipé d'un PIC 16F628 qui a servi aux essais).
1.3 Le brochage général d'un afficheur //
Voici repris d'un très bon article de Fabrice Sincère le brochage de la majorité de ces afficheurs //. Je vous invite à tirer ces pages qui sont très utiles et bien complètes. (Ses coordonnées complètes ci dessous)
http://fabrice.sincere.pagesperso-orange.fr/cm_electronique/projet_pic/LCDalpha/LCDalpha.htm
N° de Pin du connecteur 16 pins et dénomination
1 GND Masse logique
2 VCC +5V
3 V0 Réglage Contraste afficheur
4 RS choix mode commande ou data (Commande=0 , datas=1)
5 R/W lecture ou écriture (0 pour écriture)
6 ENABLE (Validation datas au front descendant)
7 D0 (Datas Poids faibles Pf)
8 D1
9 D2
10 D3
11 D4
12 D5
13 D6
14 D7 (Datas Poi
ds Forts PF)
15 Anode LED rétro éclairage
16 Cathode LED Rétro éclairage
La description RS232 de cet article est parfaite mais laisse peu de signaux utiles pour un processus adjacent au PIC 16F628 puisqu'il ne reste que 4 I/O disponibles.
Ce montage doit être vu comme un report d'informations vers un ordinateur ou un exercice didactique sur les afficheurs, ce qui n'enlève rien à la qualité de cet article, et qui est d'ailleurs dit de façon sous-jacente.
NOTA : Attention je constate sur une autre documentation des valeurs inversées pour le signal RS (EA DIP162-D de la marque ELECTRONIC ASSEMBLY).
Les niveaux RS semblent bien être ceux que j'indique, car autrement rien de fonctionnerait chez moi, et pour deux marques différentes. A savoir RS=0 pour fonction (commande) et RS=1 pour DATAS sont les bonnes valeurs.
(Voir photo ci-contre (à agrandir si besoin))
1.4 Réduction des signaux
On a vu que la réduction du nombre de signaux implique la sérialisation. On abandonne donc la RS232 Asynchrone pour les raisons évoquées. Il ne reste donc que la transmission SYNCHRONE !
Une transmission SYNCHRONE est constituée de CLOCK et DATA qui sont les deux signaux qui pilotent cette transmission.
Côté PIC il faut sérialiser un caractère et piloter les différents signaux pour être en accord avec les spécifications de l'afficheur. En réalité on va très simplement envoyer bit après bit un data de 8 bits. Chaque bit sera d'abord positionné sur un port de sortie, puis suivi d'une impulsion d'horloge dont le front montant donnera à l'afficheur l'information de bit DATA valide à sérialiser.
(Lorsque je dis "afficheur", il faut comprendre l'afficheur lui-même ET l'adaptation série que l'on va continuer de décrire ou parfois simplement l'afficheur seul...A vous de saisir les nuances, cra je n'ai pas de mot véritablement spécifique pour désigner chaque élément)
Côté Afficheur on verra d'abord arriver le bit data puis le front montant d'horloge qui le validera et le fera entrer dans la première bascule du registre à décalage tout en décalant tous les autres bits.
Nous aurons donc gagné ainsi 2 /IO sur les 4 I/O initiales de DATAS.
Un simple circuit CMOS de type 4015 suffit simplement à gagner 2 I/O. Il faudra bien entendu "supprimer" le fil Read/Write qui ne pourra plus servir car cette modification est essentiellement orientée écriture Afficheur. (Pas de Tri-state, et de plus il faudrait bien commander ce troisième état par un fil ou une logique complémentaire ...)
Ainsi que je l'ai déjà évoqué, mis à part la lecture d'un bit "Ready", la lecture de ce bit est le seul véritable intérêt de la fonction READ.
En résumé l'interface proposée utilise donc seulement 4 bits de Ports (DATAS, CLOCK, RS, ENB)
2 Le CI à monter sur l'afficheur
2.1 Choix des modes
Le Montage ajouté n'interdit pas le fonctionnement traditionnel, y compris dans la connectique qui doit rester en place.
Ainsi il sera possible d'utiliser l'afficheur sans aucune modification en mode Série, 4 bits ou 8 bits.
(Juste retirer le 4015 si on veut réutiliser les modes 4 et 8 bits).
Cela est un réel avantage de toujours pouvoir revenir à une situation antérieure et/ou reprendre un tel appareil pour un autre montage dont le logiciel n'est pas modifié…
2.2 Schéma et fonctionneme
nt
Le schéma est d'une simplicité extrême, puisqu'un seul circuit CMOS 4015 est utilisé. Les données sont transmises poids faibles en tête et viennent se ranger et se décaler dans chaque bascule D à chaque front montant de l'impulsion Clock.
Chronologiquement on réalise en premier le chargement séquentiel de toutes les bascules D par la prise en compte du bit DATA présent à chaque signal CLOCK.
Au 8ème décalage l'ensemble des bits écrits dans les bascules représentent l'octet d'origine et peuvent être validées comme en mode 8 bits (ou 4 bits) par le signal Enable envoyé par le PIC.
Après avoir transmis en série chaque bit d'un octet, on utilisera donc logiquement à ce stade, le mode 8 bits beaucoup plus rapide que le mode 4 bits, pour envoyer la validation à l'afficheur.
(La sérialisation étant effectuée indépendamment du display lui-même, on rejoint alors le mode 8 bits standard puisque les données sont présentes en permanence sur le bus de données D0 à D7 de l'afficheur)
2.3 Réalisation et connect
iq
ue
Vous trouverez le typon et le plan de placement avec les quelques fils à réaliser pour éviter un CI double face. (Le coin coupé n'est pas fonctionnel et est seulement mécanique)
Cette réalisation est très compacte, car le CI ajouté com
portant le 4015 est placé directement sur le CI de l'afficheur. Le 4015 sera monté sur un support pour permettre le retour à la situation d'origine. (Autrement les bits D0 à D7 seraient forcés suivant les valeurs des bascules D)
Des pins de longueur plus importante permettent de traverser les deux CI et permettront ainsi la connexion par un petit connecteur 2x5 broches pour utilisation SÉRIE, ou permettront la connectique standard pour les modes 4 ou 8 bits.
(Vous pouvez prendre des pins de wrapping)
Le connecteur ajouté est une rangée de 5 pins juste au dessus des premières pins de l'afficheur. Ainsi le nouveau connecteur 2x5 sera enfiché à cheval sur les connecteurs J1 et J2.
ATTENTION : On commencera par souder le connecteur standard J2 (5 pins), pu
is J1 réalisé avec des pins dépassant très largement du connecteur J1 (Petit CI) pour atteindre et traverser également le CI du LCD.
Ensuite l'ensemble pin et petit CI sera soudé sur le CI du LCD. Voir les photos ci-contre et particulièrement celle "sur tranche"
Pour garder toutes les possibilités de permutations de modes, le signal R/W qui doit être forcé à la masse en mode série, le sera nécessairement au niveau de la connectique d'arrivée sur le montage du PIC.
Au niveau connectique, j'ai prévu le rétro éclairage dans le connecteur 2x5, mais je n'ai pas soudé les 2 fils puisque le montage une fois soudé fait partie intégrante de l'afficheur qui est un modèle sans rétro éclairage, donc je ne me suis pas fatigué inutilement !
Lors du positionnement du petit CI on veillera à intercaler un isolant entre l'afficheur et le petit CI, à cause des pattes métalliques de fixation de la "partie cristal liquide" qui font une surépaisseur non négligeable (Voir sur les 2 photos ci-dessus).
Un film isolant en Kapton pour transformateur fera l'affaire, (Ou si vous n'en avez pas, un simple plastique fera tout autant d'effet car les risques d'amorçage à 5 V restent du domaine des "galéjades" !!!)
2.4 Le montage d'essai avec
PIC
Un PIC 16F628 m'a servi à tester cet ensemble afficheur, car c'est avant tout la vérification d'un principe que je souhaite utiliser par la suite, mais encore faut-il qu'il n'y ait pas de soucis pour en faire un cheval de bataille...
Je pense qu'il ne peut pas y avoir de problème pour cette solution simple. Les autres paragraphes vous confirmeront ma confiance en ce principe...
Je n'ai pas fait de schéma, car j'ai simplement noté les ports utilisés. Les voici :
RA0 signal RS
RA1 signal ENABLE
RA2 signal CLOCK
RA3 signal DATAS
Vous verrez sur la photo le petit bout de CI bleu qu
i est le PIC qui assure la création des octets de commandes et de données pour l'essai du montage.
Je l'ai câblé directement puis j'ai réalisé le programme et essayé au simulateur et surtout à l'analyseur logique de MPLAB.
(Les ports utilisés ci dessus sont évidemment ceux du programme d'essais)
Ce programme décrit au paragraphe suivant assure l'initialisation en 8 bits et envoie simplement 16 caractères DATAS. Rien de plus simple et sans interrupts.
3 Le driver et le programme d'essai
Le programme du PIC est téléchargeable et vous pourrez reprendre le driver ENB_Disp inclus dans le programme d'essai, 
en gardant seulement les noms définis par les #define, ainsi que les quelques variables utilisées.
Vous modifierez les ports dans ces pseudo instructions suivant vos applications.
Télécharger le fichier DISPL_ESS.ASM
Ce programme d'essais comporte les initialisations puis les datas à afficher. L'initialisation est également réalisée en série sur la base du mode 8 bits, de façon identique aux DATAS.
Il faut dire que mon nombre de montages augmentant, je voulais avoir une base d'affichage moins gourmande en I/O, aussi j'ai été amené à réaliser cet essai avant toute autre chose, car mes conceptions futures seront nécessairement basées sur ce principe.
Avant de "lâcher" le montage sur le Web, j'ai tout de même fait la vérification et mis au point le logiciel d'essais grâce à l'analyseur logique MPLAB.
J'ai trouvé cet outil réellement merveilleux, car il n'y a eu aucun bug réel dans le programme codé et seulement quelques modifications de détails.
Je fais cependant une parenthèse au sujet de l'analyseur, car je me suis tout de même aperçu que la modification de la taille de la fenêtre d'affichage de l'analyseur pouvait modifier sensiblement la valeur indiquée entre les deux marqueurs rouges de mesure (Même si les "marqueurs" sont positionnés exactement sur les fronts désirés).
C'est peut-être un petit bug de MPLAB ou une aberration de positionnement due à la carte graphique ? Je ne sais pas ! Mais il faut faire attention à cela si on compte les cycles !
Ce problème n'enlève rien à cet analyseur logique simulé, que j'apprécie de plus en plus et dont l'utilisation me ferait presque oublier le debug standa
rd.
Je n'ai pas résisté à la tentation d'agrémenter ce paragraphe par quelques recopies d'écran des signaux que l'on trouvera sur le montage (Mais seulement simulé). Le ZOOM et le déplacement sont fantastiques, il faut faire attention à la taille du buffer qui ne peut pas tout stocker et qui peut ralentir MPLAB.
Le driver est en réalité un sous programme de nom "ENB_Disp" qui assure le transfert des 8 bits de donnée du PIC vers l'afficheur, et valide l'information de data ou de commande (RS).
Ce signal RS doit être positionné préalablement à l'appel du driver, (C'est normal car c'est le choix commande ou DATAS), mais le driver ENB_Disp assure automatiquement la validation (ENB) sans autre comman
de du programme d'application lui même.
De plus ENB_Disp assure aussi le délai de 50µS avant de rendre la main.
Pour ceux qui considèrent que ce temps pourrait être récupéré utilement, ils pourront modifier cet appel de délai en rendant immédiatement la main, non sans avoir préparé la connexion d'un timer avec un délai correspondant à 50µS et fonction de l'horloge du PIC.
Ainsi le blocage à zéro du compteur pourrait indiquer que le temps est écoulé.
Ce temps écoulé (Ready pour accepter un nouveau caractère) pourrait être testé en début de driver ou dans d'autres parties du programme d'application du PIC.
Il faut cependant relativiser ces 50 µs qui seront vite dissipées en tâches annexes de préparation de délai ou en SCAN du mot d'horloge, (ET à la condition que le prescaler ne soit pas trop important, sinon ce serait peine perdue)
En effet à ce niveau de temps, il sera nécessaire de scanner le registre timer TMR0 (Ou un autre timer), car il n'y aura pas d'interrupt réellement possibles, car ce délai est à la fois trop long et trop court (À mon sens !), pour être réellement mis à profit, mais chacun voit midi à sa pendule !
Pour ceux qui souhaitent un package "bien ficelé" sans autre procédure, vous pourrez même supprimer l'appel à "DLY_Inst" et insérer directement le contenu de la routine à la place du "call" dans la routine ENB_Disp. (Cette facilité éviterait aussi de descendre d'un cran de plus en profondeur dans le Stack, car les 8 niveaux habituels sont toujours un peu justes).
A vous de voir ce qui vous correspond le mieux, vous avez les clefs du principe ! C'est l'essentiel !
3.1 Comparaison des temps mode 4 bits et série (8 bits)
J'ai mesuré à l'analyseur logique MPLAB ces temps du dispositif Série, et ils sont indiqués dans le programme d'essai assembleur.
Par opposition j'ai seulement évalué par comptage des instructions, les temps en mode 4 bits. (Difficile et trop long de faire un comparatif très précis).
Il n'y a à priori que peu de différence de temps de transfert d'un octet par le driver. (Je ne parle pas du délai de 50µs qui est, et sera toujours présent).
Il y aurait peut-être quelques µS d'écart en faveur du mode 4 bits, mais je crois que face aux 50 µs d'attente c'est peu, face au bénéfice de 2 I/O récupérées.
La présentation de chiffres est toujours très délicate, car il faut définir avec précision les limites et les implications. Les contextes peuvent parfois ne pas être compatibles mot pour mot, aussi je préfère rester très prudent.
Parler performances reste assez diffus car tout dépend comment on conçoit la comparaison des temps (Driver seul ou appel depuis le programme avec quelques instructions dépendantes du mode choisi (sérialisation ou swap …etc...etc...) Bref la réponse de Normand est : c'est à peu près équivalent !
3.2 Restriction READ
J'avais déjà appliqué la suppression de la commande Read/Write à ma dernière utilisation en régulation solaire, aussi je ne peux pas dire que c'est un fil de moins…
Ainsi que je l'ai déjà dit, le seul véritable intérêt de la lecture, est de pouvoir disposer du signal "Ready". Mais le traitement par le respect d'un temps est tout aussi simple et je dirais même souvent plus commode lors des mises au point.
Alors il faut aussi comprendre que l'interface avec 4015 ne sera jamais compatible avec la lecture de ce bit "Ready", car le bus DATA, D0 à D7 est toujours forcé par le 4015, et ne pourra pas se retourner.
Il faut aussi resituer le contexte global, d'économie d'un produit trop cher, la réalisation d'un gain de 2 I/O et la facilité d'emploi.
Rajouter un autre fil de commande reviendrait un peu à scier la branche sur laquelle on est assis ! et serait totalement contraire à l'esprit de cet article qui veut avant tout limiter le nombre d'I/O nécessaires.
Dans la facilité d'emploi, le debug en mode 4 Bits n'est pas toujours des plus simples à suivre…Alors désolé pour le signal "Read" c'est à l'eau !
4 Encore mieux ?
Ne pourrait-on pas "gratter" encore un fil de façon simple ?
Je pense que OUI et j'ai une solution qui je le sais par avance ne fera pas l'unanimité car c'est avec un monostable retriggerable.
Il faut aussi comprendre que toute autre solution encore plus économe en I/O...
- ne devra pas tendre financièrement vers le prix d'un afficheur série.
- ne permet pas beaucoup de place physiquement sur un CI à souder sur l'afficheur et ne devant pas dépasser ses dimensions.
- doit encore éliminer un signal, et ce sera nécessairement le signal ENB qui devra être généré localement sur le petit CI ajouté sur l'afficheur.
Dans les solutions possibles il y a à compter les 8 CLOCK et envoyer ENB juste après, ou utiliser un monostable retriggerable dont la période correspondra au moins à un écart entre deux CLOCK, et dont le front descendant assurera la commande ENB. (Prise en compte des datas par la logique de l'afficheur au front descendant de ENB)
Ces deux solutions devraient fonctionner mais je préfère rester sur cette toute simple modification initiale qui ne dépend d'aucun temps précis, et ne comporte aucun logiciel complémentaire sur l'afficheur lui-même.
On notera tout de même que le comptage à 8 est une solution plus délicate car il y a des conditions de timing à respecter et qu'une petite logique serait à mettre en place. (Peut-être même avec un petit PIC).
Je dois ajouter encore un élément qui milite en faveur de cette solution...Ainsi que vous le verrez en mi 2012, une utilisation intéressante du principe peut être transposée pour alimenter des LED...ainsi pour 8 LED, il suffit de 2 fils, dont un (DATA) qui peut même être commun avec celui d'un afficheur LCD...et d'un seul circuit 4015 qui est capable de fournir le courant d'une dizaine de mA aux 8 LED. Il faut juste un clock spécifique pour le décalage et finalement vous avez 8 LED avec un seul fil !
Autre avantage, vous pouvez croiser au choix, poids faibles et poids forts, simplement en décalant à droite ou à gauche dans le driver. C'est réellement très pratique.
5 Conclusions
Voici un petit montage tout simple qui facilite l'intégration des afficheurs sur des petits PIC disposant d'au moins 4 I/O car il y a seulement 4 données logiques de commande, et cela pour le prix d'un afficheur //.
Le nombre de fils total est réduit de 2 unités et tient dans un connecteur 2x5 permettant même de véhiculer les deux fils de la LED de rétro éclairage éventuellement, la commande de contraste et l'alimentation 0 +5V.
Je vais faire quelques circuits d'avance pour équiper les futurs montages qui viendront…
La commande en mode 8 bits issue au terme de la sérialisation permet de garder à peu près les mêmes temps au niveau driver, mais surtout de récupérer 2 I/O.
Je veux ajouter qu'au niveau des temps, il y a lieu d'évaluer les temps entre caractères à afficher, car je ne m'en suis pas encore inquiété, mais le temps de transfert de chaque bit au niveau du shift register soit environ 80 µs ne participe pas au délai de 50µS, il serait donc possible de largement diminuer le temps entre caractère, ce qui placerait encore mieux ce principe puisque l'on serait en temps masqué. Ce principe sera essayé ultérieurement.
14/08/2011...
Au niveau des temps, il y a lieu de faire attention, car lors de cette conception orientée seulement pour gagner quelques I/O, la modification a entraîné un changement radical dans le fonctionnement même, et je l'avais seulement pressenti sans en prendre véritablement conscience.
En effet lors du chargement du registre à décalage, aucune commande n'est passée à l'afficheur (Ni RS, ni ENB). Durant le chargement, l'afficheur a donc toute liberté de traiter la commande précédente sans être "dérangé".
C'est en fait rigoureusement ce qui se passe et le développement ultérieur du détecteur de radioactivité (voir l'article) m'en a donné pleinement la preuve.
Le chargement du registre à décalage prend (à horloge à 4 Mhz) à peu près le même temps que le temps de traitement de la majorité des transferts vers l'afficheur.
Si bien qu'il est quasiment possible de ne plus mettre de délai d'attente entre chaque envoi vers l'afficheur (Sauf pour les commandes "gourmandes" en temps)
Je pense qu'avec ce surcroît de fonctionnalités, vous aurez compris que ce montage va devenir mon cheval de bataille pour les développements ultérieurs.
J'espère que vous serez intéressés par ce "très petit truc" qui me semble très utile, car il est vrai que l'on manque toujours d'I/O, (Comme pour le montage de régulation solaire, où j'étais un peu juste à ce niveau), j'aurai maintenant un peu plus de marge de manœuvre.
J'ai oublié de dire un mot sur la consommation en 5 V de l'ensemble du montage…
Malheureusement je n'ai pas différentié le montage d'essai de l'afficheur, mais vu les consommations, je ne pense pas que ce soit très grave…
En effet le PIC d'essais, l'afficheur et son nouveau petit CI consomment au TOTAL 3.7 mA !
Après les "Séries télévisées", il y a les "Séries Afficheurs" ou "Display"…
_____ ( retour en début d'article ) ____
_____ ( retour accueil lokistagnepas ) ____
_____ ( retour accueil bricolsec ) ____
/http%3A%2F%2Fstorage.canalblog.com%2F97%2F70%2F338014%2F47720732_o.jpg)
/http%3A%2F%2Fstorage.canalblog.com%2F75%2F63%2F338014%2F82946627_o.png)
/http%3A%2F%2Fstorage.canalblog.com%2F81%2F99%2F338014%2F128359728_o.jpg)
/https%3A%2F%2Fstorage.canalblog.com%2F27%2F68%2F338014%2F134429101_o.jpg)
/https%3A%2F%2Fprofilepics.canalblog.com%2Fprofilepics%2F2%2F8%2F289215.jpg)