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

Unable to run the library on SSD1327 #276

Open
sofian opened this issue Mar 2, 2020 · 13 comments
Open

Unable to run the library on SSD1327 #276

sofian opened this issue Mar 2, 2020 · 13 comments

Comments

@sofian
Copy link

sofian commented Mar 2, 2020

Type of Raspberry Pi

RPi 3 B+

Linux Kernel version

Linux raspberrypi 4.19.57-v7+ #1244 SMP Thu Jul 4 18:45:25 BST 2019 armv7l GNU/Linux

Expected behaviour

The examples on SSD1327 should run fine. It works in SPI mode but not in I2C mode.

Actual behaviour

The device is not being detected.

pi@raspberrypi:~ $ i2cdetect -y 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --                         
pi@raspberrypi:~ $ lsmod | grep i2c
i2c_bcm2835            16384  0
i2c_dev                20480  0

Things I tried

I believe the I2C is setup properly because I ran a test with an i2c circuit using an Arduino as a slave (cf. https://radiostud.io/howto-i2c-communication-rpi/) and i2cdetect was able to find the device.

I also know the I2C device works because I was able to control it using an ESP32 and the U8g2 library. I have two of these devices: both of them work with the ESP32, none of them work on the Pi.

I also tried to change my wires just to make sure, but without any success.

I also tried to change from 3.3V to 5V as Vcc (the SSD1327 can support it) but it also did not change anything.

Wiring

Here is how my device is wired:

SSD1327    RPi3
-----------------------
GND            pin 6
Vcc              pin 1
SDA             pin 3
SCL             pin 5
@rm-hull
Copy link
Owner

rm-hull commented Mar 3, 2020

If i2cdetect isn’t finding it, then it isn’t really an issue with this library

@xcarcelle
Copy link
Collaborator

@sofian :

  • is there any jumpers or resistors on the ssd1327 to select i2c and spi ?
  • can you probe the signal on SDA/SCL with a scope when running i2cdetect ?
  • can you run "i2cdetect -l" and "i2cdetect -F 1" ?

@sofian
Copy link
Author

sofian commented Mar 3, 2020

@xcarcelle

is there any jumpers or resistors on the ssd1327 to select i2c and spi ?

No, it is a model that only has i2c: https://www.tinytronics.nl/shop/en/display/oled/1.5-inch-oled-display-128*128-pixels-white-i2c

can you probe the signal on SDA/SCL with a scope when running i2cdetect ?

I don't have an oscilloscope at hand but I could do it.
We managed to make the screen run from an ESP32 using the U8g2 library in 96x96 mode (it just displays on a part of the screen) using software I2C. This is the definition we used in U8g2 arduino library:
U8G2_SSD1327_SEEED_96X96_1_SW_I2C u8g2(U8G2_R0, /* clock=*/ SCL, /* data=*/ SDA, /* reset=*/ U8X8_PIN_NONE); // Seeedstudio Grove OLED 96x96

This is the result:
photo_2020-03-03_11-16-03

Also as explained the i2cdetect is able to detect other i2c devices.

So I don't know how it would be possible that the SDA/SCL would not be activated. But I'll try to get a hand on a scope today.

can you run "i2cdetect -l" and "i2cdetect -F 1" ?

pi@raspberrypi:~ $ i2cdetect -l
i2c-1	i2c       	bcm2835 I2C adapter             	I2C adapter
pi@raspberrypi:~ $ i2cdetect -F 1
Functionalities implemented by /dev/i2c-1:
I2C                              yes
SMBus Quick Command              yes
SMBus Send Byte                  yes
SMBus Receive Byte               yes
SMBus Write Byte                 yes
SMBus Read Byte                  yes
SMBus Write Word                 yes
SMBus Read Word                  yes
SMBus Process Call               yes
SMBus Block Write                yes
SMBus Block Read                 no
SMBus Block Process Call         no
SMBus PEC                        yes
I2C Block Write                  yes
I2C Block Read                   yes

Also: it looks like the address on that device is 0x78 which is outside the normal range. I tried to scan non-regular addresses but it still couldn't find the device:

pi@raspberrypi:~ $ sudo i2cdetect -ay 1
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-1.
I will probe address range 0x00-0x7f.
Continue? [Y/n] Y
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 

@thijstriemstra
Copy link
Collaborator

It works in SPI mode but not in I2C mode.

No, it is a model that only has i2c:

Huh? This is a contradiction, no?

@sofian
Copy link
Author

sofian commented Mar 3, 2020

Sorry @thijstriemstra I was not clear. There are many manufacturers that produce screens with the SSD1327. Some allow switch between SPI and I2C with a jumper. The one I am trying to make run does not -- likely there is a way to switch it between both I2C and SPI but this particular screen does not provide a jumper to do this.

@sofian
Copy link
Author

sofian commented Mar 3, 2020

@thijstriemstra We have made tests with another model that has SPI jumper (it is SPI by default) and it was working.

@xcarcelle
Copy link
Collaborator

@sofian :

  • to make it clearer : you made a test with another ssd1327 spi/i2c screen and on i2c jumper selection and it was working ?
  • do you have a picture of the set-up Rpi3 + ssd1327(i2c only screen) wiring ?
  • probing i2c bus (sda/scl) with a scope (i2c logic analyzer could be helpful also) when running i2cdetect to see if 0x78 is replying to the requests.

@thijstriemstra
Copy link
Collaborator

thijstriemstra commented Mar 3, 2020

We have made tests with another model that has SPI jumper and it was working.

Can you provide a link to this model, would be good to document what model works with SPI.

@sofian
Copy link
Author

sofian commented Mar 3, 2020

@xcarcelle

* to make it clearer : you made a test with another ssd1327 spi/i2c screen and on i2c jumper selection and it was working ?

No. I made a test with another SSD1327 spi/i2c screen in SPI mode and it was working. We tried to switch it to I2C but it did not work / however, we did not have proper equipment to solder the resistor on the SMD jumper, we did our best but I am not sure about the connections, I don't trust that that SSD1327 is still working).

* do you have a picture of the set-up Rpi3 + ssd1327(i2c only screen) wiring ?

This is a picture of the ssd1327 i2c-only screen wiring (it's the green screen on the left, not the red one next to it):
0303202153

This is a picture of the connections on the Pi:
0303202152a

* probing i2c bus (sda/scl) with a scope (i2c logic analyzer could be helpful also) when running i2cdetect to see if 0x78 is replying to the requests.

Yes I will have a look.

@sofian
Copy link
Author

sofian commented Mar 3, 2020

@thijstriemstra

We have made tests with another model that has SPI jumper and it was working.

Can you provide a link to this model, would be good to document what model works with SPI.

Sure: here.

@zsmith-ustc
Copy link

zsmith-ustc commented Jul 5, 2020

I have a related issue, in that I can see the device exactly where expected at 0x3c when using i2cdetect, but when trying to initialize the device i get an error that the device can't be found on 0x3c. I'm using a Pi 4. The code is as simple as possible, hopefully I haven't made any trivial errors there:

from PIL import Image
from luma.core.interface.serial import i2c, spi
from luma.oled.device import ssd1327
import time
serial = i2c(port=1, address=0x3C)
device = ssd1327(serial)

when run, it yields the following traceback:

Traceback (most recent call last):
  File "/usr/local/lib/python3.7/dist-packages/luma/core/interface/serial.py", line 85, in command
    list(cmd))
  File "/usr/local/lib/python3.7/dist-packages/smbus2/smbus2.py", line 622, in write_i2c_block_data
    ioctl(self.fd, I2C_SMBUS, msg)
OSError: [Errno 121] Remote I/O error

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/pi/Desktop/little screen/oled_test1.py", line 14, in <module>
    device = ssd1327(serial)
  File "/usr/local/lib/python3.7/dist-packages/luma/oled/device/__init__.py", line 712, in __init__
    nibble_order=1, **kwargs)
  File "/usr/local/lib/python3.7/dist-packages/luma/oled/device/greyscale.py", line 34, in __init__
    self._init_sequence()
  File "/usr/local/lib/python3.7/dist-packages/luma/oled/device/__init__.py", line 724, in _init_sequence
    0xA8, 0x7F)         # set multiplex ratio: 127
  File "/usr/local/lib/python3.7/dist-packages/luma/core/device.py", line 39, in command
    self._serial_interface.command(*cmd)
  File "/usr/local/lib/python3.7/dist-packages/luma/core/interface/serial.py", line 90, in command
    'I2C device not found on address: 0x{0:02X}'.format(self._addr))
