HSC2011/Software: Unterschied zwischen den Versionen
Chrysn (Diskussion | Beiträge) K (fake subpages) |
Chrysn (Diskussion | Beiträge) (split into parts for firmware, middleware, frontend and communication) |
||
Zeile 1: | Zeile 1: | ||
<small>< [[HSC2011]]</small> | <small>< [[HSC2011]]</small> | ||
+ | |||
+ | The EduBuzzer has software run in three parts: | ||
+ | |||
+ | * [[HSC2011/Firmware|Firmware]] run on the ATMega controllers (for hardware control and radio communication) | ||
+ | * [[HSC2011/Middleware|Middleware]] running natively on the computer (for serving the firmware, managing communication and for persistence) | ||
+ | * A [[HSC2011/Frontend|Frontend]] running in a web browser (containing the game logic itself) | ||
+ | |||
+ | The communication through the whole software is described in the [[HSC2011/Communication|communication documentation]]. | ||
+ | |||
+ | ------------------ | ||
there will be different software components involved | there will be different software components involved |
Version vom 2. Mai 2011, 16:02 Uhr
< HSC2011
The EduBuzzer has software run in three parts:
- Firmware run on the ATMega controllers (for hardware control and radio communication)
- Middleware running natively on the computer (for serving the firmware, managing communication and for persistence)
- A Frontend running in a web browser (containing the game logic itself)
The communication through the whole software is described in the communication documentation.
there will be different software components involved
there is a firmware on each device
there will be a hostsoftware (webserver) that runs on the pc/laptop
this webserver will provide a webinterface to the javascript application
there are positions open for
the webserver/serialcom (python)amir implements this job with java- the webfrontend application logic (javascript)
- the webfrontent design (CSS)
- firmware and protocoldesign (AVR)
firmware
The current firmware is written by clifford and chrysn and is currently capable of both being a buzzer and being a base station; the base station can control all the hardware in the buzzers and receive events. It can be checked out from the firmware part of the project repository.
During firmware development, a serial protocol was developed, which is documented alongside the firmware.
Open issues are in descending priority:
- separate timeout arrays for login and event
- redirect messages for controlling the base station itself
- fine-tuning timing for re-sends and responses (may only need validation)
- melody api
- read/write commands for VM
- enhanced get/set status packages for VM
- reading battery status using new firmware
- reading RSSI state
- multicasts
removing arduino specific stuff to reduce resource usage(not a priority unless resources become a real problem)
PC server
There is a proof-of-concept implementation of a serial controller and a simple voting game for debugging purposes in the repository. It demonstrates that the firmware can also do logins, handle disconnected clients and respond to events.