This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Multithreading on nrf9160

Hello Nordic gang.

I'm reading sensor data on the nrf9160DK, the sensors have a fifo with 96 entries. If I can't read the sensors fast enough, the fifo overflows and I get data loss.
The sampling rate is 4000 SPS and the sample size is 64bit. Therefore, there is not enough RAM to hold data and there is a need of continuously writing data to memory.

Now, I have integrated a micro sd card, it writes fast, faster than the external flash. If I do a measurement of 20 seconds, sometimes there is no fifo overflow but sometimes there are 2-3 entries being lost during the recording. I find it interesting that it is inconsistent.

However, it is extremely close to being fast enough, and sometimes it actually is. Now, as for solutions I've been considering multi-threading.

The write speed is fast enough and the fifo queue is decreased to its lowest value but then we reach entry #64, there is a delay. I'm guessing this has to do with the cluster or page size of the FAT32 format and the allocation of new memory units takes a bit of time. Every multiple of 64 there is a delay. Each entry is 64 bits so it's every 4096 bits this occurs.

Sometimes this resizing makes the queue overflow but not always. Sometimes it goes from 0 to 40 entries in the fifo, which is fine, other times it goes from 0 to 96 and we have data loss. I thought that maybe you could multithread this so that during the write, we still take down data from the fifo and store it in a variable until the write function is done, thus ensuring there is no data loss. Would this be possible? If so, how is it implemented in code?


I've been using fs_write when writing to a file on the sd card.

Edit: The idea I had was to implement a fifo structure where data from sensor is continuously added and written to memory. Thus, under cluster allocation delay, the fifo grows while waiting for the sd-card.


Thanks for brainstorming with me

Warmest regards

nWre

Parents
  • Hello nWre,

    If I understand the issue correctly, you are poking the limit of the sd card communication, because of the rate of which the data is coming from your sensor, right?

    Have you considered/tried to either:

    Increase the SPI speed (I assume that the SD card reader uses SPI or TWI (I2C)? Is it possible to increase the clock speed of that peripheral?

    Buffer up more data before you write to the SD card. Larger chunks means less overhead with the communication with the SD card.

    Perhaps one of the two can get you below the threshold, so that you can keep up with the sensor data?

    Best regards,

    Edvin

Reply
  • Hello nWre,

    If I understand the issue correctly, you are poking the limit of the sd card communication, because of the rate of which the data is coming from your sensor, right?

    Have you considered/tried to either:

    Increase the SPI speed (I assume that the SD card reader uses SPI or TWI (I2C)? Is it possible to increase the clock speed of that peripheral?

    Buffer up more data before you write to the SD card. Larger chunks means less overhead with the communication with the SD card.

    Perhaps one of the two can get you below the threshold, so that you can keep up with the sensor data?

    Best regards,

    Edvin

Children
  • Hi Edvin! I'm running SPI at the highest possible speed. I thought about larger chunks but wont there still be a resizing problem once the page size is reached? Writing 8 bytes at a time is fast enough, it is just the page resizing that slows it down. I will of course try this and get back to you.

    The question of multithreading is still relevant for me though as when data is recorded and saved, I then need to send this via FTP so server. During the transmission of this, I still need the sensors to be active and ready to record in a triggering event, that is, the system can't be occupied fully if you understand what I mean.

    Thanks for the help!

  • I don't think I understood that part about resizing. Can you please explain what you mean by that?

    nWre said:
    The question of multithreading is still relevant for me though as when data is recorded and saved, I then need to send this via FTP so server. During the transmission of this, I still need the sensors to be active and ready to record in a triggering event, that is, the system can't be occupied fully if you understand what I mean.

    What triggers the reading from the sensor? Is it triggered from the sensor, or from your software?

    Either way you want the thread handling the sensor's interrupts to be running at a high priority. The transmission of the data to the server is will happen on the modem core, which will not be interrupted. 

    Best regards,

    Edvin

  • Hi again Edvin! Sure, I drew a picture that might explain it better.
    Is there an example of running threads with prio and datatransfer like you described?
    As shown in the picture, at multiple of 4096 bits, there is a delay using fs_write. I'm thinking this might be because of the page/cluster size of the fileformat fat32 but I'm not sure. I formatted it with 32kB cluster size so it might rather be a different problem entirely.

  • nWre said:
    there is a delay using fs_write

    Is the delay caused by the call to fs_write(), or do you call fs_write all the time, and every 64 samples fs_write() takes longer than usual?

  • I call fs_write all the time, and every 64 samples fs_write() takes longer than usual. That is why I'm thinking of allocation of new memory space. I'm using a 32gb sd-card because that is what I had on hand but a 2gb would do just fine. I ordered one (hard to find a 2gb sd-card in modern times haha) to see if maybe that speeds things up a bit.

Related