ESP32-RS232-Adapter

RS232 goes WLAN! Ein modernes und preiswertes ESP32-Modul verleiht der seriellen Schnittstelle Flügel. Darüber hinaus bindet der Adapter altehrwürdige Mess- und Testgeräte über MQTT ins Heimnetz ein.

Wenn man über viele Jahre hinweg regelmäßig an Elektronikprojekten arbeitet, sammeln sich nach und nach einige Messgeräte an. So besitze ich beispielsweise ein SourceMeter 2400 von Keithley, das ich gerne nutze, um Fehler in elektronischen Baugruppen zu finden, diese in Betrieb zu nehmen oder sogar, um Eigenschaften von Bauteilen zu messen. Es lässt sich auch prima zum Testen von Elektrolytkondensatoren auf Leckströme oder zum Messen ihrer Nennkapazität nutzen. Auch ein Empfänger AR5000 von AOR ziert mein Büro. Diesen habe ich oft genutzt, um dem Amateurfunkgeschehen in der Welt zu folgen.

Beide Geräte können, wie viele andere im Labor, dank einer RS232-Schnittstelle auch vom PC aus gesteuert werden. Es gibt zahlreiche USB-RS232-Adapter im Handel, mit denen die Anbindung an den heimischen PC eigentlich kein Problem sein sollte. Doch während mein Adapter beim AR5000 prima funktionierte, war die Kommunikation beim Keithley SourceMeter deutlich instabiler. Verlorene Zeichen beim Senden von SCPI-Befehlen sorgten immer wieder für Verbindungsabbrüche.

Das ist RS232

Der in den 1960er Jahren definierte Standard RS232 überträgt die Datenbits eines Zeichens mittels Spannungspegeln. Die elektrischen Eigenschaften dazu wurden in der V.28 definiert, die übergeordnete Funktionalität ist in V.24 geregelt. Die V.28 sieht vor, dass senderseitig je nach logischem Bitwert in einem Fenster von 5 V bis 12 V beziehungsweise -5 V bis -12 V gearbeitet wird. Empfängerseitig ist dieses Fenster breiter und erstreckt sich bis hinunter zu 3 V respektive hinauf bis -3 V, um Effekte wie Rauschen, Spannungsabfall sowie durch Leitungskapazitäten oder -induktivitäten verschliffene Flanken zu berücksichtigen.

In älteren, billigen USB-zu-Seriell-Adaptern sowie in manchen Laptops ist man senderseitig schon gefährlich nahe an die ±5 V oder ±3 V gegangen, um den Entwicklungs- und Bauteilaufwand möglichst gering zu halten. Dies hat zu den berühmt-berüchtigten Weisheiten geführt, dass Laptops und RS232-Geräte oft nicht zusammen funktionieren. Die Zeichnung in Bild 1 aus einem TI-Dokument veranschaulicht die Spannungspegel, die anliegen müssen, um dem Standard zu entsprechen.

Ob das oben beschriebene Problem mit dem Keithley-Gerät nun an einem USB-Verlängerungskabel, an einer Erdschleife oder gar an den elektrischen Eigenschaften des verbauten Transceivers lag, war an dieser Stelle irrelevant, da ein USB-Kabel quer durch den Raum ohnehin nicht nur umständlich ist, sondern auch zum Stolpern einlädt. Daher musste eine schlanke, kompakte Wireless-Lösung her!

Bei Recherchen im Internet stößt man entweder auf fertige Module für Hutschienenmontage oder auf DIY-Aufbauten, die meist sehr auf eine bestimmte Anwendung ausgerichtet sind. Kompakte Lösungen waren keine zu finden, so dass ich selbst entwickeln durfte.

Designkriterien

Zwar ist die Lösung bewusst für uns „Maker“ und nicht für Endkunden gedacht, dennoch sollten wie vor jeder Entwicklung ein paar Kriterien festgelegt werden, die das Endprodukt erfüllen soll.

