Get an mbed!
Subscribe to the mailing list
A filesystem for accessing the local mbed Microcontroller USB disk drive.
This allows programs to read and write files on the same disk drive that is used to program the mbed Microcontroller. Once created, the standard C file access functions are used to open, read and write files.
Wiki home
Recent changes
All Pages
New Page
Order 
#include "mbed.h"
LocalFileSystem local("local"); // Create the local filesystem under the name "local"
int main() {
FILE *fp = fopen("/local/out.txt", "w"); // Open "out.txt" on the local file system for writing
fprintf(fp, "Hello World!");
fclose(fp);
}
If the microcontroller program opens a file on the local drive, it will be marked as “removed” on the Host computer. This means the PC will often display a message such as "insert a disk into drive" if you try to access it at this time; this is normal, and stops both the mbed and the PC trying to access the disk at the same time.
The USB drive will only re-appear when all file handles are closed in your program, or the microcontroller program exits.
If a running program on the mbed does not exit or does not release it's open file handles, you will no longer be able to see the USB drive when you plug the mbed into your PC. To allow you to see the drive again (and load a new program), use the following procedure:
Here is an example program that shows the behaviour clearly:
#include "mbed.h"
LocalFileSystem local("local");
int main() {
printf("Hello World!\n");
wait(5.0);
printf("Opening File...\n"); // Drive should be marked as removed
FILE *fp = fopen("/local/test.txt", "w");
if(!fp) {
fprintf(stderr, "File /local/test.txt could not be opened!\n");
exit(1);
}
wait(5.0);
printf("Writing Data...\n");
fprintf(fp, "Hello World!");
wait(5.0);
printf("Closing File...\n");
fclose(fp);
// Drive should be restored. this is the same as just returning from main
wait(5);
}
The LocalFileSystem actually accesses the mbed USB disk by making "semihosting" calls to the mbed Interface, which does the actual accesses on behalf of your program. This means the "filesystem" in this case is running on the interface. The underlying mechanism is the interface acting like a debugger, and the "semihost" calls are effectively breakpoints that the interface spots and does the requested operation.
The LocalFilesystem has a few restrictions:
Other filesystems (such as ones to talk to an SD card, or a USB FLASH drive) run on the target itself, so don't talk to the mbed Interface at all and these restrictions don't necessarily apply.
Patrick Grady wrote: How much can the LocalFileSystem hold?
We couldn't go more than 4KB. We have been trying to write log files but a log file can't be larger than 4KB.. Sad news
Deniz Akkaya wrote: Patrick Grady wrote: How much can the LocalFileSystem hold?
We couldn't go more than 4KB. We have been trying to write log files but a log file can't be larger than 4KB.. Sad news
It says the mbed has 512KB of flash of which some would be taken for the code. Is there any way I can calculate the remaining memory so that I can accommodate a stream of data from the Serial-IN in a .txt file on the LocalFileSystem?
Please login to post comments.
Page history
Is it possible to NOT have the mbed marked as removed when accessing a file? I realize in most situations that is not ideal but when testing code repeatedly it can be quite irritating to have the mbed removed. I also know that the file system can get pretty messed up if something goes wrong (I've done it once already). Is it part of the library that marks it removed or is it part of the mbed that I can't change?