Woher ASCII kam

Bis in die 1970-er Jahre waren Lochkarten und Lochbänder die pupulärsten Massenspeicher. Programmentwicklungen erfolgten nicht auf einem Monitor (den hatte man noch nicht), sondern auf Lochkarten oder Lochbändern. Insbesondere Lochband war die erste Wahl bei der Entwicklung von Microcontrollern, weil Schreib- und Lesegeräte vergleichbar einfach und preiswert waren und an einem Orgautomat betrieben werden konnten. Im Bild sehen wir einen Auszug. Obwohl irgendwann um 1977 von mir selbst erzeugt, erschließt sich mir der Inhalt dieses Streifenstücks nicht mehr so recht. Egal.

Was dazu zu sagen wäre: Die achte Spur (Bit 7) wurde meist als Parität oder Steuerspur genutzt. Zwischen Bit 4 und 5 lag ein Markierungsloch, welches die Aufgabe der mechanischen Bitsynchronisation hatte.

Da ein Lochband am Anfang und am Ende meist ungelocht war, konnte die Binärzahl 0000_0000 (keine Löcher) nicht benutzt werden. Hatte man ein Zeichen falsch gelocht, gab es als Korrekturmöglichkeit nur den Handlocher: Mit dem wurden alle Bitstellen durchstoßen, damit hatte die Zahl 1111_1111 ebenfalls keine Bedeutung.

Was aber bedeutete das für die Übertragung binärer Zahlen? War es noch möglich, 8 Bit von 0x00 bis 0xFF (0...255) zu codieren? Nein, denn es fehlten die Ziffern 0x00 und 0xFF. Wie kam man heraus aus dem Schlamassel? Entweder war eine neunte Spur einzuführen, oder man verzichtete generell darauf, Binärzahlen darstellen zu wollen.

Und hier kommt ASCII ins Spiel: Man begnügte sich damit, pro Zeichen nur eine Ziffer 0...9 oder 0...F zu speichern.

ASCII heute

Bei den Mikrocontrollern ist es wie in der Politik. Ein Prozessor kann entweder denken/arbeiten, oder reden, d.h. Zeit und Lebensleistung für Kommunikation nutzen. Beides zusammen ist kontraproduktiv - das wird oft übersehen, wenn neue Monster-Protokolle für die Steuerung im automobilen Bereich oder in der Industrieautomation angewandt werden. 32-Bit Prozessoren mit zig Megahertz schaffen dann in wallender Hitze tatsächlich Datenraten von 9600 Baud (man denke an Linux-Derivate oder Raspi). Ob man will oder nicht - beim Anblick solcher Lösungen wird einem kuschelig warm!

Intelligente Sensoren nutzen oft den Parameter "Zeit" zur Messung. Oft sperrt man alle Interrupts, um zur Meßzeit auch ja nicht von außen vollgelabert zu werden, sich keine Lese-Unterbrechung einzufangen.

Gerade bei unseren Kleinsten kommt es darauf an, die notwendige Kommunikation (Laden von Parametern, Ausgabe der Ergebnisse) möglichst effizient und zeitsparend in das jeweilige Arbeitsprogramm zu integrieren. Hier hat ASCII ungebrochen eine hervorragende, in den letzten Jahren sogar wieder wachsende Bedeutung. Vorausgesetzt, die IC-Hersteller erkennen irgendwann, daß es Kunden gibt, die 9600 Baud nicht 16-fach abgetastet brauchen, sondern die 64 MegaBaud einfach abgetastet wollen. Im Embedded-Bereich existieren jede Menge kurzer Punkt- zu Punkt- Verbindungen, für die Überabtastung oder Netzprotokolle nutzlos sind. Fernverbindungen laufen sowieso über ETH.

Werden Daten unbekannter Größe übertragen, so sind Steuerzeichen nötig, um z.B. das Datenende zu kennzeichnen. Das Steuerzeichen selbst darf aber nicht in den Daten vorkommen. Üblich sind zur Datentrennung Leerzeichen, NULL-Zeichen, Tabulator, Komma, Semikolon (Excel CSV-Format) sowie Zeilenvorschub oder Wagenrücklauf.

Die Verwendung eines einzigen Steuerzeichens verhindert aber nun, daß Daten hexadezimal übertragen werden können. Schließlich kann ein einziger hex-Wert auch den Code eines Steuerzeichens besitzen, wie zum Beispiel 0x0d.

Will man hexadezimal codierte ("blanke") Daten übertragen, so geht das nur in einer Kapselung in einen Datenblock bekannter Größe. Diesen nannten wir früher "frame" (Rahmen), heute zumeist "pocket" (Tasche, Paket). Wir zählen die Bytes des Datenblocks mit, interessieren uns aber erst wieder für das nächste Steuerzeichen, wenn der Block beendet ist. Damit ist sichergestellt, daß wir nach der Übertragung des Datenpakets wieder zurückschalten können auf Befehlsdekodierung. Selbst die NULL-Terminierung von C hilft hier nicht weiter, schließlich ist die '\0' als Hex-Wert 0x00 mit dem Integer-Wert Null verwechselbar; die NULL ist (ASCII-) Steuerzeichen und Integer-Wert zugleich.

