SPI/I2C OLED display


#237

sure. the OLED objects use an include, look at the original file. in short: you cannot embed them. you rather want to copy the file to your local library and copy the included file over as well (preserve the folder structure)...


#238

Thanks, yes it make sense, the included file is the font informations I guess.
I'll try it tomorrow!


#239

I've always felt that these tiny OLEDs have much more potential for controlling the Axoloti so I've started messing with tiar's OLED objects.

First of all I've added an 'invert Line' inlet which highlights one line just like when you'd scroll through a menu line by line (with integer inlet: 0=off, 10=line1, etc.).

OLED gif

For now I am adding functions via additional inlets/outlets to the existing objects, but that would leave it to each user to implement a higher-level UI on their OLEDs.

For ease of use I would eventually want to create a small collection of "menu UI" objects which offer a menu tree that:

  • must be easy to populate and navigate (dedicated menu tree object)?
  • can send and receive values to/from objects?
  • can interface with preset objects so you could load, edit, and store presets

Any thoughts?


#240

Great ideas! I also feel that having a good collection of Oled objects would change a lot the approach of Axoloti to some people. Some friends bought an Axoloti and sold it back later because they were lacking visual feedback and the did not have the knowledge or the will to fiddle around.

I'm also currently trying to study Tiar's objects, I'm quite noobish with C++ and doing more reverse engineering than coding at the moment, so I can't offer my help on the technical side.

I did start, however, to program my own fonts as well as using these to create animations on the screen.
Right now, I'm still limited by the number of lines (pages) and characters and I need to build a puzzle typeface to display an image and animate it.

I believe that a great addition would be the possibility to change (via an inlet or a selector) the number of line the user wants to display (as well as the size of the font).
being able to play around with the graphics would be a great addition and could lead to great custom animations, fonts ans menus.


#241

Any input on the oled front is always greatly received. I think @weasel79 was working on a few things, and had some animations running.

I've always looked at Norns scripts like Orca and Compass and thought they would be awesome on axoloti...compass for example is a looper that is sequenced using key\letter commands which are selected from the screen like this looks like it can go quite complex while remaining fun.

Your menu tree idea looks very useful.


#242

i've been thinking of exactly this issue on the axoctlr (i modded the one from hohum to turn a knob into a encoder)
and i was thinking of something like the thing seen here https://sebiik.github.io/community.axoloti.com.backup/t/multiple-pages-of-parameters-for-axoctrl/6572/5

It's rudimentary but it seems like it works


#243

hey @sebiiksbcs ,
...you mind sharing the modded OLED - object?
I just got myself one,and it's working as a charm thanks to
@SmashedTransistors GREAT objects.

also,I started working on objects to acces multiple parameter pages,
here's where I'm at:
oled.axp (10.8 KB)
...you need to sync libraries...
it's a scroll-down approach for up to 8 parameters.
the patch requires an OLED of course,
and a rotary encoder with a button.(or, another hardware button)

the subpatch top left only makes sense for my setup,
you have wire it up according to your setup.

cheers,
R


#244

ah and here's a little tool for text entry:

...quite minimalistic,extremly limited character-set but with a flashing cursor.


#245

also,I started working on objects to acces multiple parameter pages, here's where I'm at:
oled.axp4 (10.8 KB)

Nice! The patch works on my Axo and I'll check out what's happening code-wise when I have the time.

Meanwhile here's the 'invertLine' OLED object I've made:

OLED_invertLine.axp (51.9 KB)

Note that by now I've also added a fontObject feature which lets you choose your font directly from an object in the patcher. (You have to paste your font data in the array in the object's local data.) It just seems faster to test fonts this way.
The reason I've wanted to change the font is the original font goes all the way vertically and it doesn't look good when the line is inverted. You can compare fonts by changing the fontObject reference on the OLED object (same procedure like with the scope).


#246

thanx a lot!
...looking at @SmashedTransistors OLED-objects I notice that the code is
far beyond my spaghetti-coder capabilities, great you find your way in there..
and I just learned that '~' is bitwise NOT,cool.

BTW I moved my objects to rbrt/string , because they are not strictly OLED-related.

cheers R


#247

oops, typed a mistake here.


#248

Which Resistor needs to be removed? I've the same display, but not really a clue how to prepare it


#249

On many device, it is clearly indicated

for this one
SPI:R17
I2C R15 R13
R18 for CS (chip select)

