This repo has a demo project to demonstrate how to use the FLPR of the nRF54L15. The demo is used to drive a WS2812 LED Matrix Panel of 32x8, while enabling the BLE Device Information Service.
It can be build in two ways:
- ARM Only mode, where everything runs in the nRF54L15 application CPU (Arm Cortex-M33)
- ARM+RISC-V, where the BLE stack runs in the application CPU, and the code that drives the LED panel runs in the FLPR (RISC-V coprocessor)
The following is an image of the setup required for running the demo:
The red boxes are the main DK and the LED panel. The 5V power supply connection, and the data cable are also highlighted.
Important
the PPK2 kit of the image is not needed for running the demo, but it is always a good idea to have it around to do power measurements!
The demo is designed to work in a nRF54L15-DK. It's important to configure the nRF54L15-DK for a 3.3V output with the "Board Configurator" tool
The LED panel consist of a chain of individual WS2812 LEDs. These have a serial interface, so with the entire panel can be driven with a single wire, modulating a serial pulse of 800KHz frequency.
The demo uses GPIO P2.10, so this should be connected to the DIN line of the panel by a custom made cable. The GND line should also be connected to one of the DK pins.
The power supply must be 5V, with an output current of 200mA for this demo. It's preferrable to use a separate power supply, connected by the separate cables to the panel. Although the LEDs are 5V, they can be driven with a 3.3V signal.
For building the demo, it's recommended to use Visual Studio Code, with the nRF Connect extensions and the NCS Connect SDK installed
To test this mode, add the armonly_sample directory to a workspace in VS Code, and create a build
configuration for the nrf54l15dk/nrf54l15/cpuapp target.
In the base configuration, select the prj_standalone.conf file, and build.
Once the build is complete, flash it in your DK, and you should see a text banner that says "Arm" in the LED panel.
Doing a scan with the "nRF Connect App" from a mobile, you should not see the device.
Pressing any of the DK buttons should enable the BLE Device Information Service. You can confirm it with the app, searching for the device named "DIS peripheral"
Once the BLE stack is enabled, the banner in the LED should start showing problems, like random colours and blinks, while still trying to display the same banner.
To test this mode, add the armflpr_sample directory to a workspace in VS Code, and create a build
configuration for the nrf54l15dk/nrf54l15/cpuapp target.
In the base configuration, select the prj.conf file, and in the code snippet section, make sure
nordic-flpr is selected, then build.
Once the build is completed, flash it into the DK. The demo should show the same "Arm" banner, plus the Risc-V logo next to it.
The BLE DIS should be enabled by default, and accesible with the app, under the name "DIS Peripheral with RISC-V"
The display should not show any issue or problem.
Important
This project has a sysbuild.cmake file, that includes the other directory, building it for the nrf54l15dk/nrf54l15/cpuflpr
target. It's essentially the same C code we built before, but included as a part of a multi image, for a different architecture.
The WS2812 serial interface relies entirely on the correct timming of the pulses. The panel has 256 LEDs on it, and each LED requires 24 bits. At 800KHz, it takes 7.68 ms to send the entire display information. The display content is refreshed every 50 ms.
As the demo simply bitbangs the data using GPIO calls, it means that any interruption that occurs inside the 7.68 ms can have catastrophic side effects for the display, no matter how short it is. This is demonstrated when we pressed the button in the Arm Only mode, as this enables the BLE DIS service.
When we move hee code for bitbanging the LED panel to the RISC-V coprocessor, the radio interruptions are processed in the application CPU, while the FLPR keeps doing its job without issues. This demonstrate how the coprocessor can be used in time sensitive scenarios - the alternative would be to run the code in the application CPU disabling interrupts completely, which can cause a lot of other side effects.
Note
The WS2812 is a popular choice for hobby projects, and it's true there are other ways to drive it, using SPI, or PWM/Timers with DMA, that can deal with interruptions in a much better way. The choice of driving the LEDs with with the bitbang method is just to demonstrate the use case in a visual way
