I’m trying to use FastLED and Chibios together with some success so far. WS2812B are being controlled sending streams via SPI to get right timings as you can see on attached picture from oscilloscope . Timings are within the acceptable accuracy. My first led is stuck in a bright green. Microcontroller is an STM32F103C8T6 (Bluepill board). Any thoughts on this? Thanks.
Do you have common ground between the controller and the LEDs? This and the resistor in the data line helped me with the same problem. Another idea is to test from the next data in. Your first led might be broken.
Thomas, I’m using the ground from the board itself. Board and leds are connected to the same supply. I checked and first led is fine. I will try the resistor. Which value you recommend?
I’d have to look it up, but the Adafruit Neopixel guide suggested a value, which is what I use (https://learn.adafruit.com/adafruit-neopixel-uberguide/basic-connections). Does your controller send 3.3 V or 5 V signals? While some pixels work with 3.3, some only allow 5.
@Willian_Dolence_Ribe Yeah ive seen this myself. I wrote my own STM32F1 SPI driver https://github.com/leonyuhanov/SK6812viaSPI/tree/master/STM32 for the Neopixel/SK6812 and saw this. I think it has to do with the fact that you can not accurately set the SPI clock. I’m not sure how FastLED does it on this Micro, but i have seen exactly this behavior when the clock speed was not exact. It only alows you to set the speed by a divider and none are close to the 3.3mhz you need.
Guys, I’m sorry for taking so long to answer. I was on travel and my car has broken down. Anyway, I have followed the tips given by Leon and Thomas. Adding a 1000uf capacitor and 330r/470r resistor didn’t changed anything, unfortunately. Using the oscilloscope I made some adjustments to the SPI timings until I was able to get a more accurate signal, as you can se on the attached picture. Now, all leds are working fine in blue and red, no more weird greeny first pixel. The problem now occurs when displaying green on all leds. They become very very dim, almost unlit. Thanks for everyone helping me on figuring this out.
missing/deleted image from Google+
missing/deleted image from Google+
@Willian_Dolence_Ribe Are you using a Voltage Level Shifter? and if not, is your data line super short to the 1st pixel? strange results… definitely a timing problem. What frequency is your SPI set at?
@Leon_Yuhanov I’m not using voltage level shifter. I have the leds connected to +5v and my data outputs 3v3. Distance from the board to the first pixel is 20cm. My SPI is set to 18mhz which gives around 55.5 nanoseconds per byte transfered. I’m tweaking this ( https://github.com/andresv/FastLED/blob/297f297c823428744dc9b0e1dc276792af9105bb/platforms/arm/stm32chibios/clockless_arm_stm32.h ) port of fastled which target is an STM32F4.
WS2812B timings are as follows:
1: 900 ns high - 350 ns low -> 1250 ns
0: 350 ns low - 900 ns high -> 1250 ns
Per datasheet 150ns + - tolerance is accepted.
I’m sending 24 bytes streams:
m_one[0] = 0xFF;
m_one[1] = 0xFF;
m_one[2] = 0x80;
m_zero[0] = 0xFE;
m_zero[1] = 0x00;
m_zero[2] = 0x00;
1755.5 = 943,5 ns HIGH
755.5 = 388,5 ns LOW
24*55 = 1332 ns (within ±150 ns tolerance)
I’m almost giving up and using PWM + DMA.
@Willian_Dolence_Ribe How confident ar eyou that your SPI is actually at 18mhz?
@Willian_Dolence_Ribe try using my library linked above, it uses a 3.3mhz clock to do the same thing, but in a different manner. Although I had the same problem of having the 1st pixel muck up. I put it down to the fact that the STM32 SPI clock can not be precisely adjusted.