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
Test HW has R and G LED swapped and drives the UI LED's active
high. The changes support all the configuratons of FMUv5 on
RC00 and RC01 HW for PWM status and UI LEDs.
Added palarity mask to support active low drive on per channel
bassis.
Added open drain drive type when the enables are active low to
ensure the LED are off when supplied form 5 volts.
For active Push Pull is used. Active low drive is recomended.
Added support for test HW that had the R and G LED signals
swapped.
Use the board supplied Power control macros, in the
the board_peripheral_reset.
This abstacts the polarity from the code. Therefore changes
in signal sense can be made, just in the board config.
RC00 had an active high VDD_5V_PERIPH_EN
PC01 has an active low VDD_5V_PERIPH_EN
RC00 Test hardware did not use an LTC4417
While RC00 HW is still in circulation you can build with
PX4_FMUV5_RC00 defined and BOARD_HAS_LTC4417 undefined.
The default is PX4_FMUV5_RC01 and BOARD_HAS_LTC4417 defined.
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.
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.
David Sidrane