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
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
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
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
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
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
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
- Created a pluggable COM layer
- Converted COM + USART init into static initializers
rather than typedefs
- Generalized the USB HID COM API to match the USART
API.
- Changed USART and COM layers to be data driven rather
than #ifdef'ing/switching on the specifics of each port
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@760 ebee16cc-31ac-478f-84a7-5cbb03baadba
Added support for SPI slave configurations to the pios SPI layer.
Converted the board specific configuration for the PIOS SPI layer to
use const static initializers rather than #defines (see pios_board.c).
SPI interface between the OP board and the AHRS is now operational at
a basic level, capable of moving simple single byte messages between
boards. Multi-byte, CRC protected messages will be added on top of this.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@759 ebee16cc-31ac-478f-84a7-5cbb03baadba
- New Attitude module for AHRS (skeleton)
- New AttitudeSettings UAVobject
- New AttitudeActual UAVobject
- Regenerated UAVobjects
- Added new UAVobjects to OpenPilot and GCS builds
- New PiOS driver for OpenPilot AHRS (stubs only)
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@655 ebee16cc-31ac-478f-84a7-5cbb03baadba
This module reads from the BMP085 pressure sensor. It periodically
updates the pressure (kPa) and temperature (C) as well as the
calculated altitude (m).
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@640 ebee16cc-31ac-478f-84a7-5cbb03baadba
FreeRTOS has a strict requirement that even interrupt-safe API calls (ie.
those ending in "FromISR") can only be called from ISRs that are at lesser
or equal priorities to configMAX_SYSCALL_INTERRUPT_PRIORITY. See the
"configKERNEL_INTERRUPT_PRIORITY and configMAX_SYSCALL_INTERRUPT_PRIORITY"
section at:
http://www.freertos.org/a00110.html
The interrupt numbers used on the Cortex-M3 CPU has a somewhat backward
representation of the interrupt numbers so 255 = lowest priority and
0 = highest priority.
The calculation is further complicated by the STM32 implementation only using
the upper 4 bits of the priority value. Only 0x00, 0x10, 0x20, ..., 0xE0, 0xF0
represent useful interrupt priorities.
FreeRTOS requires that MAX_SYSCALL and KERNEL interrupt priorities are expressed
as raw unshifted 8-bit values to be programmed directly into the BASEPRI register.
The priority values passed to the NVIC initialization, however, are expected
to be 4-bit values and are shifted up by 4 within NVIC_Init() for you.
The end result is that we need this arrangement:
[highest priority]
NVIC_0 (Non-maskable-interrupt)
NVIC_1
NVIC_2
[Must NOT call FreeRTOS APIs above here]
configMAX_SYSCALL_INTERRUPT_PRIORITY (now at 48 = 0x30 = NVIC_3)
PIOS_IRQ_PRIO_HIGHEST (cur. NVIC_4)
PIOS_IRQ_PRIO_HIGH (cur. NVIC_5)
PIOS_IRQ_PRIO_MID (cur. NVIC_8)
PIOS_IRQ_PRIO_LOW (cur. NVIC_12)
configKERNEL_INTERRUPT_PRIORITY (240 = 0xF0 = NVIC_15)
[lowest priority]
The previous config had configMAX_SYSCALL_INTERRUPT_PRIORITY set at
191 (0xBF) which is effectively NVIC_11. This was allowing all of
the MID, HIGH and HIGHEST interrupt handlers to preempt the OS in
its critical sections. Since some of these ISRs were calling
FreeRTOS APIs, this would result in corrupting internal data structures
within the OS.
It should be ok to move the configKERNEL_INTERRUPT_PRIORITY to a higher
priority as long as it is less than configMAX_SYSCALL_INTERRUPT_PRIORITY.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@637 ebee16cc-31ac-478f-84a7-5cbb03baadba
