| Commit message (Collapse) | Author | Age |
| ... | |
| | | |/
| |/|
| | |
| | | |
Signed-off-by: Keith Packard <keithp@keithp.com>
|
| | |/
| |
| |
| |
| |
| | |
Not the first two. TeleMega v0.3 has these marked on the silk
Signed-off-by: Keith Packard <keithp@keithp.com>
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Instead of manually signalling the related events, use PurgeComm which
can then abort the operations itself. Also make sure all of the
relevant handles are set to INVALID before closing them to avoid race conditions.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
| | |
| |
| |
| |
| |
| | |
These are necessary for the fat release, so make sure they're built then.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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 <keithp@keithp.com>
|
| | |
| |
| |
| |
| |
| |
| | |
This sets the deviation to 0, enables the preamble and turns on the
transmitter. It will sit there happily sending a bare carrier forever
Signed-off-by: Keith Packard <keithp@keithp.com>
|
| | |
| |
| |
| |
| |
| | |
Makes more sense there.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
| | |
| |
| |
| | |
Signed-off-by: Keith Packard <keithp@keithp.com>
|
| | |
| |
| |
| |
| |
| |
| |
| | |
If other drivers use the SPI bus, the MPU6000 gets confused as its
sitting on the bus looking for I2C messages. Just grab the mutex
before the OS is running and hold onto it until the MPU6000 has been initialized.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
| | |
| |
| |
| |
| |
| | |
Without this, we can't talk to the chip very well
Signed-off-by: Keith Packard <keithp@keithp.com>
|
| | |
| |
| |
| |
| |
| |
| | |
telemega moves the igniters around so that E/F are now drogue/main.
Add custom labels for ADC values to make parsing possible
Signed-off-by: Keith Packard <keithp@keithp.com>
|
| | |
| |
| |
| |
| |
| |
| | |
This caused the u-blox driver to use serial port 1 instead of the
project-specified serial port.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
| | |
| |
| |
| | |
Signed-off-by: Keith Packard <keithp@keithp.com>
|
| | |
| |
| |
| |
| |
| |
| |
| | |
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 <keithp@keithp.com>
|
| | |
| |
| |
| | |
Signed-off-by: Keith Packard <keithp@keithp.com>
|
| | | |
|
| | | |
|
| | | |
|
| |\ \ |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
For some reason, the MD5_Final symbol isn't resolved when linking only
against libssl.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| |\| | |
|
| | | |
| | |
| | |
| | |
| | | |
Signed-off-by: Keith Packard <keithp@keithp.com>
(cherry picked from commit 7282fab337dc48d32606276e5f51c057a3bff8cb)
|
| | | | |
|
| | | | |
|
| | | | |
|
| |\| | |
|
| | | | |
|
| | |\ \ |
|
| | | | |
| | | |
| | | |
| | | | |
Signed-off-by: Keith Packard <keithp@keithp.com>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Move most of the 1.2 content to the 1.2.1 block
Signed-off-by: Keith Packard <keithp@keithp.com>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Not the first two. TeleMega v0.3 has these marked on the silk
Signed-off-by: Keith Packard <keithp@keithp.com>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
These are necessary for the fat release, so make sure they're built then.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Instead of manually signalling the related events, use PurgeComm which
can then abort the operations itself. Also make sure all of the
relevant handles are set to INVALID before closing them to avoid race conditions.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
| | | |/
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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 <keithp@keithp.com>
|
| |\| | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| |\| | |
|
| | |/ |
|
| | |
| |
| |
| |
| |
| |
| | |
Airborne mode, < 4g (as good as it gets)
Only use 3D fixes (2D isn't very useful)
Signed-off-by: Keith Packard <keithp@keithp.com>
|
| | |
| |
| |
| | |
Signed-off-by: Keith Packard <keithp@keithp.com>
|
| | |
| |
| |
| |
| |
| |
| | |
Use GPS altitude when baro altitude is not present.
Don't require flight number.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
GPS altitude is generally more absolutely correct than baro altitude,
so use that as the nominal pad altitude when generating a KML
file. This results in a KML file that has the flight trace start and
end closer to the ground, which is always nice.
Signed-off-by: Keith Packard <keithp@keithp.com>
|