1) Remove uneeded spi and reset code
2) Use the Board commin for providing the BOARD_NAME
3) Add PX4_PWM_ALTERNATE_RANGES in suport of a board agnostic
way to override the PWM_.*_{MIN|MAX} values
4) Remove #ifdefs from the IO timers*. Drive the config deltas
from the crazyflie_timer_config.c and one board agnostic
ifdef PX4_IO_TIMER_ALTERNATE_RATE that is non board specific
*I would like to eliminate PX4_IO_TIMER_ALTERNATE_RATE
as well, but I need HW to validate that the startup
script can just set the rate on the PWM to 3921 fast
enough to not effect the motors.
'mavlink stop-all' during a log streaming session previously led to a
resource leak, and log streaming could only be re-started by rebooting the
system.
Using cout drags in std::localeconv which isn't defined
on QURT. While this file is also used for POSIX, it doesn't
seem to harm much to use printf there as well.
pwm_input was not working correctly (only after a pwm_input reset) on
Pixracer because fmu was started on all PWM output channels.
This moves the check if PWM input is needed up before the fmu start.
Instead of sending actuator controls from -1..1 for SITL, we should send
0..1 like we already do for HIL. This will enable negative thrust in the
future, e.g. for pusher props that spin backwards, or for vehicles with
variable pitch propellers.
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.
David Sidrane
Mark Whitehorn
Daniel Agar
Sander Smeets
Beat Küng
Carlo Wood
Lorenz Meier
Lucas De Marchi
mantelt
CarlOlsson
Henry Zhang
Julian Oes