Afficheur série LED 4 à 8 digits (RS232 et Synchrone)

afficheur_04_LED
1    Présentation du sujet
2    Description
2.1    Synoptique
2.2    Détails et éclairement
2.3    Formats traités
2.4    Connectique et dimensions
2.5    Horloge PIC
2.6    Nombre de digits
3    Le logiciel afficheur
3.1    Choix des commandes "DATAS"
3.2    Commandes génériques
3.3    Organisation logicielle
3.4    Traitement des erreurs et timing
4    Commandes Datas
4.1    Commandes BIN24_8
4.2    BCD
4.3    Hexadécimal
4.4    Segments
4.5    Modes ASCII
5    Commandes génériques
5.1    Reset complet
5.2    Extinction afficheur et LED
5.3    CLEAR_SLEEP (Ou stanby)
5.4    Validation Time Out affichage
5.5    Commande d'affichage des zéros
5.6    BLINK
5.7    Paramétrage du Temps de Time out
5.8    Temps d'affichage en 8 digits.
5.9    Set LED
6    SCHÉMA
7    Réception commandes et données
8    Réalisation
8.1   Particularités RS232 et SYNC
9    Considérations de vitesses de transmission
10   Conclusions
11   La dernière modif...

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 ----->
Les questions correctes en fin d'un article recevront toujours une réponse, mais pas les questions par "CONTACTER L'AUTEUR" qui n'auront pas de REPONSE (car je suis obligé de répondre par mail).
A voir aussi  en colonne de droite (lien direct) ------> les articles "BONJOUR" ainsi que "INFOS rapides"... Il est déconseillé d'indiquer dans les commentaires ses coordonnées (mail, adresse ou téléphone).
Ce blog est modéré et vous pouvez demander simplement en tête de question à ce que vos informations restent confidentielles si nécessaire. Rien ne sera publié, mais ma réponse sera faite sur l'article correspondant (et non par mail).

 



Avant propos

J'avais besoin d'un affichage pour un appareil de mesure et de tri de composants (Résistances CMS), alors j'ai abandonné provisoirement ce dernier projet d'ohmmètre pour me consacrer à cette seule partie d'affichage, et essayer d'en faire un outil général que je pourrais réutiliser par la suite, (Un peu comme le display LCD série déjà publié).
Ce dispositif sera constitué d'afficheurs LED très courants à 7 segments, et 4 digits physiques dont je dispose dans mes fonds de tiroirs.

Par "afficheur", il faut comprendre les éléments LED à 7 segments (8 avec lepoint décimal) de 4 digits, et je me suis arrêté à ce type, car peu d'afficheurs à un nombre de segments plus important sont en récupération. (13 segments ou plus). (Ne pas confondre avec les "displays LCD" qui sont de véritables petits circuits intelligents et le plus souvent en technologie matricielle).
Il y a aussi des afficheurs dédiés à des appareils particuliers qui affichent aussi des logos, parfois de couleurs différentes, mais dont le principe reste identique.
(Les afficheurs LED spécialisés pour les heures et minutes ne conviennent pas en général, car ils ne possèdent pas le point décimal à chaque digit, et n'ont même pas pour certains le digit de gauche complet puisque celui-ci n'a à afficher que 1 ou 2, et parfois même pas le 2 qui est traité en AM/PM)
VFD_Display
Il serait un peu plus délicat de traiter les afficheurs type VFD (Vacuum Fluorescent Display, photo ci-contre) car les tensions sont nettement plus élevées, et il faut surtout gérer les filaments qui doivent être alimentés en alternatif haute fréquence et à un potentiel ad'hoc, mais le principe pourrait être étendu moyennant un hardware adapté que je ne ferai pas dans l'immédiat, mais j'y pense….un peu !


1 Présentation du sujet

J'ai d'abord regardé dans tout "mon bazar" pour constater que j'avais pas mal d'afficheurs 4 digits de tous poils que je pourrais réutiliser mais ils sont tous différents d'un point de vue de l'organisation : Anode commune ou cathode commune et "pinning" tous très spécifiques.
Cela sans parler des tailles ni des couleurs qui rendent chaque modèle assez unique.

Dans les grandes familles, il y a donc les modèles à cathode commune et à anode commune et après avoir regardé chez les fabricants et distributeurs, j'ai constaté que les deux modèles proposés sont en nombre quasi identiques.
Aussi après avoir posé quelques bribes de schémas, je me suis rendu compte qu'il était moins contraignant d'utiliser des afficheurs à cathode commune… (Les éléments hardware de petite puissance sont plus courants en technologie NPN).

Le principe d'affichage consiste toujours à sélectionner un digit (Chiffre) par la mise à 0V et d'appliquer l'allumage des segments correspondants sur chaque anode de LED dans le cas des modèles à cathode commune. (Avec résistances de limitation sur chaque anode des segments, bien entendu !)

Au niveau des courants commandés, quelques soient les modèles, le point commun (Anode ou cathode) reçoit donc le total des courants de segments (7 avec en plus le point décimal éventuel).
Sur les modèles anciens, le courant d'un seul segment est important et de l'ordre de 20mA, aussi le total d'un digit (Et de l'afficheur au complet) peut donc arriver à 8x20=160 mA !
Ce courant est donc impossible à drainer par une sortie de circuit intégré standard LS ou CMOS ou micro contrôleur. Il faut donc soit un transistor de petite/moyenne puissance, soit un circuit driver spécialisé tel que l'ULN2803 ou 2804.  En réalité ces "anciens courants" ont évolués vers des valeurs un peu plus "démocratiques" avec 1 à 5 mA, et on arrive à des situations d'éclairement quasi identiques au passé avec 10 à 20 fois moins d'énergie.

Mais ce n'est pas tout car le circuit spécialisé très courant NPN n'a pas beaucoup de correspondants en PNP (M54562P difficile à se procurer mais intéressant car polyvalent, ou A2982SLWT). Cette situation conduit à privilégier les circuits à cathode commune, pour lesquels la commande des digits est la plus simple en établissant le courant de sélection d'un digit au 0 Volt.

En ce qui concerne le brochage, là, il n'y a pas de mystère, il faudra réaliser les sorties sur un connecteur standard et faire la correspondance réelle par le câble de liaison. Je n'ai malheureusement pas d'autre solution si l'on ne veut pas refaire un circuit imprimé spécifique à chaque afficheur. J'ai tout de même réalisé la connectique pour le modèle utilisé.

Mais au niveau exploitation, le fait de "traîner" toujours au moins 8 I/O pour les segments et  4 ou 5 I/O pour les digits depuis un montage exploitant (Appelons le "Host") est toujours pénalisant, aussi cet afficheur devra se suffire d'une liaison série synchrone avec clock et data depuis le système utilisateur de l'affichage, ou d'une liaison RS232 qui n'utilise qu'une seule I/O
C'est là l'intérêt principal de ce montage qui réduit les I/O d'un montage utilisateur.
De plus 12 ou 13 I/O pour gérer au final l'afficheur est aussi très gros consommateur d'I/O, et là aussi il va falloir sérialiser en INTERNE au montage cette fois pour ne pas accoucher d'une montagne.

Et au niveau logiciel ? … Si l'on pouvait régler les problèmes de conversion de type de données binaire, BCD,Hexa ou ASCII et même afficher un pseudo alphanumérique… ce serait merveilleux ! Là aussi c'est l'enjeu prévu de ce montage.

Mais dans ce cas il faut pouvoir régler pas mal de choses, y compris les éternels problèmes de conversions en tous genres, les nombres de digits, les zéros significatifs etc....
Il faut aussi pouvoir éteindre l'affichage en cas de non utilisation et même de passer en mode standby pour économiser l'énergie !

Pour réaliser tout cela, on conçoit vite qu'il faut créer un LANGAGE spécifique de commande de l'unité d'affichage, avec quelques commandes telles que clear, standby, write buffer ASCII, Binaire, BCD, display buffer, stop display, …etc…

Voici donc un petit éventail de ce que je me propose de réaliser, et c'est donc un "morceau assez conséquent" dont voici quelles seraient les principales caractéristiques.

4 à 5 digits à cathode commune.
3 LED à discrétion pour afficher des unités de mesure par exemple ou autres éléments.
Sérialisation avec driver de puissance pour digits et LED (ULN2804)
Attaque en direct des segments par PIC 16F690
(Éventuelle sortie sur l'afficheur d'un status : busy, erreur ?)
Entrées commandes et données en série synchrone, mais RS232 dans l'immédiat.
Provision hardware pour le mode SPI ou I²C
Création d'un mini langage d'exploitation.

