Difference between revisions of "ZBus (Deutsch)"

From Ethersex_Wiki
Jump to: navigation, search
m (Anschluss)
m (Anschluss)
Line 23: Line 23:
  
 
[[File:ZBUS_bias_term.JPG|thumb|right|ATMega8 mit ZBUS]]
 
[[File:ZBUS_bias_term.JPG|thumb|right|ATMega8 mit ZBUS]]
[[File:Zbus_ttl.jpg|thumb|right|TTL-ZBus-Adapter mit MAX485, Termination und Bias-Widerständen]]
+
[[File:Zbus_ttl.jpg|thumb|right|TTL-ZBus-Adapter mit MAX485, Terminierung und Bias-R's]]
 
==== prozessorseitige Beschaltung ====
 
==== 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.
 
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.

Revision as of 19:17, 25 January 2015

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

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

ATMega8 mit ZBUS
TTL-ZBus-Adapter mit MAX485, Terminierung und Bias-R's

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
  • eine Datenrate von 38,4 kbit/s erzielte 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
  • die Masseverbindung sollte mitgeführt werden; eine Versorgungsspannung wird als abgesicherte Rohspannung (12V) ebenfalls am Bus zur Versorgung der Devices bereitgestellt
  • ein Testboard stellt zum Beispiel für diese Methode eine Minimalvariante dar; basierend auf ATMega328 (Arduino Pro Mini) mit Keramikresonator, Längsregler 7805 und MAX485