Reply To: SFEMP3Shield works with Arduino Due

[Anonymous]

Thank you for continuing to help me. I couldn’t do this without you.

Yes, the patch files have been copied. Yes, I am using sdfatlib20130629.

1- Okay, changing USE_ARDUINO_SPI_LIBRARY 1 fixes the problem and MP3_XCS drops to 0V

But why does changing USE_ARDUINO_SPI_LIBRARY affect this? That macro is in the SDFat stuff. The problem I was getting occurred early in SFEMP3Shield::vs_init() before the patch files are loaded and AFAIK, no SD card access is taking place (except for the initialisation of the SD card before the MP3 chip initialisation). I was not getting any problems when simply accessing a file on the SD card when USE_ARDUINO_SPI_LIBRARY was 0. So why should a setting in SDFat affect the initialisation of the MP3 chip?

2- I changed SFEMP3Shield::spiTransfer() from
return SPI.transfer( MP3_XCS, value, SPI_CONTINUE );

to

return SPI.transfer( MP3_XCS, value, SPI_LAST );

and I get problems again. Any idea why that should be? I was hoping to make a version that could use pins other than 4 and 10. I thought that the only extended API stuff was just using SPI_CONTINUE and that the default SPI calls used SPI_LAST anyway.

3- I now have a new problem. This seems the same as I used to have when trying Bill’s version of the software.

I have #define USE_MP3_REFILL_MEANS USE_MP3_Polled. When I call MP3player.begin() the following happens.

In MP3player.begin() there are the lines:

playing_state = playback;
Mp3WriteRegister(SCI_DECODE_TIME, 0);

In SFEMP3Shield::Mp3WriteRegister() it has:

if(playing_state == playback)
refill()

SFEMP3Shield::refill() then keeps on pulling data from the SD card

After about 54 seconds, there is no more data to read from the file on the SD card and track.close() is called. I hear no sound during this time.

The MP3 file is 8,908,772 bytes which, according to the file properties in Windows, should play for 5 minutes and 19 seconds. So it would seem that digitalRead(MP3_DREQ) is always returning TRUE. So either no data is getting to the MP3 chip or MP3_DREQ is not going low.

In case it means something, uncommenting lines 230 to 241 in SFEMP3Shield.ccp means I get the following diagnostic data:

SCI_Mode (0x4800) = 0x4800
SCI_Status (0x48) = 0x48
SCI_ClockF = 0x0
MP3Clock = 6000

I see that in SFEMP3Shield::refill() you have:

for(uint8_t y = 0 ; y < sizeof(mp3DataBuffer) ; y++) {
//while(!digitalRead(MP3_DREQ)); // wait until DREQ is or goes high // turns out it is not needed.
spiLastTransfer(mp3DataBuffer[y]); // Send SPI byte
}

Why call spiLastTransfer() for every write instead of spiTransfer() for all but the last one?

I just tried replacing the above with this:

uint8_t y;
for(y = 0 ; y < (sizeof(mp3DataBuffer) – 1) ; y++) {
//while(!digitalRead(MP3_DREQ)); // wait until DREQ is or goes high // turns out it is not needed.
spiTransfer( mp3DataBuffer[y] ); // Send SPI byte
}
spiLastTransfer( mp3DataBuffer[y] ); // Send SPI byte

Things now appear to work properly.

Why didn’t you have the same problem and why should it matter if spiLastTransfer() is called for every write?