Ethernet, OctoWS2801, and IR Library

[Technologic]

Hello all. I searched but cant seem to find some info on if I will have timer and/or pin compatibility issues with the Ethernet, OctoWS2801, and IR Libraries? If so anyway around it? Long story short I want to try sending E1.31 to a teensy 3.1 and then have it blast some RGB values through an IR led. I would pick up those values on an IR reciever which would drive and RGB led. I know some variation of this is possible. IE... Glow with the show, etc

Thanks for any and all help.

 

[PaulStoffregen]

This combination should work, if you're using IRremote for receiving. It can receive on any digital pin, so simply choose a pin that isn't consumed by OctoWS2811 and Ethernet.

Of course, as far as I know, nobody has tried and reported using this combination. If you do run into problem, just post about it here. If there's a library conflict, I'll investigate. Please follow the "forum rule" when posting about any tech problem!

 

[MichaelMeissner]

Well, in general the problem with IR is you need to know exactly when the pulse comes in. If you use a neopixel/ws2811 library that turns off interrupts while it is updating the LEDs (because the ws2812b LEDs have rather strict timing guidelines), you might not get the interrupt for the IR receiver in time for it to decode its protocol. The Adafruit Neopixel library does block interrupts during the whole update process. I haven't used the octows2811 or fastled libraries to say whether they are better. Various other things require timing like servos, PWM, etc.

One way to deal with this, is move the IR processing off to a separate processor, and communicate with the Teensy when it has received a complete sequence. I bought this chip some time ago, but I haven't actually hooked it up and used it: http://www.ebay.com/itm/Infrared-Re...887?pt=LH_DefaultDomain_0&hash=item51a1e7ef87. You could also just use a second Teensy, or a lower cost microprocessor (Trinket, Digispark, bare chip) to do the processing.

 

[Technologic]

Thanks guys.

Paul I forgot to mention that I would also have an IR transmitter to repeat what it was receiving to other devices for easier distribution.

Michael that is a good point with the neopixel Lib. I believe I read on the adafruit forums that someone was having a problem running serial higher then 4800bps without data corruption. I think that the OctoWS2811 shouldnt have that issue but regardless I would be lucky to get that high a data rate over any real distance.

 

[Gavin]

OctoWS2811 is great, it's really light on the CPU as advertized, doing all the work with DMA on Teensy 3.1
There are a couple of minor issues with using the library that perhaps can be fixed:
I would think that you would want it to be as compatible with Limor's NeoPixel lib as possible.
There are a few differences I've found so far:
Adafruit_NeoPixel OctoWS2811 comment
Color color Change the name of this structure? (I did this in my copy)
setPixelColor() setPixel() Change the name of this method? or make an alias some how?
setBrightness() missing Can we add this? See discussion below...
getBrightness() missing Can we add this? (Less critical than above)
setPin() missing not really needed since Octo is byte wide already
clear() missing Now this one looks easy to add, but there is an issue:

Clear the draw buffer? or clear the frame buffer? or both? Probably drawBuffer is safer, but what about if there isn't one?

For setBrightness() you could implement it as a shift if you think it takes too long to multiply the whole array
I'm thinking it should go between the draw and frame buffers, i.e. do the scaling during the move of data from drawBuffer to frameBuffer. What do you think?


Also I notice that 6 bytes are reserved for each pixel, but only 3 should be needed as each one gets 3 bytes (RGB) of data. Is there a reason to double the space used for the buffers?

Thanks again for a great library, it got me to buy into Teensy, and saved me from writing a byte wide neopixel library from scratch.