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
It makes more sense to set the optimization flags on a platform basis
instead of individually for each module. This allows for different
optimization options for SITL, NuttX, Snapdragon, etc.
The commander used to consume the battery_status topic and write the
contents after some calculations into the system state. Instead, the
calculations now happen in library calls in systemlib/battery.
This moves the battery fields out of the vehicle_status message into the
battery_status topic.
This brought quite some changes in all modules that need battery
information. The current state is compiling but untested.
- Use distinct common symbols for px4io and px4fmu device files, and use
instead of hardcoded filenames
- Use common symbols defining px4io bits consistently between px4fmu and
px4io builds.
