The board info blob is stored in the last 128 bytes of the
bootloader's flash bank. You can access this data from the
application firmware like this:
#include <pios_board_info.h>
if (pios_board_info_blob.magic == PIOS_BOARD_INFO_BLOB_MAGIC) {
/* Check some other fields */
}
DO NOT link pios_board_info.c into your application firmware.
Only bootloaders should provide the content for the board info
structure. The application firmware is only a user of the data.
AHRS_comms still needs to be implemented. INS/GPS functionality still needs to be implemented. Double-check of the new drivers still needs to be done.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@3162 ebee16cc-31ac-478f-84a7-5cbb03baadba
- Removed all unnecessary device instances and their cfg's.
- SPI to SD card
- I2C
- Aux USART
- Moved SPI baudrate setting into cfg rather than init func.
- Abstracted forcing slave select under OPAHRS API.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2786 ebee16cc-31ac-478f-84a7-5cbb03baadba
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
