PROTON pic BASIC Compilers for PIC, PIC24, dsPIC33

Main Menu

External RAM to SD efficient transfer on SPI bus

Started by Wimax, Sep 22, 2022, 05:25 AM

Previous topic - Next topic


Hello Everybody!

Which is the most efficient method to transfer to SD (using library) the content of an external RAM, with both devices operating on SPI bus ?
I am currently thinking of using the "append" command, but...any suggestions ?  :o


Both File_Create and File_Append operate the same when it comes to writing to the file, so it is up to you if you want to create a new file or use an existing file then append to it, or create a new file to write too.

See the demo programs: "File_Create_Demo.bas" and "File_Append_Demo.bas", in "C:\Users\User Name\PDS\Samples24\SD_File_System"


Nice to see you back on the forum Les  ;D !

I tried asking for help on the forum to reduce the library to the bare minimum, but examining it a bit seemed a non-trivial task.
I had to temporarily abandon my dear and trusted silicon-made friend dsPIC33FJ12GP202 because of the low internal RAM that prevents me from using the SD library.
I am now using its cousin PIC24FJ64GA002, which is a bit slower, but has good memory both flash and ram and virtually identical pinouts.

Thank you for the tip, I will try !


The FAT systems are extremely inefficient and were originally created in the 1980s for smaller drive systems! And over time, they have become even more inefficient because of the larger drives, but that does not seem to matter these days. :-( When larger drives became available in the 1990s, a totally new mechanism should have been created with efficiency at the top of its mandate, instead of just adding more code to the original FAT system, that was already inefficient. But that's Micro$oft for you. Inefficient and bloated, but it brings in lots of money, so they do not matter. :-)

SD cards can only be written in a paged mechansim, and the page is normally 512 bytes, but that is not always the same with different SD card types. Then there is all the calculations of the linked list system the FAT uses, which have "always" been inefficient, and, again, were created back in the 1980s.

Altering the code for write only would reduce it slightly, but it still requires all the code to find the cluster and sector and name list and page writes etc... To reduce it slightly, you could remove the time and date writing code, because on most microcontroller systems these are not required, and the time and date can be written in the file itself, as a header, if required.


yes, often under the guise of backward compatibility very little has been done to move forward.
In some cases this is also true for hardware, unfortunately.

I discovered a world by analyzing the library code and trying to learn more about how SDs work.
I quickly realized that it would not be easy to get my hands on it despite the fact that the code you write is a "talking code" because of the abundance of comments and the way it is structured, a very obvious sign of great expertise and experience  ;) .