The small bootloaders (CC and PipX) are out of flash space
so their stopwatch implementation has been swapped out for
one based on the DELAY clock that takes about 500 bytes less
of code space.
Identical functionality is preserved.
This allows the spektrum and sbus receiver drivers to bind
directly to the usart layer using a properly exported API
rather than overriding the interrupt handler.
Bytes are now pushed directly from the usart layer into the
com layer without any buffering. The com layer performs all
of the buffering.
A further benefit from this approach is that we can put all
blocking/non-blocking behaviour into the COM layer and not
in the underlying drivers.
Misc related changes:
- Remove obsolete .handler field from irq configs
- Adapt all users of PIOS_COM_* functions to new API
- Fixup callers of PIOS_USB_HID_Init()
Update to use 32-bit microsecond values.
Remove PIOS_DELAY_DiffuS per consensus (caller can do it easily themselves).
Update the core delay logic per Stac's suggestion to a version that is
resistant to various overflows.
Each channel was previously tracking a separate driver.
Now, channels are grouped within a channel group to save
RAM used for tracking and to better reflect how channels
are actually mapped.
Also reduce heap has it does not fit in SRAM anymore (not with current compiler).
(that's ok since if there is more space available, it will be reclaimed).
Merge branch 'master' into OP-423_Mathieu_Change_Init_To_Reduce_Memory_Footprint
Conflicts:
flight/CopterControl/System/inc/pios_config.h
flight/Modules/ManualControl/manualcontrol.c
This is a port of a work-in-progress by Sambas onto
the new driver infrastructure needed for boot-time
configuration.
PPM and PWM still don't coexist in a build but this
is closer.
This should mark an end to the compile-time selection of HW
configurations.
Minor changes in board initialization for all platforms:
- Most config structs are marked static to prevent badly written
drivers from directly referring to config data.
- Adapt to changes in .irq fields in config data.
- Adapt to changes in USART IRQ handling.
Major changes in board initialization for CC:
- Use HwSettings UAVObj to decide which drivers to attach to
the "main" port and the flexi port, and select the appropriate
device configuration data.
- HwSettings allows choosing between Disabled, Telemetry, SBUS,
Spektrum,GPS, and I2C for each of the two ports.
- Use ManualControlSettings.InputMode to init/configure the
appropriate receiver module, and register its available rx channels
with the PIOS_RCVR layer. Can choose between PWM, Spektrum and PPM
at board init time. PPM driver is broken, and SBUS will work once
it is added to this UAVObj as an option.
- CC build now includes code for SBUS, Spektrum and PWM receivers in
every firmware image.
PIOS_USART driver:
- Now handles its own low-level IRQs internally
- If NULL upper-level IRQ handler is bound in at board init time
then rx/tx is satisfied by internal PIOS_USART buffered IO routines
which are (typically) attached to the COM layer.
- If an alternate upper-level IRQ handler is bound in at board init
then that handler is called and expected to clear down the USART
IRQ sources. This is used by Spektrum and SBUS drivers.
PIOS_SBUS and PIOS_SPEKTRUM drivers:
- Improved data/API hiding
- No longer assume they know where their config data is stored which
allows for boot-time alternate configurations for the driver.
- Now registers an upper-level IRQ handlerwith the USART layer to
decouple the driver from which USART it is actually attached to.
This separates the RTC device and interrupt handling
from the devices that rely on the tick notifications.
Drivers can now register tick notification functions
that will be called on each RTC tick event.
All receivers now fall under the same driver API provided
by pios_rcvr.c.
This is part of a larger sequence of commits that will
switch the receiver selection over to boot time dynamic
configuration via UAVObjects.
Also implement some ordering (quite ugly still) in the module init and task creation order so we can decide which module to start/init first
and which module to start/init last.
This will be replaced/adapter with the uavobject list later (once it's implemented).
reserving some space for module init and task create parameters to customize module/task creation (this will be usefull once we get the list and customization from customer).
Changes have been made for OP and CC. Tested comped with CC,OP, sim_posix.
Only ran on bench with CC for couple of minutes (code increase expected but no dropping of stack which is good).
This gives task creation at the time wherethe all heap is available.
- create linker section for those <module>Initialize()
- later this list will incorporate parameters as well. (this probably will be more a OP feature to swap/remove/delete module on the fly.
- this is not done at compile time anymore by Makefile.
- this will allow us to have control on the module start at run-time (not implemented but build the ground for it).
- this simplify the startup (Part of code re-org).
- this change does not affect sim_posix and win32 (since they don't need that)
- ensure it's compiling for PiOS.posix
- port to PiOS.win32 but not tested (not compiled)
- tested on CC
- compile on OP.
- this free ~200 bytes.
- current avalable bytes (is we keep the same remaining bytes on the stack than before) is easily passed the 1.2Ko mark on CC with new gcc (4.5.2)
- this does not include init-reorg for each module (I still think more can be freed)
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 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
