Bela Gem Neopixel Pd

Knallberto

Hi,

I would like to transfer my working setup from Bela to the new Gem system.
I am currently using the Pixelbone O2L branch to drive NeoPixels from my PD patch.

Is there any difference when applying this to the new system, or is the approach the same?
Which pin should I use to drive the NeoPixels on Gem?

Thanks in advance!

giuliomoro

use the andrew branch and the instructions here https://forum.bela.io/d/7529-spi-on-gem/2

Knallberto

Thanks, I looked into the instructions and before I try to get this running tomorrow I have two questions.

The instructions say:

This sends the output from P2.20, though you need to run devmem2 0xf40c8 w 0x00040007 to enable that pin after each reboot.

(1) Is it possible to change the output pin for the Neopixels? I want to use UART4 at the same time, which uses P2.20.
(2) The command that needs to be run after each reboot, is there a way to automate this so that I can run my Bela patch at boot with the Neopixels enabled?

giuliomoro

Knallberto (1) Is it possible to change the output pin for the Neopixels? I want to use UART4 at the same time, which uses P2.20.

yes. Would P2.17 work?

(2) The command that needs to be run after each reboot, is there a way to automate this so that I can run my Bela patch at boot with the Neopixels enabled?

Sure, once you've settled on a pin, it can be added to a device tree overlay so that it's always set automatically.

Knallberto

giuliomoro yes. Would P2.17 work?

Yes, I don‘t use it.
I changed ws281x.h to GPIO 64 (for P.2.17) and the command for enabling the pin to devmem2 0x000F4104 w 0x00040007.

