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
change fmu to task
increase fmu_servo task priority to max and enable true oneshot
use lowest FMU priority which minimizes jitter
constrain oneshot updates to control group 0 events
This is the new interface to control external LED's (user-facing).
Features:
- Supports maximum N Leds (where the board can define N)
- on/off/blink M times
- Different priorities
- Allows setting a single led or multiple at once
The sensor_rest command added to the startup script for px4fmu_v4 hardware
was leaving the /dev/pwm_output0 driver open. This would prevent the
pwm_out_sim module from registering as a simulated driver. The result
would cause the system to properly boot in HIL mode, but you would not
be able to set any control surfaces.
Since sensor_rest and peripheral_reset are only used on initialization, the
drivers can be shut down after they have performed their reset functions.
Signed-off-by: zthorson <zachthorson@gmail.com>
The maximum number of missions was increased in almost 8 times in
recent commit: 9369262e63 navigator: allow more mission items.
As this board loads missions in RAM, now it don't have enough memory
to allocate causing dataman start to fail, so mark it as a memory
constrained system and reduce the number of maximum missions
supported.
We need to protect access to the param_values array. This is dynamically
allocated and resized (utarray_reserve() calls realloc). If some thread
was iterating the array while another was resizing the array, the first one
would iterate on a freed array, thus accessing invalid memory.
On NuttX this could lead to hardfaults in rare conditions.
Unfortunately we need to initialize the semaphore on startup, by calling
sem_init(). This adds a param_init() method called by every board/config
that uses the params (at least I think I've found all of them)
David Sidrane