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
Define the default I2C buss frequncies that are backward compatible
with the existing code. While allowing it the defaults to be overridden
by a board config.
Based on the legacy STM32 code, the I2C buss numbering starts at 1.
The bus frequency is stored in a 0 based array. If px4_i2cbus_initialize
returns a valid device, then the _bus-1 will act as the index to the
busses frequency.
A board may define BOARD_NUMBER_I2C_BUSES - the number of I2C busses
it supports* and BOARD_I2C_BUS_CLOCK_INIT to initalize the bus
clocks for a given busses.
BOARD_NUMBER_I2C_BUSES - the number of busses including the *highest
number bus. If the board has 2 I2C
busses I2C1 and I2C3 BOARD_NUMBER_I2C_BUSES
would be set to 3
BOARD_I2C_BUS_CLOCK_INIT - Initalization for the bus frequencies
by bus. A call init, with a frequency
less then the value used for the
Initalization will result in the device
not starting becuase the buss runs too
fast for it.
FMUv4Pro and FMUv5 Spec added multi brick support
FMUv5 added SCALED_VDD_3V3_SENSORS
This change provides legacy (FMUv2) defaults for Power Bricks and
Sensor rail volatage source.
This prevents the compiler from optimising pdump. The error was:
Firmware/src/drivers/boards/common/board_crashdump.c:41:2: error: 'memset' writing 3240 bytes into a region of size 4 overflows the destination [-Werror=stringop-overflow=]
memset(pdump, 0, sizeof(fullcontext_s));
David Sidrane