The uavo_handles section is not part of the .data segment so
it doesn't get automatically zeroed during the startup code.
This led to random data being stored in the table which resulted
in bus errors at runtime.
This change ensures that the table is zeroed before we start to
use it.
There shouldn't be any reason to need 8-byte alignment on the
F1 platform. This allows better packing of all malloc'd data.
Reducing this below 4-byte alignment is not recommended and will
likely result in misaligned pointers being passed to peripherals.
RAM savings is another 300 bytes.
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.
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.
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.
The USB VCP Port has a new DebugConsole setting that
routes all output destined for PIOS_COM_DEBUG to the
emulated serial port.
To enable this in your build, you'll have to build like:
- make fw_coptercontrol_clean
- make fw_coptercontrol ENABLE_DEBUG_CONSOLE=YES
You can then output formatted text to the console
like this:
#if defined(PIOS_INCLUDE_DEBUG_CONSOLE)
PIOS_COM_SendFormattedString(PIOS_COM_DEBUG,
"foo is %u\r\n",
foo);
#endif /* PIOS_INCLUDE_DEBUG_CONSOLE */
Please ensure that all of your debug output is
wrapped with these macros so that your debug
code doesn't bloat the firmware image.
Serial ports now have a new HW setting called DebugConsole
which can be used to dump internal state to a serial port
for debug.
To enable this feature, you need to:
- make fw_coptercontrol_clean
- make fw_coptercontrol ENABLE_DEBUG_CONSOLE=YES
- configure one of the serial ports as DebugConsole in the GCS
- save settings
- power-cycle your board
Things to note:
- The console is at 57600,8N1.
- This is not currently configurable via the GCS.
- You can only have a single console enabled at a time.
The SET_LINE_CODING request contains data and must be
handled as such.
Previously, the only requests that had data were IN
requests. SET_LINE_CODING is an OUT request so it
required additional changes to support a new type of
data request.
