Wenn einmal die Terminalemulation nicht mehr als Partner für den Microcontroller genügt, um Sensorwerte anzuzeigen oder Aktionen auszulösen, tauchen meist bei der Entwicklung der Software (in jedweder Sprache) einige Fragen zu der Kommunikation auf.
Inhaltsverzeichnis
Ein Netzwerk
Für weitere Überlegungen über den Nachrichtenaustausch ist es günstig, ein einfaches Modell als Ausgangspunkt zu nehmen
- Auf dem Controller (links) sollen drei Ports verwendet werden, zwei als Output, eins als Input, wobei die Pin-Änderungen entweder durch Polling oder durch Interrupt erkannt werden könnten.
- Auf dem PC (rechts) soll eine Applikation laufen, die einerseits die Pins der Output-Ports setzen (vielleicht durch Check-boxen) und andererseits den Status des Inputports darstellen kann.
Anmerkung: mit Hardware kann man nicht reden. Kommunikation ist etwas, was sich grundsätzlich nur zwischen Programmen (-teilen) abspielt. Hardwarefunktionen müssen durch Software-Funktionen repräsentiert werden. D.h. vor jedem PortPin sitzt ein Stück Software, das auf Verlangen dann dieses Pin manipuliert.
Aufgabenstellung
Es geht also darum, wie kann die PC-Applikation eine bestimmte Aktion beim Controller auslösen (diesen oder jenen Pin setzen), beziehungsweise wie kann der Controller dem Modul des PC-Programmes, das zuständig ist, mitteilen, daß sich etwas bei den Pins geändert hat. Da alle Nachrichten offensichtlich über den gleichen Draht gehen müssen, wird also eine "Dispatch" Funktion auf beiden Rechnern notwendig sein, die anhand einer Art Adresse in dieser Nachricht immer die angesprochenen Programmteile benachrichtigen kann. Also wurden als Adressen einerseits "Pout/1", "Pout/2" und "Pinp/1" vergeben, auf dem PC einfach "MODA/1", "MODA/2" und "MODB/1". Und wir nehmen auch einmal an, daß jeder davon weiß, wie sein richtiger Partner auf der anderen Seite heißt.
Nachrichten von Programmen an Programme (Messages)
Zweckmäßig ist auf jeden Fall eine Aufgabenteilung:
- COMM beschränkt sich darauf, Daten variabler Länge sicher über die Leitung zu senden und zu empfangen. Eventuell auch den Medium-Zugriff zu handhaben (wenn es nicht RS232, sondern eine Bus-Verbindung ist).
- DISPATCH übernimmt die Schnittstelle zu den Module und baut Sende-Pakete mit Ziel- und Absender auf, die es dem Comm-Modul übergibt. Andererseits nimmt es von diesem Empfangspakete entgegen und liefert sie bei den Modulen ab.
- Module (Applications) Für sie erfolgt der Zugang aufs Netz transparent, d.h. nicht sichtbar. Sie scheinen über die Dispatch-Schnittstellen "direkt" mit ihren Partnern auf der gleichen oder anderen Maschine zu kommunizieren.
Eine besondere Nähe zur OSI-Nomenklatur wurde hier nicht gesucht. Es scheint nicht zweckmäßig, z.B. auf einem Tiny-Controller alle Schichten explizit auszuführen.
COMM
- Start
Jede Message braucht einen für alle Teilnehmer erkennbaren und eindeutigen Beginn. Bei I2C ist es die "Start-Bedingung" (fallende Flanke auf SDA, wenn SCL auf High ist) bei SPI gilt die SS-Leitung, bei RS232 Protokollen oft der 9-Bit-Mode benutzt, wobei das 9.Bit als Kennzeichen gilt.
Der Start ist eigentlich das Wichtigste. Die Empfangsfunktion muß dadurch in der Lage sein, die weiteren Bytes einwandfrei zu lesen. Hier müßten auch Kennzeichen enthalten sein, wenn es mehrere verschiedene Paket-Typen gibt (eventuell auch die Version, das ist gut für eine spätere Weiterentwicklung)
Der Message-Start unterbricht auch immer eine eventuell laufende Bearbeitung und setzt das Empfangsmodul zurück.
- Nutzdaten: Das ist das schraffierte Bereich, dessen Inhalt für den Transport keine Rolle spielt.
- End: Das Ende muß nun wieder für die Transportfunktionen erkennbar sein.
Es kann auch im Start eine Längenangabe enthalten sein, dadurch ist dann ein explizites Ende-Kennzeichen nicht nötig, die Empfangsroutine muß dann halt mitzählen. Beim I2C-Bus hingegen ist es zum Beispiel so, daß sowohl die Empfangseinrichtung (durch Unterlassung des ACK) als auch der Senders durch eine Stop- oder eine neue Start-Bedingung die Übertragung jederzeit beenden können.
- Cks (optional): An die Nachricht kann auch eine Kontrollsumme angefügt werden.
Transparente (binäre) Messages über UART
Der Forderung nach transparenten Daten und dem damit verbundene Verlust der üblichen Steuerzeichen kann man auf verschiedene Weise Rechnung tragen
- 9-Bit Datenformat. Dieses 9.Bit zeigt an, daß die 8 anderen Bits ein Kontrollzeichen darstellen. Bei 0 sind es normale Daten.
- 8-Bit Format, aber Umkodierung. z.B. BASE64, ein gängiges Verfahren für die Übertragen von Binärdaten im Internet und Mail
- Verwendung der RS232 Steuerleitungen.
- Byte Stuffing
Alles davon hat Vor- und Nachteile. Wenn man die Daten umkodiert, hat man den Vorteil, wieder die ASCII-Steuerzeichen verwenden zu können. Der Nachteil: es sind mehr Bytes je Message zu übertragen. Ähnliches gilt für die 9-Bit Variante und auch das Byte-Stuffing. Die RS232 Steuerleitungen brauchen wiederum eine Hardware-Erweiterung.
DISPATCH
- Destination: Das ist die Ziel-Angabe. Nun würde eine Nachricht auch richtig ankommen. Es ist gut, gleich nach dem Start diese Angabe zu machen. Denn dann kann jeder Netzwerkteilnehmer sofort erkennen, ob er angesprochen wird und anderenfalls alles, was da kommt, bis zum nächsten Start ignorieren. Das ist am wenigsten belastend, und wird bei den meisten Netzwerken so gemacht.
Um aber z.B. eine Bestätigung zurückzusenden, wird wohl auch eine Angabe zur
- Source erforderlich. Das ist die äquivalente Absender-Adresse als Backlink.
Das Wichtigste an einer Adresse ist wohl die Eindeutigkeit. So gesehen ist jede Nummer recht, wenn sie den Teilnehmern bekannt ist. Aber für größere Systeme kann eine Strukturierung günstig sein.
- Node bezeichnet einen bestimmten Rechner, also einen PC oder eine Microcontroller (da gibt es aber unterschiedliche Terminologien).
- Class bezeichnet eine Modul- oder GeräteKlasse
- Ident ist dann eine spezifische Ausprägung.
Beim Absender kann es auch notwendig sein, irgendwelche "Tags" einzufügen, damit bei einer Rückantwort der Absender eine Zuordnung treffen kann. Nicht immer ist ja das Sende-Empfangsverhältnis 1:1.
- Data: auch auf dieser Ebene sind das reine Nutzdaten.
Aufgaben
- Initialize: Was der Dispatcher zur Arbeit braucht, sind einige Tabellen. Er muß die empfangenen Modul-Adressen umsetzen können auf eine CALL-Entry-Adresse und einen Verweis auf die privaten Daten dieses Modules.
- Bei einem PC kann die Initiative auch von den einzelnen Modulen ausgehen, die durch einen "RegisterCallback" Aufruf an den Dispatcher ihre Adresse und den DatenVektor hinterlegen. Bevor sie das nicht getan haben, sind sie eben nicht da.
- Auf den MC werden diese Tabellen und Verweise wohl schon im Source-Programm festgelegt werden, da hier zur Laufzeit wohl nicht mit einer Dynamik gerechnet werden muß
- Send: Auch der Dispatcher braucht zum Senden die User-Daten, als Liste oder gesamt, das kann verschieden gemacht werden. Dazu natürlich die Zielangabe und etwas, mit dem eine Rückantwort mittels der ob. genannten Tabelle zugeordent werden kann. Wir haben ausgeführt, daß für Rückantworten einfach Ziel und Absender vertauscht werden. Die Rückadresse braucht also nur beim Absendersystem wirklich eine Bedeutung zu haben. Wenn das Comm-Modul on-the-fly arbeitet, muß das natürlich in der Schnittstelle berücksichtigt werden.
- Receive: Synchron oder asynchron. Bei einem Aufruf durch das Comm-Module, daß Daten hier sind, werden jedenfalls mittels der Zieladresse in der Mapping-Table Call- und Daten-Vektor gesucht. Zusammen mit einem Verweis (Adresse, Länge) auf die Userdaten in der Message kann nun das Modul gerufen werden.
Applikations-Schnittstelle
Wenn von der Applikations eine Sendung veranlaßt werden soll, ist offensichtlich erforderlich
- Eine vollständige Zielangabe.
- Die Absenderangabe, eventuell mit einen "Tag" um auch diese spezielle Message eindeutig zu machen.
Die "Node"-Angabe kann wohl entfallen, denn das Kommunikationsmodul wird wohl wissen, auf welchem Rechner es sich befindet.
- Fields/Daten: Das sind die eigentlichen "Nutz"-Daten, deren Inhalt, Aufbau und Bedeutung nur dem eigentlichen Sender und Empfänger bekannt sein müssen. Ob diese Daten gleich gesamt übergeben werden oder in einer Feld-Liste, kann beliebig gestaltet werden.
Wenn es wundert, daß der Begriff "CMD" hier nirgends auftaucht: Es hat für den Transport von Messages eigentlich keine Bedeutung, denn eine Nachricht kann man so oder so immer nur weiterleiten. Dadurch ist es sinnvoll und flexibler, eine CMD-Feld innerhalb der User-Fields anzusiedeln.
Spezielle Applikationen
Wie schon oben erwähnt, kann es sinnvoll sein, einige spezielle Module anzuwenden, die der Betrieb sicherer und vielleicht auch einfacher machen.
- PING/Heartbeat
Eine Art Anwesenheitskontrolle. Kann auch leicht mit der allgemeinen "Timeout" Funktionalität verbunden werden. Auch ein Timestamp könnte damit verteilt werden.
- Enumerator/Enlisten
Beim Startup (oder auf Anforderung) sendet jedes System eine Liste mit den aktiven Module, eventuell mit einer "Kurz-Adresse", der dem Dispatcher die Tabellenarbeit erleichtert. DIe Gültigkeit dieser "short-cuts" muß natürlich gewährleistet sein (Änderung durch Umprogrammieren eines Controllers). Das kann geschehen, indem jedes System eine "Session"-Nummer (im EEPROM) führt. Die wird bei jedem Start oder Änderung inkrementiert. Hat ein anders System sich die letzte Nummer gemerkt, kann es durch die Unstimmigkeit die Änderung erkennen und eine aktuelle Liste anfordern.
Gateways
Ein Gateway ist ein Übergang zwischen Netzwerken, die völlig unterschiedlich funktionieren und auch andere (Netzwerk-)Begriffe haben. Im Zusammenhang mit einer Vernetzung zwischen Controller und PC kann es sinnvoll sein,
- auf einem oder mehreren PC einen eigenständigen Prozess zu implementieren, der das Controller-Netz als Server abbildet.
- die verfügbaren Controller und die Geräte darauf werden durch IP-Sockets und Ports abgebildet.
- Die eigentlichen PC-Applikationen zur Kontrolle oder Darstellung können ein oder mehrere Programme sein, die den Traffic als IP-Sessions über eines oder mehrere Ports abwickeln.
- Der Vorteil wäre die Plattform- und Sprachunabhängigkeit, denn Kommunikation über Sockets werden überall unterstützt.
Autor
Siehe auch
