ZBus (Deutsch)
| ZBUS | |
|---|---|
| Status | Stable
|
| menuconfig | Network->ZBUS Support |
| Pinning | - |
| Ecmd | yes |
| Control6 | - |
| Uses Timer | - |
| Depends on | ECMD |
| Requires | USART |
| Code | https://github.com/ethersex/ethersex/tree/master/protocols/zbus |
Contents
Was ist ZBus?
ZBus ist ein auf RS485 basierendes Zweidraht-Bussystem, auf welchem Pakete variabler Länge übermittelt werden können. Es wurde primär für die Datenübertragung zwischen Mikrocontrollern konzipiert, zum Beispiel zur Kommunikation von ATmega8 und ATmega644. Ethersex verwendet ZBus zur Übermittlung von IP-Paketen von einem Controller, der als Bridge fungiert, hin zu einzelnen kleineren ZBus-Geräten, die beispielsweise auf ATmega8 basieren. Der Einsatz von ZBus ermöglicht den großflächigen Einsatz von kleineren ATmega-Mikrocontrolleren, an die man in der Regel keinen ENC28J60 anschließen möchte. Zudem lässt sich zum Beispiel ein bestehendes Telefonkabelnetz verwenden, welches für LAN ungeeignet wäre.
Ebendiese kleineren Controller können über eine Bridge hinweg via IP-Protokoll erreicht werden, zumindest über UDP und ICMP. Eine TCP/IP-Übertragung scheitert an den begrenzten Resourcen eines ATmega8, mit größeren Controllern ist jedoch auch TCP möglich. Als Bridge kann wahlweise ein entsprechend konfiguriertes Ethersex oder ein normaler Rechner mit serieller Schnittstelle, auf dem ZBus Serial Host läuft, eingesetzt werden.
Anschluss
prozessorseitige Beschaltung
Zur Anschaltung des ZBus wird ein Pegelwandler benötigt. Dabei wird an dieser Stelle ein preiswerter und moderner MAX485 verwendet, welcher sich durch minimale Außenbeschaltung und geringen Eigenstromverbrauch (etwa 1mA) auszeichnet. Damit ist zwar nur Halbduplexbetrieb möglich, was jedoch in den allermeisten Fällen genügt. Es werden drei Prozessorpins benötigt: TX, RX sowie die TX/RX-Umschaltung.
busseitige Beschaltung
Der Bus muss an beiden Enden mit 120 Ohm terminiert werden (R1) und sollte an einer Stelle mit Bias-Widerständen (R2 und R3) bestückt sein, damit definierte Pegel herrschen, wenn kein Sender aktiv ist. Diese beiden identischen Widerstände sind unkritisch; Werte zwischen 390 und 820 Ohm funktionieren problemlos. Es kann daher Busteilnehmer mit einem, zwei oder drei Widerständen geben; der flexibelste Busteilnehmer hat alle Widerstände mit Jumper aktivierbar.
Konfiguration
todo
Statusmonitor
Der ECMD-Befehl "zbus stats" ermöglicht die schnelle Beurteilung der Übertragungsqualität. Aktiviert wird er über das Debug-flag "ZBUS ecmd" im Menuconfig.
Die beispielhafte Ausgabe bedeutet im Einzelnen: fe=2, ov=0, pe=0, bf=0, #=57736, tx #=45264
| Wert | Beschreibung |
| rx fe | frame error |
| rx ov | overflow |
| rx pe | parity error |
| rx bf | buffer full |
| # | Summe empfangene Bytes |
| tx # | Summe gesendete Bytes |
Hinweise / Praktische Erfahrungen
- unterschiedliche Kabelarten sind zu vermeiden, da sich durch Stoßstellen die Signalqualität verschlechtert (Reflexionen); "fe" steigt
- die Beschaltung der Terminierung und der Bias-R's muss experimentell ermittelt werden- hier sind deutliche Qualitätssteigerungen möglich
- "Network Buffer Size" sollte maximiert werden; vor allem beim ZBus-LAN-Gateway hilft viel Speicher bzw. ein größerer Controller (m328p=384, m32=500, m644p=1500)
- eine Datenrate von 38,4 kbit/s erzielte hier die besten Ergebnisse; eine geringere Geschwindigkeit bringt bei schlechterer Signalqualität praktisch keine Verbesserung
- bei zu hoher Geschwindigkeit (hier 76,8 kbit/s auf Mega32@16MHz am ZBus-Gateway) kommt es zum Pufferüberlauf; "bf" steigt deutlich bei hohem Datenaufkommen
- ein Mega644p@16MHz mit buffers=1500 läuft problemlos mit 115,2 kbit/s, sofern die anderen Busteilnehmer mitspielen
- die Masseverbindung sollte mitgeführt werden; eine Versorgungsspannung wird als abgesicherte Rohspannung (12V) ebenfalls am Bus zur Versorgung der Devices bereitgestellt
- ein ZBus-Testboard stellt zum Beispiel eine Minimalvariante dar; basierend auf ATMega328 (Arduino Pro Mini) mit Keramikresonator, Längsregler 7805 und MAX485
