LEDs Display

© Eberhard Haug 2003-2017

Optimale Darstellung dieser Website
bei aktiviertem
"Active Scripting" (LED-Menü-Buttons).

Bildschirm-Auflösung 800x600 wird unterstützt

Besucher seit 6.1.2004:
 

WEBCounter by GOWEB

In dieser Rubrik sollen LED-basierende Displays und deren Ansteuerung vorgestellt werden.

Hintergrund

Auch wenn ich bei meinen µC-Anwendungen häufig ein LCD zur Anzeige von Text und Zahlen verwende, sind 7-Segment-LED-Displays für kleine Anzeigen mit wenig Digits eine gute Alternative, insbesondere wenn die Anzeige bei schwachem oder stark schwankendem Umgebungslicht immer gut lesbar und ggf. selbst bei Kälte zuverlässig funktionieren soll.

Andererseits sind LED-Anzeigen deutlich cooler als LCDs, auch wenn sie ziemliche Stromfresser sind.


Der kurze Weg geht hier entlang:


LED&KEY - eine Deluxe-LED-Anzeige (25.07.2017)

Zunächst soll ein käufliches LED-Display vorgestellt werden, das außer acht 7-Segment-Anzeigen zusätzlich 8 extra LEDs und 8 Taster auf einer einzigen Platine von ca. 7,5 cm x 5 cm untergebracht hat und somit ziemlich universell ist.

Zudem ist dieses LED-Display auch noch ausgesprochen preisgünstig.

TM1638_LED&KEY


Alle Funktionen werden von einem einzigen IC übernommen, einem TM1638, der (neben einigen Derivaten) häufig für solche LED-Anzeigen verwendet wird, insbesondere wenn auch noch ein paar Tasten abgefragt werden sollen.

Common Cathode

Allerdings muss man beim Bestellen eines solchen Boards aufpassen, denn es gibt zwei verschiedene Ausführungen, nämlich einmal bestückt mit 7-Segment-LEDs mit gemeinsamer Kathode (einfacher im Aufbau und in der Anwendung) oder auch welche mit gemeinsamer Anode (aufwendiger).

Im folgenden Beitrag geht es ausschließlich um die Variante mit gemeinsamen Kathoden und zwar zunächst nur um die Ansteuerung der LEDs und nicht die Abfrage der Tasten.

Serielle Schnittstelle

Damit die Daten zum Display kommen (bzw. bei Bedarf die Tasten abgefragt werden können), wird beim TM1638 eine einfache serielle Schnittstelle verwendet, die neben Masse und 5V-Versorgung drei Signale benötigt, nämlich einen Takt, ein Strobe-Signal bzw. Chip-Select und ein Daten-Signal (ggf. bidirektional).

Wenn man das nicht gerade ausführliche Datenblatt (aktuell V1.3 in Englisch) studiert, erkennt man schnell, dass man diese Schnittstelle leicht per SPI-Protokoll bedienen kann, sofern man die folgende SPI-Konfiguration verwendet:

  • SPI-Mode 3 (CPOL = 1, CPHA = 1)
  • LSB zuerst senden (DORD = 1)

Man kann das SPI-Protokoll bei fehlender HW-SPI-Schnittstelle sogar sehr einfach per Software nachbilden, wie wir noch sehen werden.
Diese Methode (auch unter dem Begriff Bit-Banging bekannt) ist entsprechend flexibel bezüglich Pin-Belegung des verwendeten µC.

Hier ein Screen-Shot, wie ein Soft-SPI für den TM1638 aussehen kann:

Soft-SPI


Die Kanäle 1 und 2 sind die tatsächlichen Spannungen von Takt und Daten (40 cm Flachbandkabel zwischen µC und LED-Display) und der Rest sind die drei beschriebenen Logik-Signale separat per Logic-Pod gemessen und ausgewertet.

Dargestellt sind zwei Kommandos 44h (= Adress-Mode "fixed") und C0h (= Display-Adresse 0) gefolgt von einem Daten-Byte 3Fh (= 7-Segment-Ziffer "0").

Die SPI-Taktfrequenz ergibt sich aus dem CPU-Takt von 9,6 MHz für den von mir für dieses Projekt verwendeten ATmega328P und reichlich Soft-Pausen im Programm. Da liegt also noch einiges mehr drin (der TM1638 würde bis zu 1 MHz SPI-Takt zulassen).

