Ziel dieses Tutorials ist es darzulegen, was man beim entwickeln einer eigenen Kommunikationsbibliothek für den W-Bus beachten muss und wie man dies umsetzt. Dies soll helfen, eigene Software in der favorisierten Programmiersprache umzusetzen.
Auf dem W-Bus werden Nachrichten (Frames) immer zusammenhängend am Stück übertragen. Es ist keine Pause zwischen dem Beginn einer Übertragung und deren Ende vorgesehen. Ein Sync-Signal um den Beginn eines Frames anzuzeigen, ist nicht vorgesehen.
Da W-Bus ein Eindraht-Bus ist, sind die RX- und TX-Leitungen miteinander verkoppelt. Jeder Teilnehmer liest gleichzeitig auch was er sendet. Vor dem senden sollten die Busteilnehmer prüfen ob die Leitung frei ist. Dies kann angenommen werden, wenn innerhalb einer Zeit X keine Bytes am eigenen Eingang einlaufen.
Dennoch kann es zu Kollisionen kommen, wodurch Datenpakete „verstümmelt“ übertragen/empfangen werden. Hiergegen schützt zum einen das Paritäts-Bit innerhalb eines jeden Bytes während der Übertragung, aber auch das Prüfsummen-Byte (CHK) am Ende eines Frames. Ein Empfänger muss eine Nachricht verwerfen, wenn beim Empfang eines Bytes ein Paritätsfehler auftritt, oder wenn die Prüfsumme des Frames nicht stimmt. Um die Prüfsumme zu berechnen muss ein Frame vollständig empfangen worden sein. Hier gilt es aus dem empfangenen Datenstrom das Frame zu ermitteln. Da ein Empfänger nicht zwangsläufig den Beginn einer Kommunikation mitbekommt, muss er seinen Eingangspuffer auf mögliche Frames untersuchen.
Der W-Bus wird über einen Pegelwandlerbaustein mit dem UART eines Controllers verbunden. Die UARTs besitzen meist nur einen kleinen Eingangspuffer (FIFO) von wenigen Bytes. Die übertragenen Daten (Frames) sind in der Regel größer als dieser Hardware-Puffer. Um einen Überlauf und damit einen Datenverlust zu vermeiden, müssen die eingehenden Bytes regelmäßig in einen weiteren Eingangspuffer im (größeren) Arbeitsspeicher des Controllers umgeladen werden.
Diese Aufgabe übernimmt eine Serviceroutine, die idealerweise unabhängig von anderen Abläufen im Hintergrund über einen Interrupt aufgerufen wird. Das auslösende Signal kann ein einfacher Timer ab auch eine Eingangserkennung oder Puffer-Voll-Meldung vom UART sein.
Um nun innerhalb des Eingangsdatenstromes ein gültiges Frame zu finden geht man wie folgt vor:
Irgendwann hat man damit dann mal ein gültiges Frame erkannt und kann es verarbeiten!
Ihre Aufgabe ist es, auf die empfangenen Nachrichten zu reagieren, ggf. Aktionen auszulösen, Messwerte zu ermitteln, Parameter zu lesen und eine der Anfrage entsprechende Antwort zurückzusenden.
Setzt man die W-Bus Bibliothek zum Beispiel dafür ein, einen Standheizung zu simulieren und erhält diese einen Einschaltbefehl, so ist es Aufgabe dieser Routine das zu erkennen, die Parameter (Heizzeit) zu prüfen, den internen Betriebszustand (Inaktiv, Aktiv, Störung, etc.) zu ermitteln und eine Antwort zu formulieren. Diese könnte z.B. lauten „Heizbefehl für 30 Minuten akzeptiert. Heizung läuft“.
Die Antworten werden in den Nachrichtenausgangspuffer geschrieben von wo aus sie eine Service-Route an den W-Bus in Form von Bytes übermittelt.
Sie wir innerhalb der Bibliothek mit Kommandos und Parametern aufgerufen und erzeugt daraus ein gültiges W-Bus Nachrichtenpaket (Frame), welches sie anschließend in den Ausgangspuffer für die Senderoutine anfügt.
Um ein 25/25ms Break-Signal zu erzeugen gibt es grundsätzlich 3 Möglichkeiten:
Während des BREAK ist keine Kommunikation auf dem Bus möglich, bzw. wird laufende Kommunikation verstümmelt! Daher muss man vor der Generierung sicher sein, das keine Kommunikation läuft. Hierzu am besten prüfen wie lange der letzte Datenempfang her ist.
Diese Routine muss in regelmäßigen Abständen (Timer/Interrupt) aufgerufen werden um zum senden bereitstehende Nachrichten auf den W-Bus zu übermitteln. Hierzu werden die Bytes jeder Nachricht zusammenhängend über das Interface gesendet.
Der Ablauf ist dabei wie folgt: