No try_lock() in machine.I2C() or machine.SoftI2C()

General discussions and questions abound development of code with MicroPython that is not hardware specific.
Target audience: MicroPython Users.
Post Reply
hybotics
Posts: 33
Joined: Tue Apr 03, 2018 2:58 am
Contact:

No try_lock() in machine.I2C() or machine.SoftI2C()

Post by hybotics » Mon Jul 19, 2021 8:01 pm

Hello,

I am porting Adafruit's HT16K33 library to Micropython and am making very good progress! However, there is one gotcha in the Adafruit code, which is a (theirs) board.I2C.try_lock(). It is used to tell when the i2c bus is available.

Could this be easily added to Micropython's machine.SoftI2C() ??

Will it be added in an upcoming version??

8-Dale

User avatar
jimmo
Posts: 2754
Joined: Tue Aug 08, 2017 1:57 am
Location: Sydney, Australia
Contact:

Re: No try_lock() in machine.I2C() or machine.SoftI2C()

Post by jimmo » Tue Jul 20, 2021 12:46 am

hybotics wrote:
Mon Jul 19, 2021 8:01 pm
Could this be easily added to Micropython's machine.SoftI2C() ??

Will it be added in an upcoming version??
I had a look at the implementation of the CircuitPython method. This could definitely be easily added to MicroPython's SoftI2C (and hardware I2C) too.

In general we try to avoid adding functionality to the firmware that can be implemented in Python code instead (i.e. it's just a boolean flag), but this is an interesting case where the usability benefit might make it worth it (as multiple different drivers don't want to have to coordinate what their locking mechanism is).

I'd be interested to know the history about how this feature was added to CircuitPython. Because most MicroPython code (and as I understand, all CircuitPython code) is single-threaded, I'm not sure what sort of contention this is protecting against. (i.e. how can other code be contending for the i2c instance while a piece of code is using it?). My best guess is perhaps they have drivers built into the firmware (written in C, running in the background)? Maybe it's future-proofing?

If you wanted a workaround in the meantime, you could make a class in Python that wrapped SoftI2C and added these methods.

There aren't currently any plans to add it, but if you want to put it on the radar then the best way is to raise an issue at github.com/micropython/micropython.

User avatar
jimmo
Posts: 2754
Joined: Tue Aug 08, 2017 1:57 am
Location: Sydney, Australia
Contact:

Re: No try_lock() in machine.I2C() or machine.SoftI2C()

Post by jimmo » Tue Jul 20, 2021 12:54 am

I spoke to CircuitPython devs (Scott) and he confirmed both of those guesses -- they have (internal) display drivers that use the busses, as well as possible future plans for parallel code.

Post Reply