'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.
Everywhere where KHP is used, it is first completely reset, thus making
it unnecessary to keep it as a class member.
This saves 2.3KB RAM.
Stack sizes don't need changing, since there is already a function
Ekf::predictCovariance(), which needs around 3KB of stack and is called
close to where the fuse* functions are called.
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.
Paul Riseborough