Ohne Software geht gar nichts

Da nicht nur ein paar Bytes seriell übertragen werden, sondern (wegen den vielen Möglichkeiten des TM1638) auch teilweise komplexe Kommandos (und ggf. Daten in beide Richtungen), wäre es keine besonders gute Idee, den TM1638 mit einer selbstgestrickten Schieberegister-Hardware bedienen zu wollen.

Die einzig sinnvolle Ansteuerung des TM1638 ist per µC, der nun mal nicht ohne Software läuft.

nach oben


TM1638-Library

Nachfolgend soll deshalb ein umfangreiches TM1638-Softwaretreiber-Paket nebst Demoprogramm für die AVR-µC vorgestellt werden, das auf einem in AVR-Assembler geschriebenen Entwurf von Ralf Jardon[1] basiert und von mir (mit seiner Genehmigung) als sauber strukturiertes s’AVR-Programm umgeschrieben und mit ein paar Extras versehen wurde.

TM1638-Demo

Zunächst das Hauptprogramm, das abwechselnd einige grafische Effekte mit den LEDs und LED-Segmenten durchführt und dann einen Binärzähler, einen Hexadezimal-Zähler und einen Dezimalzähler (Vornullen unterdrückt) nebst zugehörigem Lauftext demonstriert.

Die beiden letzten Zähler nützen nicht alle 8 Digits aus, denn sonst würde die Demo bei unveränderten Wartezeiten zu lange dauern.

So ist der Dezimalzähler zwar ein 16-Bit-Zähler, wird aber beim Zählerstand 2.048 per EXITIF XH >= #8 angehalten.
Durch Auskommentieren dieses EXITIF zählt er natürlich bis 65.535.

Grundsätzlich lässt sich das Programm dank s’AVR einfach erweitern.

Hier der s’AVR-Code des Hauptprogramms in einem Scroll-Fenster[2]
(auf Smartphones ist der Text je nach verwendetem Browser u.U. nicht scrollbar, sondern wird dann am Stück dargestellt)
:

Das Format

Die Formatierung im Scroll-Fenster stammt direkt aus Atmel Studio und wird über den Umweg WORD und HTML-Format ohne weitere Nachbearbeitung für die Website verwendet.

Nun, das schaut zwar auf meiner Website ganz schön aus, ist aber wegen der HTML-Formatierung zur Weiterverwendung nicht besonders gut geeignet, denn selbst bei Einfügen als "nur Text" wird nach jeder Zeile unnötigerweise noch eine Leerzeile eingefügt. Außerdem sind die ursprünglichen TABs durch Leerzeichen ersetzt (was manchmal sogar ein Vorteil sein kann).

Deshalb stelle ich alle Quellprogramme zusammengezippt im Download-Bereich zur Verfügung, jeweils sowohl als strukturiertes s’AVR-Programm, als auch in compilierter AVR-ASM-Form, womit man zur Not mit einem beliebigen AVR-Assembler arbeiten könnte, auch wenn dann der ganze s’AVR-Luxus strukturierter AVR-Assembler-Programmierung dabei fehlt.

Programmänderungen und Einbindung in Atmel Studio

Unter Atmel Studio wird man zunächst ein Assembler-Projekt anlegen und alle Dateien aus dem ZIP-Paket ins Projekt-Verzeichnis kopieren.

Die *.asm-Dateien sind die Compilate der *.s-Dateien, die von mir für s’AVR geschrieben sind, sprich aus dem Hauptprogramm tm1638cc_EH.s wird durch s’AVR das Assembler-Programm tm1638cc_EH.asm erzeugt, das im Projekt unter "Output Files" mit der Eigenschaft "EntryFile" versehen sein muss (siehe s’AVR-Handbuch).

Da das Projekt aus mehreren Dateien besteht, die per .INCLUDE zusammengelinkt werden, kommt nur s’AVR 2.x in Frage, da nur diese Version das Compilieren mit unterschiedlichen Label-Prefixes zulässt.

Im Beispiel wurde Prefix _Lxxxx (voreingestellt) für das Hauptprogramm tm1638cc_EH.s, Prefix _Ixxxx für das Programm tm1638cc.inc_EH.s und _Dxxxx für das Programm tm1638cc_delay_EH.s verwendet (sonst würde es Adresskollisionen geben).

