The removes the alias so it is clear what bus and port bit
is associated with as CS or DRDY signal.
This becomes important when varients of V2 a) use the CS on differnt
busses or b) swap a RDY (in) for a CS (out). In both cases,
a CS on once buss, can back feed and cause sensor reset to not be
able to turn off the power if all the pins are not tunered
off
Pixhawk mini has reused the GPIO_SPI_CS_EXT1 signal that was associated
with SPI4. We can not in good faith assert a CS on a bus wer are not resetting.
So we must do this only on HW_VER_FMUV2MIN
Insure a 0.0 voltage initial condition on VDD_3V3_SENSORS
By starting the GPIO_VDD_3V3_SENSORS_EN, low and deferring
the GPIO init of the slave selects and drdy signals until
board_app_initialize. We get ~ 80 ms of power off time
with 0.00 voltage applied to the sensors.
There are several boards that share the px4fmu-v2 build as px4fmu-v3 build.
It was initially envisioned, that the build would be binary compatable and
the RC script would probe different sensors and determine at runtime the
HW type. Unfortunately, a failed sensor, can result in mis-detection
of the HW and result in an improper start up and not detect the HW
failure.
All these boards's bootloader report board type as px4fmu-v2.
This precludes and automated selection of the correct fw if it
had been built, by a different build i.e. px4fmu-cube etc.
We need a way to deal with the slight differences in HW that effect
the operations of drivers and board level functions that are different
from the FMUv2 pinout and bus utilization.
1) FMUv3 AKA Cube 2.0 and Cube 2.1 Bothe I2C busses are external.
This effected the mag on GPS2 not reporting Internal and
having the wrong rotation applied.
2) FMUv3 does not performa a SPI buss reset correctly.
FMUv2 provides a SPI1 buss reset. But FMUv3 is on
SPI4. To complicate matters the CS cross bus
boundries.
3) PixhawkMini reused a signal that was associated with SPI4
as a SPI1 ready signal.
Based on hardware differnce in the use of PB4 and PB12 this code
detects: FMUv2, the Cube, and PixhawkMini and provides the
simple common API for retriving the type, version and revision.
On FmuV5 this same API will be used.
This change plus the new FPGA RTL(version 0xC1 or higher) will make
use of the new I2C bus, this new bus will be shared between aerofc_adc
and ll40ls(if connected) and leaving the old bus just to IST8310.
The UART3 also have the I2C bus 2 functions so moving GPS to UART7 to
have one additional I2C.
To keep GPS working is also necessary update the FPGA RTL to version
0xC1 or higher.
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.
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.
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.
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.
David Sidrane