The simulation engine had the ability to pause already and properly handled load spikes, however, it was not hardened against constant drift. This addition enables it to run at a constant slower-than-realtime rate successfully.
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.
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.
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
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.
