display simple text from PureData?

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.

giuliomoro See the list of used pins [very hard to find].

(just so u know, but this is members-only content.. can't even open that link.)

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]

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:

giuliomoro https://github.com/giuliomoro/OSC2OLED4Bela

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!

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

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.

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

sure, would love to. but does that require a Github account? (which i don't have..)
still learning to navigate github speak, had to google 'pull request'. hah. nooby me.