Clubbus

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.

Header

Payload

• keine Garantie von korrekten Daten

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

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.

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.

• 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

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.

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

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