Firmware

From Tuxisalive

Jump to: navigation, search

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:

Personal tools