* NuttX cmake
* px4_macros:Pass the stringified predicate as second arg to static assert
CC_ASSERT mapes to the c++ static_assert or provides the same
funtionality for c via the other macros. The c++ static assert
takes 2 argumants the prdicate and a message. This fixes the
lacking second argument.
* Updated nuttx and apps submodule to upstream nuttx 7.21+==master
This is the latest uptake of upstream nuttx and apps.
* ROMFS generate with xxd instead of objcopy
* delete nuttx-patches
* NuttX update submodules to latest px4_nuttx-master
* fix nuttx apps and board dependency
* docker_run update to latest container 2017-08-29
* cmake ROMFS portable sed usage
* NuttX update submodules to latest px4_nuttx-master
was:<nuttx/arch.h> is:platform/cxxinitialize.h
Removed PX4 version:src/modules/systemlib/up_cxxinitialize.c
in favor of nuttx platform/gnu/gnu_cxxinitialize.c
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.
Daniel Agar