* Break out dshot.h from dshot.cpp and rename files to reflect the class name.
Move DShot class specific #defines from drv_pwm_output.h to dshot.h.
Replace c-style casts with static_casts, standardize method naming, single line comment styles, and formatting.
Rename update_dshot_out_state() to enable_dshot_outputs().
The device path is needed to apply PWM limits on the motors that are not
used for FW flight (switch them off). With this parameter the device path can be set
to either IO or FMU, depending on whether the motors are on the IO or FMU port.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
and remove the px4_ prefix, except for px4_config.h.
command to update includes:
for k in app.h atomic.h cli.h console_buffer.h defines.h getopt.h i2c.h init.h log.h micro_hal.h module.h module_params.h param.h param_macros.h posix.h sem.h sem.hpp shmem.h shutdown.h tasks.h time.h workqueue.h; do for i in $(grep -rl 'include <px4_'$k src platforms boards); do sed -i 's/#include <px4_'$k'/#include <px4_platform_common\/'$k/ $i; done; done
for in $(grep -rl 'include <px4_config.h' src platforms boards); do sed -i 's/#include <px4_config.h/#include <px4_platform_common\/px4_config.h'/ $i; done
Transitional headers for submodules are added (px4_{defines,log,time}.h)
- board config can define PX4_PWM_ALTERNATE_RANGES which needs to be known
by the compiler prior to processing this file
Signed-off-by: Roman <bapstroman@gmail.com>
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
We don't have C++ unsafe headers (anymore).
I added a test to fix_headers.sh that checks if certain "unsafe"
headers are ONLY included inside a __BEGIN_DECLS ... __END_DECLS
(because after all, they are unsafe), as well as checking that
no other header files are included inside such a block. The rationale
of the latter is that if a file is a C header and it declares
function prototypes (otherwise it doesn't matter) and is sometimes
included outside a __BEGIN_DECLS ... __END_DECLS block (from a C++
source file) then it has to be C++ safe and doesn't ever to be
included from inside such a block; while if a file is a C++ header
then obviously it should never be included from such a block.
fix_headers.sh subsequently found several safe headers to be
included from inside such a block, and those that were (apparently
in the past) unsafe were included only sometimes inside such a
block and often outside it. I had a look at those files and saw
that at least an attempt has been made to make them C++ safe,
but especially because they already are included OFTEN outside
a __BEGIN_DECLS ... __END_DECLS (from C++ source files) the
best decision seems to treat them as safe.
This is not risky: .c files that define such functions still
generate C-linkage for their functions. If a C++ unsafe C header
is included outside a __BEGIN_DECLS ... __END_DECLS block then
the only possible result would be an undefined reference to
a function with C++-linkage that will not exist. Aka, when
something links after this commit, then the commit was correct.
I did build all targets and they all linked.
this allows the flight code to choose whether FMU failure gives
immediate manual pilot control, or waits for the mode switch to go
past the override threshold
Daniel Agar