I've recently begun experimenting with some awesome 2812B LED Strips, and I've created some really cool patterns so far. My desire was to be able to control the LED strip programs using an IR remote, but the creator of the LED Strip library said that it wouldn't be possible because of how the LED Strip library works.
So ... I was trying to figure out another way. I'm sure there are other methods of dual-arduino communication, but I wanted to see if I could figure something out on my own. I came up with two ideas, but I wanted to see from you guys about feasibility first. Both ideas center on one Arduino (sender) having the IR Remote send data to an Arduino (receiver) that has the LED Strips attached.
Option 1 - Digital Pins
My idea here was to configure several digital pins on the sender unit as Outputs, and the same digital pins on the receiver unit as Input. The LED Strip effect would be selected by the sender unit setting certain outputs to HIGH, and then using another output to trigger the input read. In other words, for one pattern, set pins 8 and 12 to high, 7 to low, and then set pin 2 to HIGH to trigger it. Another pattern would be to set 8 and 7 to high, and 12 to low. The question would be, would this work? And what other connections would have to exist - other components, or a common ground connection with a resistor to ground on each used pin?
Option 2 - TX and RX Pins
My second idea was to hook the TX to RX, RX to TX, and then open serial communications on both Arduinos using the dedicated TX and RX pins (0 and 1) on each Arduino. But I'm not sure if additional wires, such as a common ground, or extra components, would be necessary.
I'm also going to investigate some other options - I've heard of I2C and I'm also looking into Bluetooth, but I want to see what other methods I have at my disposal.
Serial would be my choice, if you really can't bully the two libraries into working together. You need a common ground, you always do (except when you can't have common ground, and then electrical communication becomes considerably harder)
That said, it should be possible to hack up the libraries to play together. What on earth are the libraries fighting over? Did they just both pick the same timer to use?
There are multiple WS2811/12 control and IR remote libraries out there - I suspect you could find a combination that would play together. Each one needs a timer (arguably), but I can't imagine how to squander two with either task, and the '328 has 3 timers, and one is used for millis() and delay(), so that leaves two timers. And you need two.
@DrAzzy - Well, I tried both the FastLED and Adafruit libraries, and neither one worked. I posted to the FastLED forum, and here was the developer's response:
"The timing protocol for WS2812 leds requires disabling interrupts while writing out led data, and the IR library relies on interrupts to read the IR data, which means that if you're using the remote while the library is writing out led data, then it is going to miss part of the ir signal and misinterpret it.
There isn't really any way around this - switch to 4-wire leds (like the APA102 (adafruit sells them as Dotstars) or the LPD8806 or WS2801) or, alternatively, use the teensy 3/3.1 as your controller, where I have a solution that allows interrupts to run, even while using WS2812 leds."
If you right click the avatar and "view image" you should see the original image, or something close to it. If you really cannot recognise it, I will reveal it.
scodavis:
"The timing protocol for WS2812 leds requires disabling interrupts while writing out led data, and the IR library relies on interrupts to read the IR data,
So does the Serial library.
If you must avoid using interrupts you could probably devise a slow protocol in which the sender puts control wire A HIGH to say there is data on wire B and it keeps that setting until the receiver changes control wire C to show that it has received the bit. Then the receiver is in charge of the timing which can be erratic and still work.
If you could afford, say, 4 I/O pins as well as the control pins you could transmit 4-bit values at one time - i.e. a choice of 16 settings.
(I'm not sure that is perfectly workable description, but it should convey the idea that is in my head).
Paul__B:
If you right click the avatar and "view image" you should see the original image, or something close to it. If you really cannot recognise it, I will reveal it.
If you must avoid using interrupts you could probably devise a slow protocol in which the sender puts control wire A HIGH to say there is data on wire B and it keeps that setting until the receiver changes control wire C to show that it has received the bit. Then the receiver is in charge of the timing which can be erratic and still work.
If you could afford, say, 4 I/O pins as well as the control pins you could transmit 4-bit values at one time - i.e. a choice of 16 settings.
(I'm not sure that is perfectly workable description, but it should convey the idea that is in my head).
...R
Yes, I see what you are saying there, and what you described is basically my "Option 1" that I described up above. It's not the best solution because of the choice of just 16 settings, but it's better than nothing. Good idea with having a Pin C to do a confirmation prior to setting the control pin A back to low.
Two further questions on this, then - first, would I only be able to do this using the non-PWM pins, or would the PWM pins work for this as well? And second, could you explain what an interrupt is? I must confess that, while I've heard the term many times, I have no idea what it means in this context.
scodavis:
Two further questions on this, then - first, would I only be able to do this using the non-PWM pins, or would the PWM pins work for this as well? And second, could you explain what an interrupt is? I must confess that, while I've heard the term many times, I have no idea what it means in this context.
You can use any pins for digital I/O. You can only use the special PWM pins for PWM and the special analog pins for analog input.
An interrupt is a concept in which the computer (Arduino in this case) is caused to stop the task it is doing in order to do something else. When the something else is finished it will return to continue where it left off and the original task will generally be unaware that it was briefly abandoned. It's the same as the doorbell interrupting you while reading a book. You go to the door and take in the parcel. Then you go back to your book. In the computer there is a background process that is identical to putting a bookmark to keep your place in the book.
Interrupts can be triggered in a variety of ways including by the Timers built into the Arduino and by changes in the voltage on the I/O pins. When an interrupt is triggered it causes a piece of code called an Interrupt Service Routine (ISR) to run. You should keep the code in an ISR as short as possible. See Nick Gammon's interupt tutorial.
](