Sharing SPI Bus between Music Sheld and Connect Shield

I’ve written a music player based on the RLP driver written by @ godFather89 at this link: Dropbox - MyMP3v7_src.zip - Simplify your life

I ported @ godFather89’s RLP code to the Panda II and Music Shield. I’m now able to play MP3 and FLAC files from the SD card… it works beautifully :slight_smile:

The Music Shield uses SPI1. I now want to add the FEZ Connect Shield, so that I can implement the code to play Internet radio streams. The problem is that both shields use SPI1. I’m not very familar with SPI, but I’ve read that the bus can have multiple slaves controlled with individual CS lines. I think I would need to cut some traces on one of the shields to accomplish this, but before I do that I would like to know if it is even feasible to share SPI1 between the Music Shield (which I have control of in my code) and the Connect Shield (which uses GHI’s premium WIZnet driver)?

A second question: If I switch to the Cerbuino Bee, I think I will have a similar problem because it looks like the network driver on that board also uses SPI1?

Thanks.

Yep, you can share SPI lines (that’s it’s intent) and you just need dedicated CS lines for each device. I don’t have a Connect shield so I can’t tell if there is the ability to nicely change the CS pin or not, but the Wiz5100 class does have the ability to change that pin as needed, as your hardware dictates. So that part should be fine.

Ultimately your challenge is the pin definition and the inflexibility of most shields to be able to move the pin’s function. Should be something you can “fix” with a little work, as you say. That means irrespective if this is on CerbBee or Panda, your pin clash will still need a resolution - although you would not be using the Wiz shield there, you’d use the ENC28J60

@ Brett - Thanks, but I’m still don’t understand how the two drivers will coordinate access to the SPI bus. They would be running in different threads, and a third thread would be reading data from the network driver, and feeding it to the music shield driver. Won’t there be collisions? Also, won’t this halve or at least reduce the throughput to/from the network and to/from the music shield?

If multiple thread are involved then you will need to synchronize access to the shared SPI bus.

@ Architect - But how do I do that if one of the threads is inside the GHI WIZnet driver?

Sorry, I don’t think you need to worry about this. SPI driver layer should make that independent to you. It should do autonomous actions, meaning it will (should?) lock the bus, lower CS, send the data, raise CS, and unlock the bus. You should never get interactions between the two devices even if on separate threads causing issues here.

@ Brett - Good point! I just need to make sure I do a similar thing in my RLP driver.

Thanks @ Brett and @ Architect. I’ll give this a try.

I’ve had no issues running a music shield and connect shield (and a RS232 shield) on a Panda II. It is running your web server code plus GHI’s music shield code (& samurai’s stream extension). I’m not totally stressing the system, but I have not seen/head any issues.

@ eolson - very cool!

Don’t you have a conflict with the SPI CS for the music shield and connect shield?

Have you been able to load the FLAC plugin and play FLAC files from SD card? I couldn’t get the playback to work smoothly, and that is why I started using @ godFather89’s RLP driver.

@ jasdev - make sure that XCS and XDCS are high before exiting your native code. Entering the native code again to play the next bunch of data then set XDCS low again. All threads are stopped while your native code is running.

I had trouble getting smooth, high-quality playback with no delay or noise. I had the best luck with ogg. It was good enough for my application, so I moved on.

I assumed the boards were designed to work together. SPI clk/mosi/miso were common (D11-D13). Reset is common. The connect uses D10 as a SPI select. The Music shield uses A4 & A5 as SPI selects (dataCS and cmdCS). Plus the music shield has the DREQ output from the vs1053 hooked up to D4. The green LED on the music shield is the same as the red LED on the connect (D8), but the music’s red LED is unique (D9)

@ RobvanSchelven and @ eolson - Thanks for the info. I’m going to attempt to get the RLP music shield driver working with the Connect shield, but first I need to do some cleanup on the app to get a little more ROM and RAM space.