Fixes to LiveLogTick function, memory bounds checking, and optimizations to save memory space requirements in the firmware #285
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
After some discussion with @ceres-c summarized in #284 (with possible build configuration solutions in #283), the standard firmware binary that resulted before used too much memory. This seems to be the cause of several recent issues and unpredictable crashes running the firmware. I looked at this today and found some fixes that help. Note that with these changes the newly compiled binary yields:
The last numeric column is noted to not exceed
0x10000
.A complete summary of all the changes contained in this pull request are given below:
malloc/free
. This is typically not good practice on memory constrained devices, and pulls in extra memory requirements. I rewrote the core of theLiveLogTick.h
sources to store the linked list node structures in theLogMem
buffer (along with the temporary contents of logs). The solution removes the need for the dynamic memory alloc/dealloc functions from GLibC. It also seems to fix some oversights in the original code based on testing. Notice that every position for the structure pointer addresses needs to be an even multiple of four.MemoryReadBlockInSetting
andMemoryWriteBlockInSetting
that tag implementations can call to safely write to the FRAM space for their slot. These check an upper bound on the size of the block address, and add an offset into FRAM based on the slot index. In contrast, the original two functions do not ignore unintentional memory boundary errors and do not shift the block address by the slot index offset.FLASH_DATA_SIZE
option reflects the noise and discussion from yesterday. Nothing fancy, just compiler optimizations to make the memory imposed on the AVR less bloated.