The mapping of PX4_SPIDEV_ACCEL_MAG to PX4_SPIDEV_ICM is not
a clean approach and the PX4_SPIDEV_MPU is already used by the
mpu9250 leaving the only (and the correct) option to the use
PX4_SPIDEV_ICM and make it map to the reused ACCEL_MAG_CS PC15
as 206080D_CS
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.
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