Remork be impossible to use with Bela?

probably so.

See the list of used pins [very hard to find].
At least these:

  "P9.28", /* pwm: eCAP2_in_PWM2_out */
  "P9.29", /* ft5336: gpio3_15 */
  "P9.31", /* ft5336: gpio3_14 */

are already being used by Bela for audio I/O purposes.
Maybe some could be remapped. The last two are used as GPIOs so most other pins could be used instead. but the first one seems to have a pretty specific use case. Maybe P9.42A could be used instead. Using alternative pins would involve bending out the pins of the screen cape so that they do not enter the BBB's header and then jumper them with wires. The other issue is that the software support for the screen seems to be patchy. From what I understand they want you to install their image, which is clearly bonkers.

If there is a way to simply install the drivers AND P9.42A works then maybe it can be done.

      hah. gotcha.
      the only answer for me would be 'nevermind' then.
      thanks for clearing that up.

      ordered me some OLEDs, so i'll probably be back to ask more questions than you can answer.

        Remork ask more questions than you can answer.

        Challenge accepted. If you are on Bela, do not get an SPI one. If on BelaMini, SPI is fine.

          4 days later

          Remork s members-only content.. can't even open that link.)

          I know right, but what can I say? Push for the manufacturer to make their documentation more readily available and accessible? Prefer other manufacturers that do? (registration to Element14 is free, by the way)

            didn't mean anything by it, just seemed a bit surprising for a community-based brand.
            i wouldn't mind registering if i thought it'd make sense to do so.
            but tbh, i wouldn't know where to start looking for what i need - and even if i found it i'm not sure i would fully understand. once you start about what pins are already in use and remapping them, my eyes glaze over and i'm in Malibu with a coconut cocktail, mentally. (i try to learn, though.)
            plus, chances of me using a BBB without the Bela are just about zero - i only use them because it's where Belas live. i have a hard enough time getting my head around the Bela 🙂

            and so as long as there's people like yourself kind enough to help people like myself out.. [humbled]

            8 days later

            so i got the displays in.
            since most of this is going well over my head, i decided to take a few tiny steps at first.
            so i hooked up the one with the SSD1306 controller, leaving the SSD1309 for what it is for now.

            i uploaded these files to my Bela Mini:

            and i'm just running that as is, not even sending it OSC messages yet.
            it seems to work - in that i got the 'OSC TEST!' message on the display. which was quite astonishing 🙂
            changed that message in render.cpp line#165, played around with that a little, and then noticed that the text wrap was off.
            now i'm sure that has to do with the fact that i have a 102x64 display hooked up instead of a 128x64..
            i'm plowing through the code and the datasheets, and managed to change the column address to range from 13 to 114 as per the display datasheet. now the wrap seems to be fixed, but i'm losing a whole lot of characters from the beginning of the string. i'm sure it's just something small somewhere. more testing tomorrow!

                seems promising for now! I haven't really looked into the content of the library: I try to avoid actually reading the code any time I can get away with it and focus instead on the integration/wrapping of it with the rest.

                Remork 13 to 114 as per the display datasheet.

                What change did you make there? ( a diff would be very useful in these cases). If you are losing the first 13 characters, it may be that the library already handles that initial offset elsewhere and you may have to set the range to 0 : 102 or similar (this is just a blind guess, without looking at the library code. Tell me where you changed it and I will have a look)

                    giuliomoro I try to avoid actually reading the code any time I can get away with it

                    LOL 🙂 you and me both, hah. but i do want to understand what i'm doing, so if i can muster up the courage, i don't really mind. on some days.

                    i'm gonna start fresh from those files, and adjust just a single parameter at a time.. see if that makes more sense.
                    if i can't work it out, i'll yell.

                      in SSD1306_OLED.h, there's these settings for display sizes:

                      #define SSD1306_128_64 (default)
                      //#define SSD1306_128_32
                      //#define SSD1306_96_16

                      setting WxH to 128x64, 128x32 and 96x16, respectively.
                      i had hoped it would be as simple as modifying those values (SSD1306_LCD_WIDTH and SSD1306_LCD_HEIGHT) to the size of the display i'm using, aka 102x64.
                      but no such luck - very garbled results.

                      if i go back to the default settings and run a teststring ("0123456789abcdefghijkl.." etc) to start at cursor(0,0), i lose pixels at both ends of the display. if i start at cursor(13,0), the first line starts ok. which is consistent with the datasheet: https://docs.rs-online.com/1ff8/A700000006657120.pdf, using columns 13 - 114 (page6, top right.)

                      i just noticed that setting the start and end column is possible, but is not included in 'display_Init_seq()'.
                      i will try adding those.
                      nevermind. it's included in the 'display()' routine. doesn't fix my problem though..
                      setting start and end to 13 and 114, the wraparound is now correct - but i'm back where i started losing a huge amount of characters at the start of the string, and it's adding spaces between characters where there shouldn't be any. also it seems to be starting at line 24 rather than 0 (aka letters start on 'third row' with ch size 1.)

                      (sigh. maybe just buy me some proper I2C 128x64 SSD1306 OLEDs.. )

                      could this have anything to do with the sequence in which everything runs?
                      right now it's initialization - clear display - set string - and then display().
                      the latter which: 1. Resets the column and page addresses. 2. Displays the contents of the memory buffer.

                      as i understood it, setting the columns also sets the RAM locations.
                      so is it possible that i need to set the columns, thén set the string to correctly allocated memory, and then display buffer contents?

                      hmm.
                      the display is indeed acting like a cut-out version of a full 128x64 display.
                      if i set everything to default (so size 128x64), the graphic examples (testdrawcircle() etc) work ok, but as i said i'm losing text on both sides.
                      if i set start and end column to 13 and 114, everything goes haywire 🙂

                      if i set start and end column and drop SSD1306_LCDWIDTH to the required 102, it's more promising!
                      but not quite there.. see pic. this is the "testdrawcircle()" from the examples.
                      the weird thing is that the whole animation is ok, but then when the animation ends the top of the screen is being blacked out.
                      alt text

                      if i run an example with multiple actions (draw lines etc), in between stages it does the same thing.

                      now the only thing that recurs everywhere is "Display()".
                      this sets the start/end column/page, which i believe to be correct (otherwise the circles wouldn't be centered?).

                      but it also calls "transfer()", which it does at the end, and which transfers the buffer onto the display.
                      could it be i have to adjust the size of the buffer somewhere? that it is writing empty blocks last, using only 102x64 of a 128x64 size buffer, or something?

                      Ow yeah.
                      in "transfer", i changed loop_1's range from 1024 (=8x128) to 816 (=8x102).
                      set the break at the bottom to happen at index 816 as well.

                      hey presto. all good.

                      might be better if this range is dependent on the 'SSD1306_LCDWIDTH' (aka 8*LCDWIDTH), no?
                      something like

                      void transfer()
                      {
                      short loop_1 = 0, loop_2 = 0;
                      short index = 0x00;
                      for (loop_1 = 0; loop_1 < SSD1306_LCDWIDTH*8; loop_1++)
                      {
                      chunk[0] = 0x40;
                      for(loop_2 = 1; loop_2 < 17; loop_2++)
                      chunk[loop_2] = screen[index++];
                      if(i2c_multiple_writes(I2C_DEV_1.fd_i2c, 17, chunk) == 17)
                      {
                      #ifdef SSD1306_DBG
                      printf("Chunk written to RAM - Completed\r\n");
                      #endif
                      }
                      else
                      {
                      #ifdef SSD1306_DBG
                      printf("Chunk written to RAM - Failed\r\n");
                      #endif
                      exit(1);
                      }

                          memset(chunk,0x00,17);
    if(index == SSD1306_LCDWIDTH*8)
        break;
}

                      }

                      that works for me.
                      although i can imagine that there's still some possible conflict for non-64line displays in there, maybe.
                      but this should make it a little more universal at least.

                      alright, now i got that working.. onto OSC 🙂

                      to summarize for posterity, if anybody ever wants to use a 102x64 display:
                      1. don't.
                      2. if you must, do the following:

                      • in SSD1306_OLED.h, under 'Enable the WxL of the Display' (line 64):
                        add '#define SSD1306_102_64' and make sure it's the only uncommented option.

                      • add the definition (line 84):
                        #if defined SSD1306_102_64
                        #define SSD1306_LCDWIDTH 102
                        #define SSD1306_LCDHEIGHT 64
                        #endif

                      • under Configuration Commands (line 121):
                        change SSD1306_COL_START_ADDR to 0x0D (=13) or the correct start column value for your display.
                        change SSD1306_COL_END_ADDR to 0x72 (=114), or the correct end column value for your display.

                      • in SSD1306_OLED.c, under 'Transfer':
                        change 'loop_1 < 1024;' to 'loop_1 < 816;' or 'loop_1 < SSD1306_LCDWIDTH*8;' (line 762).

                        change 'if(index == 1024)' to 'if(index == 816)' or 'if(index == SSD1306_LCDWIDTH*8)' (line 782).

                      thanks for going through the steps and summarising them for others! You may want to do the final stretch and make a pull request on my repository including these changes (for the very first change: add the line commented-out, same as SSD1306_128_32 and SSD1306_96_16 currently are).