functions to use it easily
Conflicts:
flight/Modules/Attitude/attitude.c
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2707 ebee16cc-31ac-478f-84a7-5cbb03baadba
The UAVObject initcall list is now automatically
generated at link time based on the exact set of
UAVObjects linked into the firmware image.
This will allow any subset of UAVObjects to be
used in any firmware image.
The uavobj_initcall() macro automatically adds the
marked function's address into the .initcalluavobj.init
ELF section.
The UAVObjectsInitializeAll() function now simply
iterates over the functions listed in the
.initcalluavobj.init section and calls them.
You can see the contents of this section in the ELF file
like this:
./tools/arm-2009q3/bin/arm-none-eabi-objdump \
--syms -j .initcalluavobj.init \
./build/openpilot/OpenPilot.elf
This is fundamentally the same mechanism that the Linux
kernel uses to initialize the specific set of components
that the user has selected in their kernel configuration.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2630 ebee16cc-31ac-478f-84a7-5cbb03baadba
only one CS line is asserted. No checks are enforced on this by the SPI code
as I cant see a clean way of it being aware of the CS lines. We could add
another CS mode those which is driver managed per transfer and has a GPIO i
line for each device.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2579 ebee16cc-31ac-478f-84a7-5cbb03baadba
Beginning of unifying the input types into PIOS_RECEIVER.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2568 ebee16cc-31ac-478f-84a7-5cbb03baadba
accounting for the fact they are transferred in pairs when using ADC2
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2510 ebee16cc-31ac-478f-84a7-5cbb03baadba
gyro data into attitude raw. Hardcoded calibration for now.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2474 ebee16cc-31ac-478f-84a7-5cbb03baadba
1) Added nack counter monitoring
2) Made timeout for getting semaphore in I2C user space code use the one from
driver and record timeouts. This does not influence timeouts in the non
FreeRTOS case
3) Remove case block from the error handler so that all bus errors reset the
i2c interface
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2469 ebee16cc-31ac-478f-84a7-5cbb03baadba
size (may eventually need to be per revision if we get bigger ram). Typo in a
the ifdefs to get allow disabling SDCARD
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2423 ebee16cc-31ac-478f-84a7-5cbb03baadba
are logged, and separately the erirq and evirq logs are exported
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2368 ebee16cc-31ac-478f-84a7-5cbb03baadba
ActuatorSettings although for PWM aircrafts it should be done exactly as before
Actuator: Store the update times and maximum update time
OP-14 I2C: Start tracking short history of events and states in driver for
logging
OP-237 Flight/Actuator: Support for I2C based ESCs
OP-237 MK_ESC: Send all four motors as one atomic transfer
OP-237 Flight/Actuator: Allow channels to be mapped to MK I2C interface. Currently
mixer channels are either PWM or MK but in the future this will change to
support more than 8 channels.
OP-16 PiOS/I2C: Further work to try and make I2C more stable, mstly special case
handline in IRQ
OP-237 I2C ESC: Support for Astect 4 channel ESCs
OP-237: When the I2C Actuator write update fails track this
OP-237 Actuator Settings: Change the way motor types are selected to keep that
information more appropriately within ActuatorSettings instead of MixerSettings
Also make motors stay at or above neutral when armed and throttle > 0
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2366 ebee16cc-31ac-478f-84a7-5cbb03baadba
tasks directly update a flag for each module (which they register) and when all
flags set clear the watchdog then.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2365 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
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
determine retransmitting calibration, home location and such.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1755 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
Way too much was being exposed in the API for the
HMC5843. This commit properly hides internal
details of the driver.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1629 ebee16cc-31ac-478f-84a7-5cbb03baadba
The DRDY signal from the magnetometer is connected to PB8
on the STM32. This pin is now configured as an external
interrupt and is now used to signal when new data is
available from the magnetometer.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1628 ebee16cc-31ac-478f-84a7-5cbb03baadba
