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
configuration structures are const which keeps them in flash instead of ram.
However the library needs to declare them const for the compiler to work.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2231 ebee16cc-31ac-478f-84a7-5cbb03baadba
lost. Warning though: it takes ~5-10 seconds for the flight telemetry status
to go from connected so this solution still isn't great.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2070 ebee16cc-31ac-478f-84a7-5cbb03baadba
fly (EKF rate up to a limit). Also, now the algorithm selects if you are
indoor or outdoor as well as if you use a mag indoor (if you do set the z
variance higher than it calibrates to).
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1841 ebee16cc-31ac-478f-84a7-5cbb03baadba
Flight: Create PositionDesired (the active waypoint) UAVObject and make the FlightSituationActual no update since it not used.
Flight: New velocity desired object that passes information between the look computing the desired velocity and the PID loop to get it (updated at different rates)
UAVObjects/PositionActual: Remove unused GPS fields
UAVObjects/PositionActual VelocityActual: Split the velocity into a separate object. ALso make sure all the information telemetered around is in cm to avoid using floats.
UAVObject/GuidanceSettings: New guidance settings object for the guidance module
Flight/Posix: Add the new objects to the Posix sim
Flight/Guidance: Computes a desired velocity based on position error than runs a PID loop to control roll and pitch to achieve that velocity. All distances are in cm, and updated the PositionActual fields to reflect this and use int32.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1760 ebee16cc-31ac-478f-84a7-5cbb03baadba
Calibration should take less time now too (using second moments to estimate
variance in one pass). Now need to change to multiple messages to get the
calibration in to keep the request message size minimal. Also currently
running sensor calibrate doesn't store the gyro bias so if you want to use this
you'll have to tweak it manually. I'll fix that step tomorrow.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1741 ebee16cc-31ac-478f-84a7-5cbb03baadba
1. Added reenumeration function and call it on USB init (device will appear after reprogramming now)
2. Moved buffer.c to general flight/Libraries location
3. Removed the 62 byte transmission limitation by adding a transmission buffer
4. Sped up USB communication by increasing endpoint polling frequency
Note, that the nonblocking and blocking USB send functions are not blocking entirely correcting. The blocking calls the nonblocking, and the nonblocking blocks until the last chunk has started tranmission if it's a big transmission. The buffering I added would generalize to non-blocking nicely, but would require using the EP1(IN) callback to handle most of the tranmission. This creates a lot of issues if one function is pushing data onto the buffer and the interrupt is sending.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1403 ebee16cc-31ac-478f-84a7-5cbb03baadba
