_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.
fixes a 'test: syntax error' message on startup. There were two problems:
- the expansion of $MAVLINK_F lead to multiple arguments in the test
when the variable contained spaces. Fixed with ""
- the x prevents interpretation as a unary expression, if $MAVLINK_F starts
with a - character (in that case the expansion would be:
if [ -r 1200 ... and nsh interprets - as unary expression)
This limits the maximum bandwidth of ulog streaming to 70% of the specified
mavlink datarate. If less is used, the leftover is assigned to the mavlink
streams, if more is used, it starts to drop.
mavlink status outputs the currently used rate, to check if a link is
saturated.
tested on Pixracer: 14 still produces some dropouts once in a while, but I
think it's a fair tradefoff between RAM usage & dropouts. The queue needs
about 3.5KB of RAM.
When topic sizes/logging rates change, this will have to be reevaluated.