Reply To: SFEMP3Shield works with Arduino Due

[Anonymous]

The next step in my experiment with the mp3 shield was to put it to work together with the arduino ethernet shield.
I had to learn more about the SPI interface, the extended SPI library for Due, and how the Ethernet library and the SdFat library use SPI functions.
I take too in account your remarks on my first fork of your library. You right, it was working thanks to the lucky sum of omissions and errors.
So I made the following changes:
1) I redirect pin MP3-CS of mp3 shield to pin 4 of Arduino Due. As you say, extended SPI capability are only available on pin 4, 10 and 52.
pin 10 is used for Ethernet CS (Ethernet library use extended capabilities of SPI)
pin 52 is the default CS when former SPI functions are used. This the case of SdFat library. So, even if an other CS pin is used with a SD card reader (as pin 9 of SD card of mp3 shield), it is impossible to use pin 52
pin 4 is precisely the CS used by SD card reader on Ethernet shield, that I don’t use .
So I have to isolate pin 4 of Ethernet shield, bending the pin of the connector and connecting it to 3.3V.
2) I modify calls to SPI functions in your library.
Especially, I eliminate calls to digitalWrite( MP3_XCS, …)
I add a function spiLastTransfer( uint8_t value ) to take in account the parameter SPI_LAST / SPI_CONTINUE. I do not get a exact rule on the use of this parameter. By experience, It seems that in some cases it is necessary and in other situations it does not work. I don’t found any explanation in the Arduino forum
You mention use of pin MP3_XDCS. Does it not escape to SPI functions?
3) I add 3 functions to play streams:
– playStream() initiate the play. I add a value (stream_playback) to variable playing_state
– stopStream() to stop.
– fillFromStream( uint8_t * p_buf ) assume the transfer of 32 bytes from buffer pointed by p_buf to W5100 chip memory
This functions only are available when USE_MP3_REFILL_MEANS is defined to USE_MP3_Polled as the Ethernet library actually do not allow use of interrupts.
4) I wrote a sketch that plays web radios and add it to the examples.
This works fine for most radios that transmit up to 64 kb/s
The sketch prints some statistics every seconds. If I don’t make any mistake I can say thanks to this stats that cpu of Arm processor is always used under his capacity, even in the case of radios transmitting at 128 kb/s and played with some glitches.
So I believe the limitation comes from the W5100 chip that never gives a rate higher than 80 kb/s. Not for his comunication with the Arm processor (increasing the speed at witch it communicate through SPI do not better) but for his ethernet interface.
Would a W5200 allow better results?
All this modifications are available at
https://github.com/gallegojm/Sparkfun-MP3-Player-Shield-Arduino-Library/tree/Due