Thanks to a Raspberry Pi forum post about increasing performance and not losing data, I’m starting to seriously consider swapping to using the inbuilt FIFO for gathering data.

The plus side is no data is lost or corrupting, and as a result, there is no need for strict timing – that’s defined by the configured sampling rate.

The down side is it means I discard all performance code I wrote for catching the data ready interrupt, and reading the data registers – I’ve invested a lot of blood, sweat and tears to optimize that code šŸ™

The FIFO would work roughly like this:

  • the data sampling rate would be set to 1kHz like now.
  • every 10ms, read the FIFO byte countĀ register – the 10ms isn’t time critical, it’s simply to allow the FIFO to fill with roughly 10ms of data but this would be batches of ten of more sets of data
  • read the FIFO based upon (FIFO byte count % 12) – 12 bytes is the gyro and accelerometer readings fed into the FIFO
  • run motion processing over whatever size that batch of data isĀ – timing is inferred from the sampling rate and the number of 12 byte batches read from the FIFOĀ – the FIFO continues to fill in the background.
  • repeat

There will be some faff flushing the FIFO at the right points but otherwise, I don’t think the code changes will be hard, though they will be extensive.

This avoids all the major flaws I’m currently handling, providing RTOS quality timing for the data, with zero risk of sample misses or data corruption. Ā I’m certain it will all just work. Ā But I am mourning the loss of the need for the data interrupt code I spent time enhancingĀ šŸ™

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.