Raspberry Pi: Grundlagen serieller Kommunikation

Raspberry Pi meistert dank unzähliger Steckmodule vielfältigste Aufgaben, etwa im Smart Home und in der Industrie. Basis hierfür ist die 40-Pin-Stiftleiste. Dieser Grundlagenartikel informiert über die seriellen Schnittstellen.

Anbieter zum Thema

Schulz-Electronic GmbH

NetModule AG

MTM Power Messtechnik Mellenbach GmbH

Der Raspberry Pi hat für die serielle Kommunikation zwei spezielle Hardwareeinheiten, die über die GPIO-Pins zugänglich sind: den PL011-UART und den miniUART. Erfahren Sie, wie Sie diese Pins ansteuern und nutzen können und wie sich ein RS485-Transceiver daran anbinden lässt.

Ich spreche im folgenden vom Empfänger und Sender. Die Kommunikation ist meistens (außer bei Halfduplex RS485) bidirektional, d.h. beide Partner sind jeweils Sender und Empfänger gleichzeitig. Dabei erfolgt die Kommunikation im sogenannten Vollduplex-Modus. Das Geschriebene gilt also für beide Kommunikationspartner, jeweils in unterschiedliche Richtung. Es reicht dass wir uns eine Seite der Kommunikation anschauen, da die andere genau gleich läuft (einfach nur in die Gegenrichtung).

Bildergalerie

Die serielle Kommunikation

Bei serieller Kommunikation nutzen wir eine Datenleitung, um seriell Daten zu übermitteln. Die einzelnen Bits werden nacheinander, also in Serie, übermittelt. Die Alternative dazu wäre die parallele Kommunikation, bei der Bits gleichzeitig übertragen werden, beispielsweise bei älteren Druckern mit Parallelport. Die meisten modernen Schnittstellen sind seriell. Dazu zählen etwa der Universal Serial Bus (USB), das serielle Peripherie-Interface (SPI), Inter-Integrated Circuit (gesprochen als I-Quadrat-C; I²C), Serial AT Attachment (SATA) und das in Fahrzeugen verwendete Bussystem Controller Area Network (CAN).

Die serielle Kommunikation hat inbesondere bei höheren Geschwindigkeiten Vorteile gegenüber der parallelen, da es sehr schwierig wäre, parallele Pins zu synchronisieren. Die serielle Kommunikation benötigt für die Datenübertragung zudem weniger Leitungen als die parallele, was die Kabel dünner und günstiger macht.

Von Bits, Bytes und ASCII

Ein Bit ist die kleinste Informationseinheit in einem Computer und entspricht den Zuständen „0“ und „1“. Ein Byte ist die kleinste adressierbare Datenmenge. Ein Byte besteht aus 8 Bit. Mit einem Byte (8 Bits) lassen sich 256 Zeichen darstellen. Üblicherweise startet die Nummerierung bei 0, d.h. es gibt Zeichen 0 bis 255. Auf der Seite ASCII-Code findet sich die Belegung dieser Zeichen, falls sie als ASCII interpretiert werden. Einige dieser ASCII-Zeichen sind nicht-druckbare Zeichen (bspw. für neue Zeile, etc.); andere sind Sonderzeichen, etwa Umlaute. Die Zeichen ab 128 können je nach Codepage anders interpretiert werden, etwa als kyrillische Zeichen. Die Codepage bedeutet, man einigt sich darauf, was die Zeichen darstellen. UTF-8 nutzt hingegen ein bis vier Bytes zum Kodieren von einem Zeichen. Es ist zu ASCII abwärts kompatibel: die Zeichen 0 bis 127 entsprechen dem ASCII Encoding. Fazit: ein Byte, oder 8 Bit ist die Grundeinheit für Kommunikation am PC.

Wir übertragen, speichern und denken in Bytes am Computer. Über die serielle Schnittstelle übertragen wir bitweise, aber jeweils 1 Byte am Block. Die Aufgabe des Universal Asynchronous Receiver Transmitters UARTs im Raspberry Pi, Mikrocontroller, PC, Arduino, etc. ist, die Daten aus dem Byte in Bits umzuwandeln und nacheinander zu senden. Dabei kommt typischerweise eine Sendeleitung je Richtung zum Einsatz – der UART hat einen Sendeteil (TX für Transmit), und einen Empfangsteil (RX für Receive). Die serielle Kommunikation über einen UART hat im Gegensatz zu SPI und I²C keine zusätzliche Takt/Clockleitung für den Sendetakt. Auf der Gegenseite empfängt der UART die einzelnen Bits und setzt sie wieder zu einem Byte zusammen.

