Skip to content
Michael Miller edited this page Jul 17, 2023 · 5 revisions

How many pixels does this library support?

The primary limiting factor to the number of pixels you can drive with this library is the memory you have on your Arduino. This library requires a working buffer that contains state for every pixel on the bus. The next limiting factor is how fast you want to update them, as more pixels takes longer to update. The topic on speed is covered in FAQ: How fast can I update my NeoPixels

The amount of memory required does vary based on several factors.

The first factor is what type of pixel you have. If your pixels are three element pixels, RGB; then they require 3 bytes of data per pixel. If your pixels are four element pixels, RGBW; then they require 4 bytes of data per pixel.

RGB buffer size in bytes = number of pixels * 3
RGBW buffer size in bytes = number of pixels * 4

The second factor is what "method" is used to send the data. For most AVR platforms the method used is similar and requires only a few extra bytes beyond what was listed above to manage the buffer. But there are several non-AVR that will incur more memory usage.

I2S and DMA on ESP:

The NeoEsp32I2s1Ws2812xMethods and similar. This is the default method for ESP32.
The NeoEsp8266DmaWs2812xMethod and similar. This is the default method for Esp8266.
You can find more information on these methods in the NeoPixelBus object page. These "method"s not only require the above buffer, but it also requires a DMA buffer for the hardware to use. This DMA buffer requires four bytes per byte used from the primary buffer.

DMA RGB buffer size in bytes = number of pixels * 3 * 4
DMA RGBW buffer size in bytes = number of pixels * 4 * 4

This equates to approximately 3000 pixels for RGB, and 2250 pixels for RGBW; as long as you don't have anything else that requires much more memory. But these methods come with the benefit in that they don't take much of the CPU to send the data like all the other methods; so, you can then use the freed CPU cycles to do other important tasks.

RMT on ESP32

The NeoEsp32Rmt1Ws2812xMethods and similar. This is the default method for ESP32S3 & ESP32C3. These "method"s not only require the above buffer, but it also requires a "sending" buffer of the same size for the hardware RMT to sample. While the RMT hardware is sending, it allows your sketch to continue do other things while it will interrupt periodically to request a refill and translation for its internal DMA buffer.

PWM and DMA on NRF52840 (Nano 33 BLE):

The NeoNrf52xPwm0Ws2812xMethod through NeoNrf52xPwm3Ws2812xMethod and similar. This is the default method for NRF52840.
These "method"s not only require the above buffer, but it also requires a DMA buffer for the hardware PWM to use. This DMA buffer requires 16 bytes per byte used from the primary buffer.

DMA RGB buffer size in bytes = number of pixels * 3 * 16

These methods come with the benefit in that they don't take much of the CPU to send the data like all the other methods; so, you can then use the freed CPU cycles to do other important tasks.

Clone this wiki locally