La logique sera constituée du PIC 16F690 mais aussi d'un CD4015 de sérialisation des commandes de digits et LED associé à un ULN2804 pour la partie puissance de chaque digit
Au niveau logiciel, c'est encore un peu tôt pour décider, mais il y a de grandes chances pour qu'il y ait au moins deux buffers, l'un en entrée avec des conversions vers un premier buffer afficheurs. Un deuxième buffer sera le reflet de l'afficheur qui doit toujours "tourner" sur la valeur en cours (L'affichage est toujours dynamique). Erreur il y a seulement double buffer d'un octet pour le seul byte de commande et non pour les données.
Toute nouvelle commande de données remplacera l'affichage existant (Après calculs éventuels, conversions diverses et mise en forme) Durant ce temps, pour éviter tout trouble dans l'affichage, celui-ci sera éteint (Ça ne se verra pas !)

J'ai oublié un petit détail intéressant dans le contexte ainsi défini, qui est que les commandes des afficheurs seront toutes en logique positive et que j'apprécie bien ce fait qui vient toujours en aide et évite bien des erreurs, même si avec les #define ça va bien, cela reste plus difficile en mise au point réelle sur le montage, car "on se prend vite les pieds dans tapis"…!

Dernier détail important, mais vous aurez compris que l'on affiche chaque digit l'un après l'autre et que c'est la persistance rétinienne qui fait le reste du travail.
Encore faut-il que le cycle permanent d'affichage soit suffisamment rapide. C'est pour cela que j'ai préféré travailler d'emblée à 8 MHz de fréquence d'horloge pour le PIC.

De ce fait cet afficheur pourra afficher séquentiellement 8 digits avec un court "silence" (pause) de synchronisation.
C'est aussi l'intérêt de ce dispositif très restreint au niveau hard mais abondé par le programme  qui étend les possibilités moyennant la contrainte de lire séquentiellement les valeurs.

Comme il y a potentiellement 8 digits hardware à afficher par le 4015 et l'ULN, (Les LED compteront chacune pour un pseudo digit, mais sans segment attaché). Un digit sera ignoré car trop spécifique (Kpoints)
Suivant le principe de sérialisation retenu, à 8 MHz, au niveau énergie cela ne me pose pas trop de problèmes de conscience, car les afficheurs LED sont en principe suffisamment "gourmands", devant la consommation anecdotique du PIC ...

2 Description

2.1 Synoptique

afficheur_02_LED_Synopt


2.2 Détails et éclairement

J'avais initialement jeté mon dévolu sur le PIC 16F628, car j'en dispose et ce micro contrôleur est très courant et est bien organisé avec ses 2 ports A et B complets à 8 bits ce qui arrange bien au niveau simplification, surtout pour la commande des segments.

(Le 8ème segment est le point décimal) qui peut parfois nécessiter un courant un peu plus réduit pour rester homogène avec le reste de l'éclairement.
Au niveau éclairement l'œil ne percevra pas le changement rapide de digit, mais en revanche aura une impression de moindre éclairement qui devra être compensée par un courant un peu plus élevé et limité par les résistances des lignes des segments.
Ce courant à peine plus élevé sera fourni directement par les I/O du PIC à chaque segment, puisqu'il peut donner jusqu'à 25 mA.

Bien entendu suivant la couleur des segments, l'intensité lumineuse devra être adaptée par la résistance située sur chaque ligne de segments, car les tensions directes varient suivant les couleurs de 1.5v jusqu'à 3 volts environ. Les résistances seront donc en conséquence mais aussi en tenant compte que l'impression lumineuse sera plus faible à cause de l'allumage séquentiel de chaque digit.
Je donne ces valeurs de résistance qui correspondent à mon premier montage avec segments bleus (2.7V à 5 mA et très lumineux pour un  modèle LFD3E5DBK-10)

Concernant ce modèle de récupération, il possède un cinquième pseudo digit (Nommé "Kpoints" sur le schéma) comme certains autres d'ailleurs, qui concerne les deux points d'horloge qui sont séparés ainsi qu'un point supérieur à droite du 2ème digit de poids faible. (Voir le pinning spécifique).
Cette particularité est "câblée", mais non utilisée car trop spécifique à une utilisation particulière.

Au final après vérification des éléments nécessaires, je me suis aperçu qu'après avoir utilisé les 8 I/O, je ne pouvais plus avoir d'interrupt par changement sur le PORTA pour répondre au Host, (A priori plus nécessaire à ce jour), alors au lieu d'ajouter encore de la circuiterie complémentaire pour utiliser ce PIC, j'ai préféré prendre un PIC16F690 qui me permet d'avoir tous ces éléments et mieux encore puisque cette fois la transmission synchrone prévue avec le montage utilisateur (Appelons le Host pour simplifier l'écriture) est d'origine et qu'au pire il serait même possible de faire du SPI ou I²C, mais ces dernières procédures sont un peu trop précises pour moi, aussi je préfère utiliser la procédure synchrone standard en mode esclave dont l'horloge sera donc fournie par le HOST. Ce sera à moi de m'adapter (Au mieux) à la vitesse imposée par le Host.
Enfin il n'était pas possible de réveiller ce PIC par l'UART avec le bit WUE, aussi ce PIC 16F628 était mal adapté, d'autant qu'en vitesse à 8 MHz il fallait encore ajouter un quartz…

2.3 Formats traités

Pouvoir traiter plusieurs format (Avec un seule ligne I/O de datas, voire 2) est un enjeu qui donne aussi tout l'intérêt de cette réalisation, pour un montage hardware qui n'a en soi rien d'exceptionnel.
C'est surtout la partie logicielle qui en fera un OUTIL réellement intéressant.

Afficher du binaire 8 à 24 bits, signés (ou non), du BCD de l'hexadécimal 8 à 32 bits, des segments parmi les 7 (8 avec le point décimal), enfin de l'ASCII de nombres entiers, de l'ASCII de nombres réels signé ou non (Avec point décimal) en 1 à 8 digits, représente mon objectif.

Enfin une commande de service permet d'afficher de l'ASCII alphanumérique sur 4 à 8 digits. Certaines lettres ne peuvent pas être formées sur ces afficheurs (x,m,w) pour les principales. Celles-ci seront seulement symbolisées en supérieur ou inférieur et d'autres seront à interpréter par le contexte (2 et Z par exemple, ou G et 6 etc…).

(Parmi les bizarreries, je viens de voir également des afficheurs LED de radio réveil à seulement 2 anodes et 24 cathodes !)
C'est assez incroyable, et cela montre bien que le sujet afficheurs LED est réellement très vaste.

