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.
