Hi! I’m using Kolyshkin’s fork to drive WS2812 from a Maple Mini (STM32F103). It works, but the animation is about half as fast as the exact same code running on an Uno. If I switch to a clocked chipset like APA102 it runs at the correct speed. Someone on the STM32 forum suggested this may be caused by a clock divider setting. I’m looking through clockless_arm_stm32.h but I haven’t figured out how to troubleshoot this yet.
Anyone have any ideas? Thank you!
How are you determining how fast it is running, visually or by reporting frame rate? It’s possible that the stm32 port you are using isn’t accounting for the interrupts (and by extension, clock) being disabled while writing out led data. This will throw off time.
@Daniel_Garcia Sounds good, I’ll investigate. I was determining the speed visually. Thanks!
I agree that this sounds like a difference in clock rate and handling of clock dividers.
You might want to take a look through the data-sheet for the STM32F103 and maybe the reference guide. There should be a section on this topic and how to handle it from the code side. Compare that to the ref guide for the UNO’s processor for reference.
Have you tried this fork?
I’ve used it successfully with WS2812s…
@Jeremy_Spencer Yes, I tried that fork first. I couldn’t get it to compile because it was missing pin definitions needed by fastpin_arm_stm32.h in the FastLED platform module. I believe the fork I reference is basically Evey’s fork (the fork you suggested) with the missing pin definitions added and some other FastLED platform work:
https://github.com/FastLED/FastLED/pull/568/files
I’m using Arduino 1.8.5 and the latest Arduino_STM32 core for the record.
@Christopher_Gaul will do. I see that F_CPU is set to 72000 in led_sysdefs_arm_stm32.h. Is that different from the type of clock that would be relevant here?
@Daniel_Garcia I found your handy getFPS function and it’s reporting 400 frames per second. As per your suggestion, I tried printing millis() every 1000 milliseconds, and when I use a stopwatch it seems to be taking a little over 2 seconds. So that sounds right in line with what you’re suggesting, correct? The clock driving millis isn’t accounting for interrupts being disabled while writing out to WS2812. That points to it being a core issue (Arduino_STM32) rather than an issue with the FastLED platform module, correct?
Thanks everybody for the suggestions.
@Jeremy_Spencer I figured out my way around the pin definition error to try out Evey’s fork but it seems to have the same issue, unfortunately.
@Jordan_Applewhite that’s a pity, it used to work fine, I think the problem must be caused by something they’ve changed in the core 
Ask the guy with the 9036 pixel wall… He’s using the same controller