Update: Yes, works when broken up into three separate printf statements...
Update2: that’s true but now think something else might be going on...
Update3: I think there's something wrong with the compiler, but I can't pin it down because the code I'm working with is too big... Somehow a break statement nested within a for inside a case goes off the rails. When this happens, the serial output seems to put a space between every character also. Isn't that strange? I'll rewrite and see if I can figure out where it goes wrong...
Should it? Or, am I doing it wrong? I get no output other than "Cog0"...
That example works in the currently checked in fastspin. Not all debug messages are implemented, but the ones that aren't should produce warnings when you compile with -g.
The baud rate defaults to 230400. It's possible to change this with _setbaud(N), or by using the -PATCH parameter to loadp2.
Is there an SD card filesystem driver in FlexC yet?
I know you were working on one, but I don't see anything about it in docs or examples...
mount("/sd", _vfs_open_sdcard())
Should let you access your SD files with names like "/sd/hello.txt", "/sd/folder/foo.bin", and so on. This may not work well with the last release (the BASIC versions of these worked, but there was a bug in C) but it's fixed in github.
Great! I see you figured out FatFs. Now, I don't have to!
Have you tried turning on the relative path and/or long file name options?
Mine was doing OK until I turned on relative path...
Relative path isn't necessary for my implementation, the C library keeps the current directory and passes the whole path in anyway. The long file name option worked last time I tried it.
There are a ton of options in ffconf.h, as you probably know...
One of them is this:
#define FF_USE_STRFUNC 1 //RJA
/* This option switches string functions, f_gets(), f_putc(), f_puts() and f_printf().
/
/ 0: Disable string functions.
/ 1: Enable without LF-CRLF conversion.
/ 2: Enable with LF-CRLF conversion. */
But, it sounds like you have your own fprintf function that somehow gets mapped to sd.
But the thing is... I want to extend FatFs to include things like the extra space on boot flash chip, an eMMC chip, a HyperFlash chip, and possibly a RAM drive, perhaps in HyperRam...
All of these things would show as a separate drive, once relative path is enabled.
Would your fprintf work with whatever drive is mounted? Or, is it perhaps hardwired for SD card?
Anyway, I'm thinking I need to start from your FatFs files and modify them to do the above...
Ah, I see. I just use fatfs for disk I/O, and all of the standard library functions (the standard fprintf, rather than fatfs's f_printf) are implemented on top. There's also the 9pfs file system that works with files on the host's hard drive. You can mount both the SD and host at the same time and copy files between them, and the fprintf() and so on work with the file system associated with the file (so they'll ultimately call fatfs for files on the SD, and 9pfs for files on the host).
Generalizing fatfs so it can work with other targets (not just the default SD card) would be interesting.
Is there a hard limit to the argument count on printf?
I'm getting a "Internal error exceeded local register limit" error on a long one...
That error will happen if more than 150 temporary registers are needed in a function, so definitely 150 (or maybe 75?) is the upper limit on the number of parameters to any function.
Here's a binary of fastspin 4.3.2-beta with several of the bugs reported earlier in the thread fixed.
I've also attached two small programs, "simple_ls.c" and "simple_cat.c", to show file I/O from either SD card or host. To run from host, use the -9. option to loadp2 (flexgui does this by default). Edit the files to define USE_SD or USE_HOST. If neither one is defined then the mount call is skipped, which is OK if you want to test the logic on a "real" operating system like Linux or Windows.
Eric,
How do I find the assembly sources for functions like clkset() in the source tree of fastspin/spin2cpp?
Generally they're in the sys/ directory, either in sys/p[12]_code.spin (for processor specific functions) or sys/common.spin (for more generic functions).
Ok, I tested out the codes above. But, I still have the same issue with my SDHC card...
uSD mounts the first time I run it, but won't mount the second time, unless I physically remove the card and stick it back in.
I think this must have something to do with the way these pins are shared with flash and also used for booting.
No problem with my regular 2 GB SD card (non- SDHC).
I used to have more cards for testing around...
I'll have to try out @Cluso99 code and see if it does any better.
BTW: Your code seems to create an empty hello.txt file if none exists. Is that what you intended? I think there are some flags if FatFs to prevent this...
@Rayman what particular cards are you using? Some cards are just buggy. Yours might just not like being initialized multiple times. Can you try the same card on a P1 board? Can you get a known-good card (SanDisk in particular seem to have a good reputation)?
I'll look for more cards.
But, the thing is that it works fine when using different pins on my homebrew board...
Still, maybe there is something strange about this card. Suppose that could be.
Ok, maybe there is something strange with this type of card.
I checked my RasPi Zeros and found one with an identical card.
This one gives the same bad behavior.
But, I found another SDHC card that works every time.
So, I guess there are just some cards that don't like sharing the pins with boot and/or flash...
Might be interesting to read out the ID registers on yours.
Anyways, if I was you I'd buy an A1-rated card just for the improved performance... Even in lowly SPI mode, a P2 can outpace a Class 4 card in linear R/W speed.
Ok, I tested out the codes above. But, I still have the same issue with my SDHC card...
uSD mounts the first time I run it, but won't mount the second time, unless I physically remove the card and stick it back in.
I think this must have something to do with the way these pins are shared with flash and also used for booting.
No problem with my regular 2 GB SD card (non- SDHC).
I used to have more cards for testing around...
I'll have to try out @Cluso99 code and see if it does any better.
BTW: Your code seems to create an empty hello.txt file if none exists. Is that what you intended? I think there are some flags if FatFs to prevent this...
Ray, I found similar issues when testing SD back in Feb 19. I found many cards needed an extra clock pulse in order to release the SO line, so that the next boot would proceed normally. Here are my testing observations https://forums.parallax.com/discussion/comment/1465337/#Comment_1465337
Some cards (Samsung I think) needed an extra 2 clock pulses. A select few needed 0 extra clock pulses (ie they "just worked"), but this was rare. I think this included the Red and Grey sandisk that Cluso had tested with. One card didn't release even with 40 extra pulses.
I know some 'tweaks' were made to the ROM but I'm not sure whether what I found made the cut. My suggestion is to include in your code a cycling of the clock pulses, so the *following* reboot goes smoothly. I think this may be needed even if you're not using SD boot (eg if its a data drive without p2 boot bix files etc). Alternatively, I think I saw Peter dropping power to the SD via a fet or enable on an LDO
I always hoped to get back to this and do some deeper testing. Hopefully that thread saves you a bit of guesswork
The error goes away if the empty parens are dropped from the getVersion method. Unfortunately, PNut requires that () must be there.
There is no complaint if the non-array usb1.getVersion() syntax is used.
Tested with fastspin 4.3.1 and b4.3.1-14.
BTW: Your code seems to create an empty hello.txt file if none exists. Is that what you intended? I think there are some flags if FatFs to prevent this...
No, that wasn't intended. I accidentally added FA_OPEN_ALWAYS to the default case in the v_open function in include/filesys/fatfs/ff.cc. I didn't realize FA_OPEN_ALWAYS creates the file if it does not already exist. It's fixed in github now.
Not sure what's going on with the SD card timing. The low-level code for driving the card is in include/filesys/fatfs/sdmm.cc, but I pretty much just took that from the default bit-banging example that came with FatFs.
Comments
What kind of things cause this?
Update: I think this might be what breaks it:
printf(PSTR("FAT type = %s\nBytes/Cluster = %lu\nNumber of FATs = %u\n" "Root DIR entries = %u\nSectors/FAT = %lu\nNumber of clusters = %lu\n" "Volume start (lba) = %lu\nFAT start (lba) = %lu\nDIR start (lba,clustor) = %lu\nData start (lba) = %lu\n\n"), fst[fs->fs_type], (DWORD)fs->csize * 512, fs->n_fats, fs->n_rootdir, fs->fsize, fs->n_fatent - 2, (DWORD)fs->volbase, (DWORD)fs->fatbase, (DWORD)fs->dirbase, (DWORD)fs->database );Maybe just too much going on there?Update: Yes, works when broken up into three separate printf statements...
Update2: that’s true but now think something else might be going on...
Update3: I think there's something wrong with the compiler, but I can't pin it down because the code I'm working with is too big... Somehow a break statement nested within a for inside a case goes off the rails. When this happens, the serial output seems to put a space between every character also. Isn't that strange? I'll rewrite and see if I can figure out where it goes wrong...
That example works in the currently checked in fastspin. Not all debug messages are implemented, but the ones that aren't should produce warnings when you compile with -g.
The baud rate defaults to 230400. It's possible to change this with _setbaud(N), or by using the -PATCH parameter to loadp2.
mount("/sd", _vfs_open_sdcard())Should let you access your SD files with names like "/sd/hello.txt", "/sd/folder/foo.bin", and so on. This may not work well with the last release (the BASIC versions of these worked, but there was a bug in C) but it's fixed in github.Have you tried turning on the relative path and/or long file name options?
Mine was doing OK until I turned on relative path...
or, is there an easier way to write strings to file?
Relative path isn't necessary for my implementation, the C library keeps the current directory and passes the whole path in anyway. The long file name option worked last time I tried it.
Sorry, I don't understand the question. fprintf etc. work as one would expect.
One of them is this:
But, it sounds like you have your own fprintf function that somehow gets mapped to sd.
But the thing is... I want to extend FatFs to include things like the extra space on boot flash chip, an eMMC chip, a HyperFlash chip, and possibly a RAM drive, perhaps in HyperRam...
All of these things would show as a separate drive, once relative path is enabled.
Would your fprintf work with whatever drive is mounted? Or, is it perhaps hardwired for SD card?
Anyway, I'm thinking I need to start from your FatFs files and modify them to do the above...
I think I know how to do this based on some of the examples that FatFs comes with...
Generalizing fatfs so it can work with other targets (not just the default SD card) would be interesting.
BTW: I'm having trouble with a function with this in it:
I think the compiler is not including anything after the first \0.
Can that be?
I'm getting a "Internal error exceeded local register limit" error on a long one...
Are you using -O2 optimization? That's just a thing that happens on that setting. Try -O1 or -O2,!cse
Unless something goes wrong, then I try -O0...
That error will happen if more than 150 temporary registers are needed in a function, so definitely 150 (or maybe 75?) is the upper limit on the number of parameters to any function.
I've also attached two small programs, "simple_ls.c" and "simple_cat.c", to show file I/O from either SD card or host. To run from host, use the -9. option to loadp2 (flexgui does this by default). Edit the files to define USE_SD or USE_HOST. If neither one is defined then the mount call is skipped, which is OK if you want to test the logic on a "real" operating system like Linux or Windows.
How do I find the assembly sources for functions like clkset() in the source tree of fastspin/spin2cpp?
Generally they're in the sys/ directory, either in sys/p[12]_code.spin (for processor specific functions) or sys/common.spin (for more generic functions).
uSD mounts the first time I run it, but won't mount the second time, unless I physically remove the card and stick it back in.
I think this must have something to do with the way these pins are shared with flash and also used for booting.
No problem with my regular 2 GB SD card (non- SDHC).
I used to have more cards for testing around...
I'll have to try out @Cluso99 code and see if it does any better.
BTW: Your code seems to create an empty hello.txt file if none exists. Is that what you intended? I think there are some flags if FatFs to prevent this...
But, the thing is that it works fine when using different pins on my homebrew board...
Still, maybe there is something strange about this card. Suppose that could be.
I checked my RasPi Zeros and found one with an identical card.
This one gives the same bad behavior.
But, I found another SDHC card that works every time.
So, I guess there are just some cards that don't like sharing the pins with boot and/or flash...
Might be interesting to read out the ID registers on yours.
Anyways, if I was you I'd buy an A1-rated card just for the improved performance... Even in lowly SPI mode, a P2 can outpace a Class 4 card in linear R/W speed.
Ray, I found similar issues when testing SD back in Feb 19. I found many cards needed an extra clock pulse in order to release the SO line, so that the next boot would proceed normally. Here are my testing observations
https://forums.parallax.com/discussion/comment/1465337/#Comment_1465337
Some cards (Samsung I think) needed an extra 2 clock pulses. A select few needed 0 extra clock pulses (ie they "just worked"), but this was rare. I think this included the Red and Grey sandisk that Cluso had tested with. One card didn't release even with 40 extra pulses.
I know some 'tweaks' were made to the ROM but I'm not sure whether what I found made the cut. My suggestion is to include in your code a cycling of the clock pulses, so the *following* reboot goes smoothly. I think this may be needed even if you're not using SD boot (eg if its a data drive without p2 boot bix files etc). Alternatively, I think I saw Peter dropping power to the SD via a fet or enable on an LDO
I always hoped to get back to this and do some deeper testing. Hopefully that thread saves you a bit of guesswork
If you get a chance, the Sandisk 16 GB Ultra (red and grey) was the card that tended to work best
There is no complaint if the non-array usb1.getVersion() syntax is used.
Tested with fastspin 4.3.1 and b4.3.1-14.
No, that wasn't intended. I accidentally added FA_OPEN_ALWAYS to the default case in the v_open function in include/filesys/fatfs/ff.cc. I didn't realize FA_OPEN_ALWAYS creates the file if it does not already exist. It's fixed in github now.
Not sure what's going on with the SD card timing. The low-level code for driving the card is in include/filesys/fatfs/sdmm.cc, but I pretty much just took that from the default bit-banging example that came with FatFs.