Message passing between subsystems: architecture?

[gauteh]

The main CPU needs to organize:

• The notecard with cellular connection, which is responsible for sending data back home and for reading GPS positions
• The IMU which read accel and gyro and stores in kalman filter, and the part that processes and prepares the data packages for the notecard.

In order to keep the notecard off as much as possible we need to cache the data locally. We should also not process data more than necessary, so the read values should be buffered before processing.

We need to pass the information back and forth and I am thinking that maybe the following setup is a good compromise:

Setup the following queues

Notecard

• log messages (for diagnostics, power-up, errors, whatever), should be low volume and also not critical
• critical data-messages (gps, processed IMU data)
• additional data-messages (time-series)

IMU

• Readings from interrupt handler (DRDY, or FIFO if that is possible)

IMU processing

• Ready batches of data

The main routine needs to

• Collect and pass around messages from queues rapidly enough: this can be done by, RTC interrupt + WFI. The DRDY interrupt will also probably wake-up the CPU from wfi.
• Check for critical tasks and call critical handlers on subsystems. The subsystems should probably only handle one event per call, and return a flag as to whether there are more pending events.
• Once all critical tasks are done, do the non-critical.
• How do we handle non-critical tasks becoming critical (most prominently: a buffer or queue filling up!)
• Feed the watchdog.

At some point this approximates RTIC (https://rtic.rs/0.5/book/en/), at which point it would be better use it directly.

@jerabaul29: These decisions would be great to have your view on. If there's a chance that this setup might be useful in a future common firmware for the buoys at MET maybe you'd like to be involved in how this is implemented. There is probably significant overlap in theory and principle of operation between the latest platform-io version, so the approach tested out here and there will be valuable experiences whatever the final version looks like. Let me know if you have time for a chat.

[jerabaul29]

Sorry, I had missed this issue. We can discuss this next time we have a chat if you want :) .

[gauteh]

No I think we had a discussion several days ago about this. Anyway, I have a simple solution for now.