Go Down

Topic: Wifi shield and MP3 Shield on an UNO (Read 4531 times) previous topic - next topic


For my project to work I need to get my Arduino uno to connect to wifi and play MP3 files.
I have a wifi shield working fine using the basic WiServer sketch
I have a Sparkfun MP3 shield working fine using SFEMP3Shield sketch (http://www.billporter.info/sparkfun-mp3-shield-arduino-library/)
However once I combine these Sketches neither shield functions.

I have remapped the pin 9 - as this is used by both shields. I have connected the MP3 player pin 9 to pin 10 on the uno. this shield in therefore not connected on top of the other but connected via ribbon cable.

Has anyone had any luck getting these two shield types to work together? Any ideas if its hardware or software issue ?

The sketch is below if that helps (server details removed for security).


Code: [Select]

      #include <SPI.h>
      #include <SdFat.h>
      #include <SdFatUtil.h>
      #include <SFEMP3Shield.h>
      #include <WiServer.h>
      SFEMP3Shield MP3player;
      #define WIRELESS_MODE_INFRA 1
      #define WIRELESS_MODE_ADHOC 2
      unsigned char local_ip[] = {192,168,0,101}; // IP address of WiShield
      unsigned char gateway_ip[] = {192,168,0,1}; // router or gateway IP address
      unsigned char subnet_mask[] = {255,255,255,0}; // subnet mask for the local network
      const prog_char ssid[] PROGMEM = {"XXX"}; // max 32 bytes
      unsigned char security_type = 3; // 0 - open; 1 - WEP; 2 - WPA; 3 - WPA2
      // WPA/WPA2 passphrase
      const prog_char security_passphrase[] PROGMEM = {"XXXXXXXXXXXX"}; // max 64 characters
      ////////////////////////////////////////////////////// no need to edit below ////////////////////////////////////////
      // WEP 128-bit keys
      // sample HEX keys
        prog_uchar wep_keys[] PROGMEM = {
        0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, // Key 0
        0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // Key 1
        0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // Key 2
        0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 // Key 3
      // setup the wireless mode
      // infrastructure - connect to AP
      // adhoc - connect to another WiFi device
      unsigned char wireless_mode = WIRELESS_MODE_INFRA;
      unsigned char ssid_len;
      unsigned char security_passphrase_len;
      // End of wireless configuration parameters ----------------------------------------
      // IP Address for www.XXX.com.au 
      uint8 ip[] = {111,111,111,111};
      // A request that gets the latest data for site
      GETrequest getSite(ip, 80, "www.X.com", "/output.php");

      void setup() {
          //start the shield
        // Initialize WiServer (we'll pass NULL for the page serving function since we don't need to serve web pages)
      void loop(){
         // Check if it's time to get an update
        if (millis() >= updateTime) {
          // Get another update one hour from now
          // Get another update every 30 seconds
          updateTime += 1000 * 30;
        // Run WiServer
        //start playing track 3


Pin 10 seems to be used by the WiShield too:


You also include the SD library. Do you have an SD shield connected too?


Thanks Pylon. you were right about pin 10 so I have remapped that.
the MP3 card requires the SD library according to Sparklabs - it has an onboard SD slot.

I have sorted all but one problem as I see it. If I connect pin 13 -  the Serial Clock (SCK) pin to the MP3 shield it works but the wifi doesn't. Disconnect it from the MP3 shield and the wifi works perfectly. I'm assuming i have an issue with an SPI conflict. I have the two shield using different SS (or CS) pins.

Any idea how to get them playing nicely together?



Don't forget, the CS has to be separate for every device on the SPI, it's not per shield. So if your MP3 shield has some MP3 hardware that uses the SPI and an SD card on the same interface you have to have at least 3 CS lines (maybe more, I don't know what else is on it).

From this description


(see "Using the SPI for something else as well" on that page)
it seems that the SPI bus is used for the shield constantly and you have to stop the stream temporarily to do other stuff on the bus. I'd stop the stream while communicating with the WiFi shield and start it immediately afterwards. If this interrupt is short enough you probably won't hear anything.


I think this is a total road block for my project.
The idea is that the wiserver is checking a web feed and changing the music playing accordingly.
This means that currently the wiserver connects to the web service every 30 seconds. If I have to stop the mp3 stream to allow the wifi to connect its going to be a far from desirable result. Large gaps In the audio.

I'm thinking I may need a different approach maybe two arduinos
One wifi enabled triggering one that is the mp3 player.

Any thoughts appriciated.



If it's just to change music, why not do it in between songs?


I was after an immediate control rather than waiting but yes I see your point I could wait until the song ends to check the server. Any ideas if the wifi will stay connected while the SPI in under the control of the Mp3 player. It currently takes a minute or two to connect so waiting until the end of the track would cause big delays.


Stopping the stream does not mean your music gets interrupted. That depends a lot on the time you wait for the WiFi. Stream data is buffered on the shield, they don't tell exactly how long the buffer is good for but should be OK for short data transfers.

The easiest would probably be to buy a WiFi Bee, which is more or less an Arduino with a WiShield in one XBee sized package. http://www.seeedstudio.com/wiki/Wifi_Bee
This way you don't have to change your code and have simple ways to connect the two.

If your server needs a minute or two to answer a request you have to deal with that problem first (not an Arduino problem I guess).


Sorry pylon it's not the server that takes a minute or two it's the wifi shield establishing a connection.
Can I assume that the wifi bee will leave the SPI free for the mp3 shield? If so I'm getting out my credit card now.


Just looking at options could I get a diamondback controller card. The built in wifi could solve the problem.


If you wanna take the diamondback as a replacement for your UNO with WiShield you won't get lucky with it. The WiFi part of the diamonback is connected directly to the SPI interface and uses the same mechanism as the solution with the two separate boards.

The WiFi bee is it's own little Arduino and you can use any communication line you wanna use to communicate to the main Arduino (SPI not in hardware), usually the serial line but I prefer the I2C.
The SPI is free because the pins (of the ATmega328 on the WiFi Bee) are not connected to the Bee connector.


Thanks Pylon. I have fixed the issue by adding a Arduino nano I had laying around. the nano gets the mp3 player and is simply triggered by the UNO with the wifi. simple in execution just seems a bit over engineered. But hey it works so let it be yer :-)

Go Up