Just to make sure that it will never be used on NuttX. This is not an
architectural limitation, just a memory optimization, since we call
clearenv() on NuttX.
Returned the fmu mixer code to where it updated the HW once
it has a mixer. But only signals a up_pwm_update() for
onshots on actual control update.
Before this change the hw outpuse were not updated.
A recent change in in the fmu stops the instance when a
xxxx_reset command is used issued if the fmu was not
already running.
That change left publications published and then on the
next creation created a new publications was created.
This change calls orb_unadvertise to mark the publication
as un published so that on the next instantiations of the
fmu it resumes publishing on the same publication.
Recent upsteam NuttX changes needed by PX4 added sem_[wait|post]
in the stm32_flash driver.
UAVCAN Bootloaders do not use the OS's scheduler etal.
This commit nops the sem_[wait|post] with linker magic.
Which precludes the linking the nuttx scheduler in the
bootloader build.
This reverts commit 22738b1213fff704d288ec84976fa84ff9535aba.
The command was added due to a lack of my understanding of how the pwm command can be used.
The command is not needed as the all flag can be used or a proper
mask WHIHOUT -g
fmu task mode_pwm
pwm rate -a -r 50 -d /dev/pwm_output0
pwm arm
pwm test -a -p 500
fmu task mode_pwm
pwm oneshot -a -d /dev/pwm_output0 is the same as pwm oneshot -m 0xff -d /dev/pwm_output0
pwm arm
pwm test -a -p 500
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.
1) Define IOTimerChanMode_OneShot
2) Added detailed commnent on .clock_freq and how it is used
3) Added single additional API point in support of Onshot mode
io_timer_trigger - That trigger all timer's channels in Oneshot
mode to fire the oneshots with updated values.
1) Validate timer paramater before using it.
2) Allow rate of 0 to enter Oneshot mode
At first blush this seamed like a hack, but at Mark
pointed out to me, Onshot PWM does not have a rate
So this is a realy a clever and beautiful simplification
on his part!
3) Exposes up_pwm_update that runs io_timer_trigger
Which trigger all timer's channels in Oneshot mode to
fire the oneshots with updated values.
The fmu now support the commandline option to be run as a task
or off a work queue.
This reverts the board_config.h changes from commit
e33af23122f5ee3030bb9745bbbf616b24c2a14a.
Conflicts:
src/drivers/px4fmu/fmu.cpp
