(See? That's why I hate branching - thank the gods that subversion has the "merge" command)
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1016 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
- AHRS mainloop now runs flat out updating sensor data and
processing any messages sent from the OP board.
- Raw data is provided from the magnetometers
- Fake data is provided for attitude solution
- Correct data is provided for serial number queries
Note: There is a bug in the i2c code that very quickly leaves the
magnetometer in a broken state and returning incorrect values.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1013 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
The Attitude module will soon be handling updates for all UAVObjects
that require data from the AHRS. To reflect this expansion of scope,
it has been renamed to AHRSComms.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1009 ebee16cc-31ac-478f-84a7-5cbb03baadba
This object currently only holds the serial number of the attached
AHRS board. This will be retrieved each time communications are
(re)established with the AHRS board.
This will eventually be extended to hold some statistics for OP to
AHRS comms.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1008 ebee16cc-31ac-478f-84a7-5cbb03baadba
This object currently holds only the raw magnetometer readings and
an instantaneous heading calculation which are only really useful
for debugging. The contents of this object will change often as
development progresses.
Note: The magnetometer values are often garbage due to a problem
with i2c software on the AHRS.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1007 ebee16cc-31ac-478f-84a7-5cbb03baadba
The input data lines between the OP and AHRS boards had internal
pull-ups enabled. This seemed to be causing issues early on
during development of the inter-board comms. Not sure if this
is still necessary but this is how the current code was tested.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1006 ebee16cc-31ac-478f-84a7-5cbb03baadba
To the outside world, the AHRS can be in one of only a few
primary states:
Not present - AHRS is absent or non-responsive via SPI
Inactive - Only link-level status messages are processed
Ready - Ready to receive the next application level message
Busy - Application level message is being processed
Internal to the AHRS, there are many more states that need to be
managed. This FSM provides the necessary decoupling between the
ISR (which is being driven by the SPI link) and the AHRS main
processing loop which must continue to run its filters independently
of the SPI messaging rate.
With this structure, SPI messages can be received at any time but
processed at only specific points within the filter chains.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1005 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
Mark the device specific DMA IRQ handlers as strongly linked
aliases for the genericly named interrupt vector symbol.
Here's how this works...
* The address of the symbol DMA1_Channel2_IRQHandler is written
into the DMA1/Channel2 interrupt vector by the linker script.
* The startup_*.S file specifies Default_Handler() as a weakly
linked alias for DMA1_Channel2_IRQHandler.
* We now override the weakly linked alias with the strongly linked
PIOS_SPI_sdcard_irq_handler().
* This results in the address of PIOS_SPI_sdcard_irq_handler() being
written to the vector table for the DMA1/Channel2 interrupt.
* The PIOS_SPI_sdcard_irq_handler() function is now called whenever
the DMA1/Channel2 interrupt fires.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1003 ebee16cc-31ac-478f-84a7-5cbb03baadba
The AHRSComms alarm will be raised whenever the OP board
is not able to communicate with the AHRS board.
The navigation software on the OP board could use this
alarm to trigger its best attempt at an emergency landing.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1002 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
