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.
The main purpose of this new COM implementation is that it is
much simpler, and requires less code space. This takes a bit
of the pressure off of the CC bootloader which was right at
the limit of available code space in the bootloader partition.
This is not intended to ever be used by the application.
This driver also formalizes the assumptions in the bootloader's
usage of the COM layer. All messages are assumed to arrive
in atomic chunks from the HID layer.
This can be used by the GCS firmware uploader widget to boot
the firmware with a (temporarily) defaulted hwsettings uavo
so that a user can easily recover from a bad/incompatible
hwsettings configuration without wiping all settings.
This uses the same mechanism that the BootFault auto-recovery
code already uses in the CC firmware. The auto-recovery is
triggered by setting the failed-boot counter to a maximum
value forcing recovery on the next FW init.
The PIOS_COM_ReceiveBufferUsed() function call is no longer
necessary since the same semantics can be achieved using calls
to PIOS_COM_ReceiveBuffer().
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.
Reduced scope of many variables since they were being
exposed unnecessarily.
Renamed pios_usb_hid_prop code to pios_usbhook to reflect
the fact that it implements all of the callout functions
that are hooked into the stm32 usb library.
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()
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.
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.
Macros for JTAG program and wipe for each target are now
provided in firmware-defs.mk.
The _wipe target for each firmware and bootloader image will
erase either the bootloader (bl_*_wipe) or firmware (fw_*_wipe)
bank.
Now that every bootloader build has a board info blob,
make all fw and bl images use it.
The following MACROS are removed:
BOARD_TYPE, BOARD_REVISION, BOOTLOADER_VERSION,
START_OF_USER_CODE, HW_TYPE
These values are now ONLY available from the bootloader
flash via the pios_board_info_blob symbol. These values
must not be #defined or otherwise hard-coded into the
firmware in any way. The bootloader flash is the only
valid source for this information.
NOTE: To ensure that we have an upgrade path from an
old bootloader (without board_info_blob) to a
new bootloader (with board_info_blob), it is
essential that the bu_* targets do not depend
on (or validate) the board_info_blob being present
in the bootloader flash.
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.
The .bin.o rule places the contents of a raw .bin file
into an .o file wrapped within fixed symbols for start
and end. This can be used to embed a binary file inside
of an executable.
The symbols for the embedded binary blob are:
_binary_start
_binary_end
_binary_size
NOTE: The way the .bin.o rule is currently written, you
can only embed one binary blob in an executable since the
symbol names will collide if you add multiple blobs. This
limitation is easily removed later if necessary.
