What is the best way to store > 40K of data on nRF52832 before it can be processed?

We have sensor data coming at regular interval of 40B at 10msec interval. We need to collect it for a minimum of 10 sec before we can process it and then reuse the same buffer/memory location to write new set of data.

50% of flash and ram is already being used by code itself.

What's the best way to store this?

Parents
  • Hi

    Unfortunately this does not sound doable unless you scale down the amount of data you plan on storing. 

    The time it takes to write a word to the Flash is specified by tWRITE, and the CPU is halted while the NVMC is writing to the Flash. tWRITE for one word (32 bits) is 67.5-338 µs. And thus ~10 times that if you want to write 40 bytes I guess, which does not fit very well in your case.

    Multiple threads will indeed require you to store even more data. Again, I think it wouldn't be a problem on a larger device, but I guess that's not a solution here. Then I think you need to scale back the amount of data you store before transmitting it. If your entire application takes up ~50% of the RAM you should have ~30 kB of data available safely I guess. I wouldn't push the limit much further than that.

    Best regards,

    Simon

Reply
  • Hi

    Unfortunately this does not sound doable unless you scale down the amount of data you plan on storing. 

    The time it takes to write a word to the Flash is specified by tWRITE, and the CPU is halted while the NVMC is writing to the Flash. tWRITE for one word (32 bits) is 67.5-338 µs. And thus ~10 times that if you want to write 40 bytes I guess, which does not fit very well in your case.

    Multiple threads will indeed require you to store even more data. Again, I think it wouldn't be a problem on a larger device, but I guess that's not a solution here. Then I think you need to scale back the amount of data you store before transmitting it. If your entire application takes up ~50% of the RAM you should have ~30 kB of data available safely I guess. I wouldn't push the limit much further than that.

    Best regards,

    Simon

Children
No Data
Related