TIP: Click on subject to list as thread! ANSI
echo: rberrypi
to: ALL
from: DENNIS LEE BIEBER
date: 2019-11-23 15:10:00
subject: Re: One I2C bus, two prog

On Sat, 23 Nov 2019 09:55:15 +0100, "R.Wieser" 
declaimed the following:

>I've got a few I2C modules (clock, temperature sensor, etc) that I would
>like to access using different programs.
>
>Under Windows the first program accessing certain hardware "takes
>possession" of it, causing other programs to be denied access.
>
 Unless you are running the Win10 IoT release on the R-Pi, this one is
left assuming you mean that as an unfinished question "... does Linux do
that too?"

>The question is: how do I allow multiple programs to access the same I2C
>bus, but not interfering with each other ?
>
>Or am I worrying about nothing, and the OS already sequentialises the
>request for me ?

 Have you tried a search for "Linux share i2c"?

Various hits:
https://www.spinics.net/lists/linux-i2c/msg17264.html (from
https://stackoverflow.com/questions/41172797/linuxs-i2c-dev-interface-with-mult
iple-processes
)
https://stackoverflow.com/questions/16467729/i2c-concurrent-access-on-linux-mut
ex
https://raspberrypi.stackexchange.com/questions/37689/how-do-i-use-the-i2c-bus

https://www.kernel.org/doc/html/v4.14/driver-api/i2c.html requires too much
study to make sense out of...

 
 Since most documentation I've found uses the file-system access scheme
(/dev/), and Linux tends to not lock multiple opening of
files.

 Off-hand -- if you have two processes trying to access the SAME I2C
device, I suspect that YOU will have to code any locks needed to ensure a
command write and data read are isolated to single process.

 Two processes accessing different I2C devices are probably safe, and
each operation should be handled by the kernel independently...

ProcA     ProcB
write-dev1-command
      write-dev2-command
read-dev1-data
      read-dev2-data



 Crawling around Adafruit (through three layers of: module1 is
deprecated, use module2; module2 is deprecated use module3) I eventually
got to the CircuitPython/Blinka
https://circuitpython.readthedocs.io/en/latest/shared-bindings/busio/I2C.html
which explicitly states:
"""
 class busio.I2C(scl, sda, *, frequency=400000, timeout=255)

    I2C is a two-wire protocol for communicating between devices. At the
physical level it consists of 2 wires: SCL and SDA, the clock and data
lines respectively.

    See also

    Using this class directly requires careful lock management. Instead,
use I2CDevice to manage locks.
"""
and therefrom to
https://circuitpython.readthedocs.io/projects/busdevice/en/latest/api.html#adaf
ruit_bus_device.i2c_device.I2CDevice
which claims to handle device locking (and that implies one has to
open/close the device for each transaction, and may have to catch failure
to open if another process currently has it locked).

NOTE: it turns out this locking is only within the single Python (using the
Threading library). (I had to check the source code for the library to
discover the locks are internal)

 So... if you need to support external processes which may attempt to
conflict on a single device, you will apparently need to implement a
locking scheme that all those processes will follow.
https://gavv.github.io/articles/file-locks/
http://man7.org/linux/man-pages/man2/flock.2.html
http://man7.org/linux/man-pages/man2/fcntl.2.html


--
 Wulfraed                 Dennis Lee Bieber         AF6VN
 wlfraed@ix.netcom.com    http://wlfraed.microdiversity.freeddns.org/

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | FidoUsenet Gateway (3:770/3)

SOURCE: echomail via QWK@docsplace.org

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.