Are you SURE of this? Generally, SD file names can have 8 characters, plus the dot, plus 3 characters for the extension plus the NULL. That's more than 9.
I need a two-dimensional array of which only the second dimension is known beforehand. I read on a page I don’t find right now, this would be a way to do it. I’ve also tried
Code:
//filenames will be max 8 + 1 without fileending
Are you SURE of this? Generally, SD file names can have 8 characters, plus the dot, plus 3 characters for the extension plus the NULL. That’s more than 9.
The filenames in dirBuf.name are without the dot and I don’t care about the extension, since it always will be WAV in my case. Hence the
in the for-loop, because my filenames won't contain a "W", so I know this is were the extension starts. Can I be SURE of that? Yes. Why wasn't that in the original post? Because I saw no relevance for the actual problem, that strcpy() does not work.
Because I saw no relevance for the actual problem, that strcpy() does not work.
But, strcpy() does work.
You could use strlen() to get the length of the name of the file. You could then copy all but the last 4 (., w, a, and v). Be sure to deal with the two files in every directory named "." and "..".
I'd personally use an array of pointers, and use strdup() to copy the string to the nth pointer in the array.
and do Serial.print of actFilename[i] below actFilename[i] = dirBuf.name[i], it looks as it should, but with the strdup() line active, it breaks down again. So I suppose something is wrong with my actFilename?
Conditionally allocate some memory. Unconditionally free it. Not the best idea you've had today.
The whole jerking around with actSize confuses me. You CAN call malloc() and use actSize+1 as the size argument, and quit f***ing with actSize.
So I suppose something is wrong with my actFilename?
What's wrong is that you keep allocating and freeing memory as though you had several terrabytes to waste. Use a FIXED size array for actFilename. See what that does to your problems.
If printed, dirBuf.name[actSize] shows as an int (or uint8_t or whatever).
You CAN call malloc() and use actSize+1 as the size argument, and quit f***ing with actSize.
Ok, did not know that, thanks.
Use a FIXED size array for actFilename. See what that does to your problems.
I did that before the stuff above, it wasn't working either. Depending on the fixed-length, a couple of entries were correct in allFilenames but only emptyness afterwards. So I thought giving actFilename the needed size name per name would be better.
Depending on the fixed-length, a couple of entries were correct in allFilenames but only emptyness afterwards.
We’d need to see the code, and the output. But, there should be no waffling around about the size to use. The file name should be in 8.3 format, so the fixed array size, to hold the 8 characters before the . plus the terminating NULL, should be 9 elements. I never use odd lengths for arrays, and just to have a little margin, I’d use 16 for the size (so that it could hold the entire name (8 + 1 + 3 + 1) with room to spare).
I'd use 16 for the size (so that it could hold the entire name (8 + 1 + 3 + 1) with room to spare).
With this example, would it matter if the NULL is on index 12? Or could it alway be on index 15?
And would the room to spare matter for strdup() (since strlen() cannot be used as a second param there)?
With this example, would it matter if the NULL is on index 12? Or could it alway be on index 15?
Nope.
And would the room to spare matter for strdup() (since strlen() cannot be used as a second param there)?
strdup() allocates space for the string (NULL terminated array of chars) that is supplied (so, it knows the length), copies the string to that space, and returns a pointer to that space. So, if the input string is in an array of 16 chars, but only uses 3 of them, the allocated space will be enough for the three chars (and the NULL). So, no, the size of the input array doesn't matter.
Have you got something against printing a string correctly?
Serial.print(actFilename);
for(int i=0;i < fileCount;i++) {
Be nice to know what fileCount contains.
The data printed after the Filenames: line matches the crap printed before the Filenames: line, as far as I can see, except that it would appear that fileCount is hosed (perhaps because you’ve written beyond the end of an array.
Let’s make this simpler. Do NOT try to strip off the .wav from the end of the name. Do NOT implement your own copy method.
char theName[16];
strcpy(theName, entry.name);
Serial.print("theName: [");
Serial.print(theName);
Serial.println("]");
allNames[theCount++] = strdup(theName);
// After the loop, print all the names.
don’t know how the winamp-files got there, but they would have been filtered… Where the weird signs come from beats me, but I would have ignored them since they are after the ‘W’ of ‘WAV’. As I wrote, the dot does not appear in dirBuf.
You are basing this on the example that lists the files on the SS card. What does the output of that program look like?
I can't imagine why the spaces are showing up in your names, and where there are no dots in the names. I would have expected to see DLDR.WAV, DRDR.WAV, etc.
I have no explanation for the spaces, but in their example they are skipping them as well and insert the dot manually:
for (uint8_t i = 0; i < 11; i++) { // 8.3 format has 8+3 = 11 letters in it
if (dir.name[i] == ' ')
continue; // dont print any spaces in the name
if (i == 8)
Serial.print('.'); // after the 8th letter, place a dot
Serial.print(dir.name[i]); // print the n'th digit
}
Anyway, I gave my original problem some thought and was now able to solve it without the array.
Many thanks for your time, I’ve learnt a couple of things.