Den Raspi mit 3.5 Zoll RPi Display TFT Touchscreen als Serial Monitor verwenden

In einem meiner letzten Artikel hatte ich ja beschrieben, wie man den 3.5 Zoll RPi Display TFT Touchscreen für Konsole (Lite) und Desktop für Raspberry Pi OS Version Bullseye einrichtet.

Und schließlich habe ich auch den Touchscreen unter dem Desktop richtig zum Laufen gebracht, so dass dort der Mausersatz richtig funktioniert.

Doch für die heutige praxis-orientierte Anwendung brauchen wir gar keinen Desktop und auch keinen Touch. Denn heute geht es um die Verwendung des Gespanns Raspberry Pi 3B mit XPT2046-Touchscreen als Terminal beziehungsweise Serial Monitor.

Der Serial Monitor soll im Grunde genau das machen, was auch der Serial Monitor der Arduino IDE macht: die Ausgaben, die in der Firmware via Serial.print() gemacht werden, anzeigen. Nur diesmal bitte nicht auf dem PC-Monitor, sondern auf dem kleinen, mobilen Raspberry Pi.

Der Vorteil liegt buchstäblich auf der Hand: den kleinen Raspi mit eingebautem Display kann man locker in der Hand halten, während ein Notebook doch eher sperrig ist. Den Raspi kann ich mit einer Powerbank betreiben und er braucht nicht viel Strom.

Also genau das richtige, um Module, die nur draussen richtig funktionieren über den Serial Monitor zu beobachten und zu debuggen.

Mir fällt da als erstes gleich mal mein GPS-Modul ein, dass natürlich nur richtig funktioniert, wenn es Satelliten-Empfang hat und das hat man halt nur unter freiem Himmel. Und das ist meistens draußen. Und wer da nicht einen Tisch auf der eigenen Terrasse mit Strom aus der Kabeltrommel hat, der braucht halt was mobiles. Und ein GPS-Modul sendet seine Daten über die serielle Schnittstelle, die wir dann ebenfalls beobachten können.

Serielle Schnittstelle RX und TX am GPIO-Header

Am einfachsten wäre es natürlich, direkt die RX und TX-Pins des Raspberry Pis am GPIO Header zu verwenden. In dem Pinout zum Raspberry Pi sehen wir, dass diese auf Pin Nr. 8 (TX, BCM 14) und 10 (RX, BCM 15) liegen.

Nur dummerweise sind die durch den extra breiten Anschlussstecker des Touchscreen Displays komplett verbaut. Das etwas unglückliche Design mit dem breiten und langen Header, auf dem sich der Touchscreen abstützt, ist zwar eine stabile Konstruktion für den Touchscreen, klaut aber schändlicherweise viele GPIO-Pins. Und das Design der RPi Display-Platine ist leider so unglücklich, dass man da auch nirgendswo etwas an die GPIO-Pins anlöten kann.

An Pin 8 und 10 (TX und RX) ist auch ein UART verbaut. UART steht für "Universal Asynchronous Receiver / Transmitter" und ist ein kleiner Chip, der die serielle Kommunikation managt. Das heißt, er ist dafür gebaut, sich genau an die definierten Geschwindigkeiten (300, 1200, 2400, 4800, 9600, 19200, 38400, ... 115200 bit per second) zu halten und hat einen Buffer, in dem er empfangenen Daten für uns bereithält, bis wir diese abholen. Klassische Beispiele für UARTs sind große Chips mit vielen Pins wie der 86C450 von Winbond oder 8250 von National Semiconductor. Heute sind die Chips natürlich wesentlich kompakter und auch lesitungsfähiger geworden. Zu 8-Bit- und Modem-Zeiten war das noch ein wenig anders.

