Firmware
From Tuxisalive
Contents |
[edit] Topics
- Standalone behavior - description of the standalone behavior that should be integrated into Tux.
- Remote mode - control your tux with the remote only, no computer here.
- Light sensor - schema, measurement and linearization of the light measurement.
- Tux ID - adding an identification code in tux firmware.
- Sleep mode - adding a sleep mode in tux to increase battery life.
- Audio - microphone and sound output, sound processing like peak level
[edit] Recent achievements
- We linearized the light sensor value in the daemon, the firmware has been updated.
- Added battery level measurement, refactored the sensor module, added the ADC module.
[edit] To do
- Update the Light sensor page with what has been done in firmware and daemon, explain the way the measurement is done.
[edit] Current firmware development
You can test the latest firmware by simply downloading the latest snapshot of the development hex files available on SVN at http://svn.tuxisalive.com/firmware/hex_dev/.
[edit] Id, Sleep and Wifi update
[edit] Purpose
- Id: add an Id number to Tux so that it will be possible to connect to a specific tux with it's Id.
- Sleep: add functions to set tux in a power saving mode.
- Wifi: avoid a given wifi channel so that tux won't interfere with your wifi which is a problem for laptops.
[edit] Status
All functions are now implemented on SVN and the caller have been added in the daemon and api. See the tux.connect functions in the python api. There are still a lot of bugs though. Here's a first review.
What works:
- change_id(500), keep the head buttton pushed when starting the command
- connect_to_tux(500)
- disconnect_from_tux()
- id_lookup(), takes some time to get the id back though
- id_request(), you should be connected to tux to get this working
- sleep() for tuxaudio and tuxcore only
- wakeup(500) works, but as the RF doesn't enter sleep it's a bit fake
Bugs:
- When id_lookup fails, the daemon can't send new data to the dongle
- The RF connection doesn't work with all rf boards
- The ID overwrites the GF setting in the eeprom
- It takes a long time for a command sent from tuxsh to reach the dongle
- It takes around 50 attempts of RF transfers before the id is returned from the id_lookup command, sounds bad
- The check if the head button is pushed for 5 secs to change the id doesn't work, wrong code, incorrect use of _ms_delay
- When a lookup or change id, the eyes get and stay blue, they shouldn't
- Same when disconnecting from tux, leds stay on
- When changing the id and the button is not pushed, the RF link starts and the dongle/daemon blocks
- If tux is turned off in the middle of a SPI transaction between the RF and the dongle, the dongle hangs
- When not connected to tux, id_request returns 0xFFFF and should not execute at all
- The RF doesn't forward (and receive?) the sleep command and doesn't enter sleep
- When changing the wifi channel, the dongle shows and seems to send a change_id command
- When not sleeping and not connected, the wekeup command kills the status, or hangs the dongle, or connects to tux
- Wifi avoidance doesn't seem to work, need some debugging here
- When disconnected, sending a command crashes the dongle
- When disconnected, avoid_wifi() connects to tux which shouldn't
ToDo:
- Rewrite a good part of the code in order to make some room for bug fixes and enhancements, spi is a good choice I think
- Fix the bugs above :-)
- Position the GF as first byte in the eeprom, and the ID after
[edit] Brainstorming
[edit] Joining firmware development
Development is mainly discussed on the mailing list, feel free to join us there.
A few pointers that might help:
- To setup your environment, see "Setup the AVR tool chain and compile the firmware".
- To update the firmware of your tux after compiling it, check "Updating the firmware (Manual install)".
- Code documentation is available at http://doc.tuxisalive.com/.
- Report bugs here.