Then I built O2L (uncommented #define USE_OSC) and ran:

cp projects/O2L/O2L.service /lib/systemd/system/ systemctl daemon-reload systemctl enable --now O2L
Then I rebooted Bela and tried to build my Pure Data Patch.
I get the following output:

`root@bela:~/Bela# devmem2 0x000F4104 w 0x00040007
/dev/mem opened.
Memory mapped at address 0xffffaf806000.
Read at address 0x000F4104 (0xffffaf806104): 0x08214007
Write at address 0x000F4104 (0xffffaf806104): 0x00040007, readback 0x00040007
Stopping Bela ...
Building project...
Build finished
Running project...
Error in evl_create_xbuf: 17 EEXIST File exists
Unable to create pipe p_midiDiscoveryPipe with 8388608 bytes: (-1) Unknown error -1
terminate called after throwing an instance of 'std::runtime_error'
what(): RtNonRtMsgFifo: failed to initialize. NOTE: cannot call setup() or the constructor before Xenomai has been initialised

Aborted
make: *** [Makefile:744: runide] Error 134
Bela stopped
`
To check I tested with O2L only and P2.20. This makes my LEDs blink. I also tested with P2.17 (again O2L only) but no blinking.
With P2.20 it's also working when I run my PD patch locally and O2L is running on bela. When I run O2L as a service on startup and then try to build my PD Patch I get the same error as above.
There seems to be a problem with using P2.17 generally (did I do something wrong?) and with runnind O2L in the background.

For the device tree overlay: I want to use the UART4 overlay from this post UART4. Can I include the Neopixel Pin in this overlay or how should I do this?

giuliomoro

See the latest commit on that branch that enables P2.17.

Knallberto Error in evl_create_xbuf: 17 EEXIST File exists

this error is because you have another copy of the program already running, possibly running on boot? Press stop after a reboot before starting the project.

Knallberto For the device tree overlay: I want to use the UART4 overlay from this post UART4. Can I include the Neopixel Pin in this overlay or how should I do this?

Add another overlay with something like this:

#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/leds/common.h>
#include "ti/k3-pinctrl.h"

/dts-v1/;
/plugin/;

/*
 * Helper to show loaded overlays under: /proc/device-tree/chosen/overlays/
 */
&{/chosen} {
	overlays {
		PB2-P2.17-GPIO.kernel = __TIMESTAMP__;
	};
};

// many definitions from pinmux/board/pocketbeagle2/pocketbeagle2-pinmux.dts
&main_pmx0 {
	P2_17_gpio: P2-17-gpio-pins {
		pinctrl-single,pins = <
			AM62X_IOPAD(0x0104, PIN_INPUT, 7) /* (AC24) VOUT0_PCLK.GPIO0_64 */
		>;
	};
};

&cbass_main {
	p2_17_gpio {
		compatible = "gpio-leds";
		pinctrl-0 = <&P2_17_gpio>;
		pinctrl-names = "default", "sleep";
	};
};

We are planning to eventually make P2.17 as default for O2L, so the Bela base overlay will include the pinmuxing for P2.17 and it may conflict with yours then.

Knallberto

giuliomoro See the latest commit on that branch that enables P2.17.

Is this supposed to be in the andrew branch? The latest version I see is the one I used with P2.20. How can I find the version you mentioned?

giuliomoro this error is because you have another copy of the program already running, possibly running on boot?

I have nothing running on boot besides the O2L service. I can try pressing stop first on monday (would this as well stop the O2L service?)

Thanks for the overlay and the info. Do I just save this code and run it the same way as the UART4 overlay?

Knallberto

giuliomoro this error is because you have another copy of the program already running, possibly running on boot? Press stop after a reboot before starting the project.

I tried to press stop after reboot before starting the project. I get the same error.

Stopping Bela ...
Building project...
Build finished
Running project...
Error in evl_create_xbuf: 17 EEXIST File exists
Unable to create pipe p_midiDiscoveryPipe with 8388608 bytes: (-1) Unknown error -1
terminate called after throwing an instance of 'std::runtime_error'
  what():  RtNonRtMsgFifo:  failed to initialize. NOTE: cannot call setup() or the constructor before Xenomai has been initialised

Aborted
make: *** [Makefile:744: runide] Error 134
Bela stopped

giuliomoro

Knallberto Is this supposed to be in the andrew branch? The latest version I see is the one I used with P2.20. How can I find the version you mentioned?

sorry hadn't pushed. It's there now 5d09044 .

Knallberto . Do I just save this code and run it the same way as the UART4 overlay?

yes, usual instructions for loading an overlay.

Knallberto I have nothing running on boot besides the O2L service. I can try pressing stop first on monday (would this as well stop the O2L service?)

Stop would only stop a Bela project running on boot, not touching O2L. The IDE doesn't know about O2L running in the background (or not).

Knallberto

giuliomoro Thanks, I can see it now. I had only changed ws281x.h, so I missed that the .p file also needed to be updated. Could you explain how GPIO_PIN 0 is obtained in ws281x.p?

Since I started from a fresh Bela image and did not configure any project to run on boot, I do not think this could be the issue. But I will test whether pressing Stop before launching the Pd project changes anything.

giuliomoro

Knallberto Could you explain how GPIO_PIN 0 is obtained in ws281x.p?

The PRU code assumes 32-bit GPIO sub-banks, but actually the new GPIOs are 144-bit wide. Those are organised in 5x 32-bit subbanks.

Previously for pin 49 it was GPIO_PIN 17, with GPIO_BASE set to subbank1 (bits 32:63).
Now for pin 64 it is GPIO_PIN 0, with GPIO_BASE set to subbank2 (bits 64:95).

On the old boards I had some logic in there that allowed to set that value only in one header and propagate across ARM and PRU code. For the new ones I haven't done that yet, so it needs changing in two places.

Knallberto

Thanks, this is working now!

However I noticed one issue: my NeoPixels are flickering quite a lot. I’m using exactly the same strip and wiring as before with my old Bela setup, where I was running the pixelbone branch and it was quite stable.

The only thing that changed is that I’m now running the new Bela/PocketBeagle2 setup with the andrew branch of O2L.

Is this something that might be expected with the new setup, or is there anything I should check?

giuliomoro

How are you powering the neopixels? Does this only happen when running a Bela project on the side or also when running O2L only?

Knallberto

giuliomoro How are you powering the neopixels?

I am powering the neopixels with 5V. Could it be the voltage difference? This was no problem before.

giuliomoro Does this only happen when running a Bela project on the side or also when running O2L only?

I did not notice this problem when running the built in LED test from O2L. But I will check this tomorrow and get back to you.

giuliomoro

Knallberto I did not notice this problem when running the built in LED test from O2L

Try running O2L with the built in test, verify it works OK and see if running a Bela program on the side (without sending any data to O2L) is enough to make it misbehave.

Knallberto

giuliomoro Try running O2L with the built in test, verify it works OK

The built in LED test seems to work fine.

giuliomoro see if running a Bela program on the side (without sending any data to O2L) is enough to make it misbehave

Running my PD patch alongside the built-in LED test initially did not seem to influence the LEDs. However, I asked ChatGPT to create a slower LED fade-out test so that any timing issues would be easier to see.
The pixels fade out correctly when only O2L is running. When I start my PD patch at the same time, the LEDs begin to misbehave and flicker.
I also tried some of the example PD patches (e.g. with AM synthesis). In those cases the LEDs misbehave even more, blinking in different colors. The same behaviour occurs when using C++ examples.

When I run only O2L and my PD patch locally on my laptop, the Neopixels behave as expected.

giuliomoro

ok I'll see if I can reproduce the issue locally.

giuliomoro

Can you run the Pd project on the side with digital disabled?

Knallberto

Does this mean I should turn off use digital in project settings?
This does not change the problem.

giuliomoro

OK the issue seems to be with contention and related latency with accessing the wider set of peripherals from within this PRU while the other PRU is doing Bela stuff. Here's a video of the data line while O2L is doing the loop; half way through the video I start the Bela program and you can see how that affects the micro timing of it.

20260312-135746.mp4

4MB

The fix is to use the PRU's own GPIOs (accessed via R30) as that won't cause any contention or incur any latency. The latest commit from the andrew branch does just that. The overlay needs to change to change the function of P2.17 to pru0 GPO19. To make things easier, I incorporated that pin in the main Bela device tree overlay, so you can:

remove your custom overlay for P2.17 from extlinux.conf
update the board via the IDE (will update the Bela base device tree)
use the latest pixelbone branch for O2L
reboot