Will man Daten schnell übertragen, so ist Pufferung unumgänglich. Das Einlesen in den Puffer braucht wenig Rechenzeit, nachdem der String fertig gelesen ist, hat man alle Zeit der Welt für die Befehlsdekodierung. Problematisch wird es, wenn mit '\r' beendete ASCII-Befehle und ASCII-Befehle mit hex-Werten gemischt werden sollen. Unser Puffer funktioniert nicht mehr, da ein Befehlsende-Zeichen auch in einem hex-Wert vorkommen kann. Es ist unvermeidbar, Zeichen für Zeichen in Echtzeit zu dekodieren, um sofort das Paket rechtzeitig erkennen zu können. Das kostet Rechenzeit. Die übertragbare Datenrate vermindert sich.

Nun haben derzeitige Mikrocontroller unkomplizierte UART-Interfaces, die minimal mit einer Tx- und einer Rx-Leitung daherkommen. Abgesehen von Video-Kameras tut man sich in rechenintensiven Applikationen schwer, Paket-Protokolle zu implementieren. Diese blockieren Rechenzeit oder Interrupts oder beides. Flexibler ist oft eine Nutzung der ASCII-Codierung übertragener Zeichen, insbesondere, wenn Arbeits- und Kommunikationsprogramm nur alternativ laufen.

Nachteil einer ASCII-Codierung ist eine Umformung von Integer- oder Float-Werten in ASCII-Zeichen verschiedener Länge. Aus der uint16-Zahl 0xfe63 wird z.B. die ASCII-Zeichenfolge '6', '5', '1', '2', '3'. Aus der hex-Zahl 0x0000 wird ASCII '0'. Das Leseprogramm wird kompliziert, es braucht viel Rechenzeit.

Einfacher ist die von printf() bekannte Nibble-Kodierung von hex-Werten (Nibble: 4 Bit). Das Format %x stellt jeden hex-Wert als zwei ASCII dar. Damit existiert eine klare und einfache Codierungs- und Decodierungsvorschrift bei Sender und Empfänger. Steuerzeichen sind nun mit hex-Werten kompatibel.

Beispiel: Aus uint16_t 0xfe63 wird die ASCII-Zeichenfolge 'f', 'e', '6', '3'. Aus zwei Byte werden vier. Jedes Nibble (Halbbyte) wird mit seinem hex-Wert als ASCII '0'...'f' übertragen.

Weil sie immer mal wieder gebraucht werden, liegen hier einige einfache Grundroutinen zur Byte- zu Nibble-Wandlung als C-Code und als Demo-Exe.

Arbeitet man mit 12-Bit ADC, so macht die Nibble-Variante nur ein Drittel Overhead. Für die Übertragung von 2 Byte werden nur drei Nibble gebraucht. Aus zwei Byte hex werden drei Byte ASCII.

Für eine Protokollimplementierung ist also abzuwägen zwischen Rechenzeit für ein Blockprotokoll oder Übertragungszeit für die ASCII-Konvertierung und die dabei größere, zu übertragende Datenmenge:

- Die ASCII-Variante erschließt die Möglichkeit, sprachlich ungebunden zu kommunizieren, d.h. unter Verzicht auf Frames irgendwelcher Art. Man denke an Telnet, FTP, Email oder SMS. Sie eignet sich zur Steuerung und zur Übertragung von Parametern.

- Die hex-Block-Variante steht hingegen für die Übertragung uniformer Rechenergebnisse, man denke an Pixel-Bilder oder Zeitfunktionen.

Als geschlossene hex-Alternative bleibt die Definition eines einheitlichen (hex-) Pakets für alle Kommunikationen. Dieses hat mindestens die Länge des größten Parameter- oder Datensatzes plus dem Befehlswort-Format. Jeder simpelste Befehl hat die Länge des Pakets. Der Vorteil liegt darin, daß sich insbesondere ein Parametersatz als C-struct unkompliziert in und aus dem Puffer schieben läßt. Pakete können hier mit geringster Intelligenz gelesen oder geschrieben werden, damit sind höchste Bandbreiten sichergestellt. Kleben wir schlußendlich noch eine Sende- und Empfangsadresse an das Paket, sind wir fast im Internet. Der Nachteil aller Paket-Lösungen ist deren Unflexibilität. Die Gegenseite muß das Protokoll exakt kennen, um irgendwas zu verstehen. Und damit wären wir wieder bei den Vorzügen einer ASCII-Kodierung...

Wäre da nicht ein zweites Problem. Neben den langsamen USARTs derzeitiger Controller ist auch PuTTY nicht das schnellste. Etwa bei 900 kBaud ist der Spaß vorbei.

Wäre ich Prozessorhersteller, würde ich eine UART mit einem 256 Byte Puffer anbieten, die mit doppelter oder vierfacher CPU-Frequenz läuft. Der Puffer ist in den RAM-Bereich gemappt. Und ich würde sofort ein Devkit damit anbieten, welches eine Gegenstelle für eigene Experimente darstellt.