Rate changes were doing an asynchronous register reload via the EGR_UG. This could extend a PWM pulse up to 2X.
This fix removes the asynchronous update. The net effect is the the rate change will occur on the next counter expiration. The worst case is the rate change is delayed by 20 Ms.
This call rarely needs to be truly atomic and the involved CPU overhead in making it atomic was unnecessary and introduces a lot of IRQ jitter with no value-add. The call has been moved to be non-atomic and the codebase will be inspected and changed in follow-up commits for the few instances where it is truly needed.
Since tune control came in this driver does not have a
have a test based interface. The module Documentation
has been moved to tune_control
minor cleanup and assert on workque delay of 0
The data sheet for the F4, F7 indicate a maximum of 36 Mhz
in the 2.4-3.3 volt Soc operating range. This change sets
the clock based on the STM32_PCLK2_FREQUENCY.
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 PR is preliminary ground work for FMUv5.
PX4 does not use the NuttX adc driver. But used the same format
for the data returned by the nuttx ADC driver.
There was a fixme:in src/platforms/px4_adc.h "this needs to be
a px4_adc_msg_s type" With this PR the need for
src/platforms/px4_adc.h goes away as the driver drv_adc.h now
describes the px4_adc_msg_t.
Filter for channel 4 was modifying channel 1
capture and overflow reads were using wrong paramaters
in macros and addressing junk in memory.
up_input_capture_get_filter was shifing results the wrong way.
This fixes the issue with initializing channels 5,6 without
channels 1-4.
The code assumed all timers actions were in order to be
initialized. This is not the case. This commit fixes that
bad assumption by not stopping the configuration on the
first action entry with a base == 0, but processing all
entries with non-zero base.
David Sidrane