Basierend auf dem ESP32

Das RS232-Gateway soll primär Daten vom und hin zum Netzwerk übertragen. Hierfür wird üblicherweise der TCP-Port 23 (Telnet) genutzt. Allerdings sollen auch anwendungsspezifische Software-Anpassungen möglich sein, über die der Nutzer selbst entscheiden darf. Für mich war ein SCPI-zu-MQTT-Service wichtig, damit das SourceMeter über Nacht seine Messwerte an Grafana (siehe unten) zur Auswertung übertragen kann.

Der ESP32 bietet genügend Rechenleistung über das Versenden einfacher TCP-Pakete hinaus, um das angeschlossene Endgerät bequem per MQTT in Home Assistant oder einen vergleichbaren Dienst einzubinden oder mittels eines eigenen Frontends über den ESP32-Webserver freizugeben.

Eine Alternative wäre der ESP8266, der etwas weniger Platz in Anspruch nimmt und ein wenig günstiger ist. Allerdings stehen dem Platzgewinn eine deutlich schwächere CPU und weniger RAM gegenüber. Außerdem fehlt dem ESP8266 ein Bluetooth-Modul, was neben der eigentlich gewünschten WLAN-Funktion noch ein Ass im Ärmel dieser Lösung wäre.

Nachteil des ESP32 ist natürlich der deutlich höhere Strombedarf, den man mit circa 500 mA auf der 3,3-V-Schiene ansetzen darf. Freilich wird man die CPU nicht permanent zum Rechnen nutzen, aber je nachdem, wie gut optimiert die Software am Ende ist, wird der Spitzenstrom schon in diese Größenordnung reichen, wie es in Tabelle 4.2 des Datenblatts angegeben ist . Ein Vergleich mit dem Datenblatt des ESP8266 zeigt, dass die Stromaufnahme des ESP32 im Sendebetrieb etwa 35%, im Empfangsbetrieb etwa 80% höher liegt.

Kompaktes Design

Auf den Labortischen und unter den Schreibtischen gibt es schon genug Kabelsalat. Daher sollte die Schaltung zum einen direkt am DE-9 Stecker angelötet werden und von der Länge her nicht größer sein als ein Kaltgerätestecker plus dem Biegeradius des Netzkabels. Dadurch vergrößert die Platine im eingesteckten Zustand nicht den Platzbedarf des RS232-Endgeräts. Wenn ein Gehäuse benötigt wird, sollte dies einfach zu drucken sein; idealerweise könnte die Schaltung sogar in ein handelsübliches Standard-Gehäuse passen.

Spannungsversorgung über Micro-USB

Um die Platine zu versorgen, bietet sich eine Micro-USB-Buchse an, wie sie bereits für viele Kleingeräte Standard ist. Die vom ESP32 benötigten +3,3 V erzeugen wir mit einem AMS1117 von Advanced Monolithic Systems aus den +5 V vom USB-Port. Der AMS1117 ist zwar für bis 1 A ausgelegt, verursacht aber prinzipbedingt eine Menge Abwärme auf der doch recht kleinen Platine. Eine effizientere Alternative wäre der TPS62291 (Texas Instruments, ), ein Step-Down-Wandler im WSON-6-Gehäuse mit 2×2 mm, der ebenso bis 1 A arbeitet und bei geschickter Anordnung auch etwas Platz sparen würde. Allerdings ist er durch das winzige Gehäuse etwas anspruchsvoller zu löten, wenn man kein Mikroskop hat oder noch etwas ungeübt ist. Beim Löten unsichere Zeitgenossen finden im Video Trost und eine anschauliche Hilfe.