Mit einem UART müssen wir nicht mehr "jedes Bit einzeln abholen" und auf das zeitkritische Timing achten, sondern bedienen uns am Buffer, wenn wir (also unser Programm) gerade Zeit haben. Das der Raspberry Pi, im Gegensatz zu einem echten Mikrocontoller wie einem Arduino nicht so toll mit zeitkritischen Vorgängen ist, habe ich ja schon bei meinem Versuch, Töne mit dem Raspi zu erzeugen, an eigener Haut erfahren. Das liegt wohl an dem Multitasking-Betriebssystem. Ein Mikrocontoller hingegen hat nur eine Aufgabe und kann genaue Timings einhalten.

Aus diesem Grund ist der UART für den Raspi unumgänglich und ich kann auch keine anderen Pins außer den verbauten 8 und 10 benutzen, da der UART eben genau hier dranhängt. Meine Idee, an den freien Pins 38 und 40 am anderen Ende des GPIO-Headers des Raspis eine serielle Schnittstelle zu betreiben, fällt darum flach. Eine softwarebasierte Schnittstelle mit dem Raspi (wie z. B. ein Arduino das könnte) funktioniert aufgrund der Timing-Problematik nicht.

Serielle Schnittstelle über einen USB-Port

Es gibt aber noch eine andere Möglichkeit: wir können einen Serial Adapter an einen der vier USB-Ports des Raspberry Pis stecken. Der Serial to USB Adapter selbst enthält dann einen UART-Chip.

Der Raspi kann sich dann wieder seine Daten aus dem Buffer des UARTs des Serial Adapters holen und muss sich nicht um das kritische Timing der serielle Kommunikation selbst kümmern.

Ich hab mich für einen FTDI-Adapter als seriellen Adapter entschieden, wobei FTDI für den Hersteller des Chipsatzes steht. Denn der FTDI-Chipsatz ist sehr populär und wird von den meisten Systemen gleich erkannt. Auch zum Beispiel Windows findet ihn sofort und man muss keinen extra Treiber installieren, im Gegensatz zu zum Beispiel einem günstigeren Chipsatz CH340.

Und eine Treiber-Installations-Orgie unter Linux will ich mir wirklich ersparen. Da habe ich noch üble Erinnerungen dran. Aber vielleicht hat sich das ja auch zwischenzeitlich gebessert. Egal, ich gehe auf Nummer sicher und nehme einen Adapter mit dem wohlbekannten FTDI-Chip.

Verkabelung und Test des FTDI-Adapters



Um die serielle Schnittstelle testen zu können, habe ich mir einen ESP8266 NodeMCU gegriffen und ein ganz einfaches Progrämmchen über die Arduino IDE auf den Mikrocontroller geladen:
void setup() { Serial.begin(115200); } void loop() { long za; za=0; while (1) { Serial.println(za); delay(1000); za++; } }
Das gibt jede Sekunde eine hochgezählte Zahl über die serielle Schnittstelle aus, die dann zu Testzwecken wieder empfangen werden kann.

Nun schließen wir die serielle Schnittstelle (RX und TX) des NodeMCU an die des FTDI-Adapters an. Dabei ist zu beachten dass TX an RX kommt und umgekehrt. Denn das gesendete (Transmit / TX) soll ja von der Gegenseite empfangen (Receive / RX) werden:
Pin NodeMCU Pin FTDI Kabelfarbe Bedeutung 3V VCC orange Versorgungsspannung G GND blau Ground / Masse TX RX grün ser. Kommunikation RX TX gelb ser. Kommunikation
Den FTDI-Adapter jumpern wir auf 3.3V, denn der NodeMCU ist ein 3.3 Volt-Controller. Bitte nicht vergessen, denn sonst legt der FTDI-Adapter 5 Volt an die RX und TX Pins des NodeMCUs an und ich weiß nicht, ob der das schadlos verträgt.

Dann können wir den FTDI-Adapter mit einem passenden USB-Kabel an den Raspberry Pi anschließen. Den Versorgungsstrom bekommt dann der FTDI-Adapter vom USB-Port der Raspi und gibt ihn mit 3.3V weiter an den NodeMCU.

