i2c and the lilon32 Lite

[iconoclastica]

I am trying to establish a connection between the lolin32 Lite and a touch screen (Digole) by means of i2c.

Code: Select all

import machine

pinSDA = machine.Pin(22)
pinSCL = machine.Pin(23)

# Create an I2C object out of our SDA and SCL pin objects
i2c = machine.I2C(sda=pinSDA, scl=pinSCL)

# address on the I2C bus
display = 0x27

The display is not detected by i2c. The result of i2c.scan() = [ ]. Attempts to write to the display result in a 110:

Code: Select all

>>> from digole import *
>>> i2c.scan()
[]
>>> i2c.writeto(display, b'CS')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: [Errno 110] ETIMEDOUT

The display seems functional, it powers on, runs self test, and reports "I2C address:0x27". The latter depends on the jumper setting and could also be then uart of SPI. The funny thing is, that before I had the jumper setting correct, I didnot get a timeout on write (but no result, of course).

The terminial pins are continuous where they should be and have been soldered on both sides.

I there anything else I could do to make it work?

[igor_stoppa]

[quote=iconoclastica post_id=36239 time=1556866460 user_id=5241]
pinSDA = machine.Pin(22)
pinSCL = machine.Pin(23)
[/quote]

Not sure if what I have is the Lite version, but what works for me is scl=5, sda=4 just like on esp8266.
I have also seen (but not tried yet) examples using scl=22 and sda=21.

[Roberthh]

a) did you try to swap scl and sda?
b) I see that the display has a /SS pin. Did you try to pull that low (connect to GND)?

[iconoclastica]

Not sure if what I have is the Lite version, but what works for me is scl=5, sda=4 just like on esp8266.
I have also seen (but not tried yet) examples using scl=22 and sda=21.

Well, that's the point with the Lite: there is no 21. I now tried 4 and 5, but I saw no difference.

a) did you try to swap scl and sda?
b) I see that the display has a /SS pin. Did you try to pull that low (connect to GND)?

a) yes I tried that several times.
b) I now have done so, but it made no difference

[jimmo]

Documentation for that display is a bit hard to follow, but it's not clear to me that setting the I2C jumper will also add the requisite pullups to the SDA/SCL lines. And your ESP32 board certainly won't be doing that.

Can you try adding some 10k pull-up resistors on SDA/SCL.

[jimmo]

(or use SPI instead! I understand the ESP32 port has hardware SPI support, and you'll potentially be able to run at higher speeds compared to I2C --> higher framerate!)

[iconoclastica]

I replaced the display with a pn-535 mini rfid reader. That one too doesn't show up in the scan().

I will try the pullups next.

-----------------------------

A sign of life! Hope looms...

First I tried the pull-ups on the rfid sensor. That didn't work. Then I put the display back in place. Using the start-up code for the rfid-reader I reinitialized i2c and then it showed me the address of the display ([39]).

Then I copied the start-up code to the display's driver unit and it failed again. While I copied both nearly identical pieces of code into this message, I run the rfid-code again and it worked, again. But after that I ran it again and it failed. And again and it worked, etc in an alternating sequence.

In this fashion, I got the digole-unit to work by importing it at the right moment.

The first call to the display returned an error, but after that it obeyed smoothly every command I sent it:

Code: Select all

exec(open('./digole.py').read(),globals())
[39]
>>> i2c.writeto(display, b'CL')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: [Errno 19] ENODEV
>>> i2c.writeto(display, b'CL')
2
>>> i2c.writeto(display, b'TTHALLO?!/x00')
13

It turns out the pull-up resistors are essential. When I disconnect them the time-out error returns to disappear as soon as I reconnect them. Don't know yet why the rfid reader didn't respond, but there may be many reasons for that.

-- Wim

[jimmo]

It would probably be helpful to post the code to your drivers. Is it possible that they're using any of the primitive i2c methods https://docs.micropython.org/en/latest/ ... operations (e.g. i2c.start, stop, readinto, write) and leaving the bus in a weird state?

Are the pull-ups soldered in place, or at least attached as securely as possible? (e.g. breadboard).

What's the intention behind this line?

Code: Select all

exec(open('./digole.py').read(),globals())

(My guess would be forcing a re-import? Just soft-reset with Ctrl-D instead)

[iconoclastica]

AFAIK there are no python-drivers yet for the digole display. The unit I am using I am writing myself - therefore I am definitive to say that the only i2c method it calls is writeto(). At some point I will need to read out a return value. This first test, once I got connection, was promising, but the unit is not yet ready to publish.

The resitors stay firmly put, but for the rest in the i2c subsystem, well, let's say I urgently need some proper connectors...I will also by a new rfid reader, for I had great trouble today to unsolder and reconnect those finicky little jumper pads. The noble science of ergonomics seems to pass unnoticed to electronic board designers.


The quoted exec statement is not mine. I suppose it is uPyCraft that's calling it, after the unit has been edited and transmitted to the microcontroller.