Concurrent logging

[celery6]

maybe this speeds up logging idk

the concept is to split each log buffer into n sections, where each section will be handed off to tasks to write in. When a task uses logInfo, logger calculates the next free section and gives it to the task. No other task can have this section. Now multiple tasks can write to their own sections concurrently.

The downside is that most msgs do not fill the entire section, so there's a LOT of empty space. We should optimize the size of sections to be as small as possible. Possibly break up the VN log msgs into multiple msgs because that's constraining the section length requirement rn.

Other downside: buffers fill up a lot faster so it dumps to SD card more frequently. Probably not issue cuz SD card write speed is not a bottleneck.

---

things to test:

• run the program for a while
  • breakpoint somewhere in log.c and verify these counters inlog.c` are all 0
  • also breakpoint in vn_handler.c here to check the values of diff1, diff2, pass1, pass2
• open the log file from the sd card and verify every line logged is padded to the same alignment with * characters like the screenshot:

[Joe-Joe-Joe-Joe]

closes #40

[Taggagii]

The diffs are 0. If I increase the tick rate to 10000 the diff values are like 3-6. And also the logging is passing. However the log file is not being padded (see attached picture). Otherwise it appears to be working

[Joe-Joe-Joe-Joe]

not sure what Josh means by tick rate. but this is what I got. A bunch of trailing null characters for a bunch of messages until precisely 3 seconds in when the logs shit themselves and then start padding properly

but this is what I really care about Pretty sure you can't "safely" increase the tick rate (assuming you mean of freeRTOS) above 1000, at least according to the ioc file tooltip. But I can log arbitrarily sized buffers at this speed so I am happy