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 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

    hahaa
    like it!

    i guess the only real issue is indeed when to bang the [netsend -u -b] object (which is was using, actually).
    have to make sure it doesn't get banged before the custom render is online, and then fails to connect.

    now over-engineering is my middle name. 🙂
    but in this case, maybe i'll just wait a couple of seconds..
    or i could manually bang the connection with the button? once i see my startup message, that should have given Pd plenty of time - and that message only appears after the render is running.
    will run soms tests asap.

    thanks for all the help so far!

      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 ...

        hahaaa
        it feels like we're actually creating problems now. 🙂

        didn't have the time today, will probably be thursday before i manage to come back to this.
        keep u posted.

        Remork used one pin for reset, and another to switch the 12v line (high side switching w/ a 2n3904 - BD140 combo, as i didn't have any P-channel Mosfets around.)
        set project to run on boot, and now i get my startup message to greet me after plugging in! huzzah!

        huzzah'd too soon.

        don't know how or why, but it doesn't want to play anymore.
        both pins just stay high continuously.
        when you say

        giuliomoro // inside some init function:
        gResetGpio.open(gResetPin, Gpio:😮UTPUT);

        could you elaborate on 'some init function' here?
        i'm thinking that's (one of the places) where it may be going wrong.

        i have the write commands in the beginning of the main() now, where i think they belong.
        but i'm unsure as to where to put the setup lines.

              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 was trying to use Gpio pins 30 and 31 (P2_5 and P2_7).

                    this is what would need to happen:

                    "Power ON sequence:
                    1. Power ON VDD (= 3.3v)
                    2. After 3.3v become stable, set RES# pin LOW (logic low) for at least 3us and then HIGH (logic
                    high).
                    3. After set RES# pin LOW (logic low), wait for at least 3us. Then Power ON VCC.(= 12v)
                    4. After 12V become stable, send command AFh for display ON.
                    SEG/COM will be ON after 100ms."

                    so ideally, i'd start off with ResetPin high and 12vPin low.
                    pull reset pin Low, then High again.
                    pull 12vPin high.
                    the 'Display On' command is in the display_Init_seq()., so i need to toggle those pins before that happens.

                    i just tried only writing both of them LOW, but they both remain at 3.3V.
                    so i'm not controlling them at all, as it is.

                    i added #include <Gpio.h> in render.cpp.
                    i addedGpio gResetGpio;
                    int gResetPin = 31;
                    Gpio g12VGpio;
                    int g12VPin = 30;

                    underneath the extern "C" at line 45

                    and i have this: // hopefully set up pin P2_7 for reset of display
                    gResetGpio.open(gResetPin, Gpio::OUTPUT);
                    g12VGpio.open(g12VPin, Gpio::OUTPUT);
                    gResetGpio.write(0);
                    g12VGpio.write(0);
                    usleep(1000000);
                    gResetGpio.write(0);
                    printf("try turning on 12v now?\n");
                    usleep(10000000);
                    g12VGpio.write(0);

                    there for now, i was trying to use the repeat lines of write(0) to toggle them HIGH, obviously.

                    giuliomoro What happens in the destructor of Gpio is dependent on whether the pin was already "exported" before the program started.

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

                        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().

                          i added
                          Gpio gResetGpio;
                          int gResetPin = 31;
                          Gpio g12VGpio;
                          int g12VPin = 30;

                          switched the order around of these, my colleague noticed that they were the other way around.
                          seems better.
                          so changed to

                          int gResetPin = 31;
                          Gpio gResetGpio;
                          int g12VPin = 30;
                          Gpio g12VGpio;

                          i tried it with the config-pin utility in Terminal, that worked fine..
                          weird thing was that using those pins as outputs is not listed as an option in config -l
                          but i could set them to output/hi/lo just fine.

                          right now setting the 1309 test project to run on boot seems to work.
                          i have no real idea why it works now, but stopped working before- i can only hope it stays this way.

                          now need to set it so it runs in the background. deja vu 🙂

                            Remork weird thing was that using those pins as outputs is not listed as

                            Any of the gpio modes will work for output . gpio is the shortest one and will do.

                              Remork now need to set it so it runs in the background. deja vu

                              Make sure it runs before OSC2OLED4Bela, or call config-pin from C with system()

                                  giuliomoro Make sure it runs before OSC2OLED4Bela, or call config-pin from C with system()

                                  hmm not sure what you mean there..?
                                  my SDD1309 sketch is the adapted version of the OSC2OLED4Bela, modified to suit the 1309 driver IC.
                                  right now, if i run that on boot using a separate 5v supply and a 12v supply for the display, the whole thing seems to work (that is: Bela boots, and i get my startup message on the screen - the one that i put in the Main() of OSC2OLED.)

                                  now i need this to run in the background and have my Pd _main in the audio thread. is what i meant.

                                  do you mean it would be safer to call config-pin at every startup?

                                    Oh I see. I was thinking too far and thought you were talking about the last line of the config-pin page: how to have the pins set up at boot.

                                      ok.
                                      i'm a bit confused now. isn't
                                      gResetGpio.open(gResetPin, Gpio::OUTPUT);
                                      g12VGpio.open(g12VPin, Gpio::OUTPUT);

                                      supposed to have the same effect?
                                      or does the Gpio setting disappear with every power cycle, and i still have to set them at boot for the above lines to even be valid?

                                      asking, because i came across this page:
                                      https://www.bacpeters.com/2020/01/25/configuring-the-beaglebone-black-gpio-pins-permanently/
                                      where it says
                                      "But, if one power cycles the BBB, the GPIO pins will need to be set again."

                                      and i thought i was doing just that using #include <Gpio.h>etc.

                                      giuliomoro the last line of the config-pin page: how to have the pins set up at boot.

                                      i never even got that far 0_0

                                      trying to fit that page into the mold of this setup, would that mean:

                                      Create file /usr/bin/enable-display-pins.sh

                                          sudo vi /usr/bin/enable-display-pins.sh

