Go Down

Topic: Simplifying control of LED 2801 square pixel (Read 3 times) previous topic - next topic

KirAsh4

Oh yeah, in your sample code, any loop after the first one will not run because you've set 'done' to 1 in the first one.  So the second loop, when it checks whether done = 0 and finds it false, it skips the loop and moves on.  This is what I mean with, if you're setting everything in one shot, you can encapsulate the whole series of loops with one break.  If that's even necessary.  Not knowing how you plan on implementing it, I don't really know what would work here.

TSD_80

Hi there,

Is there a specific reason for why FastSPI_LED.h is recommended for this task rather than SPI.h? There will be 80 LEDs in total.

Thanks

KirAsh4

The SPI library is exactly that, a library to control the SPI functions on an Atmel.  The FastSPI_LED however is a library written to control a bunch of different types of LED drivers, including the WS2801.  So, if you only use the SPI library, you still have to write the various functions needed to control those LED drivers.  Whereas with FastSPI_LED, it's already done for you.  You just call the necessary functions.

TSD_80

Hi KirAsh4,

Thanks for your feedback. I now have the FastSPI doing what I want it too - hurray! The following step was to add Ethernet functionality so it's now calling a variable PHP file on a web server. As soon as that was added, we're getting 'disco lights' on the LEDs - specifically when it's connecting via the ethernet. Once the code is triggered the lights behave correctly, then go back to disco lights when its finished. This didn't happen when we're using the regular SPI but something on FastSPI sets it off. Is this a common problem that can be worked around? We're using an Arduino Ethernet so I'm wondering if there's a PIN conflict on the default 11 and 13... Could that be? Best

KirAsh4

That is because the ethernet add-on that you're using is more than likely also using the SPI bus.  And since the  LED drivers don't have a select pin, just about anything that goes over the SPI bus will in some way or another mess with the LEDs.  That's exactly what you're seeing.  You have two options:

a) don't use FastSPI.  Use bit-banging instead on two completely different pins, which will leave the SPI open for other devices, or
b) use a gate to control the LEDs, and you can still use FastSPI.  It gets a bit trickier, but it can be done.

For my own project last year, I went the bit-bang route.  I only had two strings of 20 LEDs each.  I used the analog pins (of all things) to control the strings, A0 and A1 for one, and A2 and A3 for the other.  Then I had an RF module on the SPI bus.

Note: bit banging IS slower than SPI, so depending on how fast you plan on sending data to the LEDs, bit-banging them may not work for you.  For me it was plenty fast still.

Go Up