Most of the incompatitbilities are luckily similar to the darwin build.
- New target OS __PX4_CYGWIN added because in other build environments on Windows defines will very likely be completely different
- added all necessary exeptions to the defines
- disabled priorities completely because on Windows they are defined 1-32 and with all the arbitrary +40 -40 priority settings there were a lot of problems
not only did some threads/"virtual tasks" not start because of out of bound priorities but also the resulting scheduling was totally random and inadequate
with default priorities it ran toally fine during my first tests, should be rethought when windows is used onboard in the future
Update the model for the standard configuration based on the model from Sensirion and add also an option to do the tube pressure loss correction from Sensirion for other configurations.
* 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
param save is an expensive operation that can take several 100ms. And
previously it was possible that a param_get() caller was blocked on a
save operation. If this happened due to a param change notification,
important modules, such as sensors, could have been blocked for a longer
period (and affecting the flight performance).
With this patch, this situation is not possible anymore, because a param
save now uses the reader lock and a separate file lock.
However it is still possible that a param_set() needs to wait for a save
operation, thus blocking for a longer time. param_set() thus needs to be
avoided in important modules when the system is armed.
In the case of mavlink it works, since it does not affect the flight if
the mavlink receiver is blocked over a longer time. It is only problematic
if a joystick is used as input or in offboard control.
And the maximum number of configured file descriptors.
Note that this is per group, not per thread, so that e.g. logger and
log_writer_file show the same number.