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.
This patch reorders px4_defines.h to make it more readable (I think)
but more importantly, cleans up the #include <math.h>/<cmath>
and [std::]isfinite stuff.
My main goal was to completely get rid of including math.h/cmath,
because that doesn't really belong in a header that is supposed to
define macro's and is included in almost every source file (if not
all).
I'm not sure what it did before ;) (pun intended), but now it does
the following:
PX4_ISFINITE is only used in C++ code (that was already the case,
but hereby is official; for C code just use 'isfinite()') and is
defined to be std::isfinite, except on __PX4_QURT because that uses
the HEXAGON toolset which (erroneously) defines isfinite as macro.
I would have liked to remove PX4_ISFINITE completely from the code
and just use std::isfinite whereever that is needed, but that would
have required changing the libecl submodule, and at the moment I'm
getting tired of changing submodules... so maybe something for the
future.
Also, all includes of <math.h> or <cmath> have been removed except
for __PX4_NUTTX. Like the HEXAGON toolset NuttX currently defines
isfinite as macro for C++. So, we could have solved this in the
same was as __P4_QURT; but since we can fix NuttX ourselves I chose
to add a kludge to px4_defines.h instead that fixes this problem,
until the time that NuttX can be fixed (again postponing changing
a submodule). The kludge still demands including <cmath>, thus.
After removal of the math header file, it needed to be included
in source files that actually need it, of course.
Finally, I had a look at the math macro's (like M_PI, M_PI_F,
M_DEG_TO_RAD etc). These are sometimes (erroneously) defined in
certain math.h header files (like both, hexagon and nuttx).
This is incorrect: neither the C nor the C++ standard defines
math constants (neither as macro nor otherwise). The "problem"
here was that px4_defines.h defined some of the M_*_F float
constants in terms of the M_* double constant, which are
sometimes not defined either thus. So, I cleaned this up by
defining the M_*_F math constants as float literals in px4_defines.h,
except when they are defined in math.h for that platform.
This means that math.h has to be always included when using those
constants, but well; not much difference there as those files
usually also need/use the macro NAN (which *is* a standard macro
defined by math.h).
Finally finally, DEFAULT_PARAM_FILE was removed as it isn't
used anymore.
All in all I think the resulting px4_defines.h is nice, giving me
much less the feeling of a nearly unmaintainable and over time
slowly growing collection of kludges and hacks.
_baro_topic can be null in init sequence
init call collect before the topic is inited.
I think this pattern is repeated in other drivers. I would suggest
allowing null in orb_publish to just return.
app.h, generated from app.h_in, has unnecessary code duplication
and isn't a header file (it defines globals, static functions
and doesn't have a header guard, moreover, it has a 'using namespace
std;'). Because of this, a real headerfile that declares the stuff
defined in apps.h was missing leading to even more code duplication:
scattered forward declarations in .cpp files and an often repeated
type of std::map<std::string, px4_main_t>.
This patch moves cmake/qurt/apps.h_in to src/platforms/apps.cpp.in
(with some changes) and removes cmake/posix/apps.h_in.
Then src/platforms/apps.cpp.in is split into src/platforms/apps.cpp.in
and src/platforms/apps.h.in, splitting declarations from definitions.
A typedef is defined for the map (apps_map_type).
The main difference between cmake/posix/apps.h_in and
cmake/qurt/apps.h_in was that the first defined a global 'apps',
while qurt stores the apps in QShell. I opted to get rid of
the global variable (which are in general evil for various reasons)
and used the API of cmake/qurt/apps.h_in where a provided 'apps'
map is initialized with a call to init_app_map. Thus removing
the existing code duplication.
The packet_count was actually an error_count, therefore we should
process RC input only when the error_count since the last packet is 0.
Also, this commit fixes the RSSI scaling for st24.
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
The integrators were set to publish at 800Hz which was overwhelming
the CPU with the EKF running. This brings them in line with what we
get from the MPU6k device.
- avoid dividing by zero when calculating max delta output
- better comments when calculating max delta output
- better naming of functions and variables
Signed-off-by: Roman <bapstroman@gmail.com>
Henry Zhang