This can help "unbrick" AeroFC when a bad firmware is loaded
and it keeps rebooting or it spinning in some loop.
No need to request to stay in booloader as it will stay
in bootloader because the pin is set.
- change memory allocation from stack to a malloc'd buffer. This avoids
increasing the stack size. And since FTP is rarely used, the buffers
are only allocated upon use and freed after a time of 2s inactivity.
- adds PX4_ROOTFSDIR as root directory prefix. This does not change
anything on NuttX, but in SITL it will avoid enumerating the whole
disk tree when using QGC (which enumerates all files recursively).
The provided argument payload->offset is in range [0, num_file_entries-1],
but seekdir might use a completely different range. It is not defined
by the API spec. It is only useful in conjunction with telldir().
This can happen for example when a param type is changed from int32 to
float. The type check will then fail if the param is stored and the param
import will be aborted.
Now we just skip the entry and continue loading the rest.
This was only a problem when running as a task not on the work queue.
The problem was that init() opened the RC serial device, which was then
read in the main loop, which is a different context when run as a task.
Both PX4Test and Beat noted if only Brick to was connected
battery_status Intance 0 voltage was 0V for Brick2
The priority selection logic is run prior to the subscription
creation and only updated the priority on a change. Before the
subscriotions were created.
_battery_pub_intance0ndx is suposed track the location in
the _battery_pub array that is instance 0. It is then used
to associate (move) instance 0 with (to) the lowest brick
(highest priority in HW) brick that is selected in HW.
The Bug was that before the subscriptions are created,
_battery_pub_intance0ndx set to 1. And then and never updated.
The fix was to only run the priority selection logic once
the subscriptions are created.
BOARD_HAS_LTC44XX_VALIDS - 0 -> No LTC44xx IC, N is the number of
Power Bricks connected to the LTC44xx
For a LTC4417 this would be 2 as the
third prioriy is used for USB
BOARD_HAS_USB_VALID - If defied as 1 imples that infact
the USB has a priority connection
on the LTC44XX
BOARD_HAS_NBAT_V - the number of battery voltage sensing chennels
on the ADC
BOARD_HAS_NBAT_I - the number of battery current sensing chennels
on the ADC
A super simple (non FMUv5 compliant) board with no LTC44xx and just one battery
that have no current sense:
BOARD_HAS_LTC44XX_VALIDS = 0
BOARD_HAS_USB_VALID = 0
BOARD_HAS_NBAT_V = 1
BOARD_HAS_NBAT_0 = 0
A fully FMUv5 compliant design would use:
BOARD_HAS_LTC44XX_VALIDS = 2
BOARD_HAS_USB_VALID = 1
BOARD_HAS_NBAT_V = 2
BOARD_HAS_NBAT_0 = 2
These setting properly condition the ADC channles and all the Power
module valid sensing logic in the ADC module.
voltage3V3_v - the sensor 3.3V voltage rail
v3v3_valid - the value of voltage3V3_v may be 0. This
field is a 1 when the HW provides voltage3V3_v
brick_valid - is now a bit mask. A 1 in the postion inticate the
Power controler HW has a valid supply voltage
present (in V window) on that priority
(channel V1..Vn).
The mapping is formed by 1<<battery_status.msg.priority
or using the manifest constanst BRICKn_VALID_MASK
usb_vaild - is now indicated from the Power controler HW or
the usb_connected if Power controler is
not present.
brick_valid == 0 and usb_vaild = 1 implies the FMU is powered
from USB only
brick_valid != 0 and usb_vaild = 1 implies the FMU is powered
from the higest priority brick, providing a 1 bit in brick_valid
and from USB
This change implements the publishing of batery_status messages
for each brick on the system, using multi-pub.
Backward compatiblity is achived by always publishing the
batery_status of the bick that has been selected by the HW
Power Controller (PC) on instance 0.
The batery_status.system_source will be true in one and
only one batery_status publication when a valid bit is
set in system_power.brick_valid. However, if USB is connected,
and both brikcs are not providing voltages to the PC
that are in the Under/Over Voltage Window (set in HW)
the system_source may be false in all publications.
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.
Lorenz Meier
stmoon
José Roberto de Souza
Beat Küng
Daniel Agar
davidaroyer
ChristophTobler
Dennis Shtatnov
Paul Riseborough
Paul Riseborough
David Sidrane