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.
system_source - This battery status is for the brick that is
supplying VDD_5V_IN
priority - Zero based, This battery status is for the brick
that is connected to the Power controller's
N-1 priority input. V1..VN. 0 would normally be
Brick1, 1 for Brick2 etc
Battery now assigns connected from the api in the
updateBatteryStatus, as well as system_source and priority
The PX4IO is an population option on some varients. To have
1) FMU only control
2) IO Only control
3) FMU fall back control
These pins need to come up as inputs, until the configuration
is determined.
Added comments to ADC defines with Pin numbers.
Added the GPIO_HW_{REV:VER}_DRIVE signals
Define the GPIO_nPOWER_IN_{A:C] and assign them to
BRICK1, BRICK2 and USB Valid.
Regroupped power signals and defined true logic Power Control macros
in the arch agnostic form.
Defined the same IOCTL defines for FMU GPIO IOCTL
Use the power Control macros on board_app_initialize
As done on fmuV4 on resets invoked from system (not boot) insure
we establish a low output state (discharge the pins) on PWM pins
before they become inputs as a result of the pending reset.
We also delay the reset by 400 MS to insure the 3.1 Ms pulse is
not too close to the last PWM pulse.
The LTC4417 provides a valid signals for brick1, brick 2 and USB
This change configures the GIOP and provides 1) a MACRO to read
the pin and 2) the IOCTL defines to read it from the FMU.
The macro's result is true logic: It is true when the signal is active.
(Active low on the the LTC4417). The IOCTL read would be the actual
pin state.
The V4 HW replaced the LTC4417 provided valid signal for USB.
with an active high, version. This commit configures the GIOP
and provides 1) a MACRO to read the pin and the IOCTL defines
to read it from the FMU. The macro result true logic: true
when the signal is high. The IOCTL read would be the actual
pin state.
The LTC4417 provides a valid signal for USB. This change
configures the GIOP and provides 1) True logic macro to
read the pin and the IOCTL defines to read it from the FMU.
The macro will return true when the signal is active (low
on the LTC4417). The IOCTL will read be the actual pin state.
Moving forward we want all the board configs to drive the
configuration. This is just cleanup to give a clear
example of how ADC should be defined by a simple list,
based on ADC pin number as related to the GPIO and
channel number. Then the xxx_CHANNEL bit are
used to form the ADC_CHANNELS (mask). The GPIO
will are used to for a list for initalization.
Test flights reported the warning `[load_mon] log_writer_file low on stack! (292 bytes left)`
Increase stack size from 1060 to 1072 (=8 + 1060 rounded to next multiple of 8).
David Sidrane