Zudem war die Verfügbarkeit dieses Bauteils in den letzten zwei Jahren zeitweise problematisch, wodurch die Bauteilkosten statt der üblichen 1,70 € bei deutlich über 20 € lagen (je nach Distributor ist das immer noch so). Wenn Sie im Internet Preise vergleichen, werden Sie aber auch Exemplare zu Preisen wie zu Omas Zeiten wiederfinden. Um es Ihnen nicht zu schwer zu machen, habe ich in dieser Version aber den AMS1117 verbaut, was das Handlöten dann doch einfacher gestaltet.

Spannungsversorgung über 9-pol D-Sub

Die Platine sollte alternativ aber auch über den 9-poligen D-Sub-Stecker zu versorgen sein. Erfahrene Elektroniker können, wenn sie diese Methode bevorzugen, eine kleine Anpassung am Endgerät beziehungsweise den Endgeräten vornehmen, um via RS232 die benötigten 5 V zur Verfügung zu stellen (und sich so ein zusätzliches Netzteil ersparen). Allerdings sieht der Standard keine solche Möglichkeit der Spannungsversorgung über den Stecker vor – hier müssen wir uns also außerhalb des Standards bewegen.

Da nach V.28 alle Signalleitungen Spannungen von +15 V bis -15 V führen können, liegt es nahe, eine der Signalleitungen zu verwenden. Pin 9, der im Normalfall vom Ring Indicator (RI) belegt ist, wird nur von Modems zur Signalisierung eines Anrufs verwendet. Da RS232-Modems ein wenig aus der Mode gekommen sind, wäre RI ein geeigneter Kandidat für die Spannungsversorgung.

Vorab müssen wir aber erst einmal prüfen, was passiert, wenn wir unerwartet die vollen Spannungen anlegen, weil wir beispielsweise ein Endgerät anschließen, das unsere Versorgungsleitung entsprechend V.28 bedient. Die +15 V wären für den AMS1117 selbst kein Problem; diese Spannung liegt innerhalb der Spezifikation. Sollten jedoch -15 V anliegen, würden die internen Schutzdioden des AMS die üblicherweise 10...20 mA des RS232 ableiten. Empirische Beobachtungen zeigen, dass diese Dioden hiermit kein Problem haben. Und ein RS232-Treiber ist laut Spezifikation kurzschlussfest, so dass auch hier kein Schaden entsteht.

Allerdings hängt an den +5 V auch die VDD unseres RS232-Transceivers, der nur bis 5,5 V spezifiziert ist. Glücklicherweise fällt in diesem Fall die Spannung durch die Strombegrenzung der RS232-Leitungen auf circa 3,5 V ab. Das klingt zunächst abenteuerlich; doch diese Überlegungen haben wir ja nur für den seltenen Fall angestellt, dass der RI auf Pin 9 durch das Endgerät doch bedient wird.

True RS232

Wie eingangs angesprochen, wollen wir möglichst die V.28 erfüllen, weswegen ein Transceiver zwingend erforderlich ist. Der ST232EBTR von ST ist im TSSOP-16-Gehäuse verfügbar und zudem mit circa 1 € recht preisgünstig. Durch seine internen Spannungsverdoppler- und -inverterschaltungen erzeugt er Versorgungsspannungen von +10 V und -10 V, die zum Treiben der RS232-Leitungen verwendet werden, wovon im Regelfall in etwa 9 V gemessen werden können.

Die Schaltung des ESP32-RS232-Dongles mit dem ESP32-WROOM-Modul (oder auch dem WROVER mit PSRAM) und den beiden ICs ST232EBTR und AMS1117 mit allen peripheren Bauteilen ist in Bild 2 zu sehen.

Bestückung

Für Platinen mit einer so kurzen Stückliste hat eine Bestückung beim Hersteller von Kosten und Aufwand her gesehen wenig Sinn, ebenso wie die Herstellung von Stencils und die anschließende Bestückung mittels heimischer Hotplate. Nein, bei dieser Platine in Bild 3 bietet sich das altmodische Handlöten förmlich an – die Bauteilanzahl ist gering, die Pads sind zugänglich.

