this module is very software and may be quite rtos heavy. Which is cool! But also it's mostly complete from last year, though there is definitely room for improvement and optimization which looks like an interesting problem. Not too many ppl needed for this one
Responsible for processing log messages from all modules and outputting those to SD card. The design follows similar to CAN Logger board, which holds messages in rotating buffers and outputs full buffers to SD card. The challenge with processor is our logging rate is like 50x faster - we write a LOT of logs, and write in string format, and it includes floating point numbers which are slow to process. This module needs to be optimized for speed and reliability! Last year’s went through a few designs for handling the buffers; early designs made logInfo() calls wait in line to write to the buffer, so each message was snprintf’d into the buffer back to back. We noticed that snprintf() was bottlenecking speed, so the latest design mitigates that by dividing each buffer into equal sections. Then, each logInfo() claims a section to own it, allowing logInfos to concurrently write to their own section.
Components:
Process any incoming log message into the output buffer (LogGeneric())
Task for processing full buffers
dump a buffer to arbitrary output (ie., SD card for production, UART for testing via console, or any other output that could be added in the future. Future-proofing is a good design principle)
Interface:
Log_Message(msg string): Any module can use this to write a log message.
Things to figure out:
Investigate logging speed properly through experiments. (This was descoped last year due to time and the person working on logging being 7 hr away on coop.) How fast does snprintf go on this MCU? We were very conservative with this estimate last year. I think it’s a lot faster than we thought.
SD Card module will be in charge of: How fast can we write to SD card? Is there an optimal buffer size for each SD card write?
From information about the speed, figure out best way to fill the buffer. The method using sections wastes space because most messages don’t fill their whole section, leaving unused bytes!! Is this a concern? Or is it worth the tradeoff of ensuring no overwriting? (owning a section is easier to be safe than writing messages tightly back to back).
From that information, also determine max logging rate so we know how much we can afford to log. This matters for spamming state estimation logs as fast as possible.
How to handle logging debug/testing msgs vs real msgs? Should we even bother distinguishing those?
look into log levels? is it worth separating beyond logInfo, to have logError etc
Last year logger implements a hacky time delay in the task because of a possible edge case (see code for details). how to avoid this? could use a counter or smth to make sure all log calls finish writing before dumping the buffer. counting semaphore maybe? or just a variable
see #5
this module is very software and may be quite rtos heavy. Which is cool! But also it's mostly complete from last year, though there is definitely room for improvement and optimization which looks like an interesting problem. Not too many ppl needed for this one
Responsible for processing log messages from all modules and outputting those to SD card. The design follows similar to CAN Logger board, which holds messages in rotating buffers and outputs full buffers to SD card. The challenge with processor is our logging rate is like 50x faster - we write a LOT of logs, and write in string format, and it includes floating point numbers which are slow to process. This module needs to be optimized for speed and reliability! Last year’s went through a few designs for handling the buffers; early designs made logInfo() calls wait in line to write to the buffer, so each message was snprintf’d into the buffer back to back. We noticed that snprintf() was bottlenecking speed, so the latest design mitigates that by dividing each buffer into equal sections. Then, each logInfo() claims a section to own it, allowing logInfos to concurrently write to their own section.
Components:
Interface:
Things to figure out: