MIOS32 SD card code example?

[ilmenator]

Next issue here: I am looking for a simple example for how to write a (new) file to an SD card in MIOS32. What I know is tutorial #019: A MIDI Player plays from SD Card, which does not contain write functions. Also, I took a look at the SEQ v4 code, but the whole file handling thing is way too complex for what I need - no need for semaphores and the likes.

The ReadMe_1st of ../modules/dosfs/ says:

MIOS32 based usage examples can be found under

$MIOS32_PATH/apps/examples/sdcard

but this is not the case - at least not where it claims to be. I have searched the whole repository, but could not find simple examples for write access to SD card. I might be just too blind :question:

Thanks, ilmenator

Edited January 8, 2011 by ilmenator

[TK.]

This example just doesn't exist yet, and it will never be created for DOSFS since FATFS is much better.

Tutorial #19 has to be overworked since it implies that DOSFS is the preferred choice (which isn't the case).

This is the most simple code snippet which writes a file to SD Card:

http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fsequencers%2Fmidibox_seq_v4%2Fcore%2Fseq_file_g.c

Best Regards, Thorsten.

[ilmenator]

This example just doesn't exist yet, and it will never be created for DOSFS since FATFS is much better.

Tutorial #19 has to be overworked since it implies that DOSFS is the preferred choice (which isn't the case).

So I was mislead... :unsure: I did find references to FATFS in the SEQ v4 code, but that did not really ring a bell. Thanks for clarifying this for me!

I'll have a look at the code snippet and see what I can make of it. And try to change what I already have to FATFS :thumbsup:

[ilmenator]

Okay, that transition was almost pain free, and I have parts of what I need up and running - great!

Now I got adventurous and tried to switch to LFN mode - I enabled the long file names. That means I added

#define FATFS_USE_LFN 1

to mios32_config.h and everything compiles just like before. But unfortunately, when I try to read out a directory, the application just crashes. With LFN disabled the same code works like a charm. Thorsten, have you tried LFN, and did it work for you?

Thanks, ilmenator

[TK.]

No, I haven't tried it yet because MBSEQ hasn't enough free memory for handling long filenames everywhere.

And this could be your issue - e.g. avoid to declare variables of the large FATFS, but especially FIL structures as local variables (so that they are located in stack memory), instead declare them as global variables (e.g. "static FIL read_file_handle, write_file_handle;")

After compilation you should be able to determine the actual variable size from the project.map file

if for example read_file_handle is much larger than 500 bytes, you found the potential crash cause (stack is limited to 1024 bytes per thread)

Best Regards, Thorsten.

[ilmenator]

I am basically using SEQ_FILE_GetDirs() from ..\trunk\apps\sequencers\midibox_seq_v4\core to read the directory.

I assume you are refering to

  DIR di;

  FILINFO de;

and if I change that to

  DIR di;

  static FILINFO de;

the application does not crash any longer, but shows short filenames as in

[42316.128] [SCE_FILE_GetDirs] SCE_FILE_GetDirs function entered!

[42316.128] [SCE_FILE_GetDirs] WHILE loop entered!

[42316.128] --> 001.bin

[42316.129] [SCE_FILE_GetDirs] WHILE loop entered!

[42316.129] --> 002.bin

[42316.129] [SCE_FILE_GetDirs] WHILE loop entered!

[42316.129] --> 003.bin

[42316.129] [SCE_FILE_GetDirs] WHILE loop entered!

[42316.129] --> 004.bin

[42316.129] [SCE_FILE_GetDirs] WHILE loop entered!

[42316.129] --> 006VEC~1.BIN

[42316.129] [SCE_FILE_GetDirs] WHILE loop entered!

[42316.129] --> 006.bin

I'm not really familiar with the project.map file and its interpretation, but I could not find either of the two in there!?

[ilmenator]

Well, apparently my mistake was that I was reading de.fname[] instead of de.lfname[], so of course I should get the short file name...

Unfortunately, no matter what I do it seems that de.lfname[0] is always NULL. I fiddled around a bit with ff.c to make sure those parts of the code dedicated to LFN are actually executed, which is the case, but I guess I am stuck there.

[philetaylor]

I never got anywhere with LFN support either. I then thought to myself, how useful is LFN for MIDIbox anyway? and decided (for me) not very :)

Have you created a Unicode code conversion function and selected a code page as described here

Cheers

Phil

EDIT: Also take a look at this post in the FatFS User Forum: http://elm-chan.org/fsw/ff/bd/?show=766

Edited January 13, 2011 by philetaylor

[ilmenator]

I never got anywhere with LFN support either. I then thought to myself, how useful is LFN for MIDIbox anyway? and decided (for me) not very :)

Good to hear that it is probably not just my stupid fault, but in general that is bad news.

For my application it would be very nice to have LFN, because that would allow the use of meaningful names. My files contain banks of patch data or banks of PCM data, in analogy to the RAM/ROM sound cards and PCM cards used e.g. in Korg M1 and the likes synths. Each "card"/bank has its own name encoded in the data, and for my system these are visible by reading out these portions of data from the file itself. But for a user on a PC who might want to exchange bank files stored on the SD card with someone else (especially interesting for PCM banks!) it is hard to know which is which without meaningful file names.

Have you created a Unicode code conversion function and selected a code page as described here

The code conversion functions - ff_convert() and ff_wtoupper() - are part of ccsbcs.c, they are already there, and code page is set to 437 - U.S. (OEM) by default. This is what I want, no fancy chinese characters required!

EDIT: Also take a look at this post in the FatFS User Forum: http://elm-chan.org/fsw/ff/bd/?show=766

I have seen this post, doing this has the same effect as declaring FILINFO static - i.e. it prevents my app from crashing, but it does not help in retrieving the long file names - unless I did something wrong...