HSC2011/Software: Unterschied zwischen den Versionen

aus Metalab, dem offenen Zentrum für meta-disziplinäre Magier und technisch-kreative Enthusiasten.
Wechseln zu: Navigation, Suche
K (fake subpages)
(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, 18: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.