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: SDVirtualRAM
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); }
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?
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
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:
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...
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:
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.
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.
“ Man ! I do like you !! seems like my kind of people ! “
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 ..
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.
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.