SFEMP3Shield works with Arduino Due

[Anonymous]

I plan to make a web radio listener.
For that project I would use an Arduino Due, an Arduino Ethernet shield and a SparkFun MP3 Player.
The first step was to put to work the MP3 Player with the Arduino Due.
I have to redirect SPI pins (only available on SPI connectors from Arduino Due) to pins 11, 12 and 13 of MP3 Player. For that I solder three wire on the Arduino Ethernet shield and I bent the connectors corresponding to pins 11-13. So the Arduino Ethernet shield act as an adapter between Arduino Due and MP3 Player
The second step was to modify your great library adapting it to the peculiarities of SAM3X8E processor.
It is working fine. I test it with MP3Shield_Library_Demo sketch, reproducing perfectly mp3 files up to 320 kpbs
So I can begin the next step: put to work the ethernet module
If you are interested, I can send you the modified library, so may be you can include the modifications. Just give me an e-mail where to send it.
I hope you would understand  my bad english …

[Michael P. Flaga]

Sounds fun. I suggest looking at “arduradio” it was based off an older version of this library. I was real close to that with the WebPlayer.ino after seeing the Arduradio, just not enough time. But it is definitely possible.

I would be interested in reviewing and possibly merging the Due.

Best way to contribute is to create a GITHUB account, then fork the library. And commit your changes. Then let us know. We can then review and merge applicable components of the forks.

[Anonymous]

Thank you for your answer!
I follow your advice and open a account on GitHub and learn to use it.
So the fork of your library is at https://github.com/gallegojm/Sparkfun-MP3-Player-Shield-Arduino-Library
As I say, I was learning to use GitHub. As a result I upload the modifications (commits ?) in 4 separated time. I think it’s not the correct procedure.
Of course I would be happy to test on the Arduino Due any change you make to the library.
I look at your WebPlayer. I create a similar machine, but with the Rogue rMP3 shield and using UDP protocol. You can look at it at http://larocola.net

[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?

[Michael P. Flaga]

I have incorporated your changes into a branch for evaluation, that will dynamically detect ARM vs AVR at compile time, along with using some helper functions, to do so. The branch can be found at

https://github.com/mpflaga/Sparkfun-MP3-Player-Shield-Arduino-Library/tree/Due

Give it a try. I have verified that it compiles on IDE 1.0.4 and 1.5.2, along with working for UNO. Where I don’t have a Due to validate.

Where I am still suspicious of the digitalRead(MP3_RESET) problem. And for the moment have used the local mp3Reset.

[Bill]

gallegojm replied to the notification email instead of submitting a response. His email:

 

i Michael
I almost finish to redact this e-mail when I see you send me an other mail. You are faster than me!
Well. I send you now what I was redacting before I make the test with the Due

===============================

Hi Michael
I shall try to answer all your questions:

1) PROGMEM does not exist on the SAM3X8E.

Yes. SAM3X8E has no EEPROM but plenty of flash memory for code (512 kBytes). So PROGMEM does not  exist.
Notice that the function F( “…” ) does not generate error under Due but don’t do anything.

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

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?

 On Due reading a digital output always return a low value. (http://arduino.cc/forum/index.php/topic,151120.0.html ,http://arduino.cc/forum/index.php/topic,157749.0.html and more) .
That is why I add the variable mp3Reset. I think it is not a bad idea to do this for all the configuration, because it is faster when you need to test the state of the pin. What do you think? Would you prefer an other name for the variable?

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

5) cs_low() and dcs_low(), you have commented out ” SPI.setClockDivider(spiRate);” and not replaced it with “SPI.setClockDivider( MP3_XCS, spiRate );”.