Start-Bit und Stop-Bit

Dabei handelt es sich um das sogenannte „Data framing“. Die Nutzdaten (unser zu übertragendes Byte) werden dabei von dem Start-Bit und dem Stop-Bit eingerahmt. Das Start-Bit ist immer „0“ bzw. „low“, das Stop-Bit immer „1“ bzw. „high“. Das passiert bei jedem einzelnen Byte das wir übertragen.

Ziel ist, dass der Empfänger erkennt, wann gesendet wird, bzw. wann keine Kommunikation erfolgt, und wann die Leitung unterbrochen ist („break detection“), desweiteren, dass der Empfänger mehrere hintereinander gesendete Zeichen sicher unterscheiden kann und sich nicht desynchronisiert.

Die Zustände „high“ und „low“ beim UART

Als Relikt aus der Telegrafie ist der Standardzustand im Leerlauf ohne Kommunikation beim UART „high“, d.h. eine logische 1. Der UART zieht also auf Senderseite den GPIO Pin (TX) des Raspberry Pis auf +3,3 V. Dieser Pin ist normalerweise mit dem Eingangspin (RX) auf der Empfängerseite verbunden, so dass hier dauerhaft +3,3 V anliegen.

Falls die Leitung unterbrochen ist, d.h. am RX-Pin der Empfängerseite der Zustand dauerhaft eine logische 0 bzw. GND ist, kann der UART der Empfängerseite das detektieren und dem System melden.

Hinweis: nur der PL011 UART ist zur „break detection“ imstande. Da der miniUART das Stop-Bit nicht prüft, würde er bei defekter Leitung fälschlicherweise 0x00 ausgeben, da er wiederholt „low“ von der „Leitung“ liest. Details hierzu finden Sie auf der Seite von Raspberrypi.org zu den Braodcom-SoCs; bei dieser Verlinkung auf Seite 10f.

Will der Sender ein Byte senden, zieht er die Leitung auf GND – das ist das Start-Bit. Danach werden die einzelnen Bits nacheinander übermittelt (0 als low, d.h. Leitung liegt auf GND und 1 als high, d.h. Leitung auf +3,3 V im Falle des Pi). Anschließend zieht der Sender für das Stop-Bit die Leitung wieder auf high, +3,3 V – den Ursprungszustand. Das ganze zusammen nennt man ein Frame.

Asynchrone Datenkommunikation

Auf diese Weise wird sichergestellt, dass zumindest ein Übergang in der Übertragung stattfindet. Würden wir eine lange Reihe von 0en übertragen, wären das ohne die Start- und Stop-Bits alles Zustände mit 0 V. Dann könnten Sender und Empfänger sich desynchronisieren. Der Sender würde beispielsweise 800 Nullen senden, und der Empfänger 798 zählen, da er nicht genau weiß, wann sie jeweils anfangen, sondern sich ausschließlich auf seine eingebaute Uhr verlassen muss. Durch das Start- und Stop-Bit kann der Empfänger sich immer wieder synchronisieren, mindestens ein Übergang der Leitung pro gesendetem Byte ist garantiert. Da das Senden des Start-Bits jederzeit erfolgen kann, mit beliebigen Pausen zwischen dem letzten Stop-Bit und dem neuen Start-Bit, wird diese Art der Kommunikation als asynchron bezeichnet.

Erweiterte Kommunikationsgrundlagen

Im folgenden wird die eben besprochene Basis konkretisiert und erweitert. Es gibt für die serielle Kommunikation über den UART folgende Parameter, die auf beiden Seiten (Empfänger und Sender) eingestellt werden müssen, etwa über PuTTY:

Geschwindigkeit: Bit-Rate in Bit/s, bspw. 115200 Bit/s – jedes Bit „dauert“ dann 8,68 Mikrosekunden.

Zahl der Daten-Bits: In der Einleitung habe ich vom Standard gesprochen, in welchem Fall wir bei jedem gesendeten Frame ein Byte, also 8 Bit an Nutzdaten übertragen. Es gibt jedoch auch andere Möglichkeiten:

