mjb/altos/src/core, branch lpc

Add Mini logging format. Use in EasyMini

2013-05-20T06:07:54+00:00

This is a 16-byte record that includes all of the sensor data in each sensor record, along with records for flight state changes. Signed-off-by: Keith Packard

altos: Use ao_data_pres macro in ao_log_tiny

2013-05-18T10:02:01+00:00

Now it works on easymini too Signed-off-by: Keith Packard

altos: Check for packet mode before trying to disable it in flight code

2013-05-18T09:54:55+00:00

This is only relevant for telemini Signed-off-by: Keith Packard

altos: ao_data_get is in ao_data.c now, not ao_adc.c

2013-05-18T09:54:30+00:00

Signed-off-by: Keith Packard

altos: Allow architecture to define the type of port registers

2013-05-18T09:53:32+00:00

LPC11U14 has 32-bit ports, STM32 has 16 bit ports. Signed-off-by: Keith Packard

altos: Move ao_data.c from stm to core

2013-05-18T09:52:49+00:00

This should be used on every processor Signed-off-by: Keith Packard

altos: Allow target-specific USB endpoint specifications

2013-05-17T10:50:07+00:00

The LPC has only a small number of endpoints, and those are not configurable. Let the LPC USB driver pick the IN and OUT endpoints by itself. Signed-off-by: Keith Packard

altos/cc1111: Hack on USB driver to make Windows happy

2013-05-17T10:38:51+00:00

The Windows modem driver is quite chatty at startup time, getting and setting the comm parameters each time the device is opened. Sometimes, when setting the parameters, the cc1111 would STALL EP0. Most of the time, Windows would happily pass this as an error back to AltosUI which would then re-try the open (and succeed, most of the time). Sometimes, Windows would stall for 30 seconds before passing the error back. This made the whole UI freeze, and I suspect most people assumed our app had died. A bit of analysis with the beagle USB sniffer and I discovered the STALL settings, but there wasn't any correlation between the data on the wire and when the STALL would be generated. So, I found a couple of other cc1111 USB stacks on the net and just looked to see how our driver differed. There wasn't anything clearly related, but there were a list of small differences: 1) Other drivers didn't bother waiting for the hardware to ack the USBADDR setting; doing it this way means we can set the address *before* acking the setup packet. It'll get set eventually, at which point the device will start responding to packets again. Easy to fix, and saves a bit of code space too. 2) The other drivers set the STALL bit for setup packets which aren't understood. This shouldn't have any effect on 'good' systems as those shouldn't ever be generating bogus setup packets anyways. The driver already handled the STALL state in the interrupt handler, the only requirement was to figure out when to explicitly set the STALL bit. That required moving the state updating code from the start of the ep0 setup handling to the end, after the setup packet had been examined and data queued in or out as appropriate. 3) Our driver explicitly queued an IN packet for any setup request that wasn't waiting for an OUT pack. This appears to tie in with the USBADDR change above as before I made that change, this change caused the driver to fail to respond to most setup packets. This was simple once the above change was made, just move the generation of the IN packet inside the code that switched to the IN state. Signed-off-by: Keith Packard

altos: Move MS5607 info from 'v' to 'c s'

2013-05-16T05:13:08+00:00

Makes more sense there. Signed-off-by: Keith Packard

altos: Add 'g' command to ublox GPS code.

2013-05-16T05:11:21+00:00

Take the gps_dump function from ao_gps_skytraq.c and move it to a new file so it can be shared with the u-blox driver. That affects every skytraq and u-blox user as they need to include the new file. Signed-off-by: Keith Packard