Your new topic does not fit any of the above??? Check first. Then post here. Thanks.

Moderator: igrr

User avatar
By j0hncc
#16949
Makuna wrote:MORE PROGRESS!
...
The interrupt system on this chip is more advanced that AVRs, and it looks like the Arduino IDE implementation for noInterrupts, Interrupts just calls in a ROM method that I suspect just disables all level 0 interrupts leaving the level 14 (a lot of the WiFi stuff) alone. I dug in and found a way to disable even these. I DO NOT RECOMMEND DOING THIS FOR A LONG STRIP OF LIGHTS.
...
GitHub Makuna/NeoPixelBus


Anybody have an idea what "LONG" is?
User avatar
By j0hncc
#16952
andrew melvin wrote:I'm not sure I understand your second bit? Are you saying that the do while causes a block in operations until it is time to update based on clock count?

The implementation I have just uses timers, so every x mills the strip is updated, which means i don't have any flickering, its pretty smooth actually. I can actually run it whilst having two instances of the PID lib, the MQTT lib, web server lib... and it still worked just fine. I got MQTT to publish the number of iterations though my loop... per second, and it was >10,000 with all that.


Hello Andrew,

Can you point me to your implementation? And, which loop are you saying > 10000 iterations per second? Is it in an example that you can share?

Thanks!
John
User avatar
By Makuna
#16958 (confirmed and corrected numbers)
Based on the WS2812 spec, a single bit takes 1.25us, with 24 bits per pixel, comes to 30us per pixel. Do the math for the number of pixels you have.

Using timers may not help. Level 14 interrupts will interrupt and or block the timer interrupts also.
1.25us is about 100 cpu cycles (80 mhz version), the documented error supported is .15us (12 cpu cycles) per bit. 12 cycles is not a lot of time for an interrupt to be serviced and returned before it starts effecting the timing.
Last edited by Makuna on Sat May 09, 2015 10:58 am, edited 2 times in total.
User avatar
By j0hncc
#16962
Makuna wrote:Based on the led spec, a single bit takes 1.2us, 24 bits per pixel, do the math for the number of pixels you have.
Using timers may not help. Level 14 interrupts will interrupt and or block the timer interrupts also.
If I remember correctly, 1.2us is about 46 cpu cycles (80 mhz version), the documented error supported is .15us or about 5 cpu cycles. that's not a lot of time for an interrupt to be serviced and returned before it starts effecting the timing. (I will confirm these this weekend).


Thanks for your reply. Based on those numbers we should not even expect flawless operation of ONE pixel?

What is your experience? How many leds have you driven and been satisfied with the result? And more specifically, no WDT resets?

This guy seems to be getting good performance driving 7 strings of 36 leds 8-12 times per second. With Graphic Eq A/D (MSGEQ7) and web server using nodemcu:
http://www.whatimade.today/graphic-equa ... q7-ws2812/

Cheers,
John