SPI threaded or DMA?

I’m having a performance problem with SPI when sending serial data to RGB LED strips. I have about 550 LEDS in total and constructing a buffer to send seems to take very little time but the actual transmission is pretty slow.
I’ve tried messing with the configuration speed but the documentation is so poor that I really have no idea what that’s doing.
I was wondering if SPI is a software process or by some miracle a DMA one?. For example, if I set up 2 SPI channels and send half the data to one and the other half to the other will the DMA make it more efficient or am I flogging a dead horse.

(running FEZ Spider a-la Gadgeteer)

Thanks for any suggestions.

If you are suing Spider, we have a thing inside to make things run ads fast as a DMA if you use SPI.Write instead of SPI.WriteRead

Welcome to the community and remember to post a video :wink:

Yup, using Write:

            //Send data to the LEDS

Can you elucidate a little on the SPI config such as the speed setting and the setup - hold times?


Yep from there it is as fast as SPI can be. Maybe other code is slow not SPI. Check RLP.

The speed, setup and hold times are all dependant on the device you are trying to talk to. Take a look at the data sheet for your SPI device. You will find this information in the specification tables or the timing diagram.

Other things can influence these settings as well. For example if you have a long wires on your SPI bus you may not be able to use as high a speed. If you are daisy chaining many SPI devices together it might affect things as well.

It might also be how you are writing to SPI, can you post a code sample?

550! We definitely need a video of that. I’ve had no trouble using spi on a spider to drive an rgb strip about 10% (60) that long. Maybe start with something smaller to isolate the issue and work your way up?

I’m curious how this is set up.

Is it in a daisy chain where each module shifts the the data in and through or does it have a bunch of CS pins (or CS pins on a shift register)?

Which mode are you using?

Re: 550 Ok. I’ll put up a video but I think I’m going to have to split the data across SPI’s or maybe even add another Spider.

I’d really like to know more about the way the spider handles the SPI bus. Can I use two SPI connections simultaneously for example.

Re: Daisy chain? Yes effectively you chuck all the RGB data into one end of a long chain of LEDS. These use the WS2801 controller bye the way, and the data propogates along the chain.

I’m currently doing the actual data send in the timer tick handler. I’m thinking this might be a bad idea and will probably change it soon.

As far as the code goes its fairly simple:

byte[] _data =new byte[550*3]; // RGB data

//fill the RGB here


Simple as that really.

The docs are pretty useless on what the config settings mean. What is the speed setting?

You can download the porting kit and see how SPI is done if you like.

Like I mentioned, it is very fast internally but the overhead is slow. So sending 10 bytes 100 times is a lot slower than sending 100 bytes 10 times.

The way you are using it is really fast!

Are you declaring the array globally and filling it locally? Constructing an array can be slow or actually, if the garbage collector gets involved it will eat a lot of time.

What happens if you SPI write a counter value in a loop and ignore the array completely?

Maybe also try smaller chunks.

All speculation unfortunately. Would be best to look at the source.

i use spi on a cobra too, and the only solution is to make spi over RLP in this case.
speeds up writing operations dramaticely.



Runtime Loadable Procedures, a.k.a. native code. If you need to get closer to the metal, this is the way to go. There’s a whole forum here dedicated to this. Here’s a link to some documentation: http://www.ghielectronics.com/downloads/NETMF/Library%20Documentation/html/f608e398-6573-8adc-5d59-b904dfa3fcee.htm

If you’re interested there are some details of the finished project on my blog. Just google Bob Powell’s external monologue.


I still would like to see a video of those leds in action

Interesting, what that second “embedded” display for?

I had one Spider inside the model and the one visible was my debug machine that I plugged in and out when necessary.

Hey all. I just uploaded a video to that blog page.

I give a little tour of the project but please remember the video was done for my kids so the commentary is a bit simplistic.