mjb/altos/src, branch debian/1.2.1-2

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

2013-05-17T10:51:16+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: Set u-blox navigation settings

2013-05-14T15:51:22+00:00

Airborne mode, < 4g (as good as it gets) Only use 3D fixes (2D isn't very useful) Signed-off-by: Keith Packard

altos: Use symbolic names for ublox packet id

2013-05-14T15:35:24+00:00

Signed-off-by: Keith Packard

altos/test: ao_gps_test_ublox uses ao_gps_blox.h

2013-05-14T05:59:26+00:00

Signed-off-by: Keith Packard

altos: Struct used for u-blox testing had lat/lon swapped

2013-05-14T05:58:18+00:00

The structs in ao_gps_ublox.h are used only by the test framework, but it's useful to have that look right anyways. Signed-off-by: Keith Packard

altos: Switch TeleMega v0.3 to u-blox

2013-05-14T05:33:28+00:00

Signed-off-by: Keith Packard

altos: Provide a define for the number of sat infos in a telem packet

2013-05-14T05:32:25+00:00

12 fit, but it's best to use a symbolic constant Signed-off-by: Keith Packard

altos: Add U-Blox GPS driver

2013-05-14T05:31:31+00:00

Uses binary mode. Signed-off-by: Keith Packard

altos: Don't bother fixing telelco-v0.1, just disable it

2013-05-14T05:29:22+00:00

Lots of stuff to do to make this old project build; just disable it instead of fixing Signed-off-by: Keith Packard

altos: Wait after configuring boot pin before testing it

2013-05-08T04:30:27+00:00

Clearly the pin isn't quite ready just after it's been configured, so hang around for a while (100 nops) to let things setting down before testing the value of the pin. Makes booting a lot more reliable. Signed-off-by: Keith Packard