Example Path: examples/EFFS/Fat/RamDrive

EFFS-FAT RAM Drive Example

Overview

This example performs the same basic file system operations as the Basic example – mounting a drive, checking free and used space, and creating, writing, reading, and listing a file – but it targets a RAM drive instead of an SD/MMC or CompactFlash card. The RAM drive lives entirely in the module's RAM, so its contents start empty on every boot and are lost when the drive is unmounted or the device resets. That makes it a convenient scratch volume that needs no physical media.

As the program runs it prints its progress to the debug serial port: space statistics, the read/write test, a directory listing, and the unmount, after which it idles until the device is reset.

Warning: All EFFS FAT examples require that you add the Embedded Flash File System File Allocation Table (EFFS FAT) library to your project: Add a Library to a Project

Selecting the RAM Drive

The other EFFS FAT examples share a single cardtype.h (in examples/_common/EFFS/FAT/src), which selects USE_MMC (SD/MMC) by default. That file is common: it is copied into each example's src/ directory at build time, so any edit you make to the copy is overwritten on the next build and deleted by make clean. That makes it an unreliable place to force a single example onto the RAM drive.

So instead of editing the shared header, this example ships its own, example-owned header, cardtype-ram.h, which defines USE_RAM and sets EXT_FLASH_DRV_NUM to the RAM drive number (F_RAM_DRIVE0). It is not a common file, so it survives clean builds and SDK updates. main.cpp includes cardtype-ram.h before it includes FileSystemUtils.h, and cardtype-ram.h deliberately reuses the _CARDTYPE_H include guard from the shared header. That means by the time FileSystemUtils.h pulls in the shared cardtype.h, the guard is already satisfied and the shared header's body is skipped – so main.cpp sees only the RAM configuration, with no conflicting card-type define. (See the comment block at the top of cardtype-ram.h for the full rationale.)

There is one subtlety worth understanding. The guard trick only affects main.cpp. The shared FileSystemUtils.cpp is a separate translation unit that still includes the real cardtype.h (USE_MMC), so its drive-bound helpers – InitExtFlash(), DisplayEffsSpaceStats(), UnmountExtFlash(), and FormatExtFlash() – remain compiled for the SD/MMC drive. That is why main.cpp does its own mount, space-stat, and unmount directly against the RAM drive (EXT_FLASH_DRV_NUM = F_RAM_DRIVE0) and only reuses the helpers that act on the task's current drive – DumpDir() and ReadWriteTest() – after calling f_chdrive() to make the RAM drive current. The SD/MMC helpers are still compiled and linked, but this example never calls them.

ramdrv_mcf.cpp, which defines the RAM buffers the driver uses, is already pulled in by the common EFFS FAT makefile, so no makefile change is needed.

If you instead want to point a different EFFS FAT example at the RAM drive, the simplest approach is to copy this cardtype-ram.h (and the include-ordering and self-contained-mount pattern from this main.cpp) into that example.

RAM Drive Size and FAT Type

The RAM drive supports 12-, 16-, and 32-bit FAT file systems. The FAT type is chosen where the volume is formatted:

int fstat = f_format(RAM_DRV_NUM, F_FAT12_MEDIA);

If you change the FAT type, make the matching change there and size the drive accordingly. The minimum drive size for each FAT type is:

FAT type	Minimum drive size
FAT12 (most common)	50 KB (up to ~2.8 MB)
FAT16	2.8 MB
FAT32	32 MB

The drive's size is set by RAMDRV0_SIZE in ramdrv_mcf.cpp (512 KB by default).

Warning: This example does not set the system clock, so the date and time stamps written on the file it creates (and shown in the directory listing) will be incorrect. To set the clock so files are stamped with the correct date and time, see the HTTP example, which synchronizes the time from an NTP server at startup.

File System Access

Every task that makes EFFS FAT calls must first register itself with the library by calling f_enterFS() exactly once, before any other f_* call. The library keeps a small amount of per-task state** – each task has its own current drive and current working directory – and coordinates concurrent access with internal locking; f_enterFS() allocates the task's context and enrolls it in that locking. Slots are limited (up to 10 tasks by default, configurable), so a task that is finished with the file system should call f_releaseFS() to free its slot.

In this example UserMain() is the only task that touches the file system, so it calls f_enterFS() once at startup and f_releaseFS() at the end. See Basic for a fuller explanation, and Multiple Tasks for an example where several tasks share a drive concurrently.