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.
This prevents the compiler from optimising pdump. The error was:
Firmware/src/drivers/boards/common/board_crashdump.c:41:2: error: 'memset' writing 3240 bytes into a region of size 4 overflows the destination [-Werror=stringop-overflow=]
memset(pdump, 0, sizeof(fullcontext_s));
previously, get_devname() was used as the I2C device path, but on NuttX,
get_devname() is the device file which the driver creates. This patch
changes it, so the sematics are the same as on NuttX: both now use _bus
to decide to which I2C bus device to talk to.
I did not see any other use-cases than the led on ocpoc.
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 ~ 180 ms of power off time
with 0.00 voltage applied to the sensors.
Given the original poster's comment that "It happens very consistently for us." I suspect the motor spin observed in https://github.com/PX4/Firmware/issues/7457 is not caused by the original issue of slow decay on the PWM pins at reset, but the post reset pulse of 3.1 Ms arriving in a window that the ESC considers it valid.
The results from testing, indicated that the if the PWM pins were clamped low for > 300 Ms, prior to reset the motors did not spin. This would delay the the post reset pulse of 3.1 Ms out by > 300 Ms.
This change delays the reset and therefore the pulse by at least 400 Ms.
problem: previously when connecting power to Power 1, commander refused
to arm (no power source error), and when connecting to Power 2, arming
works, but power consumption was not measured (& shown in QGC).
Swapping Brick1 with Brick2 makes sure both works when connecting to
power 1.
Ideally we will have support for both power sources (including fail-over)
David Sidrane