Version vom 7. Januar 2011, 22:46 Uhr

bytewerk housebus

Stage 0: Namensfindung

• brainstorm now!
• namen sind schall und rauch
  • B ytewerk
  • R emote(?) adio(?) andom(!) edundant(?)
  • O rphan(?) rbital(?) riginal(?) bfuscated(?)
  • K inetic(?) ommunication(?)
  • E nergy(?) thereal(?) nabeled(?)
  • N etwork

Stage 1: Brainstorm

denkbare systeme

• grundsätzliche Frage: Können wir den Bus sniffen/debuggen?!

• RS485
  • pro: läuft mit jedem(?) atmega
  • contra: software muss das protokoll sprechen
  • pro: mit ethersex ginge IP
  • contra: dann geht nur noch ethersex(?)
  • wir könnten auch ein eigenes RS485-Protokoll bauen

• CAN-Bus
  • pro: buslogik in hardware vorhanden
  • contra: braucht CAN-hardware
  • pro: es gibt (einige) atmegas für CAN, viele ARMs
  • pro: es gibt SPI<->CAN adapter als samples von Microchip (MCP2515, mal bestellt)

• ethernet
  • pro: IP quasi eingebaut
  • contra: braucht ARM oder teure extra-hardware
  • contra: verkabelung unpraktisch (?)
  • pro: TI-Sample-Arms eignen sich hervorragend als Ethernet<->UART-Adapter (?)

• zigbee
  • hk: cool, aber wollen wir nicht

• LIN - local interconnect network
  • struppi: "irgendwie weird"
  • cfr34x: Simpel!
  • struppi: is not my favourite bus system

• dallas onewire
  • zu langsam
  • denkbar für temperatursensoren...

was wollen wir steuern?

• Licht?
• Heizung? Wir haben sogar 2 steuerbare Ventile (-> crap?)
• Türöffner?
• Lauftexte
• Laufbilder
• Musiklautstärke?
• "Discofloor upside down" -> Decken-Tiles RGB beleuchten
• Nodes evtl. per Bus neu flashen
• Telefon? Anrufer-Display?
• Counter: Anzahl anwesender?
• Ätzbad heizen / regeln