💾SDVirtualRAM – Use Your SD Card as Virtual RAM on Arduino

Hello Makers! :waving_hand:

We all know the pain: Arduino boards (like UNO, Nano, Mega) only have a few KB of SRAM, which makes handling large buffers, logs, or binary data really difficult.

To tackle this, I’ve created a new library:
:backhand_index_pointing_right: SDVirtualRAM

:sparkles: What it does

  • Turns your SD card into virtual RAM

  • Supports random-access read/write at byte or block level

  • Works with SdFat library (fast SD handling)

  • Default VRAM size: 256 KB (configurable)

  • Includes formatting support (reset VRAM file instantly)

#include <SDVirtualRAM.h>

SDVirtualRAM vram;

void setup() {
Serial.begin(9600);
if (!vram.begin()) {
Serial.println("Failed to init SD Virtual RAM");
while (1);
}

vram.writeByte(0, 42);
Serial.println(vram.readByte(0)); // prints: 42
}

`void loop() {}``

:hammer_and_wrench: Use Cases

  • Storing sensor logs without eating SRAM

  • Handling image/audio data buffers

  • Retro-computing projects needing RAM expansion

  • Data caching for long-running projects

:light_bulb: Why share here?

I’d love feedback from the community:

  • Does this solve a problem you’ve faced before?

  • What potential applications do you see?

  • Any ideas for optimizations (caching, wear leveling, multi-file VRAM, etc.)?

Repo link: GitHub – SDVirtualRAM

Cheers! :rocket:

Because your topic does not indicate a problem with IDE 2.x it has been moved to a more suitable location on the forum.

1 Like

I think my concept of VRAM is different. The code displayed looks like you just renamed SD... to vram...
In any virtual RAM OS I have used, I just used RAM freely, and if it ran out, it was paged out to some sort of disk.
Perhaps you need to rethink the name?

1 Like

i have written it to use some of the SD storage to be used as chunked page files, and the rest is for non-volatile storage purposes. Though I would really appriciate if you do check it on my GitHub profile

You should really test first.

1 Like

Hi @saikat123x. I see you have removed the library code completely (I guess only temporarily while you work on the problem reported by @sonofcy), but I'll provide some explanation of what was wrong with the structure of the library files prior to their removal.

We can see the library as it was when @sonofcy attempted to install it here:

There are two problems:

Location of Library

The library is in the SDVirtualRAM subfolder of the repository:

It should be in the root of the repository, here:

So everything needs to be moved up one folder level.

This is useful for manual installation as it allows the library to be installed via git clone as you specify. Better yet, it allows installation in an even more convenient manner by downloading the ZIP file produced by GitHub and then using Arduino IDE's "Add .ZIP Library..." feature, as @sonofcy attempted to do.

And if you decide you want to distribute the library via the Arduino Library Manager system, having the library in the root of the repository will be mandatory.

Missing Metadata

Because you placed the code files in the src subfolder, you library has what we call the "recursive layout". It is mandatory for libraries with this layout to have a library.properties metadata file in the root of the library.

You can learn about the library.properties metadata file from the Arduino Library Specification:

https://arduino.github.io/arduino-cli/latest/library-specification/#library-metadata


The correct structure:

SDVirtualRAM/
├── LICENSE
├── README.md
├── examples/
│   └── SDManager_UNO/
│       └── SDManager_UNO.ino
├── library.properties
└── src/
    ├── SDVirtualRAM.cpp
    └── SDVirtualRAM.h
1 Like

duly noted :blush:also corrected + updated version is available now,
sometimes i do such terrible mistakes :sweat_smile:

Thanks a lot for pointing out the error :face_holding_back_tears:

3 includes are missing

#include "SDVirtualRAM_I2CSlave.h"
#include "crc16.h"
#include "SHA1.h"

Your ONE (should be several more?) example has nothing to do with ythe library in the loop section

void loop() {
  // Blinky status
  if (millis() - blinkTimer > 1000) {
    ledState = !ledState;
    digitalWrite(LED_STATUS, ledState);
    blinkTimer = millis();
  }
}

Your example appears to demonstrate the format method only.

Been there done that NO T-shirt

1 Like

It still has the problem of the library being located in a subfolder of the repository instead of the root of the repo.


I see you changed the layout from "recursive" to "flat", which avoids the requirement to add a library.properties file, so you have solved the other problem I raised, by a circuitous route.

if possible, please do test it out with real hardwares, because i don't have the SD card (SPI) module in my hand right now, so I can't check it out, even if i wanted to... :pensive_face:

You can test the problem with the library structure without any hardware at all. Remove any existing installations of the library and then try using it after following your own installation instructions:

https://github.com/SaikatMohanta/SDVirtualRAM/tree/main?tab=readme-ov-file#2-installation

The library structure is still wrong.

However either I am going crazy or this library is either incorrectly descibed or it fails to do the functionality that is described.

Let me take a stab.

You want a library that provides a virtual RAM function using an SD(TF) card .
If that is true, then ALL the operations to the SD card should be hidden (Private) and the exposed (Public) functionality should be (I am not a C++ expert, sorry) RAM operations that look like they operate on SRAM but when SRAM is full make use of SD.

1 Like

I think one of us is confused, but here is what AI says about Arduino RAM

You don't access the 32KB RAM on an Arduino Nano R4; instead, the Arduino IDE automatically uses the microcontroller's 32KB of RAM for variables and data, so you can simply write your sketch as usual, and the IDE will handle memory management. No specific commands are needed to "access" RAM; the microcontroller's RAM is volatile and used for dynamic data like variables, local arrays, and the call stack during program execution.

Since it's not directly accessible, your concept of making it bigger via a virtual function is not possible.

All that you have accomplished here in my humble opinion is add another layer to the SD card that accomplishes nothing of benefit I can see.

Please feel free to correct me if I have misunderstood.

1 Like

“ Man ! I do like you :blush: !! seems like my kind of people ! :collision:
I got very much delighted by the queries of yours… will definitely try to answer them all,
also i assure you “ it may take some time but surely it must work, it has to ”

the real question is : will you be there until that moment arrives …..? Cos I am asking you to stay ..

The latest change is a big step backwards:

You should not store the library in the repository as a ZIP file. This is harmful for several reasons:

  • Since you are now storing the content in a binary file, it makes it impossible to follow the development of the repository by looking at the text diff of the revisions.
  • It makes it very inconvenient for anyone to make code contributions
  • It will cause the size of the repository to blow up over time due to a massive diff from even the most minimal change

In addition, it is completely unnecessary as GitHub automatically generates ZIP files for every revision in the repository. If the user wants a ZIP file of the library, they can simply click the "<> Code" button on the repository home page.

Don't worry, I am not going anywhere unless I suddenly die, which at 83 is not out of the question.

First fix your REPO.

Second, state the objective or reason for the new library. It can NOT be an extension of SRAM, as it is not available at run time.

1 Like

Not really. Since the Arduino SD library is so failure-prone and unreliable(*), my solution is SPI or QSPI flash. Use them as-is for flat memory space or with a simplified library that supports a file system. FRAM chips are popular on this forum, as well.

(*) orders of magnitude less reliable than any version of the Raspberry PI linux file system for micro SD cards, for example.