Dennis,

> 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?"

Yes, and no.   That kind of behaviour is pretty-much a requirement for
accessing hardware in a multi-tasking environment.  Don't do it and the
first time two programs want to use the same hardware you get (either soft
or hardware) sparks flying all around.   So I /expect/ it to be there - but
do not know for certain.

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

Yes, I have.  Exactly two seconds ago.  :-)   And thanks for that.  I've
(ofcourse) first tried to google something myself, but couldn't think of the
right keyword combination (got stuck on "multiple programs").

:-)  The first link you posted already answers my question (yes, its handled
internally), and the second shows that others had the same one (I'm
definitily not the odd-one-out here).

And all of them are of use to me, including the "much study" one (not
exactly now, but most likely a bit further down the road).

> 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.

Ehrmm...  That is not what the links you posted seem to tell me ...

The third link you posted (I2C concurrent access on Linux, mutex) is rather
specific about it, mentioning that the kernel functions do such locking
themselves.   Or is that not enough ?

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

Which is probably 95%+ of what I'm after.

But yes, you're right.  For example, I have a standard 2-line LCD display
with I2C "packpack", for which a previous send I2C output is directly
related to the next I2C input.   A second program butting into that sequence
would be disastrous.

Lightbulb moment: The I2C protocol seems to allow to start a new command
without ending the old one (probably made for exactly the above problem).
The question is if the Pi's SMBus supports its (and thats not a
suggestion/request to look at it for me!)

> and therefrom to [snip adafruit link] which claims to handle device
> locking

Adafruit isn't Pi specific - it caters to a range of different devices,
AFAIK including ones without an OS.  I can imagine that it has to implement
locks itself for such situations.  In other words, not reference material I
would want to depend on for the Pi.

> 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.

Again thanks for those links.  I hope you do realise that you are spoiling
me this way ?    Just a few more weeks and I will just post every question I
have here, without trying to google it myself first ... :-D

Regards,
Rudy Wieser

--- SoupGate-Win32 v1.05