Raw Datalogger (For BLTPLANE)

[cowsed]

(go look at #340

Description

Filesystems are normally not used in flight software applications for a number of reasons (non-determinism, limited resources, corruption risk, etc.). Even though LittleFS mitigates a few of these issues, having it can still be non-deterministic and files were still corrupted in sensor module from its last flight. This made it difficult to try and recover flight data. By doing raw logging, we can just dump the flash contents and identify where log files are located easier.

This new system will log data raw to the flash chip. There are several modes

• Fixed: Once a log is written to the limit, it will no longer write
• LinkedFixed: Same as fixed, but new log sections can be created and the metadata will point to the address of this next section. (Think of a linked list). The new section will be placed in the next free space found that meets the requested file size set by the user
• LinkedTruncate: Same as LinkedFixed, but the new section will be placed in the next free space found regardless if the size is less than requested.

Each log file starts with a 32 byte metadata structure. This includes a

• 16 character log name
• 4 byte hash of the log name to validate we are reading metadata
• 1 byte version for the file in the event we make a breaking change
• Packet size so we know how many bytes to read per packet
• Allocated size for the file, which is useful for skipping past the file
• Next log address for linked modes

Note: There will definitely be improvements/changes that would need to be made to this as this gets integrated into actual flight applications and edge cases are caught for running our use cases. Still need reading capabilities as well. Planning a wrapper as well for persistently caching where logs are located.

Type of change

• New feature (non-breaking change which adds functionality)

How Has This Been Tested?

Ran sample through native_sim testing the different modes and hexdumped the flash binary

Checklist:

• New functionality is documented in the necessary spots (i.e new functions documented in the header)
• Unit tests cover any new functionality or edge cases that the PR was meant to resolve (if applicable)
• The CI checks are passing
• I reviewed my own code in the GitHub diff and am sure that each change is intentional
• I feel comfortable about this code flying in a rocket