Unter "Tools" wurden bei Atmel Studio diese Einträge gemacht (siehe auch Handbuch 2.x), so dass das Compilieren sehr einfach klappt:

AVR Tools


In der Datei tm1638cc_EH.def (Definitionen) müssen ggf. der gewünschte AVR und dessen Taktfrequenz und die gewünschten Port-Pins geändert werden.

Die Dateien tm1638cc.mac (Macros) und tm1638cc_font.inc (Zeichensatz) bleiben normalerweise unberührt.

Das Anhängsel "_EH" bedeutet immer, dass ich gegenüber den Originalen von Ralf etwas Wesentliches geändert habe.

Den Zeichensatz habe ich mit einigen Kommentaren versehen und zusätzlich zu "-" noch die ASCII-Zeichen "(", ")" und "." (DP) ergänzt.

Ein extra Dezimalpunkt

Der Dezimalpunkt kann entweder als separates Zeichen in einem ASCII-Text verwendet (siehe letzten Textblock im Demo-Programm) oder dynamisch per Software innerhalb eines anderen Zeichens gesetzt werden (wie z.B. beim Dezimalzähler), indem das MSB (Bit 7) an der gewünschten Display-Stelle zusätzlich im zu druckenden Zeichen gesetzt wird.

Die Routine TM1638_PRINT_CHAR bewertet dieses Bit dann als zusätzlichen Dezimalpunkt im selben Zeichen. Mit einer roten Plexiglasscheibe davor schaut das dann schon ziemlich gut aus:

2.048


Die eigentliche Library

Weil’s so schön ist, hier noch die eigentliche TM1638-Library, sprich die vom Hauptprogramm aufgerufenen Unterprogramme - wiederum als s’AVR-Quellprogramm in einem Scroll-Fenster dargestellt (funktioniert leider nicht bei allen Smartphones, deshalb wird es dort eine etwas größere Angelegenheit):

SPI per Bit-Banging

So einfach schaut z.B. das Senden eines Bytes per SPI-Bit-Banging aus:

TM1638_SEND:

    push COUNT

    FOR COUNT := #8

        rcall delay1us

        ror TM1638_DATA_BYTE         ; put lowest bit into carry flag

        IF NC

            TM1638_CLK_LOW_DATA_LOW  ; carry is not set -> DATA pin LOW

        ELSE

            TM1638_CLK_LOW_DATA_HIGH ; if carry set  -> DATA pin HIGH

        ENDI

        rcall delay1us

        TM1638_CLK_HIGH              ; CLOCK pin HIGH

    ENDF                             ; next bit

    pop COUNT

    ret


Das ist sauber strukturiert programmiert und entsprechend übersichtlich.

Und so würde die Übersetzung von s’AVR 2.x in der effizienten Betriebsart in "flachem" AVR-Assembler ausschauen:

TM1638_SEND:

   push COUNT

   LDI COUNT,8

_I1:

   rcall delay1us

   ror TM1638_DATA_BYTE     ; put lowest bit into carry flag

   BRCS _I4

   TM1638_CLK_LOW_DATA_LOW  ; carry is not set -> DATA pin LOW

   RJMP _I6

_I5:

_I4:

   TM1638_CLK_LOW_DATA_HIGH ; if carry set  -> DATA pin HIGH

_I6:

   rcall delay1us

   TM1638_CLK_HIGH          ; CLOCK pin HIGH

   DEC COUNT

   BRNE _I1

   pop  COUNT

   ret


Die Befehlszeilen in Fettschrift wurden von s’AVR erzeugt und die ursprünglichen s’AVR-Anweisungen sind bei diesem Listing unterdrückt.

Die mit diesem kleinen Programm erzeugten elektrischen Signale sind fast so gut wie bei einer echten SPI-Schnittstelle per Hardware, siehe Oszillogramme weiter oben.

Weitere Tweaks

Die s’AVR-Version enthält gegenüber der ursprünglichen ASM-Version bereits einige Verbesserungen und Vereinfachungen.

Nun werden Register auch konsequent im aufgerufenen Unterprogramm gesichert und vor dem Verlassen wieder hergestellt, sofern sie vom Unterprogramm selbst verwendet werden. Ausgenommen davon sind im Normalfall die TM1638-Register, die ja bei jedem Aufruf neu geladen werden.