(Revenons aux formats…J'ai été obligé de construire un tableau pour recenser tous les cas...)

Alors je serais obligé de me limiter aux cas les plus habituels en 16 bits mais également à 4 digits (Digits explicitement numériques) ? Je rappelle pour la compréhension que les points décimaux des valeurs numériques réelles sont presque toujours inclus dans les 7 Segments numériques (Huitième segment en général)

Aussi j'ai décidé d'innover un peu en montant jusqu'à 8 digits avec seulement 4 afficheurs ?!?.

Fort de cette innovation, j'ai d'abord réalisé une maquette de journal lumineux défilant, mais je me suis vite rendu compte de la difficulté de mémoriser les bonnes valeurs numériques, alors il ne restait plus beaucoup de solutions et donc seulement l'affichage alterné sans défilement mais avec un "silence" de synchronisation à la fin du dernier affichage qui marque également le début des poids forts de la valeur numérique.
De plus je fais maintenant l'adaptation automatique du nombre de digits d'affichage, suivant qu'il faut seulement 4 digits ou plus, ainsi on ne s'occupera pas de la longueur dans la majorité des modes.

Toutes ces possibilités sont intégrées dans le programme associées à un mini langage de commande extrêmement simple de 7 commandes d'envoi de données suivant les multiples formats (Voir tableau des commandes ci-après).
Il faut dire que les cas aux limites sont extrêmement nombreux et que j'ai eu bien du mal à faire tout coïncider, car il y a des interactions insoupçonnées.

A ce jour 9 commandes génériques sans données (Ou 2 exceptionnellement) permettent différentes possibilités comme la mise en sommeil l'effacement des afficheurs, la validation d'un time out d'extinction, le clignotement et la gestion des zéros non significatifs (Zéros de tête) etc…

En réalité après avoir tout bien séparé les différents cas, je m'étais rendu compte d'une certaine lourdeur à programmer au niveau du Host, aussi après avoir mis un maximum de commandes, j'ai ramené celles-ci à un nombre beaucoup plus petit de 7 commandes de base sans rien sacrifier aux possibilités.
Les longueurs sont devenues automatiques, ce qui a tout simplifié au niveau utilisation, mais sérieusement compliqué le logiciel, car les cas aux limites sont devenus difficiles à gérer.

Pour l'exemple si vous traitez du BCD sur 4 ou 8 digits en affichage, comment interpréter les valeurs finales de 3 ou 6 digits en complément à 4 ou 8 ? Sont-ce des zéros transmis ou des zéros générés par le logiciel ? Doit-on mettre un espace à la fin ou non ?
Ainsi dans ce cas précis je serais obligé de demander d'envoyer toujours 4 ou 8 valeurs pour lever le doute sur l'affichage. (Seul le comptage des caractères datas reçus résoudra ce problème)

Faut-il contrôler les limites d'affichage en binaire par exemple ? NON simplement parce qu'en binaire, vous ne devriez pas pouvoir envoyer 25 bits pour 24 sauf à le faire volontairement, aussi cela explique les limites numériques du tableau des commandes.
Ces limites sont également implicites en BCD mais aussi en HEXA (Le signe n'en est plus un véritablement pour ces deux modes)
Par opposition, les commandes en ASCII peuvent donner des erreurs car on dispose seulement d'une table de conversion ASCII en segments n'ayant que les principaux signes numériques et alpha.
Le tiret (Signe -), le signe égal, l'arobase et l'espace sont les seuls symboles affichables. Le signe + ne sera jamais représenté et sera toujours implicite, faute de pouvoir réellement le gérer en 7 segments
Cela est réalisé à ce jour, mais majuscules et minuscules seront confondues et prises indifféremment pour exprimer l'alphabet qui sera visualisé "au mieux" et aussi bien en minuscules que majuscules suivant les possibilités de caractères en segments.
(Les données seront acceptées en minuscules et majuscules mais restituées indifféremment à l'affichage)

Outre l'afficheur à 7 segments (Je sais qu'il y a mieux, mais je vide mes tiroirs !) 3 LED sont disponibles pour l'usage qu'il vous plaira. Ces 3 valeurs constituent les poids forts d'une commande DATA quelle qu'elle soit.
Ces LED sont indépendantes des données à afficher, car elles ne sont pas assujetties à des segments. Elles peuvent par exemple représenter l'unité d'une grandeur physique comme Ohm, K, ou M au travers d'un hublot par exemple ou au contraire indiquer une erreur au niveau Host.

Certaines commandes préalablement divisées dans le seul but de limiter le nombre de données sont maintenant automatiques, cependant au niveau réception on bloquera les datas excédentaires. Ceux-ci seront limités à 10 avec le byte de commande, car toute commande ne pourra jamais dépasser ce nombre par le simple fait de l'affichage et de ses caractéristiques virtuelles. (8 valeurs maxi y compris le signe mais le point décimal exclu)

Dans le tableau des commandes, "Nb bytes DATA" ne concerne que les données à afficher le nombre total sera toujours +1 (Commande elle-même incluant les LEDs)

L'intérêt principal réside dans les contrôles effectués pour chaque catégorie de données, avec les différents formats de données. Les formats sur une base binaire sont intéressants car ils ne figurent pas (Ou peu) à ma connaissance dans les dispositifs actuels d'affichage du commerce.
De plus afficher les différents formats ASCII est également assez large pour traiter les entiers signés ou non, mais aussi les réels.
Un outil de traduction sommaire de l'ASCII réduit à 7 segments améliore encore ces possibilités.

Les commandes génériques permettent le reset complet du dispositif, l'extinction de l'afficheurs, une commande "standby" avec réduction de consommation, la validation d'un time-out pour réduire la consommation des afficheurs après un certain délai, l'affichage ou non des zéros non significatifs, le clignotement en 4 ou 8 digits, le paramétrage du time-out, le paramétrage du "silence" entre 2 affichages en mode 8 digits, et enfin la commande des seules LED  qui sont aussi programmables dans chaque commande "datas" (Avec maintien de l'affichage en cours).

Voici donc le tableau des commandes dont chacune d'elles sera détaillée au paragraphe 5.


afficheur_commandes_ods_001_001

2.4 Connectique et dimensions


J'aurais bien voulu faire une connectique généraliste pour l'afficheur, en plus de la connectique de mon circuit spécifique, mais je suis obligé de déclarer forfait, car mettre un connecteur de plus pour l'afficheur que je veux utiliser et un connecteur généraliste moins "long" et mieux ordonné logiquement est impossible. Irréalisable en circuit simple face, et délicat en double face, si l'on veut garder des dimensions "acceptables".
Alors je garde seulement le connecteur du modèle utilisé, et les liaisons vers d'autres modèles d'afficheurs se feront par un câble spécifique.
J'ai aussi hésité sur le fait de faire un CI à chaque nouveau modèle d'afficheur, mais le sujet perd alors un peu de son intérêt généraliste, mais le logiciel reste ! Alors tout est à peser...

Au niveau des dimensions du circuit, elles restent assez grandes et l'électronique est un peu luxueuse de prime abord par le PIC utilisé, mais ce sont les possibilités qui feront tout l'intérêt en déchargeant le "Host" des tâches ingrates qui mobilisent un nombre élevé d'I/O.
Alors le montage bien qu'assez "grand" en dimensions reste intéressant pour réutiliser les fonds de tiroirs, et dans le cas où les LED sont impératives pour afficher des unités rétro éclairées par exemple.
(Il faut bien accompagner les valeurs numériques de l'unité appropriée !)

Sous conditions particulières, je pense qu'un circuit définitif pourrait être allégé de l'ULN2803 car les afficheurs deviennent de moins en moins gourmands en énergie et le PIC devrait pouvoir supporter un courant de 25 mA sur un digit avec les LED, en choisissant un afficheur économe ainsi que des LED faible consommation.

Le circuit comporte également deux autres connecteurs, l'un pour commandes et datas, y compris l'alimentation 5V, et l'autre pour la programmation ICSP du PIC, sous forme du nez de carte habituel maintenant à mes montages (Connecteur de type PCI de PC)

2.5 Horloge PIC

Pour visualiser sur des afficheurs LED des informations, il est inutile de prévoir un oscillateur à quartz pour la stabilité, mais…
Le problème est que pour atteindre 20 MHz, il faut un oscillateur à quartz et si l'on veut garder toutes les possibilités de commandes de la logique, on serait obligé d'abandonner le SPI et I²C, aussi je me contenterai des 8 MHz de l'oscillateur INTOSCIO.
(L'oscillateur RC externe ne permet pas d'atteindre cette fréquence.)

2.6 Nombre de digits

Initialement, et comme déjà signalé, j'avais voulu aller au delà de 4 digits, et jusqu'à 8 en pratique, et j'avais pensé faire un journal défilant. L'interprétation et la mémorisation des valeurs étaient beaucoup trop délicates et j'ai dû revoir cette idée pour finalement quelque chose de techniquement plus simple, et plus approprié.

Ainsi, c'est par affichages successifs que je monte jusqu'à 8 digits (Uniquement dans le cas où c'est nécessaire bien entendu, car cela prend du temps et n'est pas nécessaire pour afficher 123.5 par exemple).
On commence donc par les poids les plus forts au nombre de 1 à 4. Le deuxième affichage en séquence représente les poids faibles.
L'ensemble est suivi d'une courte extinction (Pause ou "silence visuel") permettant de situer les Poids Forts au prochain affichage (Surtout si l'on va jusqu'à 8 digits).
On remarquera qu'au niveau perception visuelle il serait plus facile de repérer les poids d'un affichage différent en nombre de digits surtout si les zéros non significatifs sont supprimés
(Notez cette habitude d'écriture assez généralisées pour désigner les poids fort en PF, et les poids faibles en Pf ou pf)

3 Le logiciel afficheur

C'est certainement la partie la plus compliquée et la plus "pénible" à traiter, mais il va falloir en premier lieu définir un langage de commande, tout en ne se fermant pas de portes pour tous les cas à traiter, mais aussi veiller à ne pas en faire une montagne de complexité et de rigidité…

L'extinction des afficheurs est prévue par la mise à zéro des segments ou parfois le blocage des digits. Cela se fera systématiquement entre 2 affichages de 8 digits pour éviter des aberrations visuelles lors des décalages dans le CD4015 mais permettre aussi la synchronisation visuelle des données.
Pour aller assez vite, j'ai aussi prévu une I/O reset complet du CD4015, qui sera surtout utile si l'on n'utilise pas 8 digits, car autrement il faudrait décaler 8 fois pour obtenir le même résultat…
Ce reset est très utile pour éviter tout "flottement visuel" dans les changements de valeurs, ainsi aucune aberration n'est perceptible.

3.1 Choix des commandes "DATAS"

Les choix sont issus de la constatation visuelle qu'il ne faut pas plus de 2 affichages différents de 4 valeurs sous peine de ne plus être exploitable, aussi les commandes de conversions binaires sont limitées à 24 bits, car cela correspond déjà 16 777 215 soit 8 digits à afficher.
Notez également qu'une règle humaine de mémorisation générale est de 7 valeurs sans erreurs, et que ce nombre est important. Alors 8 c'est vraiment la limite !
Il n'est donc pas question de passer à 25 ou 26 bits voire 32 pour atteindre 99 999 999 car ces 2 valeurs binaires anarchiques ne sont jamais exploitées et 32 ne correspondraient à rien de vraiment réel, ni exploitable.

(Passer à 32 bits resterait délicat car je ne possède pas les conversions BCD correspondantes et l'enjeu de ce PETIT dispositif serait tout de même vraiment inadéquat car 32 bits non signés c'est : 4 294 967 295, soit 10 digits et 3 affichages nécessaires !)

De plus il faut aussi considérer que le nombre de digits à transmettre doit être le plus faible possible depuis le Host. Aussi beaucoup de commandes peuvent être réduites en nombre de datas pour n'avoir que le strict nécessaire, et je pense au format le plus condensé qui est le binaire !

On notera également dans le cas de l'affichage des nombres réels ASCII avec le point décimal, que celui-ci est compté dans la taille des données d'origine, mais ne l'est pas dans l'affichage sur l'afficheur puisque le point décimal appartient à chaque digit, et particulièrement au digit précédent (Dans ce modèle).
(Cette dernière particularité fait qu'il n'est pas possible d'afficher 8 digits qui commenceraient par un point décimal).

Bon nombre de commandes datas gèrent automatiquement le nombre de digits à produire et sélectionnent ainsi les modes 1 ou 2 affichages suivant les types ET la taille des données.
Contrairement au point décimal, pensez que le signe est pleinement un caractère au niveau affichage et que les nombres négatifs sont ainsi plus limités en valeur absolue que les nombres positifs…!

Cela ne sera pas le cas des nombres exprimés en BCD, HEXA ou directement en segments qui seront toujours vus comme de simples entités non signées.

NOTA : Les nombres positifs sont par défaut des nombres sans le signe +

Dans le cas de deux affichages un "silence" ou "pause" de 200 ms, (tous segments et LED éteints) permet de synchroniser la vision suivante sur les poids forts d'un affichage. Cette méthode paraît la plus pertinente pour afficher plus que 4 digits avec un afficheur à 4 digits physiques.
(Un affichage dynamique -rapide- ne pourra donc pas se réaliser en mode 8 digits par alternance)

3.2 Commandes génériques

Ces commandes assurent la gestion de l'afficheur et permettent de l'éteindre, de passer en SLEEP, de clignoter en modes 4 et 8 digits. (Lors du clignotement, la confusion des valeurs en mode 8 digits est écartée par une fréquence de clignotement très élevée).
Il est également possible de régler le temps d'affichage des groupes de 4 digits par de telles commandes.

3.3 Organisation logicielle

3 buffers permettent de traiter facilement les différents ordres.
Un buffer de réception de longueur maximum 10 bytes avec un deuxième buffer réduit à la seule commande et deux buffers spécifiques à chaque zone d'affichage (Premier et deuxième affichage)
Toute commande DATA comporte dans les bits de poids forts, l'activation ou non des LED complémentaires dont le rôle peut être à discrétion par le Host.
Dans mon cas, j'ai prévu ces possibilités pour afficher des unités de mesures (Petite fenêtre transparente) ohms, K,M par exemple. Ainsi la valeur numérique est affectée de son unité, ce qui est vital dans l'application projetée de tri de composants.

3.4 Traitement des erreurs et timing

Des erreurs dans les conversions peuvent se produire, surtout du fait que tous les caractères ne sont pas exprimables sans ambiguïté dans une matrice de 7/8 segments. Aussi ces erreurs ne peuvent pas être reportées au niveau du Host du fait de l'absence d'un canal de réception.
Au niveau de caractères DATAS erronés possibles, il m'a semblé plus opportun de visualiser les erreurs de la manière suivante avec un "underscore" suivi du point décimal (_.), pour chaque caractère erroné.

Dans le cas d'une commande inexistante, (Ce qui peut arriver si le Host ne respecte pas les procédures), la distinction sera faite par un affichage spécifique sur 4 digits seulement :

"E.r.dA" pour une erreur de commande DATA inexistante
"E.r.GE" pour une erreur de commande Générique inexistante

Ainsi lors des essais avec le Host vous saurez rapidement si il y a des erreurs de commandes.
Sur un dispositif d'affichage seul, il semble peu utile d'aviser le Host d'une erreur, car au final, c'est l'opérateur devant l'afficheur qui voit ! Alors cela simplifie.
Il serait toujours possible par le jeu RX/TX en forçage à 0 de donner ou non un ACK (acknowledge) dans certaines procédures comme I²C par exemple, mais cela obligerait également le Host à traiter cela. Aussi comme j'ai souhaité un minimum de contraintes au niveau Host, c'est bien au niveau opérateur seul que se réveilleront les erreurs.

Initialement j'avais ajouté un double buffer complet de réception des commandes et datas, mais vu le contexte j'ai réduit cette partie à seulement un double buffer partiel d'un seul octet mémorisant seulement la dernière commande DATA, nécessaire pour l'application de quelques commandes génériques qui ne doivent pas modifier les données en cours de visualisation.

4 Commandes Datas

S'agissant d'un système "intelligent", (Désolé pour ce mot un peu "pompeux", mais je n'ai pas d'autres termes pour indiquer que ce n'est pas seulement un banal afficheur), le fait qu'il puisse afficher jusqu'à 8 digits avec seulement 4 afficheurs physiques, mais aussi et surtout qu'il prenne en compte un nombre très complet de formats de données, ainsi que des commandes de service, il est évident qu'il doit y avoir un MINI LANGAGE pour choisir les différentes possibilités.

Ne soyez pas affolés par ce langage, car c'est réellement très simple et à la fois très puissant.
Il y a seulement 7 commandes pour choisir le format d'entrée des datas à afficher, et 9 commandes de service ou de paramétrage. (Voir le tableau déjà représenté au § 2.3)

Ces commandes sont en principe en format fixe, mais des facilités sont données pour permettre un nombre moindre de datas lorsque c'est possible.

Je prends l'exemple suivant pour les COMMANDES BINAIRES : lorsque vous exprimez ce nombre binaire 10011 relativement à un nombre de 8 bits, ce nombre binaire est 19 en base 10 ou 13 en base 16 mais jamais 152 décimal ou 98 en base 16.
En d'autres termes on définira que quelque soit la référence 8, 16 ou 24 bits, un nombre exprimé avec un nombre de bits moindre (mais ramené à l'octet) que ce nombre fera toujours référence aux POIDS LES PLUS FAIBLES.

Les paragraphes suivants vont donc donner toutes les particularités de chacune des commandes de datas, puis les commandes génériques (Commandes de paramétrage ou d'attributs de données)

Toutes les commandes de datas sont immédiatement suivies des données à afficher, soit en binaire directement (Y compris BCD, Hexa et Segments), soit en ASCII.
Toutes ces commandes DATA devront comporter au moins un octet de DATAS, car une commande d'affichage sans données n'a pas de sens et sera considérée comme erreur.

Toutes les commandes datas comportent dans les 3 poids forts, et bit à bit l'allumage ou l'extinction de 3 LEDs auxiliaires dont l'utilisation est libre.

Si l'on veut allumer uniquement des LED sans modifier l'affichage en cours, une commande générique offre cette possibilité. (Voir ci-après)
(A savoir également que le buffer d'entrée des commandes est toujours totalement complété à zéro à l'issue du time out de réception)

4.1 Commandes BIN24_8

Ces deux commandes BIN24_8 et BIN24_8S (codes 0x10 et 0x11) sont immédiatement suivies de 1 à 3 octets binaires (Poids forts en tête) et permettent de transmettre à l'afficheur un nombre binaire de 8 à 24 bits
Un nombre binaire pouvant être signé (Accompagné d'un signe), ce signe occupe de façon standard le bit de poids le plus fort des 24 bits (Bit 23)
Le format accepte un nombre réduit d'octets transmis, mais la contre partie est que ceux-ci ne pourront jamais être considérés comme des nombres négatifs.
Ainsi un nombre négatif sera toujours exprimé sur 24 bits, pour que le bit 23, "titulaire" du signe soit toujours exprimé.

Pourquoi 2 commandes binaires, l'une signée et l'autre non ? Simplement parce que les résultats seront différents  selon le bit 23, mais aussi parce que beaucoup d'opérations sur micro contrôleurs sont en positif et que le fait d'utiliser le bit de signe comme poids binaire autorise des nombres plus grands, ce qui peut être utile et aussi souvent plus simple.

Ainsi en 24 bits non signés (Code 0x10) on pourra exprimer des nombres jusqu'à 16 777 215.
(Pourquoi pas 99 999 999 ? Puisque l'on dispose de 8 positions virtuelles ? Simplement parce que 24 bits binaires donnent au maximum cette valeur ! C'est aussi simple que cela !)

Pour la commande binaire signée (Code 0x11), la limite d'expression à l'affichage sera de – 8 388 608, et on perd donc la moitié des possibilités numériques en valeur absolue par la "confiscation" du bit 23 pour le signe, (Poids le plus fort).

L'affichage sera cadré à droite dans ces opérations sur 4 digits comme sur 8. Les poids forts ou le signe apparaîtront toujours en premier digit juste après la pause de séparation dans le cas de résultat compris entre 5 et 8 digits.
Le signe comptera bien entendu pour un digit et occupera toujours la première position d'affichage en 4 ou 8 digits.
Par défaut, les zéros de tête seront remplacés par des espaces, mais pourront être rétablis par une commande générique (Voir ci-après les commandes génériques).
Ces deux commandes sont les seules à cadrer les résultats affichés à droite.

Ces commandes présentent un intérêt pour réduire le volume de données mais aussi en mise au point de systèmes à base de micro contrôleurs. L'interface RS232 ou Synchrone présente aussi un intérêt majeur dans la mobilisation des I/O de systèmes utilisateurs de cet affichage.
(Vous noterez également que dans ce format, il ne peut pas y avoir d'erreur de données !).

4.2 BCD

Cette commande BCD2_8 (Code 0x12) permet d'afficher directement des valeurs BCD déjà calculées par un Host qui effectue déjà la conversion BCD de valeurs binaires.
Le format sera toujours de 2 valeurs BCD par octet, (Nombres de 0 à 9 seulement !) avec le poids fort à gauche suivant les conventions largement établies.
(Je n'ai pas prévu de BCD à une seule valeur par octet, mais toujours par groupe de 2 valeurs BCD)

Ce mode permet d'afficher des valeurs numériques jusqu'au maximum sur 8 digits, soit 99 999 999.
C'est donc un peu normal d'aller numériquement au-delà du format binaire puisqu'il y a un 4ème octet de données à la
commande !
Les valeurs dans les datas de la commande seront toujours poids forts en tête, et l'expression  à l'affichage sera
cadrée à GAUCHE, poids fort en premier.

On pourra transmettre de 1 à 4 octets pour 2 à 8 valeurs BCD, par modulo 2.

Dans ce mode les zéros seront toujours affichés pour pouvoir imager la position des valeurs non nulles.
ATTENTION : Ce mode est contrôlé sur les valeurs qui ne doivent pas dépasser 9 par quartet. Toute erreur sera signalée dans sa position par le double caractère "_."

4.3 Hexadécimal

Cette commande HEX32 (Code 0x14) est presque identique à la commande BCD, puisque tout est parfaitement similaire, hormis que le contrôle des caractères à 9 maxi est aboli et que tout est donc possible jusqu'à F.
L'affichage sera au maximum FFFF FFFF. (4 294 967 295 converti en décimal)
Cette commande présente surtout son avantage en mise au point de systèmes à micro contrôleurs.
On peut remarquer que cette commande avec ses datas ne devrait normalement générer aucune erreur, du fait même qu'elle découle directement d'un format binaire.
Les seules erreurs possibles sont des caractères supérieurs à "F" qui engendreront "_."

4.4 Segments

Vous pouvez également souhaiter commander directement chaque segment de chaque digit physique (Ou virtuel), dans ce cas vous effectuerez la commande SEG_8 (Code0x16) qui permet l'affichage de segments suivant le plan ci-afficheur_03_LED_Synoptcontre

Beaucoup d'afficheurs sont très particuliers et je n'ai gardé que les possibilités des plus courantes, car même sur le modèle que j'ai utilisé, il y a encore d'autres possibilités telles qu'un point supérieur et les deux points pour indiquer traditionnellement heures et minutes.
Cette commande peut comporter jusqu'à 8 octets de données correspondant aux 8 digits virtuels. Dans le cas de datas sous numéraires, les positions non occupées seront éteintes.

Les datas sont cadrés poids forts en tête et peuvent permettre l'affichage de 8.8.8.8.8.8.8.8.
Un octet à zéro correspond à l'extinction de tous les segments.

Cette commande vous permettra de réaliser des caractères spéciaux ou des animations comme celle d'une "roue" qui tourne ou autre gadget.

4.5 Modes ASCII

Cette commande (Code 0x18) était primitivement composé de 4 commandes différentes. Celles-ci ont donc été regroupées et la différentiation des types présentés est maintenant automatique en autorisant l'affichage de données numériques en ASCII représentant des nombres entiers ou réels signé ou non.

(Il n'est pas possible de regrouper sous ce code la commande ALPHA ASCII car les contrôles du numérique sont impératifs)

Une seule commande permet donc cet affichage, mais une petite explication s'impose….

Les nombres entiers n'ont pas de virgule (Ici on utilise le point décimal comme partout ailleurs dans le milieu informatique et depuis la nuit des temps !), mais ces nombres peuvent être positifs ou négatifs (Comme en binaire)
Les nombres réels ont une partie décimale séparée par le point, et peuvent être également positifs ou négatifs.

Le choix de représentation sera dicté seulement par les données, mais à savoir que le point décimal ne comptera PAS comme caractère utile puisqu'il appartient au niveau d'un digit de représentation et mobilise le segment "point" présent sur chaque digit.
Cependant ce qui complique un peu, c'est que ce point appartiendra au caractère PRÉCÉDENT.

Au niveau des longueurs de datas admises, le point ne comptera donc pas, et il sera donc possible d'ajouter 9 octets datas à la suite de la commande ASCII pour représenter un nombre.
Contrairement au point décimal (dp), le signe comptera comme caractère car il bloque un digit à lui seul. (Les limitations numériques de représentation sont indiquées dans le tableau).

5 Commandes génériques

Ces commandes sont au nombre de 9 et permettent quelques fonctionnalités intéressantes, tant au point de vue de l'affichage lui-même que d'un point de vue de l'exploitation, avec des réductions de consommation ou des paramétrages particuliers.
Contrairement aux commandes datas, ces commandes ne traitent pas les LED auxiliaires (Sauf une seule qui est dédiée à cette tâche)

5.1 Reset complet

Cette commande RESET (Code 0x00), permet le reset de l'afficheur, en réinitialisant le programme du PIC, et affiche "bric0x-y" indiquant l'auteur et la révision du programme d'affichage, comme à la mise sous tension.
L'intérêt peut être simplement en cas de problèmes, ou de remise en conditions initiales des différents "switchs programmes".
Penser au fait que les différents modes peuvent être enchaînés sans limitation et qu'à la fin il peut être possible que le Host "perde les pédales" sur ce qu'il a effectué préalablement (Absence de mémorisation des commandes envoyées).

Cette commande peut être utile lorsque le Host saute d'un mode d'affichage à un autre et qu'il ne veut pas mémoriser les valeurs par défaut (Time out, blink, Zéro, Nsign etc…)

Lors d'un reset, la totalité du programme est réinitialisée et le message d'entrée est affiché : "bric01-y" avec les valeurs par défaut.

5.2 Extinction afficheur et LED

La commande DISP_OFF (Code 0x01) , est un "switch logiciel" ON/OFF dont la valeur par défaut est "affichage" c'est la moindre des choses pour un dispositif d'affichage !
La suppression de l'affichage est cependant utile pour économiser l'énergie dans le cas d'une utilisation sur des systèmes autonomes alimentés par accus ou piles.
Dans ce cadre d'économie, les LEDs sont également éteintes.
Ce mode laisse cependant fonctionner le PIC contrairement à la commande suivante Standby.

Ce mode est supprimé par toute nouvelle commande data ou par cette même commande d'extinction qui fonctionne comme un switch.
Dans ce dernier cas les données précédentes sont conservées.
Si durant l'extinction, les commandes génériques autres que DISP_OFF ne rétablissent pas l'affichage, elles sont cependant exécutées et leurs action deviendra "visible" seulement lors d'un prochain affichage ou d'une commande data suivante, selon leurs nature.

5.3 CLEAR_SLEEP (Ou stanby)

Cette commande CLR_SLEEP (Code 0x02) , est fonctionnellement identique à la précédente d'extinction, mais avec cette fois la mise en sommeil du PIC (SLEEP) ce qui diminue encore la consommation de 1mA ! Certes ce n'est pas énorme, mais c'est avec des petits riens que l'on fait les grandes rivières. Il ne reste plus alors que le 4015 qui est alimenté.
(L'ULN 2803 ne consomme pas d'énergie car ce ne sont que des transistors darlington bloqués)

Pour rendre cette commande véritablement utile, le reset des segments ainsi que des LED est effectué automatiquement avant d'enclencher cette commande.
Une fois cette commande activée, le PIC passe en SLEEP et une première commande "dummy" est alors nécessaire pour le réveiller et réinitialiser complètement le programme.
Cette commande de réveil n'est pas active au sens "commande" et n'est utile que par le front descendant qui apparaît sur l'entrée RX. Il est possible de placer en commande de réveil n'importe quelle commande qui peut même être cette même commande CLEAR_SLEEP.

On peut donc dire que cette commande est également ON/OFF.

Cette commande présente aussi l'avantage de réafficher les anciennes valeurs présentes avant la mise en sommeil.

5.4 Validation Time Out affichage

Cette commande 0x04 TIME_OUT, valide seulement la possibilité d'un FUTUR Time Out avec extinction afficheurs et LED pour réduire la consommation après un temps d'inactivité prédéfini (Et paramétrable). Cette commande est un switch logiciel (ON/OFF) et après extinction, toute nouvelle commande data (Et certaines génériques) permettent de réafficher les valeurs de la dernière commande data précédente, ou immédiate.

Cette commande agit comme un monostable retriggerable. En effet toute commande réinitialise le délai initial, aussi c'est lorsqu'il n'y a plus de commande pendant un certain temps que le Time out peut se produire.

Cette commande peut être annulée en la renouvelant simplement suivant le mode switch ON/OFF comme d'autres commandes génériques qui fonctionnent suivant ce même principe.

Cette commande prend effet immédiatement et coupera l'affichage au bout du temps prévu (Même en affichage d'erreur)

Ce mode est très facile d'utilisation à partir d'un Host et permet au Host de ne pas se soucier de la consommation, vu que l'afficheur coupera l'alimentation dès qu'il n'y aura plus de commande et qu'il peut réafficher la dernière commande data ou toute nouvelle commande sans délai ni réinitialisation.

La commande générique de niveau supérieur reset, sera effectuée mais remettra à zéro ce mode avec un affichage initial.
Les commandes disp_off, Zero_Nsign, blink, seront également effectuées dans ce mode de validation de time out (actif), avec un résultat visible seulement à la prochaine commande data ou après l'annulation de validation du time_out par cette même commande de validation (invalidation).

5.5 Commande d'affichage des zéros

Cette commande générique 0x05 Zero_Sign, doit être passée AVANT une commande data pour laquelle l'affichage ou le non affichage devra s'appliquer.
Cette commande est par défaut pour les commandes DATAS de type BCD, HEXA et Segments, car la vision de tous les caractères est nécessaire et permet de mieux se repérer dans les bytes.

Cette commande doit être lancée AVANT une commande data pour être active sur CE data, mais reste en place jusqu'à ce qu'elle soit dénoncée par une deuxième commande identique. (ON/OFF).

Cependant suivant le type de commandes, cette option peut être masquée dans certaines commandes data pour des raisons de compréhension des résultats (BCD et HEXA notamment)

5.6 BLINK

C'est le clignotement des valeurs des afficheurs tant pour les affichages à 4 digits, que pour le deuxième affichage en cas de 8 digits.
C'est la commande 0x06 Blink, qui assure cette fonction.
Du fait des 2 affichages potentiels, et pour éviter toute confusion dans la lecture des valeurs, la rapidité de clignotement est très élevée.
Le Blink n'affecte que les afficheurs et non les LED qui rentent stables.
La rapidité de clignotement n'est pas prévue paramétrable pour maintenir la lisibilité. La fréquence choisie permet une moindre fatigue visuelle et à la fois une bonne intelligibilité de l'affichage ainsi que la mise en exergue voulue.

Cette commande est immédiatement active sur l'affichage en cours, y compris sur les messages d'erreurs.

5.7 Paramétrage du Temps de Time out

La commande T_O_OUT (0x09) permet de paramétrer ce temps de time out (Temps d'affichage en l'absence de toute commande avant extinction :Time out d'affichage).
Ce
temps est pré-établi à 13 secondes, ce qui permet de voir 3 affichages successifs complets (En mode 8 digits) et en l'absence de toute autre commande, avant l'arrêt.
Ce délai assez court est établi dans le but de réduire la consommation, mais peut être modifié par cette commande générique de paramétrage, par le Host. L'unité de base est la seconde et l'étendue va de 1 à 255 secondes.

Cette commande générique est une des deux seules à avoir un octet complémentaire de paramètre qui suit directement la commande elle-même. Cet octet complémentaire défini le nouveau temps de time out en secondes.

ATTENTION :

  • Ne pas confondre cette commande de paramétrage du temps  avant time out, avec la VALIDATION du mode Time_Out. Ici on paramètre le temps d'affichage avant la coupure, alors que dans l'autre commande de VALIDATION de TIME_OUT, on autorise ou non la coupure de l'affichage après ce temps.
  • Ne pas confondre non plus le time out d'affichage avec le time out de réception des datas


5.8 Temps d'affichage en 8 digits.

Cette commande TPS_SHFT (Code 0x0A) n'a d'utilité qu'en mode 8 digits.
L'affichage peut être de type standard 4 digits seulement (Et permanent) et il n'y aura donc aucune action dans ce cas, ou au contraire de deux fois 4 digits si l'on est en affichage virtuel de 8 digits.
C'est ce temps de base de CHACUN des 2 affichages qui est défini ici avec ce paramètre de 1 octet et qui est exprimé cette fois en modulo 10 ms.
Ce paramètre n'a d'utilité qu'en mode 8 digits puisqu'en mode 4 digits, l'affichage est unique et permanent.
Ce paramètre de 1 octet suit directement la commande TPS_SHFT (0x0A). Ce temps peut donc varier d'une fraction de seconde (Bien trop court) à 2.5 secondes pour l'affichage de chaque groupe (D'affichage).

Au niveau affichage en 8 digits, un temps de "repos" ou "silence" de 0.2 secondes permet de synchroniser "le premier visuel" sur les Poids Forts qui apparaissent juste après ce temps de repos. (Ce temps de repos n'est pas paramétrable). Cette commande TPS_SHFT permet  à chacun d'ajuster la visu suivant ses préférences.

5.9 Set LED

Cette dernière commande générique SET_LED (0x0B) permet de modifier l'état des LEDs sur le dernier affichage visualisé sans avoir à le renvoyer de nouveau car les données d'affichage ne sont déjà peut-être plus disponibles au niveau du Host ?

Cette commande générique est la seule à pouvoir modifier les LEDs quelque soit la commande DATA précédente qui a véhiculé également des valeurs (Ou non) pour les LEDs.
(Le Host peut en effet avoir séparé son processus d'affichage de digits et les LED en deux opérations distinctes).

Je pense en effet à afficher en premier une valeur numérique suivie de l'unité qui sera précisée par les LED et cette commande, soit devant une étiquette soit par un hublot transparent mentionnant une unité…
De plus il aurait été anormal de devoir lancer une commande data, rien que pour pouvoir positionner les LED.

Cette commande ne nécessite pas d'octet complémentaire puisque les 3 valeurs peuvent être intégrées dans la commande elle même, comme pour une commande data.

6 SCHÉMA

Celui-ci est très simple dans sa structure, et on voit le CD4015 qui assure la sérialisation interne pour les 2x4 valeurs de digits (Éventuellement moins si les LEDs ne sont pas nécessaires).
La sélection des segments est faite directement par les sorties du PIC sur le port C, ce qui simplifie largement les commandes de sélection.
L'ensemble se commande donc en logique positive au niveau des segments, mais également au niveau sélection des digits, puisqu'un 1 dans le 4015 mettra le 1 au darlington correspondant pour le retour des segments vers le 0V.

Toutes les entrées non utilisées sont rappelées à un potentiel pour éviter un flottement et des consommations excédentaires en SLEEP.

Le connecteur ICSP est maintenant comme à l'habitude en nez de carte 5 broches type PCI et la programmation du PIC ne nécessite aucune déconnection de composants.

J'ai réalisé le circuit avec le nouveau logiciel DIPTRACE et je continue d'apprendre à l'utiliser, car il reste quelques points sombres comme le miroir des textes que j'ai découvert par hasard au niveau de la sortie imprimante car ce miroir n'est possible qu'à cet endroit !
Au passage je n'ai pas pu résoudre sans artifice la mise en place sous un même nom de signal, de plusieurs pins (C'est le cas des straps par ponts CMS –Résistance nulle-)
(Dans cette recherche de texte en miroir, j'ai essayé l'introduction d'images JPG -avec succès-)

Globalement ce logiciel me plait bien, est puissant et correspond bien à mon utilisation non professionnelle.

DipTrace_Schematic___afficheur_LED_001_001



7 Réception commandes et données

Comme je n'ai pas de possibilités de mise au point en transmission synchrone, j'ai réalisé pour l'instant toute la mise au point en RS232 par le logiciel bien connu "Terminal de Bray++".

Je n'ai pas encore trouvé d'équivalent logiciel en transmission SYNCHRONE, et je vais devoir attendre d'aller plus loin dans le développement du futur ohmmètre pour faire cette mise au point en liaison Synchrone ou trouver une autre solution.
De toutes façons les deux procédés sont très proches et cela ne devrait pas poser de problèmes insurmontables, du moins il faut l'espérer !
La RS232 est également intéressante car elle utilise seulement 1 ligne I/O, mais mobilise un UART au niveau d'un futur Host qui n'en a peut-être qu'un seul ou même pas du tout ?
(C'est ce dernier point qui me déplait le plus, car j'ai déjà réalisé de la RS232 sans UART, mais ce n'est pas trop facile de respecter le timing)
Alors la transmission synchrone, bien qu'elle utilise 2 lignes, une pour l'horloge et l'autre pour les données permet une plus grande souplesse au niveau du temps pour l'envoi des données. En effet c'est l'horloge du Host qui assure l'échantillonnage bit à bit des données, aussi le Host peut utiliser de simples lignes I/O standard, ce qui libère un UART, voire même autorise l'utilisation de tout petits PIC n'ayant même pas d'UART.
(De plus en synchrone, il n'y a plus de bit START ni de bit STOP et c'est seulement 8 bits qui sont envoyés (au lieu de 10 en RS232). On gagne don aussi un peu en vitesse de transmission).


Préalablement à ce qui suit, j'avais envisagé dans les débuts du sujet, des commandes très nombreuses pour chacun des cas de données, mais cela s'est avéré un peu lourd à gérer, aussi il a été nécessaire d'introduire la notion de TIME OUT en réception, puis un autre point extrêmement important qui est le COMPTAGE DES BYTES REÇUS tout en ayant une limite à 10 bytes pour la commande la plus "gourmande" en données.
Des contrôles sont également effectués directement
au niveau des codes de commandes.

De ce comptage et des longueurs différentielles à 10, propres à chaque commande, on connaît le nombre exact de caractères reçus et de savoir ainsi dans quelle situation on se trouve. Ce point est crucial dans le processus d'analyse des données.

Mais comment traiter sans avoir une table des longueurs propres à chaque commande et de plus, traiter une même commande avec des longueurs de données différentes, et savoir quand les données sont complètes ?

Ajouter un caractère de fin ? Celui-ci pourrait être pris pour un data quel qu'il soit pour des nombres de données variables et surtout dans les commandes en binaire pur. C'est donc techniquement impossible.

La seule réponse possible est un TIME-OUT en réception qui déterminera que la commande est complète et lancera donc la décodification de cette commande.

ATTENTION : ne confondez pas ce time out de réception des données  séries avec les deux commandes de service pour le time out d'affichage cette fois ! (Rappel)

Ce time out de réception est un procédé important qui rigidifie certes un peu le timing de réception (Time out de 1.6ms) mais est essentiel pour pouvoir autoriser un nombre de données réduit si nécessaire.

En RS232 la réception est fixe à 115200 bps non paramétrable, ce qui devrait être également le maximum en Synchrone. Cependant dans ce dernier cas, on devra respecter un temps maximum entre octets ne dépassant pas 1.6ms, ce qui est tout de même un peu étroit pour les PIC à 31KHz de vitesse d'horloge.
Ce time out de réception limite un peu la rapidité d'affichage, mais il faut tout de même relativiser car l'œil humain n'a pas cette rapidité et ce temps reste très correct.

8 RéalisationDipTrace_PCB___afficheur_LED1_circuit

Comme à la bonne habitude, le circuit est là seulement pour indication car il n'est pas à jour. Il manque 3 straps et au moins 2 coupures. Il manque aussi 2 résistances de rappel pour RB5 et RB7. Plan implantation (Cuivre par transparence)

Par opposition le schéma théorique au §6 est à jour !

Bon allez, je vais me forcer... j'ajoute la photo des modifs côté cuivre. (à priori pas de modifs côté composants, mais à vérifier tout de même !)

Le circuit est assez beau, mais les vias sont beaucoup trop petits, et les runs trop fins aussi. Cela c'est la conséquence d'un nouvel outil CAO de circuits imprimé, car on ne maîtrise pas tout instantanément.

Je n'ai pas prévu de coffret car le montage sera alimenté en 5V par le Host. J'ai juste pris les courants les plus importants (Afficheurs et LED) directementafficheur_LED_cuivre_modif avant filtrage par le circuit LC d'entrée de tension. Le courant maximum (Tout allumé) pour cet afficheur spécifique, les LED et avec les valeurs de résistances du schéma est d'environ 35 à 40 mA au grand maximum.

Si vous voulez organiser autrement le circuit, libre à vous, mais je n'ai pas de possibilités de faire un beau double face, alors il me faut une certaine taille et comme j'ai encore des circuits en DIL, je les utilise.
La programmation se réalise toujours par le petit connecteur "nez de carte" à 5 broches pour l'ICSP qui ne nécessite aucune précaution spécifique.

Les lignes RB5 et RB7 sont utilisées pour la connexion au Host, et il est utile de placer un pull up de 68K à 100K sur chaque, pour pouvoir réaliser éventuellement un forçage à 0.
Les lignes RB4 et RB6 pourront être utilisées pour ceux qui voudront
fonctionner en SPI. Dans l'immédiat non utilisées, ces lignes seront rappelées également au VCC par 68K.
Cet ensemble de rappels au VCC est nécessaire pour que la consommation en mode standby soit minimale (Entrées en l'air).

En cas de plantage, ceux qui aiment un bouton reset pourront le placer sans problème mais en ajoutant un condensateur de quelques µF sur RA3, qui ne manquera pas de vous embêter en ICSP et de valider la fonction reset du PIC dans les bits de configuration, et qui ne le sont pas actuellement. Mais cela reste tout à fait possible !

Au niveau des transmissions série, (Il y aura pas une version unique, voir ci-après)

8.1   Particularités RS232 et SYNC

J'ai voulu tout de même voir un peu le problème de la réception SYNCHRONE en mode esclave et j'ai eu quelques problèmes qui commencent avec l'erreur W0005 en simulation, comme quoi ce PIC ne supporterait pas les liaisons synchrones !

En réalité ce PIC est bel et bien fait pour ce mode de transmission, mais c'est le simulateur qui n'accepte pas ce mode Synchrone. De plus, il y a des difficultés car je pensais utiliser le signal d'horloge à 1 au repos en utilisant SCKP, mais ça ne fonctionnait pas. Après bien des recherches, je me suis aperçu que SCKP ne concerne que la génération de l'horloge et que dans le mode esclave SCKP ne permet pas de choisir le front d'échantillonnage !

On comprend mal d'ailleurs pourquoi autoriser SCKP alors que la réception Synchrone fait toujours l'échantillonage des données sur le front négatif.

La documentation est loin d'être suffisamment claire sur ce point et j'avais pressenti des difficultés, c'est pourquoi j'avais écrit précédemment qu'il y aurait 2 versions spécifiques. Mais après avoir trouvé la solution qui est finalement extrêmement simple, il n'y aura qu'une seule version et le choix sera fait par le forçage à 1 ou 0 du PORTA,bit4 qui est disponible. (Seul le bit SYNC de TXSTA change le mode de transmission)
(Ce forçage non prévu d'origine peut se faire sans gros problème en plaçant R5 perpendiculaire sur le run de Vcc.)

Vous aurez compris à demi mot, que le signal d'horloge n'est plus à 1 au repos, mais à zéro (en mode Synchrone)

Ce choix est pris en compte uniquement à la mise sous tension, et le logiciel est donc en mesure d'assurer à la fois RS232 et SYNCHRONE. Il reste quand même à bien vérifier avant de crier victoire !

Je rappelle ici que ce mode synchrone, qui bien qu'il utilise 2 I/O, reste très intéressant car vous pouvez vous passer d'un PIC qui n'a pas d'UART, puisque la génération des deux signaux n'est pas critique et qu'une simple séquence peut envoyer sans problèmes des données à l'afficheur. (Je l'ai fait ainsi avec un PIC d'essais car je n'avais pas réussi à générer les signaux pour les essais)

A la mise sous tension en mode RS232 on affiche "bric S1-x" en mode Synchrone et "bric A1-x", avec A comme asynchrone et S comme Synchrone, cela dépendant du PORTA,Bit4 lu à la mise sous tension.

9    Considérations de vitesses de transmission

Il est évidentSYNCHRONE que l'affichage dynamique est un consommateur de temps important, aussi il est utile qu'un certain nombre d'évènements soient contingentés.
En RS232, il ne sera pas possible de descendre en dessous de 14400 bps, ni de monter au dessus de 115200 bps à cause du time_out de réception associé aux temps de réponse aux interrupts, mais aussi du travail interne de l'affichage. L'affichage est à fréquence fixe de 5 ms et reste prioritaire
De toutes façons, cette vitesse n'est pas directement paramétrable, et en RS232 elle est fixée à 115200 bps

On remarquera que la commande de reset avec tout à zéro sera un avantage qui sera le plus souvent une transmission sans erreur même aux vitesses anormales, et qui permettra donc toujours un reset du montage dans une majorité des cas.

Enfin je veux souligner un point particulier dû à la possibilité de travailler en mode Asynchrone ou Synchrone et qui concerne les vitesses de transmission en bits par seconde qui sont identiques dans un mode comme dans l'autre, mais il n'en est pas de même des vitesses de transmission en caractères par seconde qui sont différentes puisque dans le cas de transmission synchrone, il y a 8 bits transmis, alors qu'en Asynchrone (RS232) il y a 10 bits transmis pour chaque caractère (Un bit start et un bit stop en plus).

Au niveau transmissions synchrones les performances sont similaires avec un peu mieux aux fréquences élevées puisque le temps de transfert d'un caractère est plus rapide (8 bits au lieu de 10) soit 133 333 bps correspondant à une période bits de 15µs et pour la partie basse à 10 000 bps, soit une période bits de 200 µs.
C'est donc entre ces valeurs que le Host devra dialoguer avec l'afficheur, ce qui reste des valeurs tout à fait courantes et facilement atteignables.
En mode Synchrone, on regardera plus facilement la vitesse de transmission par le temps entre bits, ce qui correspondra mieux, surtout lorsque le Host travaillera en mode programmé (Sans l'utilisation d'un UART), il faudra alors se conformer à générer des signaux dont l'horloge pourra varier entre 15 et 200 µs.
Si les branches du sous programme ne sont pas rigoureusement égales, ce qui est presque toujours le cas, ce sera peu gênant puisque l'horloge suivra à quelques µs près. L'échantillonnage sera toujours sur le front descendant de l'horloge (Pour pouvoir rester compatible avec un Host avec PIC qui génèrera par UART ses signaux, puisqu'il n'est pas possible d'inverser le front d'échantillonnage dans ce cas précis).

Il ne sera cependant pas possible de travailler au niveau Host à 31 ou 32 KHz car on tombe en dehors de la plage du time out de réception des données. Cependant en rallongeant dans le programme, le délai de time_out, cela devrait rester possible. Ce sont des essais très nombreux et longs, mais je ne m'y lancerai pas…

La méthode utilisée pour vérifier en mode Synchrone a été d'afficher directement sur l'afficheur les valeurs de SPBRGH et SPBRG en mode binaire (code 10). L'oscillo mesure en même temps les périodes, ainsi les erreurs de calculs sont limitées !!! Les limites sont définies lorsque l'affichage "cafouille".

10   Conclusions


Ce dispositif a vocation de servir à quelque appareil de mesure ou à être utilisé comme afficheur à faible coût dans un montage électronique ou informatique devant afficher des valeurs en tous genres.

Il n'a que la prétention de permettre d'utiliser les fonds de tiroirs de façon utile et facile.

Je pense même qu'il serait possible d'utiliser seulement le PIC16F690 seul sans ULN et sans 4015, mais ce serait un peu difficile en programmation, au niveau des temps et des possibilités qui seraient réduites à l'affichage seul sans LED, encore faudrait il que la consommation des 8 segments de chaque digit reste "acceptable" pour pouvoir être drivée en direct par les 25mA d'une sortie PIC, et sans dépasser la puissance admise en global.
Dans cette ultime simplification, le nombre d'I/O
serait rigoureusement "ultra juste" avec le PIC 16F690 qui devrait pouvoir tout de même fonctionner en Synchrone ou RS232 mais sans LEDs.
En cas de difficultés sur le nombre d'I/O, il faudrait passer à la taille supérieure de PIC avec un 16F886 par exemple qui serait un peu moins "serré".

Au niveau logiciel, je dois dire que ce sujet est une véritable usine à problèmes marginaux  concernant les différents formats presque tous incompatibles entre eux avec des effets de bord nombreux.

Le regroupement des commandes "proches" est aussi un sujet délicat qui a nécessité parfois des séquences peu différentes mais pourtant incontournables.

Ce logiciel a beaucoup évolué au fil des essais et est maintenant assez stable pour que j'arrête là mes élucubrations sur un sujet bateau digne des longues soirées d'hiver.

La version "afficheur_LED_SYN.HEX" sera disponible prochainement (Je préfère attendre de diffuser pour avoir encore un peu de recul)
Si le sujet vous a plu, et si vous n'êtes pas une entreprise, alors vous pourriez même obtenir le source sur demande, mais je vous souhaite tout de même bien du plaisir, car ce n'est pas aussi simple que ça en a l'air !

(Notez que pour l'instant seule la version RS232 est opérationnelle, et en attente pour la version série Synchrone qui ne sera disponible que d'ici "quelques temps" en principe).

Bonne visu à tous !

bricolsec



11   La dernière modif...

Outre le problème de temps réel qui plantait une fois de temps en temps et qui est maintenant résolu, je me suis aperçu d'un oubli véritablement très important.
Toutes les fonctions de conversion qui permettent de soulager un programme principal ne servaient pratiquement à rien si l'on avait pas la maîtrise du point décimal d'un nombre, et notamment pour les entiers et les fonctions de type BIN_24, mais aussi pour toutes les autres qui ne le gèrent pas ou n'autorisent pas mathématiquement cette possibilité.
(Entiers qui doivent être divisés par la suite bien évidemment et deviennent des réels de fait)

C'est en réalisant le logiciel de l'ohmmètre que je me suis aperçu de cette grave lacune. Il a donc fallu ajouter cette fonction plus que nécessaire.

Pour pouvoir réaliser cela sur toutes les fonctions, il est essentiel que cette fonctionnalité soit issue d'une commande spécifique qui va agir directement sur la zone image des segments d'un affichage sans traiter le sujet mathématiquement parlant.

Cette nouvelle fonction Générique de nom Set_DP prend la valeur de commande 0x0B en remplacement de la commande Set_LED et Set_LED est maintenant déplacée à 0x0C. (Voir le nouveau tableau en fin d'a
Ce petit "shift" est seulement fait pour maintenir une homogénéité dans les commandes génériques ayant un octet complémentaire de paramètre.

Cette nouvelle fonction s'applique aussi bien sur les modes 4 que 8 digits et de façon automatique sans autre particularité.

Le principe est le suivant : L'octet d'accompagnement de la commande est bit à bit l'image du point décimal à ajouter suivant les règles habituelles PF/pf avec pf à droite sur le bit 0 de cet octet, celui correspondant au pf d'un nombre par exemple.

Cette fonction n'a d'effet que pour la durée d'une commande "datas", et doit être renouvelée à chaque nouvelle commande "datas".
Le quartet de droite de l'octet de paramètre est toujours utilisé en 4 digits comme en 8 digits et le quartet de droite n'est utilisé qu'en mode 8 digits.

Cette fonction n'a pas été limitée volontairement à un seul point mais chaque bit à 1 sera affiché. Le point appartient au digit situé à sa gauche.

J'ai hésité avant de rendre cette commande opérationnelle cette fois pour la mise à 0 éventuelle d'un point déjà existant, pour finalement y renoncer, bien que ce soit extrêmement facile, car le but est plus délicat et d'autres commandes permettent facilement de revenir à une situation sans un point décimal positionné.

Pour éviter toute confusion voici le nouveau tableau des commandes à jour.

afficheur_commandes_ods_002