Board specific HW configuration is now collected in a single .c
file for each board. This HW configuration is #include'd into
the FW, BL and BU builds for each board.
These new .c files are found in:
flight/board_hw_defs/<board_name>/board_hw_defs.c
Parts of this information were previously duplicated between
the BL and FW builds. This commit cleans up the duplication.
Using a #include on a .c file is a bit ugly but it allows us
to ensure that all of the symbols in the board_hw_defs.c file
are *ONLY* used in the PIOS_Board_Init() function for each
software build.
Summary of changes:
* USB CDC and HID drivers are completely split apart.
* This will allow different max buffer sizes for HID and CDC.
* USB descriptors have been overhauled:
* Proper structs/macros/enums declared for USB (see pios_usb_defs.h)
* Two common descriptor definitions. One for HID+CDC another for HID only.
See pios_usb_desc_{hid_cdc,hid_only}.c for details.
* Long standing bugs in OP USB descriptors became much more obvious with the
new struct definitions.
* Board specific USB initialization is now in pios_usb_board_data.h in each build target.
* Definition of USB descriptors is now entirely indpendent of STM32 libs.
Glue into STM32 libs is provided by pios_usbhook.c.
* Removed a lot of stale/irrelevant USB #defines throughout the tree.
* Improved naming consistency throughout USB code:
* PIOS_USB_HID_* now refers to the HID endpoint code.
* PIOS_USB_CDC_* now refers to the CDC endpoint code.
* PIOS_USB_* now refers to the low-level USB code.
* PIOS_USB_BOARD_* now refers to board-specific USB data
* PIOS_USBHOOK_* is glue between PIOS and STM32 USB libs.
* struct usb_* and enum usb_* and USB_* and HID_* are all types from the USB spec.
* Shrunk the buffer size on the CDC call mgmt endpoint to save some RAM.
* Made a few more USB related variables static to save some RAM.
No code changes, just file, variable and define names are changed.
First, it better describes the serial protocol used by DSMx satellite
receivers. Second, many people using Spektrum radio, assume Spektrum
protocol. This is the attempt to address those inaccuracies.
PWM and PPM can now coexist in the same load and be
selected at boot time via the hwsettings UAVObject.
This is basically a complete restructuring of the
way the drivers interact with the TIM peripheral in
the STM32.
As a side effect, the PWM and PPM drivers are now
ready to support multiple instances of each.
This also provides the first step toward being able
to reassign some of the PWM input pins to be servo
output pins. Still more work required, but this is
a good start.
This allows the GCS to emulate a receiver device via the
telemetry link.
Select "GCS" as your input type in the manualcontrol config
screen and calibrate it as normal.
Note: The expected values for the channels are in microseconds
just like a PWM or PPM input device. The channel values
are validated against minimum/maximum pulse lengths just
like normal receivers.
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 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.
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.
heap reamining is low (about 500) but stacks can be ajusted (specially the 200 bytes from system) to give the level close to 1Ko if needed.
Merge branch 'master' into OP-423_Mathieu_Change_Init_To_Reduce_Memory_Footprint
Conflicts:
flight/CopterControl/System/inc/FreeRTOSConfig.h
flight/CopterControl/System/inc/pios_config.h
It was tested being merged with OP-472_CorvusCorax_CopterControl-Guidance_v3
branch, Spektrum on USART3 and GPS on USART1 and seems to work.
Currently defaults mimic original behavior, that is, if USE_SPEKTRUM
is not defined - define USE_PWM and USE_GPS. Thsi should be refactored
later to make it configurable from the Makefile.
Also it was not ported to the OP MB: it currently does not support the
S.Bus hardware and still has original behavior with the patch. But this
is one more step to dynamic configuration of ports.
TODO: This should be dynamic in the future.
But for now define any compatile combination of:
USE_I2C (shared with USART3)
USE_TELEMETRY
USE_GPS
USE_SPEKTRUM
USE_SBUS (USART1 only, it needs an invertor)
and optionally define PIOS_PORT_* to USART port numbers
Defaults are:
#define PIOS_PORT_TELEMETRY 1
#define PIOS_PORT_GPS 3
#define PIOS_PORT_SPEKTRUM 3
#define PIOS_PORT_SBUS 1
#define USE_TELEMETRY
#define USE_GPS
Telemetry, GPS and PWM input are enabled by default.
- 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.
When running flight software from master (cf74908), my
config was pushing the system module stack usage to within
16 bytes of its limit. This triggers a stack overflow
alarm which prevents the quad from arming/flying.
This change increases the available stack size such
that there are 72 bytes of stack free (a previously stated
safe margin) when my quad is sitting idle and unarmed on
the bench.
