The EduBuzzer has software run in three parts:
- Firmware run on the ATMega controllers (for hardware control and radio communication)
- The firmware can run additional code inside a virtual machine for tasks like LED fading, meldoy beeping or even autonomous games.
- 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
there are positions open for
the webserver/serialcom (python)amir implements this job with java
- the webfrontent design (CSS)
- firmware and protocoldesign (AVR)
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
removing arduino specific stuff to reduce resource usage(not a priority unless resources become a real problem)
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.