Hello everyone,
Have any of you tried working with WS2812b LED matrices?
I imagine that it’s necessary to make a prior assignment of the ports of the Ambiq Apollo3 to try to adjust the existing management libraries of this type of LED matrices… but has anyone already faced this or knows of a library that could be functional?
I have tried to generate the bit frames according to the timing requirements indicated in the WS2812b datasheets, but I think I should access the timers of the microcontroller itself if I want to be efficient…
Any suggestions?
Thanks in advance
I tried with FastLED.h library wich is suposed to support Ambiq Apollo3 Blue platform… but something must be adjusted…
Hi @ERA ,
I acknowledge that FastLed is a very popular library to the Arduino community and RUI3 should be able to support it (I got same result on what you shown).
I already create a ticket for this and should be looked at by our team. I cannot promise though for quick update since they are focused right now on open-sourcing the whole RUI3 firmware framework.
Thanks Carl, I will be looking for any clue
Hi, again, anyone have a hint?, any news?
Dear @ERA, did you find a way to use WS2812b with RAK11720?
Now the FASTLED library includes support for Apollo3, but compiling the examples for the RAK11720 board generates the following error:
Kind regards
The FastLED Apollo3 support may target the Artemis rather than the RAK11720 specifically, so the compile error likely stems from board-definition or timer/BSP differences. I’d check whether the failing example uses a peripheral that isn’t mapped the same way on the RAK module, then try a minimal sketch that only initializes and drives a short strip. Sharing the exact error text rather than just the screenshot would also help others narrow it down.
Charlotte from Atlanta here. The point about Artemis versus RAK11720 board definitions seems worth testing before assuming library support covers the module. Since the screenshot hides the actual message, posting the full compiler output would let others see whether it’s a missing timer, pin map, or BSP symbol. A minimal sketch driving just a few pixels is a reasonable way to isolate whether the issue is FastLED’s Apollo3 backend or something in the larger example. I’d also compare against whichever Apollo3 core the library was tested with, as version drift between cores can produce exactly this kind of mismatch.
The board-definition mismatch is the first thing I’d rule out, since FastLED’s Apollo3 backend was likely validated against the Artemis core rather than RAK11720. A minimal sketch that only sets the pin and drives two or three pixels would show whether it’s a timer or BSP symbol that’s missing. Posting the actual compiler output matters too, because a timer conflict and an undefined pin map need different fixes. Comparing the Apollo3 core version against whatever the library was tested with is also worth doing, as that drift produces similar errors.