SPI/I2C OLED display

#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?

#257

You may have to change it to I2C operation and generate the reset as described in some previous post.

#258

Maybe you can use the tiar/string/mux objects

#259

Ok cool so that would mean in the case of this one reove r3 and r5 right?

#260

Yes, and maybe remove R4.
Check if they provide some pdf datasheet/info ?

#261

No datasheet but some more info on the manufactureres site:


"SPI communication or I2C communication can be switched by configuring three resistors R3 R4 R5.

As for IIC communication, it is necessary to move the resistor on R4 to R3, and R5 is soldered with 0 ohm resistor."

#262

I like the remind4 object from @SmashedTransistors but I would have the parameter on 1 line an the value on a separate line. Your approach to do it is smart but a little bit complicated. Would it be possible to modify the remind4 object to display on 2 lines?

#263

Hey guys.

Long time ago I bought a cople of the OLED display, but I don't remember if it was SPI or I2C.

Is there anyway I can find out the type?

I checked the small bags that they came it, they had a number on it, which I googled, but didn't find any answer. I also checked my Ebay purchase history, but it only goes 2 years back, so can not see anything there either, I bough them more than 2 years ago.

#264

if it has 4 pins:
- SCL
- SDA
- VCC
- GND
then it is I2C.

for SPI you would have 6 pins:
- MOSI
- SCK
- CS
- DC
- VCC
- GND

#265

@gonp

Thank you very much, it only have 4 pins, so it must be I2C. That was actually what I was hoping for. Going to try them out for an Ardunio build I am working on :slight_smile:

#266

I managed to isolate the value and display it on another line
outlet_out = c;
outlet_out2 = p;

I will investigate to display only the "prefix" on the other line.

Edit: It's ok now. I have 3 outputs. Chainable. Thanks!

#267

Not so much a question of "is this a bad idea?", but more of a question of "how bad of an idea is this?"

Can I run a single i2c display off of two separate buses (two different wires soldered onto each the SCL and SDA pins) if both are running 3.3v logic? Say for example, I'm using a Teensy sending serial to the Axoloti, and want to use the screen to indicate things on the control side (sending from Teensy i2c bus), and then I want to use a scope object in the Axoloti to view something on screen there, using MIDI to toggle between the screens. Hypothetically the "clear buffer" function of one would wipe the display of the other.

They're both running off of the same power source, share common ground, etc. I know it's not ideal, but is it possible? There's that other thread where someone attached a rotary encoder onto one pin, so I know there are other mad-lads on here :rofl:

#268

Both share the same GND, and since I2C ist open collector / open drain, I see no electrical problems (apart from a slight chance of ground loops), i.e. nothing will burst into flames or go up in smoke.
However, I2C is a single-master bus (well, there are extended specs for multi-master I2C, but I've never seen that work), so connecting two masters (Teensy and Axoloti) can lead to serious confusion and software crashes, unless the I2C implementations are very robust. Each master believes it is the one and only boss on the bus and will send commands whenever it wants and will interpret all other signals on the bus as responses from the slave (the display). So if both happen to send data to the display at approximately the same time, chaos ensues.
So, you can try it, you won't break anything, the results may be fun, but don't expect a reliably working, useful display.

#269

Oh understood, because for some reason I had thought that there wasn't any sort of "return" signal from the OLED, but since the SDA works both ways it sounds like the SDA send of the Teensy/Axo might be returned to the other device. Is it possible to use an i2c multiplexer as a demultiplexer, the way that you can with digital/analog and a 4067 (understanding that they're different protocols)?

Either way, thanks for the answer! If I try this, I'll be sure to post the results here. Should be hilarious.

#270

AFAIK, I2C multiplexers only work the other way around, i.e. to connect one master to several busses. As the multiplexer gets its switching commands via I2C, you can't just connect it "backwards".
But any analog multiplexer (e.g. 4067) should be able to switch I2C.
Also you could use a handshake signal and software to make sure that only one master at a time uses the display.

Software Patch for assigning Hardware display screen
#271

Two ideas (no clue how to achieve this):
1 - Playing arkanoid on axoloti.
2 - Display text moving from left to right or viceversa.(for larger texts).

#272
#273

There's an object called tiar/string/scroll. There's two actually, but "tiar/string/scroll v8" mentions that it scrolls vertically. Try the simple tiar/string/scroll object to see if it works horizontally.