New naming convention for the linker files:
link_(board_name)_(density)_(bl usage).ld
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2401 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
priority preempts) and adjusting the priorities around to be more sensible.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2355 ebee16cc-31ac-478f-84a7-5cbb03baadba
but not having telemetry causes a reset. If the buffer got full enough it
would never start to transmit again.
Note: also making Telemetry non-blocking
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2346 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
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
and starting transmission again. This should address the bootloader locking up
on verify.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2235 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
from the AHRS code (which will facilitate code integration with new INS) and
also will help set up a fifo queue for the downsampled data to allow gyro data
output from AHRS faster than EKF output. Also decreased ADC interrupt priority
so the SPI comms don't drop out.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2190 ebee16cc-31ac-478f-84a7-5cbb03baadba
only one receive task. This is less generally safe but decreases the
frequency of resets in our current configuration
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2144 ebee16cc-31ac-478f-84a7-5cbb03baadba
similar driver format to the PIOS_USART system. (p.s. are you happy now, PT?)
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2029 ebee16cc-31ac-478f-84a7-5cbb03baadba
running and block the interrupts while modifying the buffers
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2003 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
I2C bus errors are now recoverable. The bus is properly reset
and an error indication is now provided to the caller whenever
a bus error occurs during processing of the transaction list.
For now, the users of the I2C layer just retry infinitely on
failure. The BMP085 and HMC5843 code should be changed to
report errors to its callers to allow a more sensible retry
strategy.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1625 ebee16cc-31ac-478f-84a7-5cbb03baadba
AUTO transitions in the FSM are now handled immediately
after processing each newly injected event rather than only
at the end of the EV ISR.
This consolidation allows the upcoming addition of event
injection from both the EV and ER ISR contexts.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1624 ebee16cc-31ac-478f-84a7-5cbb03baadba
Occasionally, the I2C driver races with the STM32 I2C peripheral
at the end of a bus cycle. This leaves the bus in an errored
state and the stop condition is not properly asserted on the bus.
The polling for the stopped condition was previously implemented
in ISR context since it was expected to be nearly instananeous.
In the error condition, however, the stop condition will never
happen. The polling for this case is now done by the initiating
task (or mainloop on the AHRS) to prevent the timeout condition
from triggering the watchdog.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1623 ebee16cc-31ac-478f-84a7-5cbb03baadba
The info field in the pios_i2c_txn list can now be used
to provide a const string which describes the context
for this transaction.
This is very helpful when diagnosing an error that occurs
somewhere in the middle of the I2C FSM since the FSM runs
primarily in the ISR where the original context for the
transactions is no longer available in the traceback.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1622 ebee16cc-31ac-478f-84a7-5cbb03baadba
Differentiate the _FSM_ faulted from the (soon to
exist _BUS_ faulted state.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1621 ebee16cc-31ac-478f-84a7-5cbb03baadba
Implement low-level utility functions for sending/receiving
the opahrs proto v0 (bootloader) messages. These are used
by the OP firmware loader and the AHRS bootloader.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1586 ebee16cc-31ac-478f-84a7-5cbb03baadba
Some functions were returning -1 instead of one of the
valud enum values.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1585 ebee16cc-31ac-478f-84a7-5cbb03baadba
This cleans up some of the boiler plate code that is
repeasted for simple (empty) requests that expect a
response.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1584 ebee16cc-31ac-478f-84a7-5cbb03baadba
The number of retries and delay between retries was
increased in a previous commit. This doesn't appear
to be necessary so I'm reverting the increases.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1432 ebee16cc-31ac-478f-84a7-5cbb03baadba
No functional changes. Whitespace/tab fixups only.
Use TRUE/FALSE instead of 1/0.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1430 ebee16cc-31ac-478f-84a7-5cbb03baadba
No need to have boolean flags being floats.
Some of the attitude message was being populated twice.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1428 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
Issues have been reported with CRC errors
on the SPI link between the OP and AHRS
boards. Slowing the link down eliminates
the errors in my testing.
If we speed this link back up in the future,
further investigation will be required to
diagnose the source of the CRC errors.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1356 ebee16cc-31ac-478f-84a7-5cbb03baadba
This file had mixed line endings. Now they're all the same.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1353 ebee16cc-31ac-478f-84a7-5cbb03baadba
This is to align the object names to matches the UAVObject
architecture doc. No functional changes.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1351 ebee16cc-31ac-478f-84a7-5cbb03baadba
The transition from the ADDR state to the read state
was broken for non-final reads. The FSM diagram was
also wrong for this transition.
Since reads are always the last transaction in a sequence
in our current usage, this doesn't actually fix any known
bugs.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1350 ebee16cc-31ac-478f-84a7-5cbb03baadba
Since the i2c bus is bidirectional, there are certain
states (eg. part way through a read) where the slave
device is in control of driving the SDA line.
On a cold start (power on), the slave devices are all
quiescent and will not drive the bus. However, on a warm
start (eg. watchdog or jtag restart), it is possible that as
the CPU boots, the slave device may be holding the SDA line
low. This is a bus busy condition and will prevent the I2C
bus master in the CPU from being able to seize the bus during
init.
The fix for this is to clock the i2c bus sufficiently to ensure
that the the slave device finishes its transaction and releases
the bus.
Once the slave has released the bus, the bus master can properly
initialize and assert a STOP condition on the bus.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1349 ebee16cc-31ac-478f-84a7-5cbb03baadba
into NED reference frame and used in the INSGPS algorithm, although currently this
information isn't propagated back to OP. Data structures related to the GPS position
into the algorithm and the position estimate out will likely be in flux.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1334 ebee16cc-31ac-478f-84a7-5cbb03baadba
Altitude/pressure sensor data is sent to the AHRS whenever
the AltitudeActual object is updated.
Altitude, Pressure and Temperature are sent as floats.
Same as in the UAVObject that goes to the GCS.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1291 ebee16cc-31ac-478f-84a7-5cbb03baadba
The STM32 I2C block has a number of errata associated with it.
These errata are primarily related to timing sensitivities between
the peripheral and the interrupt handler. In particular, the
correct generation of the stop bit relies on the I2C IRQ running
immediately and not being held off for any reason.
NOTE: The I2C interrupts must be the highest priority IRQs in the
system to ensure correct operation.
I2C protocol is now implemented as a formal state machine.
See: stm32_i2c_fsm.{dot,jpg} for FSM description.
I2C init is now expressed by const initializers in pios_board.c
for both OP and AHRS boards.
I2C device drivers (ie. bmp085/hmc5843) now pass in const arrays
of an unlimited number of bus transfers to be done atomically.
The I2C adapter driver now handles all bus-level locking across the
list of transactions. Generation of start/restart/stop conditions
are handled automatically over the list of transactions.
Timeouts have been removed from the API for now. May be added
back later.
This driver has run error free on both the OP and AHRS boards for
up to 48hrs but it still sometimes fails earlier than that on the OP
board. There is another possible set of improvements to the driver
that could employ the DMA engine for transfers of >= 2bytes. This
change would reduce the timing sensitivities between the peripheral
and the driver but unfortunately, both the SPI and I2C interfaces
share the DMA1 engine. That means only one of these two peripherals
can use the DMA engine and right now, SPI between OP and AHRS is
already using it.
Failures are currently fatal and will lock up the CPU. This allows
useful information to be obtained in the failure cases.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1241 ebee16cc-31ac-478f-84a7-5cbb03baadba
Mark the I2C_InitStruct parameter as const so that we can pass
const data as the initializer.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1240 ebee16cc-31ac-478f-84a7-5cbb03baadba
The AHRS comms module now sync's with the AHRS and
exchanges interesting data periodically. Whenever
the link to the AHRS is down, the AHRSComms alarm is
raised.
This is fairly basic for now but provides the last
piece of the infrastructure to move data back/forth
between the OP and the AHRS.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1014 ebee16cc-31ac-478f-84a7-5cbb03baadba
PIOS SPI devices may now make use of automatic CRC generation
and checking on block transfers. Only supports CRC8 for now.
Since the SPI interface CRC calculation continues across message
boundaries (ie. not reset on every transfer), we must manually reset
the CRC registers for every transfer to allow the two sides of the
link to resynchronize.
Unfortunately, resetting the CRC registers requires disabling the
SPI peripheral which must now be done on every block transfer.
Note: The last byte of the tx buffer is never sent and is assumed to
be a place holder for the tx CRC8.
Note: The last byte of the rx buffer is expected to hold the rx CRC8.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1011 ebee16cc-31ac-478f-84a7-5cbb03baadba
Tx buffers should not be modified. This allows passing const data
to the transfer function.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1010 ebee16cc-31ac-478f-84a7-5cbb03baadba
This defines the SPI message format as well as a few
initial messages for moving data across the link.
The v0 messages are place holders for firmware download
in the bootloader.
The v1 messages are to be used by the main application.
Note: This is not the final protocol definition.
Subject to change without notice.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1004 ebee16cc-31ac-478f-84a7-5cbb03baadba
The com layer transmit functions should provide guarantees
that they will not modify the buffer that you're transmitting.
Declaring the parameter as a pointer to const keeps the underlying
implementations honest.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1001 ebee16cc-31ac-478f-84a7-5cbb03baadba
TransferByte API is simplified to either assert or
return the rx byte.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@999 ebee16cc-31ac-478f-84a7-5cbb03baadba
