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.
Working spektrum bind routine, depending your TX try BIND_PULSES 3,5,7,9 (5 works with DX7)
Boot process takes too long on MB so bind command misses the window (20-140ms).
the throttle is < 0. This will make things like axis-lock work while armed
without throttle. HOWEVER don't hold your stick in the arming position for a
long time or you can wind up the integrals now.
zero and making the attitude get NaN. Wrote recovery code for that condition
(should never occur) and also force minimum dT to 1 ms (also shouldn't occur)
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.
The initial baud rates of each interface are now forced in the
board init code.
Any modules using USARTs should have fields added to
their settings object to allow the user to change the
baud rate from the default by using the COM layer APIs.
Developers requiring custom baud rates before the settings
objects are in place should locally edit the cfg structs
to specify the desired baud rates.
Tested this heap2 at runtime with CC and new compiler since old one (current) triggers strict alliasing error.
That's ok since strict aliasing is disabled on OP, and CC only use heap1.
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.
The FreeRTOS IDLE task was using 512 bytes of stack.
The UAVObject Event task was also using 512 bytes of stack.
Both have been reduced, recovering 400+ bytes of heap.
