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.
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
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?
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)
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.
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!
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…