display simple text from PureData?

Remork bool setup(BelaContext **context, void *userData)

one * too many. PS: use ``` around your code.

There are two fundamental issues here:

Remork i was hoping bela would know what the context was

There is nothing special about a variable of type BelaContext* named context. It is not defined "somewhere" and you cannot access it globally. You can operate on a it it gets passed to the function you are in. It is passed to setup(), render(), cleanup(). From one of those functions, you can pass it to other functions if needed, but you are not allowed to cache it for longer than the lifetime of the function. In other words, with the exception of setup() and cleanup(), you cannot use the BelaContext outside the audio thread.

Remork digitalWrite(context, 0, gResetPin, 0);
usleep(1000);
digitalWrite(context, 0, gResetPin, 1);

Had you written these lines within the audio thread (e.g.: within render(), or a function called by it(, what you'd have as a result is probably:
- a mode switch (usleep() is not a Xenomai-safe function)
- several dropped blocks (you are telling your thread to do nothing for 1ms, which is 44 samples, but it will actually sleep for a bit longer)
- the first digitalWrite() line would have no effect

The last statement may be the confusing one. Unlike other physical computing platforms (e.g.: Arduino), on Bela a call to digitalWrite() (or any of the other read/write functions, for what matters), does not actually go and write the value. Rather, it sets its value in memory, so that after the execution of render() is completed, the value you set for each specific frame is written to the digital output. Your first call sets the memory buffer to 0 for all frames (for a block size of 16, that'd be frames 0 to 15). Your second call sets the memory buffer to 1 for all frames, effectively overwriting all the others. The value for that channel in the buffer at the end of the render() function would therefore be 1 and that's the value that will be written to the output.

In order to obtain a delay of 1 ms between writing a 0 and writing a 1 to a Bela digital channel from within the audio thread, you should "count samples", i.e.: write a 0 to each frame for 44 samples (997us) (possibly across multiple calls to render()), then write a 1. This example and this video should help clarify the issue.

HOWEVER

IIUC, you are doing this as a modification to OSC2OLED4Bela. As you will have noticed, that one is not a "Bela program" as such (i.e.: it contains a main() function, which doesn't call the Bela API, so it doesn't have setup(), render() and cleanup(). This is in fact just a program that uses some of the Bela libraries, but does not actually run a Bela audio thread, but is conveniently built and run through the Bela IDE. The fact that it doesn't call the Bela API and doesn't run a Bela audio thread is actually a requirement for it to be able to run at the same time. All of this means that you should not actually call any of the digitalWrite() or pinMode() functions, because those operate on Bela's digital channels and can only work as part of the Bela audio thread. What you need to do instead is to pick a digital pin not used by Bela (or by anything else) and use the Gpio class (#include <Gpio.h>) . See this page (https://learn.bela.io/using-bela/technical-explainers/other-uses-of-gpio-pins/) for more information.

Remork i'm thinking i can use a digital pin to toggle the reset before (or at the beginning of) display_Init_seq(); , or even before connecting the I2C. and i could use a digital pin to control the 12v line with a mosfet or something.

this should work, with the above adjustments.

Remork and there was me thinking this would be relatively straightforward 0_0

it's not too hard, really ... this should be all you need

#include <Gpio.h>

// globals
int gResetPin = ...; // TODO: find a free pin
Gpio gResetGpio;

...

// inside some init function:
gResetGpio.open(gResetPin, Gpio::OUTPUT);

// when needed:
gResetGpio.write(false);
usleep(1000);
gResetGpio.write(true);

Remork giuliomoro it's not too hard, really

didn't want that to sound bad ... I just wanted to follow up from the previous post, which was pointing to a lengthy explanation and an API documentation, with a barebones practical example

Remork phfew. that is beautiful.

indeed!

Remork in terms of timing - does this sort of 'background' thread start up first, compared to Audio/Pd?

probably a bit later. I'd recommend that you don't rely on any particular startup order. Just have one ping the other until the other responds, then you'll know they are both alive.

Remork spread some of the heavier lifting needed at startup

For most application, "startup" heavy lifting is "free": you'll get mode switches, dropouts, whatever, doesn't matter: you haven't started yet! If anything, it's better to avoid spreading it out so that it completes as fast as possible ... if - on the other hand - you are trying to do the "startup heavy lifting" while at the same time playing some audio (e.g.: a power on tone), then the "spreading" can definitely help!

this is clearly over-engineering, but you could have a Bela digital in connected to the pin you are toggling from OSC2OLED4Bela and monitor that pin from within the Pd patch

giuliomoro This is actually easier said than done, as I see now that there are no OSC-sending capabilities in there at the moment, so you'd need to add a OscSender object and also UdpServer should be modified to use recvfrom() in order to be able to retrieve the address from which a message was received and use that for a response.

Actually, without any changes to the libraries, you could just hardcode a port number to send messages to in OSC2OLED4Bela and have a OscSender object send to it in response to a /ping or something like that ...

Remork could you elaborate on 'some init function' here?

Inside main(), at the top, would be fine.

Remork both pins just stay high continuously.

Both pins ... which ones?

What happens in the destructor of Gpio is dependent on whether the pin was already "exported" before the program started. Also, whether the destructor is executed at all depends on whether the program exits cleanly. You could try adding gResetGpio.write(0) just before returning from main() to ensure the pin goes back to 0. Feel free to post your code here if that helps.

I guess it's because those pins by default are not set to GPIO but to UART. The document I linked earlier https://learn.bela.io/using-bela/technical-explainers/other-uses-of-gpio-pins/ mentions the issue of pinmuxing and goes through how to test pins from the command line before moving to C++.

Remork no clue what that means, or how to make sure it gets exported.?

I thought you had your pins staying high when the program ended, which could have been explained by the above, but actually it seems irrelevant now that I understood your problem better. "exporting" is sysfs GPIO jargon for "telling the kernel the pin should be available for user space to manipulate". "Unexporting" it would mean telling the kernel you don't need it anymore. On BelaMini all pins are exported at all times, so ... it doesn't really make a difference either. Just remember that if you want the pin to go low when the program exits gracefully, add a yourPin.write(0) just before returning from main().