Diskussion:HSC2011/Software: Unterschied zwischen den Versionen
Die Seite wurde neu angelegt: „== 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 reg…“ |
Keine Bearbeitungszusammenfassung |
||
| Zeile 9: | Zeile 9: | ||
* rgbled colorcycle (rainbow) | * rgbled colorcycle (rainbow) | ||
* rgbled strobo | * rgbled strobo | ||
== notes on the protocö designs == | |||
clifford: | |||
<pre> | |||
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> | |||
</pre> | |||