- use IRQStack for ISRs (at begening of SRAM) (let's call it the irq stack)
- use end of heap for stack needed during initialization (let's call it the init stack).
- the systemStats in GCS indicate the remaining bytes in the IRQ stack (this is realy usefull to monitor our (nested) IRQs.
This is the base ground to provide as much memory as possible available at task creation time.
Next step is to re-organize the initialization in order to move all the init out of the thread's stacks onto the init stack.
This will provide as much memory as possible available at task creation time.
Basically the stack during initialization will be destroyed once the scheduler starts and dynamic alloc are made (since the init stack is at the end of the heap). We will need to make sure we don't clobber the heap during initialization otherwise this will lead to stack corruption.
- only affect flight/PiOS (no change for posix and win32)
- tested on recent master (some runtime on CC with GCS)
- the new timer feature is not compiled-in since we don't use it yet.
- NO TEST FLIGHT
The pipxtreme boards use a sector of the on-board flash
for configuration storage. Adjust the memory maps to
reflect this.
The board_info_blob is also extended to include the EE
bank definitions. This should be used by the pipxtreme
firmware rather than determining it based on chip size.
The USE_BOOTLOADER compile flag was only being used
to determine where the ISR vector table was located.
Provide this explicitly from the linker since it knows
exactly where it is putting the ISR vector table.
- New macros for fw, bl and bu rules in top-level make
- Per-board info factored into make/board/*/board-info.mk
- Per-board info now shared btw. fw, bl and blupd for each board
- BOARD_TYPE, BOARD_REVISION, BOOTLOADER_VERSION, HW_TYPE
- MCU, CHIP, BOARD, MODEL, MODEL_SUFFIX
- START_OF_BL_CODE, START_OF_FW_CODE
- blupd_* goals renamed to bu_*
- all_blupd goal renamed to all_bu
- firmware goals renamed to fw_*, board name goals are preserved
- bu_*_program now writes updater to correct address for all boards
- BL updater firmware builds now produce .opf format including
version info blob.
- BL updater firmware name now includes board name.
- INS makefile brought up to date w.r.t. linker scripts
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.
This change is made up of a number of tightly coupled
changes:
- Deprecate the use of the USE_BOOTLOADER command-line
option. It is now hard-coded in each Makefile.
Overriding it on the command line is not allowed.
- Split apart the memory declaration and the section
declaration in all linker files (*_memory.ld and
*_sections.ld).
- Describe the split between bootloader and app sections
of flash in each board's _memory.ld file.
- Change program target to selectively erase flash so
that the installed bootloader is preserved across even
JTAG programming operations.
- All elf files are built with debug symbols and are not
stripped. This should help debugging with gdb. The
images programmed on the boards are all .bin files now
which do not include symbols.
New targets:
- make blupd_all_clean
- make blupd_all
- make blupd_openpilot
- make blupd_ahrs
- make blupd_coptercontrol
- make blupd_pipxtreme
These targets are also included in the 'all_flight' target.
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
We where hammered on the head with interrupts that the driver does not need, not allowing the ISRs of other drivers to run
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@3018 ebee16cc-31ac-478f-84a7-5cbb03baadba
Needed to clear the NACK flag in the ISR, or the next transfers seem to get a nack too because the IRQ comes back
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@3017 ebee16cc-31ac-478f-84a7-5cbb03baadba
will need to be forward ported (and ideally pushed up stream) for FreeRTOS
updates
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2939 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
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
projects which messed up a timer on OP and serial on PipX. Now this is only
changed for AHRS. Ideally wouldn't even change for that but then ADC runs too
fast and we get a lot more CRC errors for dealing with all that data.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2459 ebee16cc-31ac-478f-84a7-5cbb03baadba
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
