Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Differences with sh1107 #24

Open
PvdBerg1998 opened this issue Jan 2, 2021 · 7 comments
Open

Differences with sh1107 #24

PvdBerg1998 opened this issue Jan 2, 2021 · 7 comments

Comments

@PvdBerg1998
Copy link

PvdBerg1998 commented Jan 2, 2021

Happy new year!

I've got some sh1107's lying around and they seem very similar to the sh1106. In fact, they appear to work with this crate, or at least I was able to render some text. However, their resolution is 64x128 instead of 128x64. I've tried to add this resolution to your code but I got stuck on the i2c send implementation assuming a 128 byte array. Do you know if this is easily fixable?

Thanks in advance!

Edit: I've tried rendering at 90 degrees, which works sort of. The coordinate 0,0 renders to 0,32 (left middle), so something is wrong with the coordinate transform.

@PvdBerg1998
Copy link
Author

I've implemented my own tiny driver. Just fyi, it appears that the screen is shifted 32 pixels to the right, meaning 0,0 is actually 32,0.

@aaron-hardin
Copy link

I would also be interested in the sh1107, though I guess that would be it's own crate.
I found these resources but haven't verified the command differences with the datasheets:

It seems that (according to the code above) the following commands are different:

  • 2 suggested ratio
  • 3 set multiplex
  • 5 display offset
  • 18 set vcom detect

@aaron-hardin
Copy link

I got a fork working here: https://github.com/aaron-hardin/sh1107
It's not pretty but it's working for the most part. It has some stray pixels along the top but other than that uses the full display.

@DanCrank
Copy link

DanCrank commented May 28, 2022

I found that bumping the DisplayOffset from 0x60 to 0x62 cleaned up the two uninitialized columns of pixels on my hardware (Adafruit 64x128 OLED FeatherWing). I have no idea why this is the case, since the C++ driver uses 0x60 and works fine on the same hardware.

@aaron-hardin, thanks for the fork!

@petekubiak
Copy link

Hi, I came here from @aaron-hardin 's fork, which I'm using to control an Adafruit 64 x 128 OLED FeatherWing too. I came to the same conclusion as @DanCrank, setting DisplayOffset to 0x62 in order to get rid of the uninitialised pixels.

I added a new variant to the DisplaySize enum for the FeatherWing - I'll raise it as a PR soon.

I also noticed the crates.io badge on the SH1107 fork links to a crate for a different repo. I was going to raise an issue, but apparently you can't create issues on a fork.

@aaron-hardin are you still maintaining the fork? In response to whether it should be its own repo or not, a common pattern is to have (for example) a SH110x library which covers drivers for all similar hardware. This might be a better approach rather than having two entirely separate crates.

@petekubiak
Copy link

I have no idea why this is the case, since the C++ driver uses 0x60 and works fine on the same hardware.

Comparing that batch of init commands in the C++driver to the logic in init_column_mode, there are a number of differences. It seems odd that this would result in requiring a shift of 2 in the display offset configuration, but it might be a place to begin the investigation.

@aaron-hardin
Copy link

@petekubiak I haven't really done anything with it in quite a while. I think a SH110x library sounds like a great idea.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants