Feature/logging

[ryan-summers]

This PR adds a logging facade for booster. The logger implemented serializes the log and stores it in an internal buffer for later transmission by the serial terminal.

When the USB process eventually executes, logs will be written out over the USB serial port.

This fixes #14

Background

• Implementers of log::Log must be static, which imposes the following design restrictions:
  • Cannot directly contain any RTIC resources
  • Should be const fn to avoid static mut and unsafe access

Heapless Vec::new() is not a const fn, so we have to implement our own minimal vector for data buffering, which is implemented here as the LogBuffer.

[jordens]

Hmm. Ack the static issue.
Doesn't bbqueue or heapless::spsc, mpmc help here (compared to the custom buffer and compared to the potentially long critical sections)?

[jordens]

Doesn't this take quite a while?
It's in a critical section.

[ryan-summers]

This boils down into a copy into the USB serial output port buffer, so the actual blocking time should just be the amount of time to copy the data - the output isn't actually transmitted over USB here.

[ryan-summers]

Doesn't bbqueue or heapless::spsc, mpmc help here (compared to the custom buffer and compared to the potentially long critical sections)?

heapless structures work perfectly here, but they don't provide a const fn constructor, so we can't use them unless we store them in an internal Option and initialize them later (which is a potential path forward).

I think a bbqueue fits our needs, but it won't eliminate the need for critical sections. The problem is that the global logger is being used across multiple contexts (any task that creates a log will then refer to the global logger). Thus, we need to take care about preemption of the write into the queue from a higher priority task. Essentially, the issue is that bbqueue's Producer is not Sync (which implies it is not safe to use the producer across multiple contexts).

The heapless::mpmc does implement Send and Sync, so it is safe to share, but only supports up to 64 elements in the queue. Having a queue of heapless::String would then resolve this issue.

[ryan-summers]

Usage of the heapless::mpmc queue allows us to avoid critical sections entirely here if we limit ourselves to N queued logs, each with a maximum of 128 bytes (which should be fine).