Zusätzlich könnte man einige der Routinen (sowohl im Hauptprogramm als auch in der Library) noch weiter vereinfachen, indem man z.B. die-Register TM1638_SEGM_BYTE und TM1638_GRID_BYTE direkt und nicht über einen AKKU-Umweg bedient (es sind ja alles jeweils AVR-Register im oberen Bereich R16 ff). Bei meinen MAX7219-Programm wird dies der Fall sein.

Der Rest

Die restlichen Programmdateien will ich mir an dieser Stelle schenken.
Sie sind - wie gesagt - alle im ZIP-Paket enthalten.

Eigene TM1638-Applikationen

Wenn man selbst ein (s’)AVR-Assembler-Projekt mit der vorgestellten TM1638-Library machen möchte, muss man nur das Hauptprogramm (sprich tm1638cc.s bzw. tm1638cc.asm) durch das eigene Programm ersetzen.

Die anderen Dateien können bis auf die Anpassungen an den verwendeten AVR-µC und die Pins für die serielle Schnittstelle so gut wie unverändert bleiben.

Tastenabfrage

Die aktuelle Library unterstützt noch nicht die Abfrage der Tasten (8 auf dem verwendeten Board, insgesamt sind maximal 24 möglich).

Bei Gelegenheit soll es auch hierfür noch einen Treiber und Beispiele geben - natürlich wieder geschrieben in s’AVR-Sprache.

nach oben


7-Segment-LED-Platine mit MAX7219 (3.8.2017)

Das folgende Projekt soll s’AVR-Software für diese kaskadierbare MAX7219-basierende 8-Digit-7-Segment-Anzeige sein:

MAX7219

Die Platine gibt es für wenig Geld fertig zu kaufen. Sie ist normalerweise etwas teurer als die oben beschriebene mit dem TM1638, obwohl sie weder Tasten noch separate Einzel-LEDs hat.

Das liegt vermutlich am verwendeten LED-Treiber MAX7219, der (wie der TM1638) mit dem geringsten Aufwand 7-Segment-Anzeigen mit gemeinsamer Kathode ansteuert.

Außer dem MAX7219 und den beiden 4-fach-7-Segment-Anzeigen gibt es auf der kleinen Platine nur noch einen Pufferkondensator und einen Widerstand, mit dem der maximale Segmentstrom eingestellt wird (10 kΩ für ca. 40mA LED-Strom).

Diese 40mA sind reichlich viel. Deshalb wird in der Library-Routine MAX7219_CLEAR per Software nur der halbe Segmentstrom von ca. 20mA eingestellt. Natürlich kann man das bei Bedarf ändern.

HEX voll dekodiert

Interessant ist vielleicht dieser Hinweis für den Fall eines eigenen Aufbaus:

    Der kompatible AS1107 von AMS ist möglicherweise etwas günstiger als der MAX7219 und hat sogar einige zusätzliche Features, u.a. einen zweiten Decode-Mode-Zeichensatz, um Binärwerte direkt von 0 bis F als HEX-Wert anzuzeigen, was beim MAX7219 per Soft-Font gemacht werden muss, denn dieser dekodiert zunächst die Ziffern 0 bis 9, einen Bindestrich und dann noch die Buchstaben E, H, L, P und ein Leerzeichen, womit man zwar "HELP" anzeigen kann, aber keine HEX-Zeichen ...

Mehrere Module kaskadiert

Die abgebildete Platine hat zwei Stiftleisten: Links eine zum Anschluss an den µC und rechts (auf dem Foto nicht sichtbar) eine zweite, um weitere solche Platinen hintereinander zu verschalten (leider nicht lückenlos, sondern nur mit großem Abstand).

Das geschieht mit einem SPI-Ausgang beim MAX7219/AS1107, der mit dem SPI-Eingang des jeweils nächsten Moduls verbunden wird (zusätzlich zu den gemeinsamen Chip-Select- und Takt-Anschlüssen).

Der Software-Aufwand dafür ist per s’AVR kaum größer als bei einem einzigen Modul, denn man muss nur genau so viele 16-bit-Datenpakete hintereinander verschicken, wie man Module hat und zwar beginnend mit dem Modul ganz am Ende der Kaskade.

Falls in einem der kaskadierten Module nichts geändert werden soll, gibt es hierfür einen NO-OP-Befehl (Digit-Adresse 0).

Auf diese Art steht nach dem Senden aller Datenpakete eine lange Datenschlange durch alle kaskadierten MAX7219 bereit, die schließlich mit dem Deaktivieren des allen gemeinsamen Chip-Selects (also der steigenden Flanke) individuell in die einzelnen MAX7219/AS1107 geladen wird.