Damit wären wir hardwaretechnisch fertig. Die eine LED auf dem FTDI-Adapter sollte jetzt schon im Sekundentakt kurz aufflackern.

Raspberry Pi OS einrichten

Kommen wir nun also zur Softwareseite des Raspberry Pi. Hier installieren wir zuerst ein Terminalprogramm. Das ist ein Programm für die Kommunikation über die serielle Schnittstelle. Das zeigt alles auf dem Bildschirm alles an, was darüber ankommt und schickt alles über den seriellen Port raus, was wir über die Tastatur eingeben. Also im Prinzip ein seriell Monitor, nur dass ein Terminalprogramm noch ein bisschen mehr kann wie den Datentransfer mitprotokollieren, Dateien senden, eine VT100 oder ANSI-Emulation um den Bildschirm zu löschen etc. pp.

Terminalprogramme hat man früher benutzt, um Daten von einem Großrechner an Terminals zu senden und umgekehrt. Die Geräte am Arbeitsplatz waren "dumme" Terminals, gerechnet wurden auf einem großen Rechner, den sich mehrere Mitarbeiter teilten. Dazu gaben sie Befehle auf der Terminaltastatur ein, die dann über ein (serielles) Kabel zum Großrechner gingen. Dieser führte die Befehle aus und schickte das Rechenergebnis dann über das Kabel wieder zurück zum Terminal, wo es dann angezeigt wurde.

Ich kann mich noch gut an die guten alten Mailbox-Zeiten erinnern. Auch ich hatte damals in den später 80ern und früher 90ern eine Mailbox, die CMT betrieben. Das war im Prinzip das Gleiche, nur dass das Kabel durch die Telefonleitung verlängert wurde. Man brauchte auf beiden Seiten ein sogenanntes Modem (Modulator / Demodulator), dass die seriellen Bits in Töne umwandelte, die über die Telefonleitung übertragen wurden. Auf der Gegenseite wurden aus den Tönen wieder Töne.

Natürlich habe ich damals selbst auch andere Mailboxen, auch BBS (Bulletin Board System) genannt, besucht. Und das manchmal so ausgiebig, dass mir beim Anblick der Telefonrechnung Tränen in die Augen stiegen. Aber das ist eine andere Story, zurück zum eigentlichen Thema.

Ich entscheide mich auf dem Raspberry Pi für das Terminalprogramm Minicom. Das ist schön kompakt, hat aber alles, was wir brauchen.
sudo apt install minicom
Als nächsten schauen wir, ob der Raspi unseren FTDI-Adapter gefunden hat:
pi@raspberrypi:~ $ lsusb Bus 001 Device 004: ID 0403:6001 Future Technology Devices International, Ltd FT232 Serial (UART) IC Bus 001 Device 005: ID 0513:0318 digital-X, Inc. Bus 001 Device 006: ID 0424:7800 Microchip Technology, Inc. (formerly SMSC) Bus 001 Device 003: ID 0424:2514 Microchip Technology, Inc. (formerly SMSC) USB 2.0 Hub Bus 001 Device 002: ID 0424:2514 Microchip Technology, Inc. (formerly SMSC) USB 2.0 Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Er hat. Und der Pi zeigt uns auch gleich an, dass es sich um einen RS232 UART Adapter handelt.