• 5 Bit: z. B. als Baudot-Code

• 6 Bit: selten genutzt

• 7 Bit: für das „echte“ ASCII (nur mit den ersten 0-127 Zeichen)

• 8 Bit: am weitesten verbreitet

• 9 Bit: selten genutzt

Die Stop-Bits werden am Ende jedes Zeichens bzw. als Abschluss des Frames gesendet. Sie erlauben dem Empfänger das Ende zu detektieren, und sich zu synchronisieren. Üblicherweise wird ein Stop-Bit verwendet, es gibt aber auch 1 1/2 oder 2 Stop-Bits. Das war zum Beispiel für die langsamen elektromechanischen Teleprinter notwendig.

Die Parity ist eine einfache Möglichkeit, Fehler bei der Übertragung zu prüfen. (Aber ohne Korrekturmöglichkeit!) Diese Fehler können beispielsweise durch äußere Störeinwirkungen (elektromagnetische Störungen auf schlecht geschirmten Leitungen) erfolgen, der Empfänger detektiert fälschlicherweise eine 1 wo eine 0 sein sollte oder umgekehrt.

Bei der Parity wird dabei die Zahl der logischen 1er im übertragenen Byte, inklusive des ParityBits gezählt. Das ParityBit wird so gesetzt (also 0 oder 1), dass die Zahl der logischen 1er immer entweder gerade oder ungerade ist (je nachdem ob ODD oder EVEN Parity eingesetzt wird). Falls ein „Bitflip“ vorliegt, und eine vorher nicht dagewesene 1 detektiert wird, bzw. eine 1 zu einer 0 geworden ist, kann der Empfänger das erkennen. Leider werden zwei bzw. andere gerade Anzahlen an Bitflips nicht gemerkt!

Falls ein Parity-Bit vorgesehen wird, wird es zusätzlich nach dem letzten Daten-Bit, und vor dem Stop-Bit im Frame mit übertragen (Bild 1). Es gibt folgende Möglichkeiten die Parity zu konfigurieren:

• None: es wird kein Parity-Bit mitgesendet

• Odd: die Zahl der „logischen 1er“ muss ungerade sein

• Even: die Zahl der „logischen 1er“ muss gerade sein

• Mark: das Parity-Bit wird immer auf 1 gesetzt

• Space: das Parity-Bit wird immer auf 0 gesetzt

Mark und Space werden normalerweise nicht eingesetzt, da sie nicht zur Fehlererkennung beitragen.

Unabhängig vom Parity-Bit können wir auf einer höheren Schicht der Kommunikation weitere Fehlermechanismen, bzw. Mechanismen zur Wiederanforderung der Daten vereinbaren.

Flow Control

Ebenfalls am besten aus der historischen Sicht zu verstehen ist Flow Control: Es geht hier darum, dass der Empfänger den Sender informiert, wenn er für weitere Daten bereit ist. Beispielsweise könnte der Empfänger eine gewisse Zeit benötigen, um die Daten zu verarbeiten, oder sein Empfangsbuffer ist voll, und er kann keine weiteren Daten annehmen ohne welche zu verlieren. Zum Beispiel ein Drucker, der Zeile für Zeile langsam druckt – und nicht nachkommt, wenn die Daten zu schnell geschickt werden. Es gibt Hardware-Flow-Control und Software-Flow-Control, oder Flow Control kann abgeschaltet werden.

Für Hardware Flow Control werden zwei zusätzliche Steuerleitungen benötigt:

• RTS = Ready to send

• CTS = Clear to send

Am Raspberry Pi sind diese zwei zusätzlichen Pins für beide UARTs (PL011 und miniUART) verfügbar. Die Idee dahinter ist, dass der Sender RTS auf GND herunterzieht, wenn er senden möchte. Der Empfänger zieht im Gegenzug CTS auf GND, und signalisiert damit dass er bereit ist, Daten vom Sender zu akzeptieren.

Möglich ist auch, statt RTS den Pin als RTR zu verwenden. In diesem Fall wird RTS immer als „gesetzt“ angenommen (d.h. der Empfänger sollte sich immer empfangsbereit halten). RTR dient jetzt als Indikation für die Empfangsbereitschaft des Senders (für die Kommunikation in die Gegenrichtung).