luma.core.error.DeviceNotFoundError: I2C device not found on address: 0x3C

When trying one of the included examples, I get the same error. Here is an image of the output along with the i2cdetect results:

output

Any thoughts on what might be going on here?

@ssarna1
Copy link

ssarna1 commented Jan 1, 2022

I have the same exact problem as @zsmith-ustc. I have confirmed the display itself working with Arduino and U8G2 library, but other libraries did not worked for me. I came across some other posts stating that some of the displays are not sending ACK back to master device, can this be the cause? If so, can the library get away with not getting ACK signal?

@pettefar
Copy link

pettefar commented Feb 26, 2022

I have exactly the same problem as I have the same exact problem as @zsmith-ustc and ssarna1.

nick@pop:~/luma.examples/examples $ i2cdetect -y 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- 3c -- -- -- 
Traceback (most recent call last):
  File "/usr/local/lib/python3.7/dist-packages/luma/core/interface/serial.py", line 91, in command
    list(cmd))
  File "/usr/local/lib/python3.7/dist-packages/smbus2/smbus2.py", line 643, in write_i2c_block_data
    ioctl(self.fd, I2C_SMBUS, msg)
OSError: [Errno 121] Remote I/O error

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "./tryit.sh", line 8, in <module>
    device = ssd1327(serial)
  File "/usr/local/lib/python3.7/dist-packages/luma/oled/device/__init__.py", line 723, in __init__
    nibble_order=1, **kwargs)
  File "/usr/local/lib/python3.7/dist-packages/luma/oled/device/greyscale.py", line 35, in __init__
    self._init_sequence()
  File "/usr/local/lib/python3.7/dist-packages/luma/oled/device/__init__.py", line 735, in _init_sequence
    0xA8, 0x7F)         # set multiplex ratio: 127
  File "/usr/local/lib/python3.7/dist-packages/luma/core/device.py", line 48, in command
    self._serial_interface.command(*cmd)
  File "/usr/local/lib/python3.7/dist-packages/luma/core/interface/serial.py", line 96, in command
    'I2C device not found on address: 0x{0:02X}'.format(self._addr))
luma.core.error.DeviceNotFoundError: I2C device not found on address: 0x3C

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

7 participants