Als erstes zu bestückendes Bauteil empfiehlt sich der ST232 (U3). Er ist relativ flach und die Pins benötigen unter Umständen etwas Nacharbeit. Danach darf das Hühnerfutter – Kondensatoren, Widerstände und LED – bestückt werden, anschließend der AMS1117 (U1) und die USB-Buchse. Als nächstes kommt der ESP32 an die Reihe und am Ende der 9-polige D-Sub-Verbinder.

Firmware

Die Grundfunktionen der Firmware sind zum einen natürlich das Routen der über das Netzwerk empfangenen Zeichen an den RS232-Port und zurück. Aber dank der Vielseitigkeit des ESP32 ist hier deutlich mehr möglich. Die Firmware, wie sie im Repository liegt, bietet aktuell zwei Arbeitsmodi – Telnet und MQTT/SCPI – die im Folgenden ausgeführt werden.

Telnet / Raw TCP-Socket

Wie schon in den Designkriterien ausgeführt, ist der Hauptzweck, die Daten vom Netzwerk auf den RS232-Port auszugeben. Bei solchen Adaptern ist es üblich, die zu übertragenden Zeichen roh über den TCP-Port 23 zu übertragen. Dieser Port wurde früher für Telnet-Verbindungen zu Servern genutzt, findet heute jedoch (abgesehen von eingebetteten Systemen) kaum noch Anwendung. Für unseren Zweck, der Übertragung von Befehlen oder Messwerten an serielle Endgeräte oder zurück, ist dies im Heimnetz absolut ausreichend.

Telnet ist ein Netzwerkprotokoll, das entwickelt wurde, um eine Fernsteuerung von Computern über ein Netzwerk zu ermöglichen. Es bietet einen textbasierten Kommunikationskanal, der es einem Nutzer erlaubt, auf einen entfernten Rechner zuzugreifen und dort Befehle auszuführen. Diese Verbindung erfolgt bidirektional, was bedeutet, dass sowohl Eingaben als auch Antworten über das Netzwerk übertragen werden. Ursprünglich im Kontext früher Internet-Standards entwickelt, wird Telnet häufig in Umgebungen verwendet, in denen eine einfache, textbasierte Kommunikation ausreichend ist. Allerdings gilt es als unsicher, da es keine Verschlüsselung bietet und somit alle übertragenen Daten, einschließlich Passwörter und anderer sensible Informationen, potenziell abgefangen werden können.

Für die ersten Kommunkationstests kann man das Tool telnet.exe nutzen. Bei älteren Windows-Versionen war das Tool Teil der Standardinstallation, falls nicht bei Ihnen vorhanden, bietet es sich an, die freie und universellere Alternative PuTTY zu verwenden.

MQTT / SCPI

Wenn man Messwerte über mehrere Stunden hinweg erfassen will, kann man geeignete Python-Skripte entwickeln oder gar fertige Tools auf seinem PC starten und per Telnet-Port auslesen. Wer aber bereits eine geeignete Infrastruktur in seinem Heimnetz besitzt, spart sich den stromfressenden PC und vereinfacht den Messaufbau.

In vielen Haushalten werden bereits Dienste wie MQTT, InfluxDB und Grafana zur Erfassung von Messwerten auf einem Raspberry Pi oder in Docker-Containern des heimischen NAS ausgeführt. Ohne zu weit auszuschweifen und in einfachen Worten:

• MQTT ist ein sogenanntes Broker-Protokoll, das von vielen Geräten unterstützt wird, um einfache Schlüssel/Wert-Paare zu publizieren.
• InfluxDB ist eine Datenbank, die darauf ausgelegt ist, Schlüssel/Wert-Paare, insbesondere deren zeitliche Verläufe, effizient zu speichern.
• Grafana liest Daten aus der Datenbank und stellt sie benutzerfreundlich mit beliebigen Zeitskalen auswertbar dar.

