Makuna/NeoPixelBus
1
0
Fork 1
mirror of https://github.com/Makuna/NeoPixelBus.git synced 2025-08-09 22:04:27 +02:00
Code Issues Packages Projects Releases Wiki Activity

Updated FAQ #5 (markdown)

Michael Miller
2016-03-28 15:53:44 -07:00
parent 01537cd99c
commit a40475ea64
1 changed files with 10 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files

17
FAQ-#5.md

@@ -2,22 +2,25 @@
There are two pieces to this question really. One is how much time does it take to send the data to the NeoPixels. And the other is how fast can your code provide the next set of changes so they can be sent.
#### How much time does it take to send the data to the NeoPixels?
The wire protocol takes 1.25us per bit. If you are using a 3 element Rgb LEDs, that's 30us per pixel. Add 50us latch between updates, and a little overhead of about 10us, and this should be what to expect.
The wire protocol takes 1.25us per bit. If you are using a 3 element Rgb LEDs, that's 30us per pixel. Add 50us latch between updates, and a little overhead of about 100us, and this should be what to expect.
For 4 element Rgbw LEDs, its 40us per pixel.
```
RGB microseconds = pixelcount x 30 + 50 + 10
RGBW microseconds = pixelcount x 40 + 50 + 10
RGB microseconds = pixelcount x 30 + 50 + 100
RGBW microseconds = pixelcount x 40 + 50 + 100
```
Depending on the "method" used to send this data, the actual time the CPU takes will vary greatly.
For most platforms, the CPU will be doing the work. So the cpu will consume time to do all the work except for the latching. So you end up with...
```
RGB cpu microseconds = pixelcount x 30 + 10;
RGBW cpu microseconds = pixelcount x 40 + 10;
RGB cpu microseconds = pixelcount x 30 + 100;
RGBW cpu microseconds = pixelcount x 40 + 100;
```
Once its finished with raw data, it will return from 'Show()'. It does not wait on the latch time before returning, but it will wait on it if you call `Show()` again before the latch was finished being sent.
For the `NeoEsp8266Dma800KbpsMethod`, it uses the hardware to send the data. But it still does have to copy the working buffer into the DMA buffer. This copying of the buffers will also vary depending on the pixel count, but now we are talking on the order of 0.05 us per pixel if running at 80mhz. 160mhz will make it even less time. Once its copied, it will return from 'Show()' to let you start preparing the next frame of data.
On some tests I ran for a 3000 pixel strip, I found the following:
For the calculation, it comes out to about 90100us.
For the `NeoEsp8266BitBang800KbpsMethod`, it took 91518us to send the data. 1500us more overhead than the calculation would account for.
For the `NeoEsp8266Uart800KpbsMethod`, it took 89679us to send the data. This is faster due to the 128 byte hardware buffer.
For the `NeoEsp8266Dma800KbpsMethod`, the default for Esp8266, it took 904us to copy the data. This is faster as it uses the hardware to send the data. But it still does have to copy the working buffer into the DMA buffer. This copying of the buffers will also vary depending on the pixel count, but now we are talking on the order of 0.7us per pixel if running at 80mhz and 0.4us per pixel at 160mhz. Once its copied, it will return from 'Show()' to let you start preparing the next frame of data.
#### How fast can my code provide data for the NeoPixels?
This truly depends on how complex your sketch is. How many animations, how complex the animations, and what other things are you doing.