Writing Sensor Data to File Leads to Delay Every 4kb (Arduino Nano Connect) #13061
Replies: 4 comments 4 replies
-
Unfortunately this kind of thing is normal with flash filesystems, flash chips are typically arranged into 4096 byte pages internally which need to be erased (slow) before write. You may be able to restructure this to handle the sensor reads in a machine.Timer interrupt, storing into a buffer that the main loop reads to dump to file? You could possibly find a way to connect an SD card too and write to that instead. |
Beta Was this translation helpful? Give feedback.
-
It might work to move the data collection to a thread on the second processor, and push the results to a queue. Then, have the main processor take chunks off the queue and write to a file. I suspect that the second processor won't be held up by the flash write from the first processor. The documentation of the XIP system indicates that it is designed to allow continued instruction reading while a block write is in progress. If you are very lucky, most of the code for the second processor will be sitting in the XIP cache, anyways. |
Beta Was this translation helpful? Give feedback.
-
First: Could this frequency be a problem?
I changed the whole code and created a class for reading the data. The data reading method is called by a timer interrupt (100Hz). Whenever the global variable contains 100 or more lines, it will be written to the file. Unfortunately, the writing process will still slow down the reading every 2 or 3 writings when surpassing another 256 lines = 4096 bytes Interestingly, the timer interrupt will "catch up" and trigger multiple times in a row very fast. I saw this when I printed the cycle time of the data collection to the console: Writing within a 4kb block:
Writing when new 4kb block is created (average cycle time is 12.xx ms for the cycles that are not exactly 10 ms) :
|
Beta Was this translation helpful? Give feedback.
-
you may want to double-buffer the queue, that is, write to the queue as you do, but on the consumer end, pop data off the queue into a secondary buffer, and the write to disk from the secondary buffer. I would also use thread safe locks to lock and unlock the primary queue when you are writing and reading data from it. Since the read and write operations on the queue will be very fast, that should never take enough time to block your data producer. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
I'm reading the acceleration and gyroscope data from the LSM6DSOX-Chip on the Arduino Nano RP2040 Connect and store it in a file.
Since I am also storing a timestamp and another value, it is 6 axes + 2 → 8 values of 2 byte → 16 bytes. Those are saved as a binary file.
Unfortunately, every 4096 byte, there's a ~160ms delay. I think this is when some buffers are full/ emptied.
Probably it's the same problem as the person in this post had.
Is there a way to fix it? I want to save data with 100Hz, but having a delay every 2.5 Seconds screws up the data.
Here's the code (I don't know why i'ts not all in the code block..):
from machine import I2C
from machine import Pin
import ustruct
import utime
import random
`
def collect_data(time_s=10,file_name='file.csv',led=None,button=None):
Beta Was this translation helpful? Give feedback.
All reactions