Dem Leonardo die Hand schütteln

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

1dcb.fRtsControl = RTS_CONTROL_ENABLE;
2dcb.fOutxCtsFlow = TRUE;

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 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!

📧 📋 🐘 | 🔔
 

Meine Dokus über:
 
Weitere externe Links zu:
Alle extern verlinkten Webseiten stehen nicht in Zusammenhang mit opengate.at.
Für deren Inhalt wird keine Haftung übernommen.



Wenn sich eine triviale Erkenntnis mit Dummheit in der Interpretation paart, dann gibt es in der Regel Kollateralschäden in der Anwendung.
frei zitiert nach A. Van der Bellen
... also dann paaren wir mal eine komplexe Erkenntnis mit Klugheit in der Interpretation!