#My library has few improvements: One separate buffer for your (big) framebuffer and second small internal bitbuffer for DMA. I overclocked the STM32F100 little bit (exactly twice the speed to 48MHz :Đ) and it works without issues. When I run similar code on old STM32F100 on maximal CPU freq 24MHz (F100 line is slow), I had big jitter when the DMA was battling with CPU interrupt bus access. The jitter is within the WS2812 specification so don't worry. The DMA has of course some small jitter but when you run this lib on anything above 40MHz it is fine. This is because DMA needs pre-processed data in specific format. If you have LED strip connected to the pin PB3 then the 3rd bit of each item in array is used. So you are wasting 93% of your array in RAM. So if you use one strip with ten LEDs then it creates the uint16_t array of length 240 (480 bytes) where only one bit of each item in array is used. On the other side if you use only 2 or 4 LED strips (outputs) then you are wasting your RAM because of the data organization in the library.īased on your longest LED strip the octo library creates an array uint16_r buffer. Because it can output data for all your 16 strips. The octo lib is great when you use lot of parallel strips. I have documented all approaches on my site. The I looked around and discovered that this is the approach that already OctoWS2811 library is using. So I've made some DMA tests and it appeared that I can use my code to precise generate necessary waveforms. The best solution is to keep the CPU free and let the DMA and timer do the precise timing. Some improvements can be made if part of the bits are generated by some HW peripheral for example SPI or PWM. This is implemented in NeoPixel library for AVR and ARM processor. The most easy approach would be implement blocking cycle-exact code in assembly that will spit out ones and zeroes as we need. WS2812B has specific communication protocol and it is necessary to bend some standard peripherals to use this protocol. Signal that buffer is changed and transfer new data Update your framebuffer here or swap buffers You have to trigger new transfer by setting the ws2812b.startTransfer = 1 Then you just call the ws2812b_handle() function. You can also have one big framebuffer and point the 'frameBufferPointer' to different places in your buffer. This is great if you would like to have 500 LEDs in one strip but you only need to repeat 8,16. When the framebuffer is shorter than the WS2812B_NUMBER_OF_LEDS the framebuffer wraps over, nothing breaks. You can also use one framebuffer on many outputs. If you need more parallel LED strips, increase the WS2812_BUFFER_COUNT value Set output channel/pin, GPIO_PIN_0 = 0, for GPIO_PIN_5 = 5 - this has to correspond to WS2812B_PINS In ws2812b.h you have to set few defines: The library is in the /src/ws2812b directory and example of init, redraw and effects are in src/visEffect.c file. Under this example below is explained how lib works under the hood If you like this library, please let me know, follow me subscribing to my electronics youtube channel with practical videos and teardowns will motivate me to make more content for community. It is possible to change the code to work based on other timer or STM F1, F2 or F4 line. Project is made in Atollic TrueStudio but you can compile it with any ARM-GCC. The DMA2 is necessary because only this DMA has access to the AHB1 bus where the GPIO peripheral is located. The example is implemented for STM32F4 line with TIM1 and DMA2. See my other repositories for L0, F1 and F3 port. You have to compile it with -Og or at least -O1 optimizations to take advantage of it. This is a memory and CPU efficient implementation of WS2812B library for STM32 processors.

Peak reflow temperature of ws2812b