Free up some RAM - Githubissues

We are tight on memory! With WAAS etc coming, we need to make room.

Some ideas:

Each ephemeris is 168 bytes, we have 2 * 32 of them = more than 10 kB. Figure out how to avoid having two copies for the trusted/untrusted thing. Allocate just one ephemeris per tracking channel, and archive them to flash so they can be reused if still valid when a channel is initialized.
Nav bit handling also wastes some space having the separate buffers for raw nav bits and then the same bits split into subframe words. It's messy anyway and needs an overhaul.
4 kB buffers for each of 3 UARTs, necessary?
Some threads have working areas larger than might be necessary. e.g. system_monitor, {acq,track} management
SBP thread has to have a large working area because of expensive activities conducted in callbacks. Make the callbacks slimmer, posting larger work chunks to be serviced asynchronously -> also reduces necessary UART buffers.
The simulator uses a few kilobytes. Is it worth keeping? In its current form? Could we offload some of it to pregenerated output streams stored in flash?
Aside from the hypothesis memory pool, why exactly does all the RTK stuff need so much bss and stack? Any tractable way to reduce it?

Also, in the next hardware rev let's get more RAM and a memory protection unit.

cc @gsmcmullin @fnoble

swift-nav / piksi_firmware