Flash Storage nRF52832

[connorshannon]

Hello,

I'm using an nRF52832 and an accelerometer/gyro to record data and send it over Bluetooth. My end goal is to store this data in large chunks, and then send it all at once (as opposed to collecting data and immediately sending it over Bluetooth). I'm not quite sure what the best way to do this is. From what I can tell, FDS is something that might work for what I want, but I can't find sample code that implements it. 

I suppose my questions are these:

1. Is FDS likely the best method of storing data, retrieving it, and writing over it again for this chip?

2. If so, where would be a good place to start as far as sample code or documentation for this? Everything I find seems to be outdated or uses a different method to store data in memory.

Thank you!

[connorshannon]

Thank you, this answer was exceptionally helpful. I do plan on using ring buffers, and am in the midst of figuring out the best way to make the largest buffer possible (given the amount of available RAM). I have a discussion post about this here, but I thought I would keep this thread open in case you have any insights on the best way to do that.

[tesc]

Hi,

I'm afraid I don't have any specific hints or tips regarding ring buffers, other than the ones already given to you in the other thread and in the documentation.

However, regarding data rate, please note that the 2M PHY does not provide 2 Mbps payload throughput. There is overhead for any data transmission, including for BLE. For instance, during connection events packets are sent back and forth both ways between central and peripheral, leaving only half the time for transfers in one particular direction. In addition, there are short pauses between each back and forth, and there are pauses in-between connection events.

To minimize overhead, and maximize throughput, in addition to using 2M phy, you should increase ATT MTU size and data length. See Optimize the connection for throughput - NUS throughput example for details.

Depending on your use case and surroundings, 448,000 bps (i.e. around 450 kbps) should typically be achievable, but not necessarily with default data length, ATT MTU size, connection event length and connection interval.

Please note that if throughput is too low, any ring buffer will fill up regardless its size. Therefore, the most important part of your design, is to make sure that you are able to consistently send data at preferably a somewhat higher rate than produced. The size of the buffer will mostly depend on the jitter (variability in throughput, so that you get occasional bursts of data build-up (producing faster than you can send/consume) and occasional bursts of sending more than is produced (to reduce the amount of buffered data again.))

Regards,
Terje

[hmolesworth]

One other thing to keep in mind, in case it was overlooked: each 0x1000 byte FLASH page is divided into 8 x 0x200 byte blocks. Best to minimise the number of writes to each block, ie suggest buffer 512 bytes in RAM prior to the sequence of 32-bit word flash writes.

"The same block in the Flash can only be written nWRITE number of times before an erase must be performed using ERASEPAGE or ERASEALL"

nWRITE = 181 on the nRF52832, so 128 x 32-bit writes is ok but not 512 x incremental byte writes using '1's for unused bytes. No information is available on pattern sensitivity on adjacent blocks.