Diskussion:HSC2011/Software

notes on the firmware

we should have some features in the clients firmware that can be triggered from the basestation and should behave the same regardless of the application running

• yes (buzzer ba-ding)
• no (buzzer möööp)
• alarm (buzzer)
• shine led (binary encoded?)
• blink led (binary encoded?)
• rgbled colorcycle (rainbow)
• rgbled strobo

i don't think we should hard-code this in the clients (it's added complexity that needs flashing), rather have that in the same byte-code form as the application specific sounds (otherwise, we'd need additional commands for all of those). (we might store them in a more permanent form in the eeprom, where we can set them over the air as well?) --chrysn 18:27, 28. Mär. 2011 (CEST)

notes on the protocol designs

clifford:

Pkgs zur steuerung der buzzer
-----------------------------

afaics brauchen wir folgende packete (sowie dann passende acks bzw.
antowrten):

* buzzer -> basis: login/ping
ich wuerd gern die adresse vom ibutton direkt als mac adresse der buzzer
verwenden. d.h. ein buzzer ist inaktiv solange kein ibutton erkannt wird
und wenn er dann einen hat schick er so ein login/ping paket damit die
basisstation weiss das da wer ist.

ein entsprechendes logout muss es nicht geben. nach einer gewissen zeit der
inaktivitaet wird der buzzer von der basisstation einfach wieder als
offline markiert.

zusaetzlich kann im eeprom noch eine mac-addr stehen die von dem buzzer
verwendet wird bevor ein ibutton erkannt wird. dann kommt auch automatisch
ein login/ping nach dem power-on.

* basis -> buzzer: status/keepalive
zum checken fuer die basisstation of der buzzer noch im netz ist und
abfragen des button-status.

* basis -> buzzer: prog
zum einspielen des codes fuer die state machine auf dem buzzer.

* basis -> buzzer: setip
zum setzen des instruction pointer der state machine

* buzzer -> basis: event
wenn ein event vom buzzer erkannt wird, dann wird so ein pkt verschickt.


ACKs, Resends und online-list
-----------------------------

bei den beiden buzzer -> basis pkgs versucht der buzzer automatisch resends
bis ein entsprechendes ack von der basisstation kommt. dazu gibt es im
buzzer ein begrenzt grosses fifo in dem packete bei bedarf aufgestaut
werden koennen.

die buzzer -> basis pkgs werden von der basisstation automatisch geackt und
ueber USB an den PC geschickt.

die basis -> buzzer pkgs werden von der basisstation verschickt wenn ein
entsprechendes cmd ueber USB daherkommt. die acks gehen ueber USB an den PC
zurueck. resends muss der PC nach einem timeout machen.

da auch acks verlorengehen koennen muss der PC es verkraften wenn ein pkg
mehrmals daherkommt. die pkgs sind mit aufsteigenden sequence-numbers
versehen damit duplicates erkannt werden koennen.

da das setup auch mit ein paar hunder buzzern (denkt an unihoersaal oder
millionenshow publikum) funktionieren soll kann die liste der online buzzer
(incl. metadaten wie die letzte sequence-number zum buzzer) nicht auf der
basisstation verwaltet werden sondern muss am PC liegen.


Events
------

die state machine am buzzer kann eine bitmask mit acht bits fuer button
down und button up events fuer jeden button programmieren. wenn das
entsprechende bit gesetzt ist wenn so ein ereignis auftrtitt

ausserdem soll die statemachine auch 'user events' mit einer 1-byte id
verschicken koennen. da die statemachine in abhaenigkeit von den buttons
branchen kann, kann so auch ein teil der logik im buzzer laufen.


Protokoll Basis - PC
--------------------

Ich denke eine einfaches zeilen-orientiertes interface mit einer zeile pro
befehl/pkt sollte ausreichend sein. z.B.:

basis -> pc:
	LOGIN <mac>

pc -> basis:
	STATUS <mac> <seq>

basis -> pc:
	STATUS-ACK <mac> <seq> <button-states>

pc -> basis:
	PROG <mac> <seq> <offset> <data...>

basis -> pc:
	PROG-ACK <mac> <seq>

pc -> basis:
	SETIP <mac> <seq> <instruction-pointer>

basis -> pc:
	SETIP-ACK <mac> <seq>

basis -> pc:
	EVENT <mac> <seq> <event-code>