1

I want to use an SD card and when including the library both SPI.h and SD.h are included. Also later I want to use an external SRAM chip (probably using SPI.h as well). However, without the SRAM chip my sketch uses around 849 bytes of global memory, where I expect most of it taken by the SD.h / SPI.h combination. Without these includes only 9 bytes are used.

How can I reduce the amount of global memory (still I want to use the SD and SPI interface)?

Edit:

According to a remark below 512 bytes are used for the SD so that explains mostly of the 849 bytes. And some additional questions:

Is it possible to reduce the 512 bytes for the SD card to much less like 16 bytes ...I only need to read a file (128 KB) and copy it to an SRAM (external). And I don't mind if it will be transferred in 16 byte blocks. Actually, I could get rid of the buffer at all after the SD to SRAM copy.

My ultimate goal is to leave 1KB + some dynamic memory (for function call stacks/local variables). However, finally I need to move to the Arduina Mega anyway, but was hoping I could already start the project with my Arduino Uno.

Improve this question
6
  • 2
    First you need to understand the terms and measurements. If your memory "usage" figure comes from the Arduino IDE, then it does not include dynamic memory at all. Only a very careful modeling or output from actual execution could measure that. In terms of the static allocations you are probably measuring, buffers would be a likely suspect, not only for the those libraries, but also if you make use of Serial, etc. If you want more precise control or optimization you may need to replace libraries with your own tuned code.
    – Chris Stratton
    Mar 17, 2017 at 3:27
  • Sorry with dynamic memory I mean the SRAM usage internally within the Arduino Uno. The global data is 849 bytes. And the remainder (1150 bytes or so) is used for dynamic allocation.. And yes, the buffers is indeed something that needs to be tweaked. What would be the best way? To copy the library files to be changed within the project and use those instead of the original ones... I don't like the change the generic library files since it will affect all projects I might do in future.
    – Michel Keijzers
    Mar 17, 2017 at 9:33
  • 2
    What is your ultimate objective? At present you are using less than half the available RAM. What is the problem exactly? Any SD card interface is likely to require a disk buffer (probably 512 bytes) so you won't get much below that.
    – Nick Gammon ♦
    Mar 17, 2017 at 10:49
  • Thanks for your good question and remark about the SD buffer. I will edit the question.
    – Michel Keijzers
    Mar 17, 2017 at 10:56
  • 1
    Note that there are various ARM chips that cost no more than an ATmega but have substantially more RAM. Some of them even have Arduino ports of various maturity.
    – Chris Stratton
    Mar 18, 2017 at 0:02

1 Answer 1

Reset to default
1

Is it possible to reduce the 512 bytes for the SD card to much less like 16 bytes

The Arduino SD library uses an internal file block caching (512 bytes) to improve performance. It is possible to read directly from a file block on the SD but that would be very slow. Every 16 bytes read would require reading from file block, discharging all preceding bytes (as the file block is read serially), reading the 16 bytes, and then stopping the block read.

There are a few tiny SD libraries that actually use this technique. See for instance Petit FAT File System http://elm-chan.org/fsw/ff/00index_p.html

Another technique is to block copy from the SD directly to the external SRAM without going through additional buffers. This requires a refactoring of the SD library so that it uses a callback instead of the internal buffer.

Cheers!

Improve this answer
3
  • Thanks for the answer. In that case I will keep the 512 bytes (it shouldn't be a sub-project just to overcome this problem. However, if the Petit FAT works, maybe I can use it temporarily. The last sounds interesting, but might be a bit tricky but workable. Or maybe I try to dynamically create the 512 byte buffer and just remove it after use (which is after the copy).
    – Michel Keijzers
    Mar 17, 2017 at 15:49
  • 1
    To allow BMP images (from SD) to be written to LCD without a lot of buffer copying I introduced a callback in the Cosa Canvas handler in the form of a virtual member function. Please see github.com/mikaelpatel/Cosa/blob/master/libraries/Canvas/… for an example.
    – Mikael Patel
    Mar 17, 2017 at 15:56
  • Thanks, I will take a look into that, very nice to have an example, it might be similar with buffer copying to an SRAM
    – Michel Keijzers
    Mar 17, 2017 at 16:27

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.