mjb/altos/src, branch 0.7

altos: prepare for sdcc 2.9.1

2010-08-27T07:10:29+00:00

A few minor language changes -- non-standard keywords are now prefixed with __, such as 'at', 'interrupt', 'naked'. Signed-off-by: Keith Packard

altos: mark gps date written only after it gets into eeprom

2010-08-27T06:37:29+00:00

Data logging doesn't start until boost detect occurs. As the GPS date is only logged once, if that happens before logging is written to the flash, then the GPS date will never get saved. Signed-off-by: Keith Packard

altos: print GPS state flags in GPS 'g' command

2010-08-26T22:59:09+00:00

Having the GPS state information can help with GPS debugging. Signed-off-by: Keith Packard

altos: always rebuild ao_product.c to track git version

2010-08-26T22:57:09+00:00

The git version is built into ao_product.c and saved in eeprom log files, providing useful diagnostics about the firmware revision used for each flight. However, if ao_product.c isn't recompiled, then the updated version won't be included. Force recompilation of this file each time make is run to ensure that the final output contains an updated version number. Signed-off-by: Keith Packard

altosui: write USB serial number string while flashing

2010-08-24T11:02:27+00:00

USB serial number is encoded in UCS2 as a part of the string descriptors. Place those right after the other rom config bits so that altosui can find it. altosui is changed to write the serial number there. Signed-off-by: Keith Packard

altos: Place rom config variables in fixed location

2010-08-24T05:03:36+00:00

The device serial number and radio calibration values are stored in flash, mostly so that TeleDongle gets them saved. Placing them in well-known locations (starting at 0xa0) makes it possible to find the previous configuration and to re-write it easily, without requiring the .map file. altosui doesn't have the .map file parsing code, so it relies upon this new technique. As a benefit, it reads the old values from the device before reprogramming it. Signed-off-by: Keith Packard

altos: Define USB product ID in per-product Makefile.defs file

2010-08-22T00:09:41+00:00

This allows Win7 to tell which kind of device is connected purely by USB id as it doesn't expose the USB product ID string to user space. Signed-off-by: Keith Packard

altos: add callsign to packet mode, increase payload to 64 bytes

2010-08-07T04:40:59+00:00

Untested, but it 'should' work. Need to add callsign setting to packet mode users. Signed-off-by: Keith Packard

Make ao_log_data re-entrant as it is used for both sensor and GPS logs

2010-07-28T18:19:45+00:00

Because ao_log_data is called from two different threads, failing to make it re-entrant would cause the 'log' pointer parameter to get overwritten if another thread asked to log data while the eeprom was busy writing out a block. This would cause the second thread to re-writing data from the first thread's address, but without re-checksumming the data as the checksum is computed before the log mutex is taken. The bug can be seen by log blocks with invalid checksums. Here's what happens with the ao_gps_tracking_report and ao_log threads: ao_gps_tracking_report ao_log Writes a bunch of records *blocks* in the eeprom flush sets ao_log_data 'log' to global 'log' computes checksum for 'log' block *blocks* on ao_log_mutex Wakes up sets ao_log_data 'log' to 'gps_log' writes remaining records 'gps_log' is left with svid = 0 *blocks* on ao_gps_tracking_data writes data, reading from the current ao_log_data 'log' pointer which points at 'gps_log' Making ao_log_data re-entrant fixes this by ensuring that the 'ao_log' thread has its own copy of the ao_log_data 'log' parameter. I made this function take an __xdata restricted pointer so that it could be passed in the dptr register instead of needing to go on the stack. Signed-off-by: Keith Packard

When the EP0 IN buffer is full, don't panic, just skip sending another

2010-07-26T19:54:41+00:00

If the host doesn't pull the IN packet out of EP0 before sending another SETUP command along, the IN buffer will still be busy when we try to reply to the SETUP command. While I don't quite understand why this would ever happen, there's no need to panic about it, just drop the reply packet on the floor. Signed-off-by: Keith Packard