How to use "nRF LED Matrix" sample and library from Zephyr with nRF Connect SDK 1.9.1 and SES for use in an app on Micro:Bit V2?

[Mike Wirth]

Kind folks,

I have used the nRF Connect app on my MacBook Pro to (carefully!) install the new 1.9.1 SDK and the Nordic version of the SEGGER Embedded Studio.  Using this environment I can build, load and run various sample apps from the SDK on an nRF52840 DK.  Further, by loading Segger's J-Link OB code for the Micro:Bit on that board (and with a fair degree of care about board & peripheral configurations), I can build, load and run some sample apps on the Micro:Bit V2 board (based on the nRF52833) as well.

So far, so good.  But now I want to use the 5x5 LED matrix on the Micro:Bit, instead of the one or two single LEDs typically found on Nordic dev boards.  Interestingly, there's even sample code in the Zephyr system to support this task, explicitly labeled nRF LED Matrix,, which purports to what I want and it's even included in the Zephyr repo in the nRF SDK!  But, alas, it doesn't seem to be accessible to me from the SES "Open nRF Connect SDK Project..." path.  Using that wizard, the Projects selector (slow, unresponsive, prone to crashing!) doesn't allow me to get at the requisite "nRF LED Matrix" sample app.  (Trying to install a separate Zephyr build environment off to the side for experimentation is its own tar pit, e.g., involving all kinds of Python version conflicts and west problems, at least in macOS).  And the sample code and this part of the Zephyr library(?) may not be directly useful, since it's C++ code and dependent on Zephyr low-level support. a different build model, etc..

Can anyone point me at an "nRF LED Matrix" library in C (not C++) that would integrate with the other, documented nRF libraries in the nRF 1.9.1 SDK?  Other approaches?

TIA,

Mike

[Mike Wirth]

A bit of Google searching on the undefined reference in my prior reply leads to the following in the Zephyr docs:

DEVICE_DT_GET
...
If no such device was allocated, this will fail at linker time. If you get 
an error that looks like undefined reference to __device_dts_ord_<N>, that 
is what happened. Check to make sure your device driver is being compiled, 
usually by enabling the Kconfig options it requires.

This refers to Kconfig settings, which are part of the build files generated by the code generation wizard (I presume).  How do I fix this?  

Mike

[Øyvind]

Hi Mike, 

Yes, you seem to have encountered a Devicetree error, indicating that you have configured something incorrectly. I would recommend going through the Devicetree Guide, and have a look at this YouTube video from the Zephyr Community on the Device Model.

Can you share your project in a .zip file?

Kind regards,
Øyvind

[Mike Wirth]

Øyvind,

Many thanks. Your suggestion is right on target.  I've started tp go through the DTS videos.  Seem clear enough, but when I try to apply them, I still run into problems.  What I'm trying to do is a mashup of the Nordic nrf_dm sample and the Zephyr nrf-led-matrix sample:

1. Starting with the nrf_dm sample targeted to the nRF52833 DK, I can remove the dependence on single LEDs.
2. Then I can change the target to bbc_microbit_v2 (which also uses the nRF52833 SOC).
3. At this point, I start adding code snippets from main.c in the nrf_led_matrix that use that display device.
4. I tried adding a dts overlay file (and changing where the alias already included in the solution that didn't point anywhere), but didn't get the details right.  Seem to have gotten tangled up in aliases for device "labels". 

Here's what I put in the overlay:

led_matrix: led_matrix {
		compatible = "nordic,nrf-led-matrix";
		status = "okay";
		label = "LED_MATRIX";
		width = <5>;
		height = <5>;
		pixel-mapping = [00 01 02 03 04
				 10 11 12 13 14
				 20 21 22 23 24
				 30 31 32 33 34
				 40 41 42 43 44];
		row-gpios = <&gpio0 21 GPIO_ACTIVE_HIGH>,
			    <&gpio0 22 GPIO_ACTIVE_HIGH>,
			    <&gpio0 15 GPIO_ACTIVE_HIGH>,
			    <&gpio0 24 GPIO_ACTIVE_HIGH>,
			    <&gpio0 19 GPIO_ACTIVE_HIGH>;
		col-gpios = <&gpio0 28 GPIO_ACTIVE_LOW>,
			    <&gpio0 11 GPIO_ACTIVE_LOW>,
			    <&gpio0 31 GPIO_ACTIVE_LOW>,
			    <&gpio1  5 GPIO_ACTIVE_LOW>,
			    <&gpio0 30 GPIO_ACTIVE_LOW>;
		refresh-frequency = <50>;
		timer = <&timer4>;
		pwm = <&pwm0>;
		pixel-group-size = <4>;
	};

       // pwm0: pwm0 {
		//compatible = "nordic,pwm0";
		//status = "okay";
		//label = "PWMO";
        //}

        pwm-led0: pwm0-led0 {
		compatible = "nordic,pwm0";
		status = "disabled";
		label = "PWMO";
        }

pwm0: pwm@4001c000 {
			compatible = "nordic,nrf-pwm";
			// reg = < 0x4001c000 0x1000 >;
			// interrupts = < 0x1c 0x1 >;
			status = "okay";
			label = "PWM_0";
			//#pwm-cells = < 0x1 >;
			//phandle = < 0x6 >;
                        }

Am I headed in the right general direction?  Suggestions on the details?  I'm headed off to look at more dts videos and docs, especially if there are any dts-related tools that help you sort out labels, devices, status, etc.

Thanks again,

Mike

[Øyvind]

Hi Mike, 

Yes, this looks correct, however, note that the bbc_microbit_v2 board files include most of what you need to use the MicroBit v2 functionality except for the pwm_led0.

The nrf_dm uses the pwm_led in led_notifcation() found under nrf\samples\bluetooth\nrf_dm\src\peer.c. When building it will complain about this LED missing, which is used to indicate the distance. You will need to configure this for your use on the MicroBit e.g. led_matrix. 

-Øyvind