so remove R17 and add straps on R15 R13 and R18 markings.

Do you have this exact one ?

Do you have some markings on yours ?


#250

my fault, I thought I have to add additional straps apart from the obvious .

Now it's working


#251

Hey @SmashedTransistors
Thanks for these awesome objects!
I managed to change the adress of one display and I have now 2 of them hooked up.
Your help patch seems to be fine.
When I start to change thing however the bar object is not really working. Instead of a bar it cycles theough different characters. Anything I’m doing wrong here?

UPDATE: Got it working right with 2 independent objects. Now I'm trying to hack into these objects, so I could have 2 bars next to each other on one line so they would better reflect my encoder arrangement here :face_with_monocle:


#252

Yes you're right,
you should use the "OLED128x64nice" objects (along with a gpio/i2c/config object from the standard lib).

The old OLED128x64Dbl does not implement the horizontal bars.
I added some obsolescence comments in its help patch and object info.


#253

Allright thx!

I have some more questions (also to the oled community here)

could these slightly bigger displays be used as well?


It says SPi but as I recall @SmashedTransistors you have been modding spi displays too right?

Another question is:
can I run the more common oleds in this thread that I'm using as well run on 5v instead of the 3.3?
The reason for this is, that I am embedding two oleds in an existing midi controller and combining the oled and usb data to a custom connector to axoloti. If the oled is running on 5v I could just take the 5v from usb and save one wire running to axo. Or is that extremly stupid for some reason?


#254

No, they won't work.
They cannot be configured to I2C and
they do not work at all like the little monochrome 128x64 oled displays (not the same binary structure and commands to display pixels).


#255

I got two of the displays working, thanks for the great object.
In order to organize my patch, I want to dynamically switch the data sent to the display depending on the context. My object only has one string output per display line.

I made a function in my sub patch in the "local data" tab, copied from "f_c", and I added the local data and init calls as well.

char* f_c(float i, char* prefix) {
	char c[7+strlen(prefix)];
	char *p=c+strlen(prefix);
	strcpy(&c[0],prefix);
	float f = i * (1.0f/(1<<21));
	if(i > 0)       p[0] = '+';
	else if(i < 0) {p[0] = '-'; f = -f; }
	else p[0] = ' ';
	if(f >= 1000){
	  p[1]=127;p[2]=127;p[3]=0;
	} else {
	  {
	    int cent=(int)(f/100);
	    if(cent == 0) p[1]=' '; else p[1]='0' + cent;
	    f -= cent * 100;
	  }
	  {
	    int diz=(int)(f/10);
	    if(diz == 0) p[2] = ' '; else p[2]='0' + diz;
	    f -= diz * 10;
	  }
	  {
	    int un = (int)(f);
	    p[3] = '0' + un;
	    f -= un * 1;
	    p[4] = '.';
	  }
	  {
	  int diz = (int)(f*10);
	  p[5] = '0'+diz;
	  f -= diz * 10;
	  }
	  p[6]=0;
	}

	return c;

}

If I call it from my k-rate code, the prefix string is displayed, the float is not. I don't understand why.
I tried both strbar and bar mode in the same manner. I get similar results (no bar basically)
I set the c[0] byte according to the mode. they are displayed as "U"

char* stringbar(int i, char* prefix) {
	char c[2 + strlen(prefix)];
	strcpy(&c[2], prefix);
	c[0] = 0;                         //string bar mode
	int32_t v = __SSAT(i,28)>>21;
	if(v >= 0)
  		c[1] = (uint8_t)(v + 1); // must not be zero !
	else 
  		c[1] = (uint8_t)(256 + v); 
	return c;
}


char* barmode(int i){
	char c[3];
	c[0] = 2;  //bar mode
	c[2] = '\0';
	int32_t v = i >>20;
	if(v >= 0)
	  if(v > 127)
	    c[1] = 128;
	  else
	    c[1] = (uint8_t)(v + 1); //[1 128]
	else
	  if(v < -127)
	    c[1] = 129;
	  else    
	    c[1] = (uint8_t)(256 + v);  //[255 128] 
	return c;
}

Obviously I'm missing something here, but I do not get it...


#256

Hey ho thanks for the clear answer! Did you have any progress getting 8 lines on a 2,42"? What you posted there above looks quite promisings!

EDIT: Ah I just saw the objects with the 8 lines. Looks very very promising, I wanna get one of these. Do you know if this one would work?