Define modes of reset and way to tell the system to enter
the bootloader via an api defined in board_common.h
If hardware or simulation deo not support the reset or
bootloader API and can define BOARD_HAS_NO_RESET and
BOARD_HAS_NO_BOOTLOADER respectivly.
This board don't have a SDCard to save crash dumps and it was causing
the board to get stuck into '[boot] There were %d reboots with Hard
fault that were not committed to disk - System halted', until user
connect to the serial console and clear the fault.
1) Key the exsitance of the PX4IO HW based on BOARD_USES_PX4IO_VERSION
2) Set default PX4IO_FW_SEARCH_PATHS based on verions of the PXPIO HW
3) allow PX4IO_FW_SEARCH_PATHS to be overwritten if a board provides
BOARD_PX4IO_FW_SEARCH_PATHS
This adds a src/board/<bebop|eagle|excelsior|rpi|sitl>/board_config.h
to configure the build as is done with the Nuttx targets
src/platforms/posix/include/board_config.h has been renamed to
src/platforms/posix/include/system_config.h to allow the common
posix defines to be included with the board specific defines.
Prep to distrubte the magic numbers assgined in parameters.cpp
to the board_config.h
common/board_common.h will define:
1) BOARD_BATTERY[1|2]_V_DIV as 0.0f if not defined to ensure
the missing default trips a low voltage lockdown
2) BOARD_BATTERY[1|2]_A_PER_V as 0.0f if not defined to ensure
the default leads to an unrealistic current value.
The gpio leg can use either the FMU GPIO_SERVO (Aux Pins)
or the FMUv1 style IO pins.
We define either LED_ON_SERVO_GPIO or LED_ON_EXT_GPIO_AND_PIO
based on if the board_config provides GPIO_SERVO_1 or
GPIO_EXT_1.
For LED_ON_SERVO_GPIO we further define GPIO_MIN_SERVO_PIN and
the GPIO_MAX_SERVO_PIN based on the highest GPIO_SERVO_x provided
by the board_config
When base the ability to use the PX4PIO not in the existance of
the path but on the define BOARD_USES_PX4PIO
David Sidrane
José Roberto de Souza
Lorenz Meier
Julian Oes
Andrew C. Smith
Paul Riseborough