Reply To: SFEMP3Shield works with Arduino Due

[Michael P. Flaga]

I have reviewed your code and find the following and some questions about some of them that follow.
1) PROGMEM does not exist on the SAM3X8E.

2) There is a problem reading back the MP3reset pin.

3) SPI member functions between UNO and DUE have some differences.
a. SPI.tranfer’s member function requires the Chip Select in the function call.
b. Default setup can’t be used for setBitOrder and setDataMode
c. setClockDivider is obviously different

4) attachInterrupt() and detachInterrupt() have changed from INT(x) vector to actual pin.

For the most part we can use either the following to merge a correspondingly distinguish the appropriate code to use:
#ifdef __AVR__
Or
#if defined(__arm__) && !defined(CORE_TEENSY)"
I see the SdFatLib uses the later.

What Shield are you using and how have mated it to the DUE?
Other than the MISO,MOSI,SCK of the SPI; Does it require any jumpers? If so please describe.
Or does it work connected straight up ?

I have the following concerns:

5) cs_low() and dcs_low(), you have commented out ” SPI.setClockDivider(spiRate);” and not replaced it with “SPI.setClockDivider( MP3_XCS, spiRate );”.
This may appear initially acceptable. Whereas it may not account for SdCard calls’s which the change setClockDivider to faster rates for the SdCard. One cannot assume other user functions don’t change the SPI speed for their purposes. Can you provide a better explanation for this?

6) I don’t understand the reason for digitalRead(MP3_RESET) not reading back the MP3_RESET pin. Do you know of a reason for this? Perhaps you could direct me to a Link explaining why. Or is this something you are observing?
I am suspicious this may because of the SparkFun MP3 shield is actually designed for 5V. Where the Due is only 3V which may not be supplying or reading proper signals.
Is it possible that your board or PIN is not actually going low and resetting?