Yes, “the SAM3X8E has advanced SPI capabilities” (http://arduino.cc/en/Reference/DueExtendedSPI )

This is related with SAM3X8E SPI capabilities. “If you specify one of the Arduino Due’s Slave Select (SS) pin in the call to setClockDivider(), the clock setting is applied only to the device connected to the specified SS pin” (http://arduino.cc/en/Reference/SPISetClockDivider )

I just see now I can increase velocity for multiple transfers (like in function Mp3WriteRegister() ) using aditional parameter SPI_CONTINUE calling SPI.transfer()

What Shield are you using and how have mated it to the DUE?


I use an Arduino Ethernet shield between the Due and the MP3 shield.
On the Ethernet shield I solder 3 wires to connect SPI pins MOSI, MISO and SCK from SPI connector to digital pins 11, 12 and 13 and I bent this pins
I also cut the bridge between digital pin 4 and GPIO1 on the MP3 shield as it conflict with SD card select of Ethernet shield.



I think I have to try now to ensure there is no conflict with Ethernet library and if that is right try to merge Due’ modification to you library

[Anonymous]

Your library work perfectly with Due, compiled on IDE 1.5.2

 

[Michael P. Flaga]

It may have worked. But it was not working for some of the right reasons.
I thought I had sent a follow up this morning, about some items I subsequently learned and some I was perplexed about.

The main purpose of the F() and PROGMEM was to avoid the tendency of C++ to place const variables, strings or arrays into and consuming RAM. A dangerous waist, when the AVR is limited to 2K and easily consumed. I don’t recall if the ARM tool chain does this, regardless the SAM3X8E 100K of SRAM is plenty.

Thanks for the links about digital read back problems. In reading the tool chains code and how the ARM’s helper functions are significantly different than the AVR’s, I see how the arduino core wiring_digital.c definition of digitalRead has problems reading back an assigned out. Yuck. This is possible on the ARM, but was skipped in the Arduino Due core library implementation, likely due to its complexity. And I see future room for improvement. (some day, I don’t even have a Due).
This read back is common on most all Micro’s I have worked with. It is common to use it, as it is an actual Register just like RAM, should be just as fast as other RAM. Keeping a copy of it only doubles the work and overhead. And in 8bitters every byte or bit counts, it is too easy to pile up. I have done it. The SFEMP3 library is very efficient on memory. As libraries should be, using as little of a footprint as possible leaving as much as possible for the main objective. You will notice this library does not store copies of parameters internal to the VDSP. But rather gets them.
Regardless the Due as is makes this convoluted. So a copy is simplest, as it has plenty of space.

About the DueExtendedSPI, I may be repeating an apparently lost posting from this morning. I read the spi.c for the Due and see the functions are overloaded with original and new enhanced. The later having the channelized Chip Selects. Where I see that only pins D4, D10 and D52 can function as automatic chip selects. Where original commands are still available, without CS and CONTINUE (defaulting to assert D52, anyways). Note the MP3_XCS and MP3_DXCS are correspondingly mapped to D6 and D7, and therefore should not work when placed into ExtendedSPI methods, they actually fall through not matching any of the allowed Chip Selects and assert SS3 (aka D78 not available) by default. I notice your forks dcs_low() uses SPI.setDataMode( MP3_XCS, SPI_MODE0 ) but note that both dcs_low() and cs_low() still have the original digitalWrite(MP3_?XCS, LOW) in them. Hence I believe the d/cs_low()’s are still asserting the correct chip selects D6/D7, making it work.

Note that while the SPI_CONTINUE is nice and sounds more efficient, the SPI.transfer with CS still while() loops and BLOCKING until the transfer is done, to be read back. No real speed increase. So the important reason for including the SPI_CONTINUE, in conjunction with including the CS, is not speed or ease, but to remove the glitch of the CS bouncing between transfers, when using the Extended method. Where it is not truly applicable in the case of MP3_XCS(D6) and MP3_DXCS(D7). As an FYI, I would mention that SdFat’s SPI for the ARM does not use the Arduino Due Core SPI functions but appears to use is own to take advantage of the SAM3X8E DMA features.

That all said I see errors or miss-conceptions in my suggested branch and need to clean them up. I don’t want to be propagating false code.

[Anonymous]

After I download the files of your branch for Due, I rename the subdirectory that contain my modified files of SFEMP3Shield
So I have:
arduino-1.5.2
libraries
SFEMP3Shield_mine      <- my version
SFEMP3Shield                 <- yours

And it seems to work
Trying to make modifications in your files I realise there where something wrong, as my modifications where not taken in account by the IDE.
It took me a while to understand that in case of multiple files with the same name, the IDE use the first occurrence of them, no the ones in the directory witch name coincide with the correct name of the library.

So I have to move the subdirectory “SFEMP3Shield_mine” to an other place.

This correct my beginner’s mistake, and I can really test your branch for Due.

In your file SFEMP3ShieldConfig.h , line 159 I have to replace
#if defined(__ARM__)
with
#if defined(__arm__)

[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

[Anonymous]

I can now listen web radio up to 320 kb/s !
I replace the Ethernet shield with a WIZ820io. It has a w5200 chip, connect through the SPI bus and work with the same library as Ethernet shield (with a little modification)
See http://forum.arduino.cc/index.php?topic=139147.0 for discussion on that module and how to connect it.
Download W5200 library by Jinbuhm Kim at
https://github.com/jbkim/W5200-Arduino-Ethernet-library
I modify my Webradio example, add some examples of high baud rate web radio and made a minor change to my fork of SFEMP3Shield library
You can download it at
https://github.com/gallegojm/Sparkfun-MP3-Player-Shield-Arduino-Library/tree/Due

[Anonymous]

gallegojm, I didn’t understand your comment, “pin 52 is the default CS when former SPI functions are used. This the case of SdFat library.”

What do you mean by “former SPI functions”? I didn’t see anything referring to pin 52 in SdFatConfig.h

[Anonymous]

You can have, in the same sketch, devices than use “extended” spi functions and devices than use the “formers” ones. For those ultimate devices, the SPI library use a trick, attributing them the “virtual” chip select 52, despite you connect them to an other CS pin and you control using that real pin.
If you want, you can look at the code, and search word BOARD_SPI_DEFAULT_SS in files:

arduino-1.5.2/hardware/arduino/sam/libraries/SPI.h ,
arduino-1.5.2/hardware/arduino/sam/libraries/SPI.cpp and
arduino-1.5.2/hardware/arduino/sam/variants/arduino_due_x/variant.h

I am sure this would be clearer than my bad english…
Hope this would help

[Anonymous]

Thanks for your reply. So as I understand it, SDFat doesn’t use extended SPI functionality but the SPI implementation means that it defaults to use pin 52 anyway. Since we are using an SD card which needs SPI and also MP3 which needs SPI, we can’t use pin 52 for the MP3 chip otherwise the SD card access and MP3 chip access would get confused. We can therefore only use pin 4 or pin 10 as the chip select pin for the MP3 chip when using the Due (if we want to use extended SPI capabilities).

Also, as I understand it the way you have modified the SFEMP3Shield software, we can only use extended SPI when using a Due.

[Anonymous]

That is right.
You can be interested too in reading my post in Arduino forum: Summary of mysteries about SPI and extended SPI library with Due
And take a look at my web page: LaRocola II (in french, but technical stuff is easy to understand, I guess)

[Author]

Posts