This is an old revision of the document!
Table of Contents
Clubbus
Clubbus | |
---|---|
Kontakt | mrq, spq, pouze, nd |
Status | inaktiv (2024-09-08 01:20) |
Interessenten | |
URL | https://git.aachen.ccc.de/~pouze/klubbus/ |
ENTWURF
Zu diesem Dokument: Norm steht an den Sachen dran, die für die Implementierung relevant sind. Unter Info steht die Begründung für die vorige Norm.
Protokoll Layer
Header
Name | Größe in Bytes | Kommentar |
---|---|---|
Preamble | 1 | immer 0xAA |
Sender | 2 | little endian uint16_t |
Empfänger | 2 | little endian uint16_t |
Länge | 2 | nur des Payloads little endian uint16_t |
CRC | 1 | das Polynom das AVR in der libc hat… |
Payload
- keine Garantie von korrekten Daten
Physical Layer
Norm: Wir nutzen das Physical Layer des CAN-Bus. Info: Das heißt direkt am Bus hängen CAN-Transciever
Norm: Der Bus ist als Zweidrahtleitung ausgeführt. Die Leitungsimpedanz sollte möglichst nah an 120 Ω sein. Die Leitung ist beidseitig mit 120 Ω abgeschlossen.
Norm: Leitungsführung: Die Leitung wird in Kabeln geführt, die 4 Zweidrahtleitungen enthalten. Info: In jedem Kabel gibt es zwei CAN-Leitungen (hin und rück), so dass sich quasi ein Sternförmiger Aufbau ergibt. Das steht schon ziemlich konkret fest und sollte hier nochmal ausführlich normiert und erklärt werden.
Norm: Anschluss: RJ45
Bit Layer
Norm: UART Info: UART wird von vielen billigen Microcontrollern nativ unterstützt. Das Protokoll lässt sich einfach mit dem PC debuggen. Es geht sparsam mit der Bandbreite um.
Medium Access
Norm: Ohne bekannte Kollision darf gesendet werden, wenn die Leitung frei ist.
Norm: Die Leitung ist frei, wenn der Empfangstimer abgelaufen ist oder ein korrekt formatiertes Paket vollständig empfangen wurde. Info: Der Regelfall ist, dass korrekte Pakete (vollständig) empfangen werden. Dann soll der Nachfolger sofort danach senden können, um den Bus möglichst gut auszulasten. Es kann aber auch sein, dass ein Empfänger verwirrt ist. Dieser Zustand tritt ein, wenn ein Gerät gerade gebootet wurde, oder der Empfang fehlerhaft ist. In dem Fall sorgt der Timer dafür, dass wieder gesendet werden kann, wenn der Bus kurze Zeit unbenutzt ist. Vorher zu senden macht eh keinen Sinn, weil man dann nur in Konkurrenz zu anderen Sendern treten würde.
Info: Die Zeitdauer des Empfangstimeout wurde noch nicht festgelegt. Wir sind uns aber ziemlich einig, dass es nicht viel länger als ein-zwei Bytes sein sollte.
Diagramm
Ideen für Nodes
- Thermometer (mehrere → Heatmap)
- Automatisierung Fenster (Öffnen/Schließen)
- Automatisierung Heizungsthermostat (Mit elektrischem Thermostatskopf)
- Automatisierung Leinwand Empore
- Auslesen elektrischer Zähler
- Blingblinglichter
- Steuerung HDMI-Matrix
- klingel
- clubstatus button
- licht
- switches ausschalten
Spannungsversorgung mit Abschlusserkennung
Idee: Im alten Entwurf gibt es eine Leitung zur Spannungsversorgung (5V) und eine Pulldown-Leitung, um Link zu erkennen. Man kann die aber auch zusammenfassen:
Auf Versorger-Seite: 12V — R(500kΩ) — 5V(über Diode) — Pin
Auf Verbraucher-Seite: Pin — Zenerdiode(gegen GND) — Betriebsspannung
Somit kann der Versorger feststellen, ob es einen Verbraucher gibt: Wenn die Pin-Spannung 12V ist gibt es keinen Verbraucher, ist sie 5V gibt es einen. Die Erkennung kann ziemlich einfach über einen PNP-Transistor mit Emitter=12V realisiert werden.
Baudrate
Würde 500k Baudrate vorschlagen, da das sowohl bei 8 MHz (für RC-Oszilator in tinys) sowie für 20 MHz (für größere AVRs) gut passt.
http://wormfood.net/avrbaudcalc.php?postbitrate=500000&clock_speed_table=1&postclock=8&u2xmode=1
Remote programming
Durch einen akzeptabel hohen timeout bei WAIT_FOR_DATA_COMPLETE könnte ein device, welches dies unterstützt in einen programming mode versetzt werden:
- der programmer versendet ein paket header mit length = 0xffff, dest = <target>, hängt aber nicht unmittelbar alle daten an
- eine magic value (8 byte oder so) sollte dem device zu erkennen geben das das jetzt ein programmer request ist, diese wird unmittelbar angehangen
- der programmer sendet jetzt wiederholt einzelne bytes auf die das device antworten darf, das device darf immer unmittelbar nach einem empfangenen byte vom sender antworten
- hat das device ge'ack't, das es im programming mode ist, kann der sender anfangen dem device daten zu schicken
- nähert sich die anzahl ausgetauschter bytes der 0xffff grenze
- informiert der programmer das device darüber
- füllt die vollen 0xffff bytes auf
- versucht möglichst schnell wieder ein 0xffff paket auf dem bus zu “allokieren”
- sendet wieder die magic sequenz am anfang
- das device kann dadurch nach der info, das ein neues paket erwartet wird in eine busy waiting loop gehen, in der es auf die sequenz wartet
- dieses konzept ermöglicht es, eine deutlich primitivere bidirektionale kommunikation auf dem bus zu ermöglichen, was gerade für remote programming interessant ist