Instead use a single timestamp for subscription checks. This frees up
~800B of RAM.
Also make sure the subscription checks are distributed over time. On each
update, at most 1 topic subscription is checked. Reduces the load of the
logger from 7.3% to 5.8% (Pixracer)
ulog_message_info_header_s *msg = reinterpret_cast<ulog_message_info_header_s *>(buffer);
members of msg could end up unaligned, because of the uint8_t buffer.
_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.
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.
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.
Beat Küng