This commit is the groundwork to fix the power LED
blinking on V5
Background:
----------
Early boards only had an AMBER LED that was used to
indicate a High Load condition.
This change defines the new logical inteface
the LED_<color> should not be used in application
code moving forward, only the minipulator macros
should be used.
Logical usage Legacy default
------------------------+-------------
BOARD_OVERLOAD_LED | LED_RED
Later boards defined BOARD_HAS_CONTROL_STATUS_LEDS
and added the use of a BLUE and GREEN LED that were
used as follows:
Logical usage Legacy default
------------------------+-------------
BOARD_ARMED_LED | LED_BLUE
BOARD_ARMED_STATE_LED | LED_GREEN
With this PR a board may now define _only_ a subset
the leds and map them at the board level to the
color LED it wants to use.
Logical usage Legacy default
------------------------+-------------
BOARD_OVERLOAD_LED | LED_RED
when BOARD_HAS_CONTROL_STATUS_LEDS is defined
BOARD_ARMED_LED | LED_BLUE
BOARD_ARMED_STATE_LED | LED_GREEN
If any of the BOARD_{OVERLOAD|ARMED|ARMED_STATE}_LED are not
defined. The code output generates a null action for that
LED.
board_get_px4_guid() called board_get_uuid() with a 2 bytes offset into an
uint8_t array. This gives no guarantees on alignment, and board_get_uuid()
casts it to an uint32_t array, leading to potentially unaligned accesses.
The form of the PX4 GUID is as follows:
offset:0 1 2 - 17
<ARCH MSD><ARCH LSD><MSD CPU UUID>...<LSD CPU UUID>
Where <ARCH MSD><ARCH LSD> are a monotonic ordinal number assigned by
PX4 to a chip architecture (PX4_SOC_ARCH_ID). The 2 bytes are used to
create a globally unique ID when prepended to a padded CPU ID.
In the case where the CPU's UUID is shorter than 16 bytes it will be
padded with 0's starting at offset [2] until
PX4_CPU_MFGUID_BYTE_LENGTH-PX4_CPU_UUID_BYTE_LENGTH -1
I.E. For the STM32
offset:0 1 2 3 4 5 6 - 17
<ARCH MSD><ARCH LSD>[0][0][0][0]<MSD CPU UUID>...<LSD CPU UUID>
I.E. For as CPU with a 16 byte UUID
offset:0 1 2 - 17
<ARCH MSD><ARCH LSD><MSD CPU UUID>...<LSD CPU UUID>
Flight tested: ekf2 w/ mag and compass by @nathantsoi: https://logs.px4.io/plot_app?log=79b81031-cf1e-41f0-890b-d6cd7d559766
NOTE: external I2C devices need a pullup. I have tested with a 3.3v 2.2k pullup.
Working:
- mpu6000, bench tested and verified via nsh
- fmu
- all 6 ch output bench tested w/ pwm and oneshot via nsh
- ppm input bench tested
- dsm input bench tested
- bmp280, bench tested and verified via nsh
- hmc5883, bench tested and verified via nsh, but requires an external i2c pullup
- gps on uart6
- startuplog, nsh, mavlink on uart4, but params are not sent for some reason. RSSI pin is TX, MOTOR 5 is RX (normal mode, 57600 baud)
- rgbled over i2c, bench tested and workingp
- sbus via the shared sbus/ppm pin (which includes an inverter to the mcu SBUS in pin), remove the solder bridge or jumper to the ppm pin before use
Not yet implemented:
- ADC
- OSD: passthrough video is untested, use at your own risk until a basic driver is implemented.
Change to be coherent with the change on NuttX upstream, in the future
STM32_BKP_BASE will be removed. This is using the definition over stm32_rtc.h interface.
BOARD_ADC_OPEN_CIRCUIT_V is the voltage present on an ADC due
to the bias current on the terminition resistor.
BOARD_VALID_UV is the under voltage min set by resistors on a
board's Power selector.
A battery is considered connected when the Voltage measures is
greater than BOARD_ADC_OPEN_CIRCUIT_V.
In the case where BOARD_ADC_OPEN_CIRCUIT_V is greater then
BOARD_VALID_UV we can use the HW to qualify connected.
* NuttX cmake
* px4_macros:Pass the stringified predicate as second arg to static assert
CC_ASSERT mapes to the c++ static_assert or provides the same
funtionality for c via the other macros. The c++ static assert
takes 2 argumants the prdicate and a message. This fixes the
lacking second argument.
* Updated nuttx and apps submodule to upstream nuttx 7.21+==master
This is the latest uptake of upstream nuttx and apps.
* ROMFS generate with xxd instead of objcopy
* delete nuttx-patches
* NuttX update submodules to latest px4_nuttx-master
* fix nuttx apps and board dependency
* docker_run update to latest container 2017-08-29
* cmake ROMFS portable sed usage
* NuttX update submodules to latest px4_nuttx-master
Using new type of uint32_t for spi device and macros
that define a PX4 device on a given BUS and Chip Select
Refactored to pack the PX4 format in the new NuttX format
David Sidrane