error message for embedded stuff.
Note: this was only tested on PC although I'm fairly confident about it.
Please let me know about any errors.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2285 ebee16cc-31ac-478f-84a7-5cbb03baadba
will run slower but greatly reduce the memory footprint (360 floats less).
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2284 ebee16cc-31ac-478f-84a7-5cbb03baadba
settings but only be used when home location is valid. Also discard any mag
data that is all zeros although we shouldn't see this.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2283 ebee16cc-31ac-478f-84a7-5cbb03baadba
little aggressive. Also increased the drift rate of the gyro bias per Sambas'
testing (thanks) although not to the levels required for flying through 40 deg
C transitions.
Made the dump_ekf function handle both numbers of states
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2282 ebee16cc-31ac-478f-84a7-5cbb03baadba
One potential issue: X-Plane expects 4-byte floats, the code is potentially not 64bit compliant...
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2281 ebee16cc-31ac-478f-84a7-5cbb03baadba
before because if transmission got NAK then sending would stop. Now the next
time data is added to the buffer a new send will be attempted.
fifoBuf: in clearData just set the read pointer to the write pointer. This is
safer for multiple people accessing it assuming the reader will be clearing it.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2279 ebee16cc-31ac-478f-84a7-5cbb03baadba
what they would be on a real board. Also fixed a typo in stabilization.c which made me lose time when trying to understand the code...
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2260 ebee16cc-31ac-478f-84a7-5cbb03baadba
I have done my best to make the interface foolproof, by only enabling the relevant buttons in the relevant situations, please let me know if this creates trouble in some use-cases I have overlooked...
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2254 ebee16cc-31ac-478f-84a7-5cbb03baadba
FirmwareIAP to get me back for breaking Sys_Reset. You got me! :)
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2246 ebee16cc-31ac-478f-84a7-5cbb03baadba
required for longer sequences, Need to deal with when it happens
inappropriately better.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2245 ebee16cc-31ac-478f-84a7-5cbb03baadba
sometimes thrown, and made errors not lock it up by default. It works for me,
but since this has historically been associated with lots of lock ups please
check your systems carefully.
PiOS/I2C: Make the bus by default try to recover from errors instead of locking
up
PiOS/I2C: After a bus error and clocking all previous data create a STOP
condition to make sure bus is released (note, this also requires creating a
START condition first)
PiOS/I2C: If the same event hits the I2C bus twice in a row then disregard
second one, there is no situation where we should get the same event multiple
times that matters and this gets us out really quickly to catch the real
events. I was seeing this with repeated 0x70084 which means byte transmitted.
This is related to STM32 bugs in the IRQ timings I believe.
PiOS/I2C: 1) Mask out some bits we don't care about in the event flags
2) Don't lock up if the give semaphore fails, although why it does is strange
3) Recover from bus failure through the "auto" state path instead of just
coding state
PiOS/I2C: Change the reset bus code to follow
http://www.analog.com/static/imported-files/application_notes/54305147357414AN686_0.pdf
(thanks for the reference Neontangerine). Although this may actually NOT clear
the bus the first time through, subsequent bus errors should eventually clock
it out. The up side is it is less likely to clock a bunch of 1s into an ESC
and make it run up.
PiOS/I2C: Some cleaned up code for getting a snippet of the history when
something strange happens
PiOS/I2C: Export logging information from I2C through a UAV object
PiOS/I2C: Improve the diagnostic information
PiOS/I2C: Need to handle the event 0x30084. This seems to happen between a
byte transmitted and new byte started
PiOS/I2C: Handle the NACK condition by simply going to the stopping state.
PiOS/I2C: Add a new NACK state to handle sending the STOP signal after a NACK
following the STM documentation. Other error conditions still are not dealt
with.
PiOS/I2C: Should handle the NACK condition from all the write cases. Need to
think about read cases
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2239 ebee16cc-31ac-478f-84a7-5cbb03baadba