Wer ein solches Setup zuhause hat, für den gibt es mit dieser Firmware die Option, die vom SCPI-sprechenden Endgerät erzeugten Messwerte direkt an einen MQTT-Broker zur weiteren Auswertung zu senden.

Da sich die Befehle für die unterschiedlichen SCPI-Geräte deutlich unterscheiden, ist das einzig unterstützte Gerät momentan das Keithley Sourcemeter 2400. Dieser Code bietet aber einen guten Startpunkt für eigene Firmware-Varianten. Versierte Embedded-Entwickler sind gerne willkommen, den Funktionsumfang zu erweitern und mit der Community zu teilen.

Wie Messwert-Darstellungen in verschiedenen Anwendungen aussehen können, sieht man in Bild 4 (Grafana), Bild 5 (MQTT Explorer, ein umfassender MQTT-Client für verschiedene Plattformen ) und Bild 6 (ebenfalls Grafana). Um das all dies zu bewerkstelligen, muss der ESP32 sich um ein paar Dinge kümmern. Dazu braucht er Informationen, die wir per Webinterface zur Verfügung stellen müssen.

WLAN-Setup

Wird der konfigurierte Access-Point (AP) nicht gefunden oder ist noch keiner konfiguriert, wird der ESP32 aktiv und bietet sich als AP mit dem Namen esp232-config an. Am besten verbindet man sich mit dem Handy mit diesem AP. Nachdem man sich angemeldet hat, kann man per Browserzugriff auf http://192.168.4.1/ die wichtigsten Parameter konfigurieren. Die im ESP32 gehostete Webseite stellt sich wie in Bild 7 dar.

Tabelle 1 erläutert, was in die einzelnen Zeilen eingetragen werden muss.

OTA – Updates Over-The-Air

In der Arduino-IDE oder in dem von mir bevorzugten PlatformIO kann der ESP32 auch „remote“ aktualisiert werden. Das unterliegende Protokoll wird durch die Komponente ArduinoOTA implementiert. Zwar erleichtert dieses Feature ein hochfrequentes Aktualisieren des Mikrocontrollers, bei der praktischen Anwendung zeigten sich aber auch wesentliche Nachteile. Durch ein ständiges Allozieren und Freigeben von Puffern bei jedem empfangenen UDP-Paket fragmentierte der Speicher des ESP32, was völlig unvorhersehbar zu Resets geführt hat. Zu allem Überfluss passierte das unabhängig davon, ob OTA-Pakete unterwegs waren. Man kann sich vorstellen, dass eine Crash-Meldung, die über den UART des ESP32 ausgegeben wird, vom angeschlossenen Endgerät selten gut aufgenommen wird. Glücklicherweise gibt es mittlerweile Verbesserungen , die die Crashrate deutlich reduzieren. Gerade wegen dieser Unsicherheit wird das OTA-Feature immer nur kurz und auf Benutzerwunsch aktiviert, weswegen es oben im Webinterface einen Link (Enable OTA) dafür gibt.

Flashen

Wenn man nicht schon einen Pogo-Adapter für die ESP32-Module hat, muss der Mikrocontroller nach dem Bestücken mit der passenden Firmware versehen werden. Dazu sollte man den Sourcecode von [7] herunterladen und in PlatformIO importieren, kompilieren und letztendlich flashen.

Im Entwurf ist hierfür unten rechts ein Programmierport vorgesehen. Für kleine Stückzahlen reicht es, die Leitung IO0 auf GND zu ziehen und sowohl TXD0 als auch den etwas unglücklich benannten Pin U4_34 (RXD0 direkt am µC, siehe Bild 8) an einen USB-UART-Adapter zu löten.

