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)
boards define BOARD_NAME, so board_name() is not necessary. HW_ARCH was
just a wrapper around board_name().
This patch simplifies to having only one common method px4_board_name().
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.
The Nuttx CAN driver is not used with UAVCAN. However to
facilitate compilation to allow the Nuttx CAN Example to be
compiled and linked, the missing proto type was needed.
Futhermore to include the NuttX CAN eaxample the following changes
are needed:
1 ) In cmake/configs/<target>.cmake
Add can to config_extra_builtin_cmds as:
set(config_extra_builtin_cmds
serdis
sercon
can
)
Add:
add_custom_target(can)
set_target_properties(can PROPERTIES
PRIORITY "SCHED_PRIORITY_DEFAULT"
MAIN "can" STACK_MAIN "2048"
COMPILE_FLAGS "-Os")
2) Update the nuttx-configs/<target>/nsh/defconfig
Run make oldconfig and make menuconfig and set the follwoing:
CONFIG_CAN=y
CONFIG_STM32_CAN1=y or CONFIG_STM32_CAN2=y
CONFIG_CAN_EXTID=y
CONFIG_CAN1_BAUD=250000
CONFIG_CAN_FIFOSIZE=8
CONFIG_CAN_NPENDINGRTR=4
CONFIG_EXAMPLES_CAN=y
It makes more sense to set the optimization flags on a platform basis
instead of individually for each module. This allows for different
optimization options for SITL, NuttX, Snapdragon, etc.
the value '1000' is not really magic, and it was resulting in sending
a single 1ms pulse on all IO channels for a brief instant on
startup. With some servos this led to the control surfaces being at
extremes (and straining) on startup. It may also contribute to making
ESC calibration harder on multi-rotors
In the worst case it could cause a IC motor with reverse throttle to
go full throttle on startup
A logic analyser shows the problem very clearly. Changing the
default_value fields to 0 from 1000 fixes the issue and no pulses are
generated until an explicit value suitable for the airframe is
provided via one of the many methods PWM output values can be
generated
Conflicts:
src/drivers/boards/px4fmu-v4/px4fmu_pwm_servo.c
src/lib/ecl
Since mtd already checks whether CONFIG_MTD_RAMTRON is set in
defconfig use this define to check whether to call ramtron_attach()
or at24xxx_attach() in the main function, instead of checking
CONFIG_ARCH_BOARD_PX4FMU-V1.
Also instead of using #ifdef CONFIG_ARCH_BOARD_AEROCORE to determine
whether to start mtd on spi 2 or 4, rather use a new board define
PX4_SPI_BUS_RAMTRON in the board_config.h file.
Beat Küng