Weil er erkannt hat, dass es sich um eine serielle Schnittstelle handelt, sollte er uns eigentlich auch gleich ein TTY-Gerät eingerichtet haben. Das überprüfen wir mit
pi@raspberrypi:~ $ ls /dev/*USB* /dev/ttyUSB0
Ahja, wunderbar. Unser FTDI-Adapter steht nun unter dem Gerätenamen /dev/ttyUSB0 zur Verfügung. TTY steht für TeleTYpe, also Fernschreiber oder Telex und benutzt eine serielle TTY-Schnittstelle, die es in Computermaßstäben schon ewig gibt.

Nun können wir Minicom starten mit
minicom -b 115200 -D /dev/ttyUSB0
Et voila:



Wir sehen die serielle Ausgabe des NodeMCU auf unserem Raspi.

Und weil ich mir den komplizierten Aufruf nicht merken mag und außerdem möglichst wenig über die Mini-Tastatur tippen will, mache ich mir eine kleine Batch-Datei mit
nano serial.sh
in die ich dann schreibe
#!/bin/sh minicom -b 115200 -D /dev/ttyUSB0
Danach noch die Datei mit
chmod +x serial.sh
ausführbar machen und ich kann Miniport in Zukunft mit ./serial.sh aufrufen.

Minicom konfigurieren

Ein paar Kleinigkeiten sollten wir in Minicom noch einstellen. Dazu drücken wir STRG+A und dann o für kOnfiguration.

Dann stellen wir die Hardware Flow Control aus, denn sonst müssten wir uns hardwaretechnisch um den DTR-Pin am FTDI-Adapter kümmern. Und solange wir dann nicht tun würden, würden wir nichts an die Gegenseite senden, wenn wir auf der Tastatur des Raspberry Pi herumtippen.

Stattdessen schalten wir die Software Flow Control an. Dann können wir immer noch mit STRG+s und STRG+q die Ausgabe pausieren und wieder einschalten, sollte uns das, was über den Bildschirm huscht, zu schnell sein. Alternativ können wir natürlich auch die Bps herunterschrauben, dann sind wir aber zum langsam lesen gezwungen. Außerdem ist ja manchmal auch wichtig, welche Baudrate (Bps) die Gegenseite benutzt und wir brauchen die gleiche.
+-----------------------------------------------------------------------+ | A - Serial Device : /dev/ttyUSB0 | | B - Lockfile Location : /var/lock | | C - Callin Program : | | D - Callout Program : | | E - Bps/Par/Bits : 9600 8N1 | | F - Hardware Flow Control : No | | G - Software Flow Control : Yes | | H - RS485 Enable : No | | I - RS485 Rts On Send : No | | J - RS485 Rts After Send : No | | K - RS485 Rx During Tx : No | | L - RS485 Terminate Bus : No | | M - RS485 Delay Rts Before: 0 | | N - RS485 Delay Rts After : 0 | | | | Change which setting? | +-----------------------------------------------------------------------+
Jetzt kommt auch auf der Gegenseite das an, was wir tippen. Allerdings sehen wir selbst nicht, was wir tippen, darum schalten wir das lokale Echo ein:
+-----------------[Screen and keyboard]-----------------+ | A - Command key is : ^A | | B - Backspace key sends : BS | | C - Status line is : enabled | | D - Alarm sound : Yes | | E - Foreground Color (menu): WHITE | | F - Background Color (menu): BLACK | | G - Foreground Color (term): WHITE | | H - Background Color (term): BLACK | | I - Foreground Color (stat): WHITE | | J - Background Color (stat): BLACK | | K - History Buffer Size : 2000 | | L - Macros file : .macros | | M - Edit Macros | | N - Macros enabled : Yes | | O - Character conversion : | | P - Add linefeed : No | | Q - Local echo : Yes | | R - Line Wrap : No | | S - Hex Display : No | | T - Add carriage return : No | | Change which setting? (Esc to exit) | +-------------------------------------------------------+
Und damit wir nicht immer die gleiche Einstellung nach einem Neustart von Minicom vornehmen müssen, speichern wir unsere getroffenen Einstellungen als default:
+-----[configuration]------+ | Filenames and paths | | File transfer protocols | | Serial port setup | | Modem and dialing | | Screen and keyboard | | Save setup as dfl | | Save setup as.. | | Exit | +--------------------------+
Danach beenden wir Minicom mit STRG+A q und starten es neu, damit auch alle neuen Einstellungen aktiv sind.

Damit wäre der mobile Serial Monitor für den weiteren Einsatz bereit und ich kann demnächst mal mein GPS-Modul testen.

Video

Ich habe noch ein kleines Erklär- und Demonstrationsvideo gemacht, das ihr bei Youtube anschauen könnt: