Closed mnemocron closed 3 years ago
I just tested it again on my other computer with a fresh install of the CubeIDE and it worked. Somehow my installation seems to be f-ed up. I'll close the issue if it is resolved by a fresh install.
It is working with a fresh installation of STM32CubeIDE 1.7.0
Apparently that was not it.
On the f303re Nucleo 64 Board the PC0 PC1 work fine, but when I change it to PA5, only a bunch of ones are output all the time. Any idea what I need to change?
never mind, found the line ws2812b.item[0].channel = 5;
for PA5
Glad it still works and people are using this lib :)
The documentation regarding the settings spread across multiple files is a bit sparse. But I finally figured it out. It is a pretty darn good example of DMA usage, Thanks a lot! :)
Meanwhile I adapted it to use TIM4 instead of TIM2 (because of PWM) and CC3 event instead of CC1 (because it blocks DMA1_ch1 for the ADC)
And then a few lines to work with RGBW type LEDs.
I am having problem making this work. I tried to complied the lib but it is giving error and warning.
Description Resource Path Location Type 'ws2812b_set_pixel' declared 'static' but never defined [-Wunused-function] ws2812b.h /ws2812b_f3/src/ws2812b line 90 C/C++ Problem
Description Resource Path Location Type initialization discards 'volatile' qualifier from pointer target type [-Wdiscarded-qualifiers] ws2812b.h /ws2812b_f3/src/ws2812b line 84 C/C++ Problem
Can you help me.
this too..
Description Resource Path Location Type in expansion of macro 'BITBAND_SRAM' ws2812b.c /ws2812b_f3/src/ws2812b line 458 C/C++ Problem
So I tested your code on two different STM32f3 Microcontrollers and I cannot get it to work. The library somehow works, because I get the correct timing at the output data pin (~1.2us per bit 2/3 on high, 1/3 on low). However, all the data that is sent is always "1"s turning all the colors to 255 on the LEDs itself.
I do not know why this is happening. Obviously the DMA and TIM are working otherwise I would not get an output signal. When debugging, I can see that the
frameBuffer
variable is updated and written to byvisRainbow()
. So somewhere after that the color info must get lost.Tested on:
Using: