O2L pixelbone not compiling

Knallberto

Hi,

I ran into problems loading my Pd patch on Bela startup, so I decided to start from scratch.
I flashed a fresh Bela image from SD to eMMC, then updated Bela to the dev branch. After that, I created a folder called O2L and uploaded the current O2L pixelbone branch.
When trying to compile the project, the build fails with the following error:

Building ws281x.p... Invoking: PRU Assembler ws281x.p:2: Fatal Error: Can't open source file '/root/Bela/projects/O2L/../../pru/board_specific.h' Aborting... make[1]: *** [/root/Bela/projects/O2L/ws281x_bin.h] Error 1 Makefile:550: recipe for target '/root/Bela/projects/O2L/ws281x_bin.h' failed Makefile:625: recipe for target 'runide' failed make: *** [runide] Error 2 Bela stopped

giuliomoro

You should be able to work around that by replacing the #include line with

#define GPIO0 0x44E07000
#define GPIO1 0x4804C000
#define GPIO2 0x481AC000
#define GPIO3 0x481AE000
#define GPIO_CLEARDATAOUT 0x190
#define GPIO_SETDATAOUT 0x194

Knallberto

giuliomoro
Thanks, this worked. I compiled O2L and tested it with the local.pd file. The Neopixels are lighting up correctly. Next, I did:
cp /root/Bela/projects/O2L/O2L.service /lib/systemd/system/ systemctl enable O2L && systemctl start O2L

I also compiled my PD patch, and it is working fine, but the Neopixel control part is not working. I suspect that O2L is not actually running in the background. How can I check or fix this?

I tried this in a console
root@bela:~# journalctl --boot -fu O2L
output was
-- Logs begin at Thu 2016-11-03 17:16:43 UTC. --

giuliomoro

Knallberto output was
-- Logs begin at Thu 2016-11-03 17:16:43 UTC. --

then it's not running.

cat  /lib/systemd/system/O2L.service

Knallberto

Okay, I used ChatGPT to figure it out. The O2L service was masked (any idea why?), so I ran sudo systemctl unmask O2L, copied the service file to /lib/systemd/system/, then ran sudo systemctl daemon-reload, sudo systemctl enable O2L, and sudo systemctl start O2L.

There was a conflict with Bela starting first, causing PRU timeouts (any idea why?). We fixed it by adjusting the boot timing in /lib/systemd/system/O2L.service (After= / WantedBy=). Now O2L runs in the background and can be checked with systemctl status O2L or journalctl -fu O2L.

This way it is working now.

giuliomoro

The O2L service was masked (any idea why?)

Unlikely that that would have happend on its own ... were you able to verify it was actually masked? Or was your only observation that after running all those commands it worked?

Knallberto There was a conflict with Bela starting first, causing PRU timeouts (any idea why?).

Not sure, maybe a conflict when accessing the PRUs?

We fixed it by adjusting the boot timing in /lib/systemd/system/O2L.service (After= / WantedBy=)

It should have probably added a sleep in the ExecStart line instead.

Knallberto

Okay, thank you.
I got this in the console:
root@bela:~# systemctl status O2L O2L.service Loaded: masked (/lib/systemd/system/O2L.service; masked; vendor preset: enabled) Active: inactive (dead)

I am not sure why it was masked or why the conflict occurred.
O2L is supposed to be enabled and run as a background service so that it can be controlled by PD messages, right? And once enabled on startup, it should work together with the Pure Data patch also running at startup without conflict?
I started with a fresh system (SD → eMMC, updated to the dev branch from the IDE, checked that my PD patch is running, compiled O2L, tested O2L with local.pd, and tried to make O2L run in the background).

As it seems to work this way now (with the adjustmens from above), I will wait until I receive a new Bela and then try again to see if the basic problem persists.

giuliomoro

I am not sure why it was masked or why the conflict occurred.

One reason for masked is if the service file exists but is corrupted (e.g.: empty) ...

O2L is supposed to be enabled and run as a background service so that it can be controlled by PD messages, right? And once enabled on startup, it should work together with the Pure Data patch also running at startup without conflict?

Correct, however I never tested the pixelbone branch at boot against Pd; it may well be that one of the two does require some delay.