Hinweis: Ich nutze hier das Wort Sender für den Computer ("DTE, Data Terminal Equipment"), da die Terminologie dem Computer das RTR bzw. RTS-Signal zuweist, während der Empfänger/ DCE = Data Communication Equipment das CTS-Signal zugewiesen hat.

Im einfachsten Kommunikationsfall können wir auf Flow Control verzichten.

Beim Software-Flow-Control werden zwei besondere Zeichen vereinbart, bspw. die ASCII-Kontrollzeichen XON/XOFF. Standardmäßig startet der Empfänger im „Bereit“-Modus, und empfängt Daten. Falls seine Buffer überfüllt zu werden drohen, sendet er dem Sender (auf der anderen Leitung, bei der der Empfänger selbst der Sender ist) ein XOFF Zeichen. Sobald er wieder empfangen kann, sendet er ein XON Zeichen.

Software Flow Control benötigt weniger Kabel, allerdings muss sichergestellt sein, dass die XON/XOFF Zeichen nur für diesen Zweck verwendet werden, und falls bspw. binäre Daten übertragen werden entsprechend „escaped“ werden.

PuTTY Flow-Control-Möglichkeiten

PuTTY PuTTY ist eine freie Software zum Herstellen von Verbindungen über Secure Shell, Telnet, Remote Login oder serielle Schnittstellen. Die Flow-Control-Einstellungsmöglichkeiten von Putty sind (Bild 2):

• None: es wird kein Flow Control verwendet. Sinnvoll ist daher die Datenrate so zu setzen, dass der Empfänger die Daten sicher empfangen und verarbeiten kann, bzw. mit Pausen von Senderseite zu arbeiten, oder in höheren Protokollschichten Mechanismen für erneuten Versand vorzusehen

• XON/XOFF: Software Flow Control

• RTS/CTS: Hardware Flow Control mit RTS und CTS

• DSR/DTR: Hardware Flow Control mit DSR und DTR (nicht Standard, aber bei manchen Geräten) - am Pi nicht verfügbar.

RS232-Schnittstellenstandard

RS232 ist ein Standard für serielle Kommunikation zwischen Geräten (bspw. Computer und Modem). Bei diesem Standard wird die elektrische Schnittstelle definiert, und es gibt Übereinkünfte über die Steckverbinder. Die entsprechende aktuelle Norm stammt aus dem Jahr 1997 und heißt EIA/TIA-232-F. Das RS von RS232 steht für „Recommended Standard“. Diese früher weit verbreitete Schnittstelle wurde u.a. von USB abgelöst und wird in moderne Computer nicht mehr eingebaut. Sie ist aber in vielen Geräten etwa Diagnoseschnittstelle verbaut und spielt gerade in der Industrie immer noch eine Rolle.

Zu beachten ist, dass der Raspberry Pi mit seinen UART-Pins wegen anderer Signalpegel nicht direkt mit einem RS232-Gerät verbunden werden darf! Mehr dazu gleich.

Heutzutage gebräuchlich ist bei RS232 der SUB-D 9-pin Stecker, beim Computer männlich (Bild 3): Der Stecker ist auf eine bestimmte Art und Weise belegt, wobei nicht alle Pins geschaltet werden müssen: Wichtig ist, dass die RX- und TX-Pins bei Sender (Computer) und Empfänger (bspw. Modem oder zweitem Computer) jeweils gekreuzt sein müssen, damit die Daten empfangen werden. Falls zwei Computer miteinander verbunden werden, werden daher sogenannte Nullmodem-Kabel eingesetzt. (Nullmodem, weil kein Modem dazwischen hängt), bei denen die RX- und TX-Leitungen gekreuzt sind.

Pinbelegung am Computer / Sender 1:

• 1: DCD (Data Carrier Detect)

• 2: RxD / RX (Receive Data) - Empfang an Computer 1, Sendelinie für Computer 2, bzw. Empfänger

• 3: TxD / TX (Transmit Data) - Senden für Computer 1, Empfang für Computer 2 bzw. Empfänger

• 4: DTR (Data Terminal Ready)

• 5: GND - Die Signale werden gegen diese Referenz gemessen

• 6: DSR (Data Set Ready)

• 7: RTS oder RTR (siehe oben, Hardware Flow Control) - Computer 1 ist bereit Daten zu empfangen