Der ESP32 hat, wie Tabelle 2 zeigt, ein paar „Strapping-Pins“, die das Verhalten beim Start des ROM-Codes festlegen. In diesem Setup müssen wir uns nur um einen (IO0) kümmern. Ist die Firmware hochgeladen, sollte nach circa 30 s eine blinkende LED auf sich aufmerksam machen.

The Ugly

Der ESP32 hat sich in meinen Projekten mittlerweile sehr bewährt. Zwar gab es anfangs diverse Probleme in der verwendeten Arduino-Bibliothek hinsichtlich des UART-Puffers, weswegen der Code teilweise direkt auf die Bibliotheken des IDF-Frameworks zugreift. Auch Bugs in der ArduinoOTA-Bibliothek verursachten lange Debugging-Nächte, um dem Problem auf die Schliche zu kommen. Dadurch gibt es im Quellcode einige Stellen, an denen Workarounds zum Einsatz kamen. Da diese Firmware aber Open Source ist, wird sie weiterleben und erfreut sich an Verbesserungen, die von der Community kommen.

The Next Generation

Was mich an der Version v1.0 des Projekts bis heute stört, ist die doch recht umständliche Flashbarkeit bei der Erstinbetriebnahme (oder nach dem Flashen von fehlerhaften Entwicklungsständen). Dank eines Flashadapters mit Pogo-Pins, den ich für alle meine Projekte nutze, hält sich der Aufwand zwar in Grenzen, allerdings hat nicht jeder einen passenden Adapter parat oder hantiert gerne mit Fädeldrähten.

Aus diesem Grund geht der ESP32-RS232-Adapter in die nächste Runde und wird aktuell als Version 2.0 mit einem ESP32-S3-PICO entwickelt. Es gibt schon die ersten Prototypen, und die sehen vielversprechend aus. Der PICO ist ein komplettes Modul mit SPI-Flash und RAM, alles integriert in ein LGA-56-Gehäuse. Zwar schaut der PICO auf den ersten Blick nach einem QFN aus, die in der Regel gut per Hand lötbar sind, allerdings muss GND über das Exposed-Pad versorgt werden, weswegen bei Handbestückung das Pad per Bohrung verlötet werden muss. Weiter hat dieses Package keinen Anschlussrahmen und man kann die Pins nur sehr schlecht von der Seite verlöten. Letztendlich bleibt hier doch wohl nur eine (Mini-) Heizplatte als Ausweg .

Der große Vorteil des S3 ist, dass er über eine vollwertige USB-Peripherie verfügt, über die geflasht oder debugged werden kann. Notfalls lässt sich der ESP232 v2.0 dann auch als USB-zu-RS232-Adapter verwenden.

Ob wir damit im Kreis gehen und wieder da stehen, wo wir am Anfang losgelaufen sind, lassen wir bewusst offen. Denn wenn man es genau betrachtet, für was der ESP8266 damals gedacht war, nämlich als eine WLAN-zu-Seriell-Adapter, fragt man sich, warum es noch kein Gerät dieser Art zu kaufen gibt.

Anmerkung der Redaktion: Dieser Artikel (220352-02) erscheint in Elektor März/April 2024.

 Über den Autor

Gestartet in der Ära des C64 und der Lochrasterplatinen hat der Autor nach einer. Ausbildung zum Elektroniker ein Studium in der Informatik abgeschlossen. Seitdem entwickelt oder reverse-engineered er Software und eingebettete Systeme und veröffentlicht ausgewählte Projekte auf seiner Webseite www.g3gg0.de. Zu den bekannteren Projekten gehören Firmwaremodifikationen für Canon DSLRs namens Magic Lantern (www.magiclantern.fm) oder für die Toniebox (https://gt-blog.de/toniebox-hacking-how-to-get-started).

Sie haben Fragen oder Kommentare?

Haben Sie technische Fragen oder Anregungen zu diesem Frojekt? Dann kontaktieren Sie bitte den Autor unter elektor@g3gg0.de oder die Elektor-Redaktion unter redaktion@elektor.de.