Makuna/NeoPixelBus
1
0
Fork 1
mirror of https://github.com/Makuna/NeoPixelBus.git synced 2025-08-10 06:14:26 +02:00
Code Issues Packages Projects Releases Wiki Activity

Updated FAQ #5 (markdown)

Michael Miller
2016-03-28 16:17:38 -07:00
parent a40475ea64
commit f53dd449c3
1 changed files with 4 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

7
FAQ-#5.md

@@ -17,10 +17,11 @@ For most platforms, the CPU will be doing the work. So the cpu will consume tim
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.
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 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.
* 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.
* For AVR, it doesn't have enough memory for 3000. When I tried timing smaller counts using `micros()`, it showed extremely unreliable time values. This leads me to believe that `micros()` is not good enough for timing code and I am left with no alternative.
#### 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.