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.
Since the Onshot<->PWM mode is changed based on rate. The
this signale the higher layers that the operation is invalid
test case:
fmu task mode_pwm2cap2
pwm oneshot -m 0xf -g 0 -d /dev/pwm_output0
should fail, because all the channels in the group are
not in the same mode.
1) Updated copyright
2) Defined BOARD overrideable BOARD_PWM_FREQ and BOARD_ONSHOT_FREQ
Not recogmended but allow experimentation
3) Solved the support for BOARD_PWM_DRIVE_ACTIVE_LOW using
the Polarity control bits as apposed to the negation of
the ARR.
4) Added a cache for getting a timers channels. This is static
and benifits from the qucik response.
5) Added a function to realocate all channes in a given timer
from one mode to another.
6) Removed the frequecy table in favor of the intended use of the
channel mode set. At it is the way to determine the mode of a
channel. Or in onshot's case a timers's complete set channels.
7) Added 2 lowlevel mode changing functions:
io_timer_set_oneshot_mode and io_timer_set_PWM_mode
that encapsalate the changes in mode to one place
in the code.
8) Added io_timer_trigger (the up_pwm_update) with low
latancy timer to time in updating.
9) io_timer_set_rate - use sets to enforce all or none
rules for switching PWM<->OneShot.
Onshot is entered using the very approriate rate of 0.
Only deltas will change the HW state.
David Sidrane