Die im Download-Bereich bereitgestellte MAX7219-Library ist zunächst für ein Modul geschrieben, eine Erweiterung auf mehrere Module ist wegen der genannten Eigenschaft aber sehr einfach bzw. Teil des Anwendungsprogramms.

So würde man z.B. in MAX7219.inc die beiden Macro-Befehle MAX7219_STB_LOW am Anfang und MAX7219_STB_HIGH am Ende der Routine MAX7219_SEND_WORD entfernen (auskommentieren) und stattdessen diese beiden Macros am Anfang und Ende des gesamten Datenstrings (bestehend aus lauter MAX7219_SEND_WORD ohne die STB-Macros) einfügen.

Alternativ könnte man den gesamten Daten-String auch im RAM aufbereiten und mit einer neuen Routine MAX7219_SEND_STRING verschicken, die ein modifiziertes MAX7219_SEND_WORD ist.

Ähnlich, aber einiges doch etwas anders

Beim MAX7219 gibt es einige Ähnlichkeiten mit dem TM1638 (wie z.B. die SPI-Schnittstelle), aber mit gravierenden Unterschieden:

  • Zunächst wird beim SPI-Transfer das MSB und nicht das LSB zuerst verschickt.
  • Es werden immer 16 Bit pro Digit übertragen.
  • Der SPI-Takt liegt im Ruhezustand auf LOW statt auf HIGH.
  • Dann werden 7 der LED-Segmente (nämlich a bis g) in umgekehrter Reihenfolge in einem Byte dargestellt, so dass man einen komplett neuen Zeichensatz[3] benötigt, falls man nicht den eingeschränkten Zeichensatz des MAX7219 im Decode-Mode verwendet (oder den etwas besseren des AS1107).
  • Lediglich der Dezimalpunkt bleibt einheitlich an Bit-Position 7.
  • Schließlich fehlt dem MAX7219 die Möglichkeit, Tasten abzufragen. Dafür kann er einfach kaskadiert werden.

Die Library basiert eigentlich auf der s’AVR-Version des TM1368, wobei natürlich die genannten Unterschiede eingeflossen sind.
D.h. der Zeichensatz ist komplett neu und die SPI wird gemäß der abweichenden Spezifikation angesteuert, sowohl per Bit-Banging als auch per Hardware-SPI.

Die Änderungen bei SPI sind dennoch eine relativ einfache Angelegenheit. Dabei wurde auch die Pin-Belegung der Bit-Banging-Version so geändert, dass dasselbe Verbindungskabel zwischen µC und MAX7219-Platine verwendet werden kann wie bei der TM1638-Platine.

Da der MAX7219 die HEX-Zeichen 0xA bis 0xF nicht voll ausdekodiert, werden in der Library alle Ausgaben mit dem Soft-Font ausgeführt.

Die Behandlung des Dezimalpunktes als höchstwertiges Bit ist dieselbe wie bei der TM1638-Library.

Test-Mode

Der MAX7219 hat einen speziellen Test-Mode, mit dem man alle 8x 8 Segmente gleichzeitig mit maximaler Helligkeit anzeigen kann.

Wichtig ist, dass man den Test-Mode für Normalbetrieb wieder deaktiviert, denn sonst ist keine andere Anzeige möglich.

Da ich bei meinen Untersuchungen Situationen festgestellt hatte, dass der MAX7219 sporadisch in den Test-Mode ging (vermutlich wegen der relativ langen Zuleitung bei meinem Testaufbau und der geringen Pufferung der 5V-Versorgung auf der Anzeigeplatine) und in diesem Zustand nicht mehr per Software ansprechbar war, habe ich nach dem Power-On-Reset eine längere Wartezeit vorgesehen und bei jedem Aufruf von MAX7219_CLEAR wird vorsichtshalber auch der Test-Mode deaktiviert. Seitdem habe ich immer eine zuverlässige Anzeige.

Die Demo

Das Demo-Programm wurde gegenüber TM1638 ziemlich "aufgebohrt".

Der Binärzähler ist weiterhin 8 Bit breit (da bei einem Modul nur 8 Digits zur Anzeige zur Verfügung stehen), aber der Hexadezimalzähler ist nun 16 Bit breit und wird entsprechend mit 4 Digits angezeigt, im Programm aber (wie beim TM1638) bei 2.048 angehalten, damit die Demo nicht zu lange dauert.