• 8: CTS (Clear To Send) - Empfänger bzw. Computer 2 ist bereit Daten zu empfangen (Hardware Flow Control, siehe oben)

• 9: RI (Ring Indicator)

In allen Fällen benötigt werden zur Kommunikation RX, TX und GND.

Die digitalen Signale werden durch den UART erzeugt, müssen allerdings durch einen RS232-Transceiver-Chip auf die richtigen Pegel gebracht werden. RS232 nutzt dabei für die Datenleitungen (RX und TX) für eine logische 1 eine Spannung zwischen -3 V und -15 V, und für eine logische 0 eine Spannung von +3 V bis +15 V.

Signale zwischen -3 V und +3 V gelten als undefiniert.

Bei den Steuerleitungen (RTS, CTS, etc.) ist der aktive Zustand (d.h. asserted) +3 V bis +15 V und der inaktive -3 V bis -15 V. Das entspricht einem Ziehen auf „GND“ bzw. eine logische 0 des UARTs, entsprechend einer logischen 0 auf den Datenleitungen.

Um diese bereits erwähnten Spannungen am Sender auch bei Spannungsabfällen über das Kabel, Stecker, usw. zu erreichen, muss der Empfänger mindestens eine Spannung von +5 V bzw. -5 V aufbauen. Üblich sind sogar +12 V bzw. -12 V.

Solche Spannungen würden die empfindlichen GPIO-Pins am Raspberry Pi grillen. Die GPIO-Pins des Raspberry Pi sind nur für 0 - 3,3 V ausgelegt. Es muss daher ein spezieller Chip angeschlossen werden, um Kommunikation über RS232 zu ermöglichen. Dazu gibt es entweder spezielle Aufsteckplatinen für Raspberry Pi, so genannte Hardware Attached on TopHAT, oder man kann sich einen Chip auf einem Breadboard aufbauen.

Interessanterweise ist es nicht unbedingt nötig, eine 12-V-Spannungsquelle zu haben, da manche Chips bereits integrierte Ladungspumpen haben. Ein solcher Chip ist etwa der MAX3225E von Maxim. Im sogenannten DIP Package ist dieser Chip auch verfügbar (breadboard freundlich). Im folgenden sehen Sie ein Schaltdiagramm für den MAX3225E von Maxim.

Dabei wird T1OUT als TxD Pin auf der RS-232 Seite genutzt, und T2OUT als RTS bzw RTR Signal.

R1IN ist RxD auf RS232-Seite, R2IN CTS.

Auf der Seite des Raspberry Pis werden die Pins entsprechend an die UART-Pins beschaltet:

• T1IN = TXD & T2IN = RTS (die zwei Sendesignale)

• R1OUT = RXD & R2OUT = CTS (die zwei Empfangssignale)

Der Chip kann mit 3,3 V versorgt werden und generiert sich die benötigten Spannungen für die RS232-Schnittstelle mittels Ladungspumpe selbst. Dazu benötigt er externe Kondensatoren als Zwischenspeicher für die Ladungen. Details siehe Datenblatt von Maxim.

RS232 ist eine Punkt-zu-Punkt-Verbindung. Es werden genau zwei Geräte miteinander verbunden. Der Nachteil von RS232 ist, dass die Signale nicht differentiell, sondern asymmetrisch (unbalanced) übertragen werden. Sie sind auf sogenannte Gleichtaktstörungen empfindlich, die beispielsweise durch elektromagnetische Störer auf den Leitungen entstehen können. Damit ist unter anderem die maximale Länge der Leitungen limitiert. Mehr Störsicherheit bietet durch differenzielle Signale RS485.

RS485 für erhöhte Stabilität

RS485 auch als EIA/TIA-485 bekannt, adressiert einige der Probleme mit RS232 für eine erhöhte Stabilität der Übertragung. Daher kommt es vor allem in Industrieanwendungen zum Einsatz. Bei RS485 kommen differentielle (balanced) Signale zum Einsatz, und es können mehrere Kommunikationspartner auf dem gleichen Netzwerk miteinander sprechen. Für die differenziellen Signale werden zwei Leitungen benötigt (A und B). Eine weitere Leitung (SC / G / reference pin) als GND-Referenz ist in manchen Fällen ebenso vorhanden.

