• Hardware

  • Using an OLED 128x128 RGB with BelaMini

PaulELong I guess i thought that since P25 and P27 are also Digital(10/11), and I'm using those for SPI1, that using other digital pins should work.

that only works because you have changed the pinmuxer for those pins, so that their electrical signal is no longer connected to the GPIO peripheral, but to the SPI peripheral.

PaulELong I think you are saying when pings are assigned as GPIOs, bela will take them, but since I assigned to SPI bela won't.

that one!

think P1_3, P2_9, P2_11, p2_33

P1.3 is a bit of a special pin, leave it alone!
P2.9 and P2.11 both work for me:

config-pin P2.9 gpio
config-pin P2.11 gpio

P2.33 indeed doesn't work, and the reason is that we (probably mistakenly) disable the cape. This can be rectified if needed.

Do P2.9 and P2.11 not work for you? What error do you get? Maybe you are using i2c-1 ?

      @PaulELong

      Hold on, I realized why it works for me and it doesn't work for you: I actually have P2_09 and P2_11 commented out in my dts (for whatever reason, maybe related to something that happened earlier in this thread).

      so you could try applying this patch to the file /opt/bb.org-overlays/src/arm/BB-BELA-00A0.dts:

      diff --git a/src/arm/BB-BELA-00A1.dts b/src/arm/BB-BELA-00A1.dts
index 69ab609..f86e5c9 100644
--- a/src/arm/BB-BELA-00A1.dts
+++ b/src/arm/BB-BELA-00A1.dts
@@ -19,12 +19,9 @@
        fragment@0 {
                target = <&ocp>;
                __overlay__ {
-                       P2_09_pinmux { status = "disabled"; };
-                       P2_11_pinmux { status = "disabled"; };
                        P2_26_pinmux { status = "disabled"; };
                        P2_30_pinmux { status = "disabled"; };
                        P2_32_pinmux { status = "disabled"; };
-                       P2_33_pinmux { status = "disabled"; };
                        P2_34_pinmux { status = "disabled"; };
                        P1_05_pinmux { status = "disabled"; };
                        P1_06_pinmux { status = "disabled"; };
@@ -156,10 +153,9 @@
                target = <&i2c1>;
                __overlay__ {
                        pinctrl-names = "default";
-                       pinctrl-0 = <&i2c1_pins>;

                        status = "okay";
-                       clock-frequency = <100000>;
+                       clock-frequency = <1000000>;
                };
        };

@@ -251,6 +247,8 @@
                        P1_30_pinmux{ pinctrl-0 = <&P1_30_bela>; };
                        P1_02_pinmux{ pinctrl-0 = <&P1_02_bela>; };
                        P1_04_pinmux{ pinctrl-0 = <&P1_04_bela>; };
+                       P2_09_pinmux{ pinctrl-0 = <&P2_09_i2c_pin>; };
+                       P2_11_pinmux{ pinctrl-0 = <&P2_11_i2c_pin>; };
                };
        };

      This does the following:

      • avoids disabling P2_33_pinmux (which was a mistake, as mentioned above)
      • Instead of disabling the P2_09_pinmux and P2_11_pinmux, it just sets its default values to be i2c. Then via config-pin you can still change their behaviour to make them gpio. The downside of this is that I don't think it would work straight away on a BeagleBone, but it should work well for your purposes.
      • avoids telling the i2c-1 bus to own the pins (as they will already be set by the P2_xx_pinmux entries)
      • bonus: increases the speed of the i2c-1 bus

      After you apply the patch (either manually, by removing the lines marked with a - and adding those marked with +, or using patch or git apply), then to apply these changes you would do:
      - rebuild the dtbo:

      make -C /opt/bb.org-overlays

      (if this does not output this line DTC src/arm/BB-BELA-00A1.dtbo, it may be that the date is not set correctly on the board and so the file does not appear to have changed to the make building system. In that case, simply delete the output file with rm /opt/bb.org-overlays/ src/arm/BB-BELA-00A1.dtbo and try again).

      • install it in the system location 
        make -C /opt/bb.org-overlays installl
      • then reboot and you should be able to use config-pin again

      Success! I can now control P2_9, P2_11 and P2_33 while bela is running C++ app or my code. Attached a gif (animated, but I don't think that it works on the site) which shows a demo app running. It's redrawing the screen each time and sending as one big buffer 23 times a second (if my calculations are correct).

      alt text

        great!

        PaulELong Attached a gif (animated, but I don't think that it works on the site)

        I noticed the same thing today. The solution was to go to imgur, upload it manually (no need for an account), then get the url by clicking the "get share links"

          Sorry it turns out my instructions were wrong, I amended your post. It turns out that imgur has "images" or "posts" and sharing one is different from sharing the other.

          That is very, very cool! Thanks for blazing the trail.

          Now that this is getting real, time to ask some questions!

          • What's the latency/frame rate now?
          • What's the CPU overhead for running this? I assume it's related to how often the image is changed (e.g., any change to a framebuffer requires resending all the bits on the bus, a static image needs no refresh)

          Would love this capability to be baked into bela someway. Having a display is a common feature. But given that it only works on the Bela mini makes that less appealing. Still even having a slow display for the non-mini bela would be useful. Wonder how fast this could go without the hardware assist.

          The OLED is 128x128 waveshare.

          My frame rate is 23 frames/sec. I haven't thought about latency yet or how to test it. Also the only testing with load so far is running the my OLED demo with the passthrough example. My next step is to integrate it into my harmonizer project, which will tell me what happens in a real-time scenario where latency will be a factor. I can try to figure out a way to measure latency/cpu load more directly, but my guess is you are right, and it will be related to how often you update the buffer. The OLED I'm using has a way to write any rectangle area, so updates could optimized to maximize the redraws.

          As for baking it in, I think I2C is an option. The original waveshare demo supported SPI and I2C, and was targeted at some other platforms using flags. I added a BELA and the associated code. So my guess is that with the I2C version is pretty easy to create.

            Would be good to bake this into the hardware/os and support on bela (as well as bela mini). Hardware support (even at the optional expense of some other feature like an analog out or spare pru) seems key to a real-time display. Would take some effort and possibly some changes to next gen of boards...

            PaulELong As for baking it in, I think I2C is an option. The original waveshare demo supported SPI and I2C, and was targeted at some other platforms using flags. I added a BELA and the associated code. So my guess is that with the I2C version is pretty easy to create.

              a month later

              Hey giuliomoro ,

              I have my screen at my bow and I’m not using my computer to load the Bela when I perform. Is there a way to connect the screen with my patch without calling from the terminal?

              alt text

                Not sure what you mean by "connect the screen with my patch without calling from the terminal". If what you mean is that you are handling the display from a separate process and you want to start that process at startup, then see the answer i gave to @crosswick here. Otherwise, please rephrase the question so that I can better understand what you mean.