Der Dezimalzähler geht in einer Binärversion nun ebenfalls über 16 Bit Breite und in einer ASCII-BCD-Version sogar über 5 volle Digit.
Der Stop ist hier ebenfalls bei 2.048 bzw. bei 10.000.

Da durch eine kleine Erweiterung ein ASCII-HEX-Zähler dabei abfällt, wurde ein solcher ebenfalls über 5 Digit realisiert (sprich bis F.FF.FF), der für die Demo aber bei  1.00.00 angehalten wird.

Da bei beiden BCD-Zählern[4] die Anzeige ab der niederwertigen Stelle erfolgt (nämlich so, wie gezählt wird), fällt bei der Ausgabe automatisch eine Vornullenunterdrückung mit ab, wenn vor Aufruf der Zähler die gesamte Anzeige im Hauptprogramm per MAX7219_CLEAR gelöscht wird.

Und das ist das zugehörige s’AVR-Programm des ASCII-HEX-Zählers in einem Scroll-Fenster (Auszug aus dem s’AVR-Quellprogramm MAX7219.s) - so aufgeräumt schaut strukturierte AVR-Assembler-Sprache aus:

Zeichen für Zeichen

Um ein einzelnes ASCII-Zeichen an einer bestimmten Stelle des Displays auszugeben, muss das ASCII-Zeichen generell zunächst in das Register MAX7219_DATA und die gewünschte Stelle (1 = ganz rechts bis 8 = ganz links) in Register MAX7219_ADDR geladen und dann die Routine MAX7219_PRINT_CHAR aufgerufen werden.

Mit Dezimalpunkt

Will man auch noch den Dezimalpunkt im selben Digit anzeigen, muss man vor dem Aufruf zusätzlich das höchstwertige Bit des ASCII-Zeichens z.B. per ori MAX7219_DATA, 0x80 setzen. Das ist schon alles.

Um alle 5 HEX-Digits zählen zu lassen, muss man im dargestellten s’AVR-Programm die Programmzeile EXITIF AKKU5 == #'1' (ziemlich am Ende) auskommentieren.

Der Nachteil bei den beiden ASCII-BCD-Zählern ist der Bedarf an fünf Zählerregistern (AKKU bis AKKU5), die aber wegen der ASCII-Darstellung eine sehr einfache Ausgabe auf der Anzeige erlauben.

Deshalb gibt es in der Library auch keine MAX7219_PRINT-Unterprogramme für die beiden ASCII-BCD/HBCD-Zähler.

Beim recht umfangreichen HEX-BCD-Zähler ist gleich zweimal eine größere Sprungweite per REPEAT.m nötig (siehe oben), da der AVR-Assembler sonst einen Range-Fehler reklamiert.
Ansonsten könnte man MAX7219.s auch mit der weniger eleganten und weniger effektiven "schmerzfreien" s’AVR-Option compilieren.

In einem umfangreicheren Anwendungsprogramm könnte man die BCD-Zähler auch von den Registern ins AVR-RAM auslagern (wohlgemerkt, es handelt sich hier um ein Demo-Programm für eine MAX7219-Library).

Außer den diversen Zählern enthält die Demo die kreisenden Segmente wie beim TM1638 und die Dimm-Funktion, allerdings hier logarithmisch in fünf Stufen. Zusätzlich wird noch das ganze Alphabet als Lauftext angezeigt - viel Spaß und gutes Gelingen damit!

nach oben


[1] Hier ein Link zur ASM-Library: https://github.com/Radulfus/TM1638

In diesen Dateien steht auch die vollständige E-Mail-Adresse von Ralf, die ich (wegen eigener schlechter Erfahrung) bewusst in den Scroll-Fenstern ausgeixt habe.

[2] Inline-Frames sind zwar altmodisch, aber in diesem Fall sehr praktisch, denn bei einem veränderten Quellprogramm muss nur die zugehörige Datei ausgetauscht werden.

[3] Man kann den neuen Zeichensatz mit wenig Aufwand durch Spiegelung der unteren 7 Bit des TM1638-Zeichensatzes erzeugen.

[4] Genau genommen müsste man den HEX-Zähler mit BCH = Binary Coded Hexadecimal statt BCD bezeichnen.