I'm not sure if it helps but I played a bit with the
oled_clear() function and I changed
pari2c_writebyte_bc(0x00); to
pari2c_writebyte_bc(0xd5); just to see where it writes. I've also changed the number of iterations from
for (uint8_t i=0; i<128; i++) to
for (uint8_t i=0; i<2; i++) to see what happens. The conclusion is that it does not increment the page, it always increment the segment number. Please see below.
void oled_clear(void)
{
//ssd1306_set_region(0, 3, 0, 127);
ch1115_set_location(0, 0);
pari2c_start();
pari2c_writebyte_bc(OLED_SLADDR);
pari2c_writebyte_bc(0x40);
for (uint8_t i=0; i<128; i++)
{
pari2c_writebyte_bc(0xd5);
pari2c_writebyte_bc(0xd5);
pari2c_writebyte_bc(0xd5);
pari2c_writebyte_bc(0xd5);
}
pari2c_stop();
}
Edit: The set_location function doesn’t work. No matter if I change x or y, nothing changes on the screen.
We have to take inspiration from this file.
That one is made however for a different display resolution, but the same controller.
I wonder why the flickering. Is the data input from the meter connected? Can you disconnect it? It shouldn’t matter though because it should ignore the RAM content in this state.
Yes, it was connected to the meter. All reverted and packed away now though as the bench is now taken up with a client job. But Terra's response that he didn't see flickering is good.
I am getting corrupt SELF TEST OK message at startup, as some others mentioned. Changing various fuse settings didn't help, so I suspect my alternate choice of switching PSU components (from stock) are a bit slow to start up. I might reduce the bulk capacitor as the ones I had in stock are a bit large in size (Wurth E case 100uF 35V).
FWIW, my OLED's have the following written on the back:
L2832TSWV
P2413077-11-A***
This is the same as the 60 pcs I bought.
Interesting that you saw nearly 200mA draw on the 8V supply with all pixels lit on 12 displays. That is about 1.6W, when I only measured 800mW when using the 13V unregulated input...
Hi Miti,
I found out that the CH1115 seems to require that you send always 0x80 before a command. This was not done correctly, thus the function could not have worked properly indeed as you reported.
That part is fixed in the attached one. I also adjusted the oled_clear based on the fact that the increment at the end of one page to the next page seems not to happen as it does for SSD1336 displays.
So you should see some changes now.
I did not adjust the touch sequence in the oled.c, But (and a big one):
I think your init code is not taking care of that 0x80 value. I'd suggest to look into the .txt file I shared in my previous post and see if you can take that init sequence and adjust it to your resolution.
Crossing fingers,
Kai
Nope, the same page over and over again. I modified the init sequence as well with control byte before every command, nope. I think this chip is a POS that is advertised as compatible with SSD1306, but is not, and is not properly documented. I may cut my losses, and save your time, and buy whatever Kean bought.
Before that, I may try some of the functions in that .txt file, just to see if I can get it to show anything.
Cheers,
Miti
Edit: I'm not sure about that 0x80 control byte before every command. If you look in the oled data sheet from LCSC, there's a sample code that doesn't have that. It may be just the wrong understanding of the programmer who wrote that code. But, there are differences between his init sequence and mine, I'll compare tonight.
Hmm, the lcsc datasheet does also not state that it's a ch1115 controller.
But yeah, I think also best is to just buy the right display.
Did you spot criterias to detect that "bad" display?
Hmm, the lcsc datasheet does also not state that it's a ch1115 controller.
But yeah, I think also best is to just buy the right display.
Did you spot criterias to detect that "bad" display?
Yes it does, page 5, by the drawings, bottom right corner, page12 top of the page.
I don’t think they are defective, it’s just hard to understand how to control them.
Am I an engineer or what?
Edit: A big "Thank you" to Xyphro, he coded the new functions, I just corrected one thing that was missing and adjusted the init sequence.
Mirroring the characters wasn't too hard but the annunciators are displayed vertically and every time an annunciator is displayed, it starts scrolling.
Wow great, you got into the 5 minutes of dopamine rush after x hours of hard engineering work, that we engineers all love :-)
Will check your code. It seems to get a scroll command somehow.
Update: no scroll conmand, but also no mirroing. Just the oage adrresses have to be set.
Check this file. I have put the same method in there for the annuciators as for the digits. It is based on the latest oled.c that you shared. I did not throw this thing through the compiler yet, so typos might be there.
It seems that Display has 2 I2C addresses. 0x80 (which is 0x40 in 7-bit format) for sending commands and 0x3f for sending data? Don't get that full concept yet on how it differentiates between commands and data in i2c mode.
Check this file. I have put the same method in there for the annuciators as for the digits. It is based on the latest oled.c that you shared. I did not throw this thing through the compiler yet, so typos might be there.
Thanks, I'll give it a try soon.
It seems that Display has 2 I2C addresses. 0x80 (which is 0x40 in 7-bit format) for sending commands and 0x3f for sending data? Don't get that full concept yet on how it differentiates between commands and data in i2c mode.
Yes, A0, which in I2C mode is called SA0, is part of the slave address, same as SSD1306.
BTW, it does not need 0x80 before each command. The sequence of commands from the data sheet works, with the slave address followed by one 0x00, and with with the correct parameters, of course.
Ha ha, bull's-eye! Thanks Kai! I've also selected the correct annunciators.
Two things I observed:
1. It does not show the annunciators when pressing SHIFT -> RESET, as mentioned by TERRA.
2. It does not clear the annunciators, at least SHIFT, after the reset. Is the reset a HW reset which this design cannot catch?
Edit: And no more scrolling.
Are those 2 issues a general issue, or newly introduced by rhe changes?
Just want to see where to put my search-scope!
Yes, the 0x80 is just the "command slave address". I did not interpret the .txt file correctly.
So yes and no. It has to be sent, but not as data value, but as slave address at the end.
Happy that it works now for you. Gives me also a small adrenaline kick, though a smaller one than experiencing it myself :-D
Are those 2 issues a general issue, or newly introduced by rhe changes?
Just want to see where to put my search-scope!
I don't think they are new, at least not showing the annunciators after reset was seen before with the original code by other members.
I checked it once with my 3457a:
https://youtu.be/VUZxWYohl38?si=Zg9qbPTjzVtnXP-2It turns all annuciators on and also clears shift.
Could it be hp3458 specific?
In case you have some logic analyzer capturing all signals like this would be grear:
Precobdition: ensure the display does not continously change its content, e.g. select manual trigger
Start capturing press shift then reset
Sorry, no logic analizez on this side of the pond.
In case another user has one and also that issue, letme know :-)
I could use the scope. It is SPI , isn’t it? Rigol can decode SPI.
It's not spi unfortunately. Capturing it with a scope might not be easy cause it cannot capture many muliple seconds at high samplerates :-(
You can give it a try, maybe it works, but it can end up in frustrations. Exporting a waveform as csv or so would enable me to decode.
@Terra, do you maybe have a logic analyzer to capture a shift->reset sequence of your device by capturing all data lines with it?
Just to understand why e.g. the shift annuciator does not clear.
I suspect that, rather than updating the annunciators, there’s a special command that reset the front panel and you don’t have it in your list. However, the digits are updated.
Me too, that's exactly why I look for a logic analyzer trace to get to know that cmd.
My hp3547 seems to behave as expected and I did not see unhandled commands during development. It is very well possible that there is even a bigger set of commands which is missing for full compatibility.