SD only partially works.

I was only planning to play all the files in a single director and not worry about descending into sub dirs, so I I did was have a number which was effectively indexing N files into the directory

Initiall N = 0

so it opens the dir, skips N files and then reads the file name, stores it, closes the dir file handle, increments N and calls playFile
Loop back around unless N > files in the current folder

ie I only need to store an int for N and also the folder path

I agree to write a general purpose play all files in all folders is far more complex. I was just relying on the high level functions in the SD lib, and only going to play files in the selected folder

RogerClark wrote:I was just relying on the high level functions in the SD lib, and only going to play files in the selected folder

@sheepdoll

I’d not really considered playlists, but I know what you mean

My primary focus was initially just getting the SD and VS1003 stuff working, and I was interested to see if I could DMA to the VS1003 (though I’m having problems with that at the moment), and start the DMA transfers (of the 32 byte blocks), from an interrupt generated by the VS1003 with its Data Req line

So that the system becomes entirely interrupt driven for both the SD and the VS1003, leaving the main loop to handle UI

But thats a long way down the track

Since I’ve been unblocked by this NSS issue, I’ve done some more tests…
There is a new issue I’m facing with SD lib :
I’m mounting the SD.begin(), I’m doing a list printDirectory() provided in example, it work’s fine ! I’m doing it again, it works fine !
I’m doing fileRead(), the fileRead() work fine by itself, but doing printDirectory() give me only few files from the real list …
(I pay attention to what Roger said, I’m closing the handle in printDirectory(), but still there is a new bug …)

Martin

I suspect these are bugs in SD lib and perhaps would be present on AVR (as we’re using the same code)

From what I understand SD has been superseded by SdFat, but the problem with this appears to be Victor sent a pull request to the SdFat repo which was accepted but SdFat no doesnt compile on STM32

Victor_pv has an updated SdFat on his github account, but it didnt work for me (regardless of which CS pin I used), and I suspect it may not compile for F4 because of the F1 DMA stuff thats in that version ;-(

So were does this leave us…

Perhaps going back to the version of SD Fat prior to Victors pull request acceptance may work..

I was thinking we should probably create a separate thread for SPI lib issues, since that’s more general than the SD stuff, and may need a bit of thought and discussion as how best to proceed.

As for SdFatLib, I have some experience in porting that to the mighty-1284p project, so I know my way around reasonably well, and could have a look at porting for the simple non-dma SPI case, since we have a workaround for that now.

BTW, the CSN bug for F103 also affect F2 and F4 devices, but supposedly doesn’t affect F0 and F3 devices (from reading on the my.ST.com forums.)

@pico

Thanks for the heads up about F0 and F3

I’m actually looking at a fix for it this evening (now)

I’m writing a new low level function

gpio_pin_mode gpio_get_mode(gpio_dev *dev, uint8 pin);

I’m unclear what you are actually fixing with this. Can you explain your reasoning?

In any case, start a new thread for SPI lib issue?

I’ll start a new thread

Thread continued here

http://www.stm32duino.com/viewtopic.php?f=14&t=300

Hello,

I’m working with and SD for read/write on a maple mini clone and using standard Arduino SD class.

I’ve found that using this library with an ancient 32Mb (yes, Mb, not Gb) I have to add any debug (Serial.println) or delay(1) between each File.read() because if I don’t do so read fails.

What’s recommended library for this board? Reading the thread I assume Maple Mini is supported by new library, isn’t it?

Naguissa

I’ve also noticed that I needed to add delays. This may be an issue with the speed of your SD card, but I think the old SD library has some “issues”
BTW. Have you tried the latest version of the repo with the change to spi_f1.c, as part of my problem (requiring the delays) seemed to be the issue with using PA4 as the SS pin.
But if you are using another pin, its definitely the SD lib or your card that’s the problem.

I know Victor_pv was working with the author of

https://github.com/greiman/SdFat

Which is the replacement for SD on all Arduino’s

However at the moment it doesn’t seem to work. In fact that repo doesnt compile at all.

Victor_pv has an update SDFat on his github account, but it didnt work for me, so I’m back on the old SD lib which works 95% of the time

RogerClark wrote:Naguissa

I’ve also noticed that I needed to add delays. This may be an issue with the speed of your SD card, but I think the old SD library has some “issues”
BTW. Have you tried the latest version of the repo with the change to spi_f1.c, as part of my problem (requiring the delays) seemed to be the issue with using PA4 as the SS pin.
But if you are using another pin, its definitely the SD lib or your card that’s the problem.

I know Victor_pv was working with the author of

https://github.com/greiman/SdFat

Which is the replacement for SD on all Arduino’s

However at the moment it doesn’t seem to work. In fact that repo doesnt compile at all.

Victor_pv has an update SDFat on his github account, but it didnt work for me, so I’m back on the old SD lib which works 95% of the time

I think that SDFat is the replacement for SD on all Arduinos, but that the Arduino team is slow to roll out this sort of change
I’ve noticed that the IDE Team don’t update the libs very often, and the website doesnt get updated that frequently either, so some stuff on the website is not correct either.

Just a short info:
SDfat lib is currently working, see
http://www.stm32duino.com/viewtopic.php?f=13&t=20