#!/bin/bash

config-pin p9.5 out
config-pin p9.7 out

    sudo chmod 755 /usr/bin/enable-display-pins.sh

                                      Create file /lib/systemd/system/enable-display-pins.service

                                          sudo vi /lib/systemd/system/enable-display-pins.service

[Unit]
Description=Enable Display SDD1309 pins
After=generic-board-startup.service

[Service]
Type=simple
ExecStart=/usr/bin/enable-display-pins.sh

[Install]
WantedBy=multi-user.target

                                      Enable the new systemd service

                                      sudo systemctl daemon-reload
sudo systemctl enable enable-display-pins.service

                                      Reboot and test

                                      sudo systemctl status enable-display-pins.service
config-pin -q p9.30 && config-pin -q p9.31

                                          and if so, is there a way to set the reset pin high by default, and the 12v pin low?

                                          something like

                                          config-pin p9.5 high
config-pin p9.7 low

                                          ?

                                            Remork and if so, is there a way to set the reset pin high by default, and the 12v pin low?

                                            config-pin wouldn't help for that . If you want to do it from bash, see https://learn.bela.io/using-bela/technical-explainers/other-uses-of-gpio-pins/#accessing-a-pin "Accessing a pin -> From the command line"

                                            Remork trying to fit that page into the mold of this setup, would that mean:

                                            that looks OK. Except:

                                            • the formatting (careful how you use your ``)
                                            • the parameters to config-pin you got the pin and mode wrong.

                                            However, the best way of combining the gist and OSC2OLED4Bela, respecting their chronology (i.e.: the former first, the latter second), may be to have a single systemd service that runs a single script and the script contains:

                                            #!/bin/bash
config-pin my.pin my_mode
config-pin my.other_pin my_mode
/root/Bela/projects/OSC2OLED4Bela/OSC2OLED4Bela

                                                  giuliomoro the formatting (careful how you use your ``)

                                                  i'll get it right one day - for now i'm just copy/pasting, which may go wrong here and there. my apologies.

                                                  let me try to get this. when you say a single service running a single script, does that mean i no longer need to create another service file to have my current sketch running in the background, as this one takes care of that as well?

                                                  so say i were to create a single script. that still means

                                                  sudo vi /usr/bin/enable-display-pins.sh?

                                                  after which i get the --INSERT-- mode, and enter

                                                  #!/bin/bash
                                                  config-pin p2.5 output
                                                  config-pin p2.7 output
                                                  /root/Bela/projects/1309_Display/1309_Display

                                                  (hopefully correcting the pins and modes) to create the actual script.
                                                  then save the file? esc +:wq?

                                                  then create the service file to actually run the script at boot?
                                                  sudo vi /lib/systemd/system/enable-display-pins.service

                                                  entering
                                                  [Unit]
                                                  Description=Enable Display SDD1309 pins
                                                  After=generic-board-startup.service
                                                  [Service]
                                                  Type=simple
                                                  ExecStart=/usr/bin/enable-display-pins.sh
                                                  [Install]
                                                  WantedBy=multi-user.target

                                                  Enable the new systemd service

                                                  sudo systemctl daemon-reload
                                                  sudo systemctl enable enable-display-pins.service                                                  .

                                                  does that look at all okay?