I’ve got a fairly generic wiring question in regards to the various 4-wire SPI based LEDs. Since these things don’t have a slave-select pin, is there a good way to drive these when SPI is also needed to run some other device?
I’m driving these with an ATMega/Arduino based board, and want to also control a RFM69 radio module. I’d prefer not to use software SPI if possible. I was thinking there might be a way to use another pin of the Arduino as an effective SS pin to force the MOSI or CLK pin on the LEDs to ground when talking to the radio module, but I’m not quite sure how to go about that.
Any pointers would be greatly appreciated.
I figured I’d also share what this is for, as I’ve been working on some boards for running a distributed network of art pieces. Currently these communicate over RS485 and so require wires between them, I’m working on moving these to communicate over RF instead. https://youtu.be/_SjtJ5UlvZA
The ones here were WS2801, but I am switching to APA102 for my new stuff. Driving either the clock or data line to ground seems like the way to go, I’m just trying to figure out the right way to wire it considering that the CLK and MOSI output from the Arduino need to go to both devices.
It looks like the post you linked to uses an SPI multiplexer, which is something I’d rather avoid if possible.
What if you ran the SPI SS and CLK pins through an AND gate to the CLK in the strip? Then when its SS was high, it would pass the CLK signal through, but when SS was low, The gate output to the strip CLK would stay low as well.
The SPI CLK would go straight to other devices, bypassing the gate.
@dougal that’s a great idea, and should work. I’ve been getting back into hardware design for the last couple years, but I haven’t thought about discrete logic components since I was an undergrad in the 90s. Thanks.
My limited electronics knowledge wants to know more. Could you recommend a chip/part number so I could look at this a bit more to try to understand it?
Why? The ATMega doesn’t have a FIFO buffer, so there’s literally no way to make LED communication faster, even if you use hardware SPI.
I too was of the “I should always use hardware SPI” persuasion until I realised it makes literally no difference on the AVR. Now, if you were using an ARM board like a Teensy…
I was unaware that hardware SPI wouldn’t actually be faster on AVRs, so if using software SPI is just as good that would simplify my setup. I have been considering trying to redesign my boards based on the Teensy, but I don’t think I can get to that before I need to have working ones this summer.
As for trying to avoid an SPI multiplexer, at most I think I’ll be running ~300 LEDs with these (and more commonly <100) so the extra complexity there would just be a hassle. And yet more things to squeeze into Eagle’s free size limit (I already have the radio module, a MPR121, RS485, and all the stuff needed for the AVR, plus a bunch of screw terminals)
EAGLE’s size limit is a very artificial restriction that can be easily avoided by using a FOSS package like KiCad or gEDA (note: I only recommend gEDA to hardcore masochists). I figured that if I hit EAGLE’s free size limit even once, I’d just end up switching to another package, so I chose not to waste my time learning it.
It is a very artificial limit, but when I started learning KiCAD wasn’t anywhere near as complete as it appears to be today. I’ve considered switching but there is still better tooling and support in Eagle, so I’m not ready to make the jump yet. Currently I’m using the size limit as an excuse to figure out how to move to mostly SMD parts for new boards, but this project is just adding a radio to an existing board.
Ah, yes you definitely want to move to SMD parts. Get yourself a hot air rework tool and some solder paste, it’s a lot easier than you’d think. Just don’t try to solder SMD with an iron – even with paste, that way madness lies.
I’ve actually gone some ways down that road, I had the rework station previously but did a toaster conversion and built a PID controller for it a couple months ago.