Dem Leonardo die Hand schütteln
« | 29 Oct 2018 | »Der Arduino Leonardo
ist zwar auch ein Arduino … aber eben doch ein bisschen anders.
Das gilt in erster Linie für die serielle Kommunikation, denn schnell schreibt
man sich ein paar Zeilen um Bytes an die
Mikrocontroller zu senden.
Beim UNO oder allgemein bei
allen Boards mit separatem USB-zu-Seriell-Konverter sind die Parameter für den
COM-Port recht anspruchslos …
… doch beim Leonardo funktioniert das dann nicht.
Der Leonardo basiert auf dem ATmega32u4 und dessen Fähigkeit ist, dass die MCU gleich selbst über das USB Protokoll kommunizieren kann. Das können viele andere ATmega Geschwister, wie ATmega328 und ATMega2560 eben nicht und haben deshalb einen separaten ATmega8U2 oder ATmega16U2 am Board montiert, der die Daten vom USB Anschluss zum Haupt-Mikrocontroller hin und her übersetzt.
Der Leonardo kann auf so einen Zusatzchip verzichten, weil er ja selbst
das USB Protokoll fließend versteht.
Das führt aber auch dazu, dass sein Verhalten anders ist.
Also was war das Problem?
Nun, beim Programmieren des COM-Ports dürfen wir auf der PC-Seite einige
Parameter setzen. Neben der Geschwindigkeit gibt es auch noch die
Flusskontrolle, und genau die hatte ich bis dahin immer ignoriert und
deaktiviert.
Die Arduino UNOs haben dann bei mir mit meinen Standard-Parametern immer
brav funktioniert, doch der Leonardo verweigerte die Kommunikation.
Zum Glück findet man schnell auf stackoverflow.com jemanden, der das Problem auch schon mal hatte und auch eine Lösung publiziert wurde.
In diesem Fall waren es auch bei mir die notwendigen Zeilen
die falsch und früher auf RTS_CONTROL_DISABLE
und FALSE
gesetzt waren.
… bzw. die
DCB
Struktur war ausgenullt und nicht vollständig befüllt.
Das war für mich tatsächlich das erste mal, dass die Parameter zur Datenflusssteuerung des COM Ports eine direkte Auswirkung auf die Kommunikation hatten. Zu Modem - Zeiten war ich leider noch weit von der Programmierung von COM-Ports entfernt … und heute kommt man in der Praxis nur noch bei Mikrocontrollern mit RS232 und seinen Verwandten in Berührung.
Die vielen Einstellungsmöglichkeiten sind also kein unwichtiges Erbe aus
der Vergangenheit, wie man meinen könnte.
Und deshalb sind seither
Flusssteuerung
wie auch
Handshakeprotokolle
ein Pflichtbestandteil in jeder COM-Port Klasse.
Fazit
Aus Fehlern lernt man eben doch was.
Zu meinem Glück schenkte mir ein ganz lieber Kollege ein RS232/DB25 Steckbrett, mit dem sich verschiedene Kommunikationswege effizient durchprobieren lassen.
Ich fürchte, solche hilfreichen Brückenbauteile werden heute nicht mehr
erzeugt, zumindest habe ich das noch nie wo zum Verkauf angepriesen bekommen.
In jedem Fall erspart es recht viel Arbeit, da man sich keine
Stecker selbst zusammenlöten muss.
Dieser Punkt geht also wieder an: Früher war alles besser!