4
\$\begingroup\$

I'm working with an Atmega328P microcontroller. This microcontroller will be generating data and will be storing that data onto an SD card. My project will also be battery powered. My research has shown that writing to an SD card is relatively expensive. Especially due to the fact that I'm using a 225mAH battery with a 120mA limited power regulator.

I've read that a common method for saving power is to buffer write commands into a single write. This seems relatively straightforward.

However, I'm now running into the problem that the Atmega328p only has 2kB of RAM. Thus, I really have limited buffer space.

So my question: would it be a viable technique to purchase a dedicated flash memory / RAM IC to increase buffer space? I'm curious about the practicality of this and how difficult it would be to implement.

Any thoughts? I know the obvious answer would be to purchase a microcontroller with more RAM, but I'm trying to stick with this microcontroller such that the project is Arduino language compatible.

\$\endgroup\$
6
  • 5
    \$\begingroup\$ Staging things through an external memory probably isn't worthwhile, but do look at a better processor with more RAM. The "Arduino language" is not tied to the AVR architecture, though sooner or later you should broaden your horizons anyway. Also, if you only need megabytes and not gigabytes you might consider an SPI flash. \$\endgroup\$
    – Chris Stratton
    Jul 24, 2016 at 21:39
  • \$\begingroup\$ @ChrisStratton Regarding that last comment of SPI flash, I wasn't aware that such a thing existed. And I am only interested in storage on the range of megabytes. This seems like something that could potentially be valuable. Would you still advise against it per your first comment? And for what reason, simply because it would be easier to just go to a different microcontroller? \$\endgroup\$
    – Izzo
    Jul 24, 2016 at 21:51
  • \$\begingroup\$ You'll find affordable MCUs with up to a megabyte or so of internal flash, which they can usually re-write. You'll find easy to work with SPI flashes ranging up to at least 4 megabytes (32 megabits) easy to obtain, and 8 megabyte versions do exist. Above that you get pushed towards parallel NAND which is more of a pain, and SD cards which as a consumer commodity are less predictable (to put it mildly) than bare ICs. My comment was against staging something through one external memory before writing it to another - try to find enough on-board RAM to hold partial blocks internally. \$\endgroup\$
    – Chris Stratton
    Jul 24, 2016 at 21:57
  • \$\begingroup\$ SPI SRAM is also a thing. SD cards are kind of rubbish especially if you lose power during a write. Of you just log every thing to a serial Flash chip that might be most convenient. \$\endgroup\$
    – pjc50
    Jul 24, 2016 at 22:37
  • 1
    \$\begingroup\$ Adding another chip, and then writing to it just to read from it again in order to save some writes to your SD card doesn't seem like the best way to save battery power. Besides the added IC, CPU cycles use power as well. \$\endgroup\$
    – Mark
    Jul 24, 2016 at 22:49

1 Answer 1

Reset to default
2
\$\begingroup\$

I have implemented a system like this. We used non-volatile FRAM as a buffer, but SRAM would work too depending on your requirements for surviving power loss.

I buffered data into the FRAM until it was nearly full. I then wrote it to SD card. To make the system more reliable, I used checksumming of blocks in FRAM. I also wrote all the filesystem metadata from the SD card into FRAM as well. When updates were required, the FRAM was updated first and then copies to the SD card, making updates atomic (i.e. at no time in the process was it possible to lose data or leave the filesystem in a corrupt state). I used a modified FAT32 driver for this, which is unfortunately proprietary code or I would share it.

I found this to be a very efficient method. Although some time is lost to writing data three times (once to the FRAM data buffer, then to the FRAM SD card block buffer, and then to SD card) this was actually largely compensated for by being able to DMA the data out and do other processing in the mean time.

With normal volatile RAM, obviously you can't use it to make writes atomic. However, the buffering is still valuable. In my tests SD cards write significantly faster if you can save blocks of >4kB at a time, ideally 64kB or more. This is likely due to the way their internal flash memory is managed.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.