Telemetry module was iterating over all UAVOs including
meta UAVOs and creating a periodic event item for each
object. These items cost us about 32 bytes for each list
item.
This is wasteful for two main reasons. First, meta UAVOs can't
meaningfully have periodic updates so excluding them entirely
makes sense. That halves the number of objects in this list since
there is one meta object for every data object. This is worth
about 500 bytes of RAM on CC.
Second, about half of the remaining UAVOs are not periodic by
default so they're wasting memory unless someone happens to want
to make them periodic at runtime. This is worth another 450 bytes
of RAM on CC.
So, objects that are configured as periodic during board init will
support all of the periodic config at runtime. Objects that are
*not* periodic during board init can only be made periodic on the
next boot.
Each object that you make periodic during init will cost you an
extra 32 bytes of RAM.
With erased settings, free RAM comparison for CC is:
Before: 2736 bytes free
After: 4048 bytes free
Total RAM savings with this update is 1312 bytes!
When reading the jedec device id the code only transfered one byte via spi leaving
the expected input buffer uninitialized. This may lead to the problem that flash
initialization fails because the expected input may be whatever the stack was set
when entering the function. The impact of the bug is somewhat limited tough as the
initialization usually takes place before starting up the rtos and thus is pretty
deterministic. So if the code passed init while testing it should pass init in
production as well.
This new UAVO serves principally to log data for future comparison with
onboard estimation techniques.
Conflicts:
ground/openpilotgcs/src/plugins/hitl/il2simulator.cpp
ground/openpilotgcs/src/plugins/hitl/simulator.h
Previously, when unconnected, only the flighttelemetrystats
UAVO was Tx'd. All other UAVOs were inhibited. This led to
zero telemetry data when the connection to the GCS was gone.
This precluded getting useful telemetry from a receive-only
station.
This commit changes two main areas.
First, UAVO updates are now allowed regardless of the "connected"
state between the GCS/FC.
Second, it makes both the flighttelemetrystats and gcstelemetrystats
UAVOs un-acked. This prevents these objects from blocking all
other UAVOs while they wait for their ack. This is OK since the
real "connection" negotiation happens via the states exchanged in
the Status field of these UAVOs.
This removes the detailed output of the GCS build by
default so that warnings and errors become more evident.
Full output can be enabled by adding "V=1" to the make
command line. Same mechanism as is used for the firmware
builds.
are downloaded
In the case of a flaky connection this will render telemetry mostly masked
from the activities. However, it ensures that all the information is present
after a connection.
Some compromise is probably needed for using this in the field, such as a
tiered system:
1. Physical channel open (no idea about reception)
2. Link estabilished (at least some reception)
3. Full telemetry established (all objects synced up)
We allow sending objects that don't create a transaction while waiting for one
to complete. However, this was overriding the pending transaction information
(when there wasn't a new transaction) and masking the transaction completed
message.
Note: I think this logical error can occur on the GCS side and might explain the
"transaction completed when not expected" messages.
