• Hardware

  • is anyone successfully using i2c OLED / LCD?

5 months later

aha! ran into the same issue.
might be good to add that to the 'Using an OLED Screen' knowledge base page?

also, for Github noobs such as myself, 'the latest dev branch' is somewhat vague.
i'm assuming it's dev-i2c, but if that turns out to be the working one, it was still a lucky guess.

    also, allow me to type

    No rule to make target '/root/Bela/projects/O2O-main/build/

    for community searching purposes. i kinda lucked out finding this thread.

    so i got lucky 🙂 and got the ascii BELA logo on my screen. wonderful!

    i had to change the
    [connect 192.168.6.2 7562 (
    message box in the included local.pd file to
    [connect 192.168.7.2 7562 (
    for everything to communicate correctly.

    yay!

    Remork also, for Github noobs such as myself, 'the latest dev branch' is somewhat vague.

    I literally meant the latest dev branch: the current version of the dev branch, sorry fpr the confusion.
    I would discourage using dev-i2c for anything as it's only randomly occasionally rebased on dev but otherwise unmaintained

      6 days later

      tried updating to the latest dev branch over the IDE.
      that went wrong somehow, got a dropped IDE connection and no way to recover.
      trying the script method as we speak.

      edit: seems to have worked. yay.

      a year later

      so i'm trying to get an SSD1327 128x128 oled to work.
      updated the code on the board using the script method (again, IDE method failed).
      dropped O2O .zip on IDE, adjusted setup function to
      u8g2_Setup_ssd1327_midas_128x128_f
      it runs, i get the ASCII Bela logo, and i can communicate with local.pd.

      my problem is the display speed: if i runparameters, lfo'sorwaveformsfrom the example, everything slows down dramatically, where it feels like the display can't keep up with the data it's being sent.
      e.g. waveformssends data every 100ms, but that data gets displayed magnitudes slower.
      if i hitnumberafter one of the other functions it will eventually display a number, but only after it churns out every single change it was sent - and it seems to be chewing on that info for quite a long time.
      e.g. i hadlfo'srunning for about ten seconds, turned it off and hit display-text. that text would take over a minute to appear.

      i've a feeling the old OSC2OLED4BELA was faster, but maybe that's just me thinking everything was better when i was younger.

      is this to do with the library? am i the first one to notice this? any way to remedy this?
      i read about boosting the clock speed (post #57 of this thread) but not sure how to go about doing that, or if that is even the key to the issue. thanks!

        okay nevermind, just found another thread where i'm asking the same questions.
        still need to check those solutions.
        focus much?

        hmm. so i hooked the OLED up to pepper.
        it's faster than the other board i tried, but still too slow to succesfully keep up with the 100ms bangs Pd is sending out. it seems to be updating at something between half and 1/3 that speed. i.e. if i run LFO'sfor four seconds, then turn it off in Pd, it takes another four or five seconds to finish the animation.

        it could be workable, but it's not really ideal.

        first, check the i2c bus speed by running:

        dmesg | grep omap_i2c.*bus

        Remork i've a feeling the old OSC2OLED4BELA was faster, but maybe that's just me thinking everything was better when i was younger.

        I don't think that would have been the case. It is really down to how much data you send, how fast the I2c bus is and how busy the CPU is doing other things. It seems like it would be good to ignore all past OSC messages and only take into consideration the most recent one available in the queue, but this is a workaround. Let's first find out what is limiting the refresh rate for you now.

          [ 0.702571] omap_i2c 44e0b000.i2c: bus 0 rev0.11 at 400 kHz
          [ 0.704215] omap_i2c 4802a000.i2c: bus 1 rev0.11 at 400 kHz
          [ 0.707380] omap_i2c 4819c000.i2c: bus 2 rev0.11 at 400 kHz

          OK that looks good. Let's see about this performance issue, then: do you get this "delay" even when running O2O alone, without any Bela program?

          not sure if that's what you mean, but this is with just O2O running on Bela/Pepper, and the pd example patch running on my laptop.
          i don't have O2O running in the background, with another project running on Pepper, if that's the question.

          yes that's the question. I guess this is unexpected, then. Can you disable all metros from the Pd patch and just use the following (with the sliders set to a range of 0:1 ) and see if you still notice the latency when adjusting one of the sliders manually:

          alt text

          will try.
          but i found this on an arduino forum:

          'The SSD1327 indeed is a graylevel controller (4 bit per pixel). There is no monochrome mode and no graphics acceleration: So, u8g2 has to transfer 4 bit for one pixel.
          Also remember, that u8g2 is a monochrome library. U8g2 can not use all the different shades of gray: 0 is mapped to 0000 and 1 to 1111.

          Maybe the full page mode constructor will be a little bit faster (if you have something bigger than an Uno), but in general, there is nothing much what you could do.'

          so sounds like SSD1327 is just a bad match for the U8g2 lib..
          will look into other screens then - probably easier than reinventing the wheel on the lib front.

          Let's try to live with the low refresh rate but avoid messages piling up which cause the noticeable delay after a while. I will send you a patch later today hopefully.