Daniel, Thanks again for these details. Jitter in my terms meant that when trying to drive a long strand of WS2812’s, I would get random flashes, or colors jumping around.
I have tried some of the adafruit libraries vs FastLED’s and noticed with Fast, I would get the first LED in the path to randomly blink green. However, after reading your post,
perhaps my crummy little arduino is having issues with the signaling and causing this, not the library. I have 640 LED’s to light up, 8 strands of 80 to build a matrix.
I’ll pick up a Teensy 3.X and see where that takes me. I will also update my library, as I think I am on 3.0.2 instead of 3.1.x. I noticed last night that the dates on my library files were off. Thanks again for everyones hard work with these libraries and the support of the group!
And keep up the good work and feeding the homing cows.
I’m not sure how well 640 leds off of an arduino would’ve worked anyway, in the long term - that’s 1,920 bytes of ram - just for your led data. Most arduinos are only 2kb of ram, the leonardos are 2.5kb, and the megas are … I think 16? And the system needs more than 80 bytes of other ram to be happy. It is possible that you were having issues with led memory randomly getting overwritten by other code
@Daniel_Garcia yup, I went through all that a couple years ago when I wrote the optimized timer0 ISR. It’s really tough to get proper 32 bit rollover and exactly 1 millisecond by post-processing a 16e6/16384 incremented count.
At the time, I concluded the only viable way would involve keeping a 48 bit count to post process. Plenty of people will complain if your code has a roll over problem in 49 days, but 8919 years might as well be “never”.
@Daniel_Garcia Understandable. Honestly I haven’t even made it to the big 640 yet. I am still having issues with the first 80. I am not sure what the error is yet. I am thinking of bringing it in to work and putting it on a scope.
Was out for the day, but now have time to test beyond the quick IR test I did this morning. Am finding that my display routines are blinking a lot (when compiled via Stino). I need to narrow down very specific test conditions though, as it’s not consistent/reportable. For instance, it appears to compile/display correctly with the Arduino 1.0.5-r2 IDE, but flashes when I use Sublime Text and Stino. . .
The interrupt handler in the IRLRemote takes a bit of time to run. Remember, the interrupt handlers only get about 90-110 clock cycles, otherwise the library is going to cut off writing out your frame. As it is, I may have the threshold set a little bit too high. Looking at their interrupt I see multiple levels of function calls as well as lots of 16 and 32 bit math. On avr 16 bit math takes at least twice as long as 8 bit math and 32 bit math takes at least 4 times as long.
As it stands right now, I’m not convinced that any of the IR libraries out there are efficient enough in their handling of interrupts for you to use, and I still stand by my recommendation that if you want to use the IR libraries you either move to ARM or switch to LPD8806/APA102 for leds.
You get a lot more bang for your 90 cycle count on a 16Mhz arm processor than you do on a 16Mhz AVR processor, and when you have a 48Mhz clock (360 cycles!) or a 96Mhz clock (720 cycles!) you have even more headroom.
Oddly enough, the IRRemote library, with it’s 50µs interrupt timing may also have an efficient enough interrupt handler to run in the time that you have (the 90-110 clocks). It’s a bit dicey though, still, even there. At some point I will stop trying to pretzel twist the library to support this use - especially since there isn’t much more I can do with the library - it’s all in the hands of the interrupt writers, and instead tell people “Want IR? Use ARM or switch to APA102/LPD8806.”
I went to a two processor setup for the tunnel project and with how cheap processors are, I think this makes sense considering how complicated it gets doing otherwise. Two arduino minis cost $6 Now. Connect then with I2C and have one do the irr remote or sensor and I one to do the light…
Soon there will be Arduino-compatible ARM boards in the $12 price range… able to do FAR more than those two $6 AVR minis, and without lots of slow I2C communication between them!
Al of this is pointing more and more into developing customized FastLED specific controllers that are blazingly fast. Have the library able to fallback to the slower, stock Arduino cores, but also run on dedicated FastLED optimized hardware and cores.
The current ARM boards are really pretty good already. We love the Teensy 3.0 and 3.1. The RFduino and SparkCore/Photon are great, too, and the next generation of ARM Cortex boards will probably continue the trend.
In several months to maybe a year, I think we’re going to see a LOT more ARM boards, both on a low end using Cortex-M0+ (same or lower cost than AVR) and high end boards with Cortex-M7. Especially when M7’s with TCM start appearing, we’re going to have microcontrollers at 300 to 400 MHz running on all single-cycle memory, which is competitive in performance with Raspberry Pi. Awesome things like simple video processing and 4+ channel spacial audio effect will soon become possible on microcontrollers.
I was not sure, what the result of that discussion is. I tried FastLED 3.1 and IRLremote 1.7 and it crashes when using the remote control.
as both parts work alone reliable I made an ugly hack: as my sony remote sends every code 3x, I just trigger with the first IR signal a delay(1000) in the main loop. then the following ir code is received correct. the idea behind: delay stops the WS2812 show (disable interrupt) and the delay loop can be interrupted by irlremote. for my application i can accept a stop of the light-show. I’m sure it is not perfect, the implementation has room for improvements, it does not analyses the source of the crash, but after 30 min coding, it works good enough for a demo.
yes, it’s breaking the show, but for me it is ok. I use it for changing the animation. not so perfect for setting absolute brightness, but still acceptable. (compare it with the setup off a video beamer) finally it is also about price and effort, and what I had in my box (ic, parts)
I’m not sure, what you mean with “it”. The led pixels? Not that I’m aware. What had made me wonder: the shift in the color to pink (when it should be white). But I assume it was because of power supply. I used a old Iphone accu. But it worked for about 2 hours and that was fine to impress the people. (where did you bought it???) Might also be the change of environment. I developed it with no daylight, and the “show” was with daylight and neon light.
I am not sure what the error is yet. I am thinking of bringing it in to work and putting it on a scope.