Die Signalpegel (Spannungen) sind dabei auch niedriger als bei RS232. Spannungen zwischen -7 V und 12 V sind erlaubt, der minimale Spannungslevel um ein Signal zu erkennen liegt für den Empfänger bei +/- 200 mV. Die tatsächlich auf dem Bus anliegende Spannung hängt typischerweise von der Betriebsspannung des Treibers ab (bspw. 5 V oder 3,3 V beim Rasppberry Pi.)

RS485 unterstützt Datenraten von bis zu 10 MBit/s über kurze Entfernungen (typischerweise bis zu 12 m), und bei geringeren Datenraten bis zu 1,2 km Entfernung. Als Faustregel gilt: die Geschwindigkeit in Bit/s * Länge in m sollte 10^8 nicht überschreiten, ein 50 m langes Kabel kann also mit maximal 2 MBit/s betrieben werden. Es sind standardmäßig bis zu 32 Teilnehmer auf der Leitung möglich, bei Einsatz spezieller Transceiver-Bausteine auch mehr.

Auch RS485 benutzt UARTs als Eingang für RS-485 Treiber, die das UART-Signal in RS485-konforme differentielle Signale umsetzen. Dabei ist der binäre Zustand der Leitung 1 oder „MARK“, wenn die Leitung A (auch: TX-/RX-/D-) im Hinblick auf die Leitung B (auch: TX+/RX+/D+) negativ ist, und 0 oder „SPACE“ wenn B im Hinblick auf A negativ ist. Der RS485-Empfänger wandelt das Eingangssignal entsprechend wieder um.

Bild 5 zeigt die Zustände der Leitungen für asynchrone Kommunikation mit Hilfe von zwei UARTs, an denen auf beiden Seiten RS485-Transceiver angeschlossen sind. Aus dem Idle Modus („Mark“) wird die Leitung, wie beim UART diskutiert, auf den SPACE-Zustand gezogen (eine 0) - das Start-Bit. Anschließend erfolgt eine Übertragung von in diesem Fall 8 Bits, und das Stop-Bit (auch als Mark - der Zustand der logischen 1, wie beim UART). Danach ist die Leitung erneut im Ruhezustand. Durch mindestens einen Übergang pro gesendeten Frame kann sichergestellt werden, dass der Empfänger-UART nicht mit dem Zählen der empfangenen gleichen Bits durcheinander kommt und verrutscht.

Da die Treiber bei RS485 selektiv auf die gemeinsame Leitung aufgeschaltet werden können (bspw. Pin „Driver Enable“ beim Texas Instruments SN65HVD1782), ist bidirektionale Kommunikation auch über nur ein Leitungspaar möglich (sogenannter „Half-Duplex"-Modus bei RS485). Diese zwei Leitungen werden üblicherweise, um Störungen zu minimieren, miteinander verdrillt (Twisted Pair). Es gibt auch Implementationen, wo zwei Leitungspaare genutzt werden, dabei wird eine Master / Slave Architektur (ein Master, mehrere Slaves) aufgebaut.

RS485 spezifiziert nur den physikalischen Layer

Da RS485 nur den physikalischen Layer spezifiziert, gibt es kein Kommunikationsprotokoll und keine Stecker vor, nur ein elektrisches Interface. Einige andere Protokolle, beispielsweise Modbus, und Profibus, basieren auf RS485 und definieren Stecker, Datenübertragungsformate, etc.

Ein wichtiger Punkt ist bei dem Bus die Topologie. Es werden hier am Hauptbus über kurze Stichleitungen die einzelnen Teilnehmer angeschlossen. Der Bus sollte zur Vermeidung von Reflexionen an beiden Seiten mit Abschlusswiderständen versehen werden. Typischerweise werden dazu 120 Ω zwischen A und B geschaltet. Bei sehr kurzen Leitungslängen (z.B. für Testversuche auf dem Breadboard) oder sehr geringen Datenraten kann man den Abschlusswiderstand weglassen, da die fehlerfreie Datenübertragung durch die Reflexionen in diesen Fällen weniger stark behindert wird. Die DMX-Schnittstelle, die zur professionellen Lichtsteuerung etwa in Theatern benutzt wird, basiert auf RS485.

Hinweis: In Kürze wird ein Folgeartikel erscheinen, der die praktische Kommunikation mit UART und RS485 zeigt.

* Maximilian Batz ist Geschäftsführer von pi3g.com

(ID:45884161)