Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
One I2C bus, two programs - how does that work ?
773 views
Skip to first unread message
R.Wieser
Nov 23, 2019, 3:55:38 AM11/23/19
to
Hello all,
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.
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 ?
Regards,
Rudy Wieser
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.
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 ?
Regards,
Rudy Wieser
Jan Panteltje
Nov 23, 2019, 5:11:33 AM11/23/19
to
On a sunny day (Sat, 23 Nov 2019 09:55:15 +0100) it happened "R.Wieser"
<add...@not.available> wrote in <qras68$ako$1...@gioia.aioe.org>:
Different tasks to the same i2c interface from user space is not possible in a multitasker.
But you can make your own i2c interfaces on _any_ pins with some diodes,
I am doing that exactly here using two i2c busses:
http://panteltje.com/panteltje/xgpspc/index.html
It is Linux so on windows you are on your own.
I never use the hardware i2c,
software is more than fast enough and that way I can port my code to any other platform.
<add...@not.available> wrote in <qras68$ako$1...@gioia.aioe.org>:
But you can make your own i2c interfaces on _any_ pins with some diodes,
I am doing that exactly here using two i2c busses:
http://panteltje.com/panteltje/xgpspc/index.html
It is Linux so on windows you are on your own.
I never use the hardware i2c,
software is more than fast enough and that way I can port my code to any other platform.
R.Wieser
Nov 23, 2019, 6:30:58 AM11/23/19
to
Jan,
> Different tasks to the same i2c interface from user space
> is not possible in a multitasker.
Ofcourse it is. The only question is: how.
Though chances are the serializer for it is already present in the OS, and
we do not need to do anything special.
> But you can make your own i2c interfaces on _any_ pins with some diodes
Did you know that, as long as you can switch a pin from in to output, you do
not even need diodes for that ?
Just write a Zero to the pin and switch it from input to output and back.
That way you mimic a open-collector pull-down pin. :-)
Regards,
Rudy Wieser
> Different tasks to the same i2c interface from user space
> is not possible in a multitasker.
Though chances are the serializer for it is already present in the OS, and
we do not need to do anything special.
> But you can make your own i2c interfaces on _any_ pins with some diodes
not even need diodes for that ?
Just write a Zero to the pin and switch it from input to output and back.
That way you mimic a open-collector pull-down pin. :-)
Regards,
Rudy Wieser
obruT
Nov 23, 2019, 8:29:51 AM11/23/19
to
On 2019-11-23, R.Wieser <add...@not.available> wrote:
> Hello all,
>
> I've got a few I2C modules (clock, temperature sensor, etc) that I would
> like to access using different programs.
Make one program which access I2C modules and serves other programs
> Hello all,
>
> I've got a few I2C modules (clock, temperature sensor, etc) that I would
> like to access using different programs.
through some protocol (sockets, message queues, REST API, whatever...).
Benefits:
- you can scale to large number of consumers
- consumers do not need to know anything about I2C
- if you add additional modules which do not use I2C but some
other protocol, they can be exposed through same interface
--
obruT
R.Wieser
Nov 23, 2019, 10:44:35 AM11/23/19
to
obruT,
> Make one program which access I2C modules and serves other programs
I take it that you mean to say you do not know of a build-in serializer for
it. Thats too bad, as it would have made everything much simpler.
> Benefits:
...
being able to google the public (for the Pi) I2C one ...
> - if you add additional modules which do not use I2C but some
> other protocol, they can be exposed through same interface
Warning, feature-creep detected. :-)
Thanks for the suggestion though.
Regards,
Rudy Wieser
> Make one program which access I2C modules and serves other programs
it. Thats too bad, as it would have made everything much simpler.
> Benefits:
...
> - consumers do not need to know anything about I2C
But instead need to know about the private interface/API instead of just
being able to google the public (for the Pi) I2C one ...
> - if you add additional modules which do not use I2C but some
> other protocol, they can be exposed through same interface
Thanks for the suggestion though.
Regards,
Rudy Wieser
Jan Panteltje
Nov 23, 2019, 11:37:16 AM11/23/19
to
On a sunny day (Sat, 23 Nov 2019 12:30:34 +0100) it happened "R.Wieser"
<add...@not.available> wrote in <qrb59f$1iot$1...@gioia.aioe.org>:
>Jan,
>
>> Different tasks to the same i2c interface from user space
>> is not possible in a multitasker.
>
>Ofcourse it is. The only question is: how.
Maybe you think you can use flags to signal 'in use' for one process,
and have the other task wait 'Semaphore' i the keyword.
But that just may easily lock, reduces speed, not my sort of solution.
>Though chances are the serializer for it is already present in the OS, and
>we do not need to do anything special.
i2c has many modes, muti-master is one of those.
Why make it difficult if you have a zillion (tm) pins available on GPIO (or anywhere else).
>> But you can make your own i2c interfaces on _any_ pins with some diodes
>
>Did you know that, as long as you can switch a pin from in to output, you do
>not even need diodes for that ?
Yes, me using diodes it is just a fail safe protection, you can switch I/O direction
but that is not safe in case of a software fault if your I/O pin is high and the i2c chip does a sda pulldown
as acknowledgment.
In experimental setups like I use (well sort of permanent, it is working perfectly for years now) it is just a protection measure.
I leave it in in case of raspi, as new raspis are more expensive than diodes.
<add...@not.available> wrote in <qrb59f$1iot$1...@gioia.aioe.org>:
>Jan,
>
>> Different tasks to the same i2c interface from user space
>> is not possible in a multitasker.
>
>Ofcourse it is. The only question is: how.
and have the other task wait 'Semaphore' i the keyword.
But that just may easily lock, reduces speed, not my sort of solution.
>Though chances are the serializer for it is already present in the OS, and
>we do not need to do anything special.
Why make it difficult if you have a zillion (tm) pins available on GPIO (or anywhere else).
>> But you can make your own i2c interfaces on _any_ pins with some diodes
>
>Did you know that, as long as you can switch a pin from in to output, you do
>not even need diodes for that ?
but that is not safe in case of a software fault if your I/O pin is high and the i2c chip does a sda pulldown
as acknowledgment.
In experimental setups like I use (well sort of permanent, it is working perfectly for years now) it is just a protection measure.
I leave it in in case of raspi, as new raspis are more expensive than diodes.
R.Wieser
Nov 23, 2019, 12:31:32 PM11/23/19
to
Jan,
> But that just may easily lock,
Do tell how that might happen, so that I can evade such a situation.
> reduces speed, not my sort of solution.
:-) You have some solution in which neither program needs to wait for the
other ? I'm intrigued.
> i2c has many modes, muti-master is one of those.
I wanted to limit the scope a bit (with the Py functioning as /the/ master),
but realized that that doesn't make any difference that I can think of.
> Yes, me using diodes it is just a fail safe protection, you can
> switch I/O direction but that is not safe in case of a software
> fault if your I/O pin is high and the i2c chip does a sda pulldown
> as acknowledgment.
Yep, a glitch and an acknowledgement at the same time might cause that.
What do you think of the chances of the first, and than the chances of both
happening together (mind you, for an I2C device to generate an ACK it first
needs to recognise its own address).
Personally I would be more afraid of me/someone connecting the device the
wrong way - putting vcc on a data/clock pin or just a 5v device with its own
passive pull-ups - and that way blow a pin.
> I leave it in in case of raspi, as new raspis are more expensive than
> diodes.
Absolutily. But I than rather spend a buck-and-a-half and put an I2C
level-converter in - even when both sides are 3v3.
Regards,
Rudy Wieser
> But that just may easily lock,
> reduces speed, not my sort of solution.
other ? I'm intrigued.
> i2c has many modes, muti-master is one of those.
but realized that that doesn't make any difference that I can think of.
> Yes, me using diodes it is just a fail safe protection, you can
> switch I/O direction but that is not safe in case of a software
> fault if your I/O pin is high and the i2c chip does a sda pulldown
> as acknowledgment.
What do you think of the chances of the first, and than the chances of both
happening together (mind you, for an I2C device to generate an ACK it first
needs to recognise its own address).
Personally I would be more afraid of me/someone connecting the device the
wrong way - putting vcc on a data/clock pin or just a 5v device with its own
passive pull-ups - and that way blow a pin.
> I leave it in in case of raspi, as new raspis are more expensive than
> diodes.
level-converter in - even when both sides are 3v3.
Regards,
Rudy Wieser
mm0fmf
Nov 23, 2019, 12:41:03 PM11/23/19
to
driver/API section.
Jan Panteltje
Nov 23, 2019, 12:41:47 PM11/23/19
to
On a sunny day (Sat, 23 Nov 2019 18:30:38 +0100) it happened "R.Wieser"
<add...@not.available> wrote in <qrbqdi$lcl$1...@gioia.aioe.org>:
If you already think you know everything why ask?
How many i2c projects did you design / write code for BTW?
<add...@not.available> wrote in <qrbqdi$lcl$1...@gioia.aioe.org>:
How many i2c projects did you design / write code for BTW?
A. Dumas
Nov 23, 2019, 1:30:06 PM11/23/19
to
It's his modus operandi.
Jan Panteltje
Nov 23, 2019, 1:48:46 PM11/23/19
to
On a sunny day (23 Nov 2019 18:30:05 GMT) it happened A. Dumas
<alex...@dumas.fr.invalid> wrote in
<5dd97aad$0$10264$e4fe...@news.xs4all.nl>:
>Jan Panteltje <pNaOnSt...@yahoo.com> wrote:
>> If you already think you know everything why ask?
>
>It's his modus operandi.
I just hope he does not design for space or airplanes or something like that
'unlikely to happen' (bus conflict), for me rules Murphy's law:
If it can happen it will.
Same for 2 programs using the same i2c hardware nd semaphore communication,
if one fails (could be user exit, crash, whatever) while it has the 'i2c in use flag' set,
then the other will also fail, wait forever, do nothing.
<alex...@dumas.fr.invalid> wrote in
<5dd97aad$0$10264$e4fe...@news.xs4all.nl>:
>Jan Panteltje <pNaOnSt...@yahoo.com> wrote:
>> If you already think you know everything why ask?
>
>It's his modus operandi.
'unlikely to happen' (bus conflict), for me rules Murphy's law:
If it can happen it will.
Same for 2 programs using the same i2c hardware nd semaphore communication,
if one fails (could be user exit, crash, whatever) while it has the 'i2c in use flag' set,
then the other will also fail, wait forever, do nothing.
R.Wieser
Nov 23, 2019, 2:43:54 PM11/23/19
to
Jan,
> If you already think you know everything why ask?
I didn't. It was /your/ suggestion to go use a software I2C solution
instead.
My question is still about *how to access* the Pi's own I2C. And that means
that the question /is not even about I2C itself/ - but rather about the OS.
> How many i2c projects did you design / write code for BTW?
Ah. Nope, not going into a pissing match. Sorry. But you now know that I
also know a thing or two about both I2C as well as electronics.
Regards,
Rudy Wieser
> If you already think you know everything why ask?
instead.
My question is still about *how to access* the Pi's own I2C. And that means
that the question /is not even about I2C itself/ - but rather about the OS.
> How many i2c projects did you design / write code for BTW?
also know a thing or two about both I2C as well as electronics.
Regards,
Rudy Wieser
R.Wieser
Nov 23, 2019, 2:50:12 PM11/23/19
to
Jan,
> I just hope he does not design for space or airplanes or something like
> that 'unlikely to happen' (bus conflict), for me rules Murphy's law:
> If it can happen it will.
Really ? Is that so ?
So, how do you protect both the Pi as well as th I2C modules you connect to
it against mishaps like I already described (miswiring, voltage
differences - and I'm sure there are more) ?
Or do you think that that is way more unlikely than a glitch ? For the
record, I don't. Especially not as both the Pi and the attached modules
are there to experimenting with. Murphy's law indeed.
> Same for 2 programs using the same i2c hardware nd semaphore
> communication, if one fails (could be user exit, crash, whatever)
> while it has the 'i2c in use flag' set, then the other will also fail,
> wait
> forever, do nothing.
Ah, the old "I'm are not going to answer the person who asked it, but use it
to impress someone who already agrees with me instead". Great going kid.
A bit obvious though.
But I wonder how different OSes deal with .... I dunno, multiple programs
trying to access the internet, and not geting in a deadlock.
I mean, if deadlocks are as easy to get into as you try to make it sound
than I should have had one even just in the last month, if not week. But
for some reason I can't seem to remember one, not even for the last year
(or ever actually) ... How is that possible ? Can you explain ?
And if you can, why isn't the same approach not usable for an I2C device ?
Regards,
Rudy Wieser
> I just hope he does not design for space or airplanes or something like
> that 'unlikely to happen' (bus conflict), for me rules Murphy's law:
> If it can happen it will.
So, how do you protect both the Pi as well as th I2C modules you connect to
it against mishaps like I already described (miswiring, voltage
differences - and I'm sure there are more) ?
Or do you think that that is way more unlikely than a glitch ? For the
record, I don't. Especially not as both the Pi and the attached modules
are there to experimenting with. Murphy's law indeed.
> Same for 2 programs using the same i2c hardware nd semaphore
> communication, if one fails (could be user exit, crash, whatever)
> while it has the 'i2c in use flag' set, then the other will also fail,
> wait
> forever, do nothing.
to impress someone who already agrees with me instead". Great going kid.
A bit obvious though.
But I wonder how different OSes deal with .... I dunno, multiple programs
trying to access the internet, and not geting in a deadlock.
I mean, if deadlocks are as easy to get into as you try to make it sound
than I should have had one even just in the last month, if not week. But
for some reason I can't seem to remember one, not even for the last year
(or ever actually) ... How is that possible ? Can you explain ?
And if you can, why isn't the same approach not usable for an I2C device ?
Regards,
Rudy Wieser
Jan Panteltje
Nov 23, 2019, 3:10:15 PM11/23/19
to
On a sunny day (Sat, 23 Nov 2019 20:43:31 +0100) it happened "R.Wieser"
<add...@not.available> wrote in <qrc25m$1p9s$1...@gioia.aioe.org>:
>Jan,
>
>> If you already think you know everything why ask?
>
>I didn't. It was /your/ suggestion to go use a software I2C solution
>instead.
Yes, and it still is.
>My question is still about *how to access* the Pi's own I2C. And that means
>that the question /is not even about I2C itself/ - but rather about the OS.
>
>> How many i2c projects did you design / write code for BTW?
>
>Ah. Nope, not going into a pissing match. Sorry. But you now know that I
>also know a thing or two about both I2C as well as electronics.
So show us what you are making / did make, open source your code, contribute.
<add...@not.available> wrote in <qrc25m$1p9s$1...@gioia.aioe.org>:
>Jan,
>
>> If you already think you know everything why ask?
>
>I didn't. It was /your/ suggestion to go use a software I2C solution
>instead.
>My question is still about *how to access* the Pi's own I2C. And that means
>that the question /is not even about I2C itself/ - but rather about the OS.
>
>> How many i2c projects did you design / write code for BTW?
>
>Ah. Nope, not going into a pissing match. Sorry. But you now know that I
>also know a thing or two about both I2C as well as electronics.
Jan Panteltje
Nov 23, 2019, 3:11:50 PM11/23/19
to
On a sunny day (Sat, 23 Nov 2019 20:49:50 +0100) it happened "R.Wieser"
<add...@not.available> wrote in <qrc2hh$1r6l$1...@gioia.aioe.org>:
Get lost!
<add...@not.available> wrote in <qrc2hh$1r6l$1...@gioia.aioe.org>:
R.Wieser
Nov 24, 2019, 4:15:32 AM11/24/19
to
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
> 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
R.Wieser
Nov 24, 2019, 4:15:32 AM11/24/19
to
Jan,
>>I didn't. It was /your/ suggestion to go use a software I2C
>> solution instead.
>
> Yes, and it still is.
And that is your whole problem. Instead of focussing on my question you
just replace it with something you know something about - without any
consideration if that is what I'm looking for.
> So show us what you are making / did make, open source your code,
> contribute.
Lol. Kiddo, the only thing you are trying to do there is to find something
of that you can criticise. Why would I set myself up for that ?
As I said, I'm not here for a pissing match. I'm here seeking an answer to
my question. Go find someone else to butt heads with.
Regards
Rudy Wieser
>>I didn't. It was /your/ suggestion to go use a software I2C
>> solution instead.
>
> Yes, and it still is.
just replace it with something you know something about - without any
consideration if that is what I'm looking for.
> So show us what you are making / did make, open source your code,
> contribute.
of that you can criticise. Why would I set myself up for that ?
As I said, I'm not here for a pissing match. I'm here seeking an answer to
my question. Go find someone else to butt heads with.
Regards
Rudy Wieser
Stephen Pelc
Nov 24, 2019, 9:20:32 AM11/24/19
to
On Sat, 23 Nov 2019 09:55:15 +0100, "R.Wieser" <add...@not.available>
wrote:
The Linux API seems to expose what you need. See:
https://www.kernel.org/doc/html/v4.14/driver-api/i2c.html
There are functions:
lock_bus
Get exclusive access to an I2C bus segment
trylock_bus
Try to get exclusive access to an I2C bus segment
unlock_bus
Release exclusive access to an I2C bus segment
That was after a few minutes Googling.
That was the easy bit. However, you don't say what cable lengths or
electrical environment you will be working with. I2C hardware is
*very* sensitive to electrical noise. Software bit-banged drivers tend
to be much more tolerant, so the idea of just using a pair of GPIO
pins has merit.
A client of ours produces train control systems. They spent a few
weeks writing a supposedly bullet-proof hardware driver for a deep
embedded CPU. On test, it failed (but recovered) more than once per
hour. On reverting to the bit-banged driver we had already supplied,
they saw no failures in more than two weeks.
Except for memory devices, most I2C chips change the bus direction
very frequently (every few bytes). If you want to use an unsupported
device, I suggest you do it from scratch, mmap() the GPIO port, and
read/wite the pins yourself. This has the downside of requiring you to
use sudo to run the program, but the upside that even the klunkiest
bit of coding should be able to toggle bits at tens of megahertz.
Stephen
--
Stephen Pelc, ste...@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, +44 (0)78 0390 3612
web: http://www.mpeforth.com - free VFX Forth downloads
wrote:
https://www.kernel.org/doc/html/v4.14/driver-api/i2c.html
There are functions:
lock_bus
Get exclusive access to an I2C bus segment
trylock_bus
Try to get exclusive access to an I2C bus segment
unlock_bus
Release exclusive access to an I2C bus segment
That was after a few minutes Googling.
That was the easy bit. However, you don't say what cable lengths or
electrical environment you will be working with. I2C hardware is
*very* sensitive to electrical noise. Software bit-banged drivers tend
to be much more tolerant, so the idea of just using a pair of GPIO
pins has merit.
A client of ours produces train control systems. They spent a few
weeks writing a supposedly bullet-proof hardware driver for a deep
embedded CPU. On test, it failed (but recovered) more than once per
hour. On reverting to the bit-banged driver we had already supplied,
they saw no failures in more than two weeks.
Except for memory devices, most I2C chips change the bus direction
very frequently (every few bytes). If you want to use an unsupported
device, I suggest you do it from scratch, mmap() the GPIO port, and
read/wite the pins yourself. This has the downside of requiring you to
use sudo to run the program, but the upside that even the klunkiest
bit of coding should be able to toggle bits at tens of megahertz.
Stephen
--
Stephen Pelc, ste...@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, +44 (0)78 0390 3612
web: http://www.mpeforth.com - free VFX Forth downloads
R.Wieser
Nov 24, 2019, 12:00:56 PM11/24/19
to
Stephen,
> The Linux API seems to expose what you need. See:
> https://www.kernel.org/doc/html/v4.14/driver-api/i2c.html
Thank you.
> That was after a few minutes Googling.
I have been googeling for quite a bit longer than that, but just have not
been able to come up with the right keywords. :-\
> That was the easy bit. However, you don't say what cable lengths
> or electrical environment you will be working with.
Thats because I regard that as a fully seperate item, having nothing to do
with the "One I2C bus, two programs" one problem. One thing(/problem) at a
time seems to work best for me.
Also, what I currently have (in experimental wiring to at least two devices)
does not seem to cause any problems (yet).
> On test, it failed (but recovered) more than once per hour. On
> reverting to the bit-banged driver we had already supplied, they
> saw no failures in more than two weeks.
Ever found out what the problem was ? A too-high transmission speed ?
> If you want to use an unsupported device
??? Unsupported ? I was not aware that there where supported devices.
I normally grab myself the devices datasheet and work my way up from there.
Much more fun than just installing someone elses drivers. :-)
> I suggest you do it from scratch, mmap() the GPIO port, and
> read/wite the pins yourself
Currently I've just been using the available drivers, but with me being me
there is a rather good chance (understatement) that I will try my hand at
that too.
Regards,
Rudy Wieser
> The Linux API seems to expose what you need. See:
> https://www.kernel.org/doc/html/v4.14/driver-api/i2c.html
> That was after a few minutes Googling.
been able to come up with the right keywords. :-\
> That was the easy bit. However, you don't say what cable lengths
> or electrical environment you will be working with.
with the "One I2C bus, two programs" one problem. One thing(/problem) at a
time seems to work best for me.
Also, what I currently have (in experimental wiring to at least two devices)
does not seem to cause any problems (yet).
> On test, it failed (but recovered) more than once per hour. On
> reverting to the bit-banged driver we had already supplied, they
> saw no failures in more than two weeks.
> If you want to use an unsupported device
I normally grab myself the devices datasheet and work my way up from there.
Much more fun than just installing someone elses drivers. :-)
> I suggest you do it from scratch, mmap() the GPIO port, and
> read/wite the pins yourself
there is a rather good chance (understatement) that I will try my hand at
that too.
Regards,
Rudy Wieser
R.Wieser
Nov 24, 2019, 1:43:35 PM11/24/19
to
Dennis,
>>Yes, and no. That kind of behaviour is pretty-much a requirement
>> for accessing hardware in a multi-tasking environment.
...
> Except for the minor facet that Linux treats /everything/ as a /file/
> -- and files don't have commonly have inherent mutex locking.
Which means its good I asked. :-)
But that raises the question about what I should think about whats in the
third link you posted (i2c-concurrent-access-on-linux-mutex), which seems to
indicate its present - and on a low level too.
> and that file is submitted to a spooler daemon
...
> This is the equivalent of a method you've already rejected
I didn't (intend to) reject the gatekeeper method itself, just the part
where the communication with it is supposed to be done by the user "through
some protocol". I would like to create/see an API, preferrably shadowing
an existing I2C one.
> As I understand, you don't have to worry about two I2C operations
> interfering with each other... BUT
[snip]
That is the problem I tried to explain in my "lightbulb moment" paragraph.
Although I referred to the I2C signals themselves (the "start" and "stop"
ones) I also assumed that those signals would coincide with the locking and
unlocking of the I2C bus (or the other way around).
In other words, I was coining up the possibility of an atomic write-read
sequence (by not ending the write sequence with a "stop" condition, but
sending another "start" instead). It would solve most, if not all of the
interference problems.
The only question is if that has already been implemented, or if I need
to/can do it myself.
Regards,
Rudy Wieser
>>Yes, and no. That kind of behaviour is pretty-much a requirement
>> for accessing hardware in a multi-tasking environment.
> Except for the minor facet that Linux treats /everything/ as a /file/
> -- and files don't have commonly have inherent mutex locking.
Which means its good I asked. :-)
But that raises the question about what I should think about whats in the
third link you posted (i2c-concurrent-access-on-linux-mutex), which seems to
indicate its present - and on a low level too.
> and that file is submitted to a spooler daemon
...
> This is the equivalent of a method you've already rejected
I didn't (intend to) reject the gatekeeper method itself, just the part
where the communication with it is supposed to be done by the user "through
some protocol". I would like to create/see an API, preferrably shadowing
an existing I2C one.
> As I understand, you don't have to worry about two I2C operations
> interfering with each other... BUT
[snip]
That is the problem I tried to explain in my "lightbulb moment" paragraph.
Although I referred to the I2C signals themselves (the "start" and "stop"
ones) I also assumed that those signals would coincide with the locking and
unlocking of the I2C bus (or the other way around).
In other words, I was coining up the possibility of an atomic write-read
sequence (by not ending the write sequence with a "stop" condition, but
sending another "start" instead). It would solve most, if not all of the
interference problems.
The only question is if that has already been implemented, or if I need
to/can do it myself.
Regards,
Rudy Wieser
Stephen Pelc
Nov 24, 2019, 1:50:00 PM11/24/19
to
On Sun, 24 Nov 2019 18:00:25 +0100, "R.Wieser" <add...@not.available>
wrote:
>> On test, it failed (but recovered) more than once per hour. On
>> reverting to the bit-banged driver we had already supplied, they
>> saw no failures in more than two weeks.
>
>Ever found out what the problem was ? A too-high transmission speed ?
I2C is an edge-triggered protocol by design. Very small but fast
glitches can upset the hardware peripherals. Designing I2C interfaces
with good noise immunity is well beyond the scope of very
cost-sensitive devices including the Raspberry Pi.
wrote:
>> On test, it failed (but recovered) more than once per hour. On
>> reverting to the bit-banged driver we had already supplied, they
>> saw no failures in more than two weeks.
>
>Ever found out what the problem was ? A too-high transmission speed ?
glitches can upset the hardware peripherals. Designing I2C interfaces
with good noise immunity is well beyond the scope of very
cost-sensitive devices including the Raspberry Pi.
Stephen Pelc
Nov 24, 2019, 2:50:58 PM11/24/19
to
On Sun, 24 Nov 2019 18:49:59 GMT, ste...@mpeforth.com (Stephen Pelc)
wrote:
>I2C is an edge-triggered protocol by design. Very small but fast
>glitches can upset the hardware peripherals. Designing I2C interfaces
>with good noise immunity is well beyond the scope of very
>cost-sensitive devices including the Raspberry Pi.
Given the nature of I2C, high-reliability and safety-critical
applications need to assume that I2C *will* fail at some stage.
Reliabilty of a comms link does not mean that the link has no
errors, only that you will be able to detect the errors.
wrote:
>I2C is an edge-triggered protocol by design. Very small but fast
>glitches can upset the hardware peripherals. Designing I2C interfaces
>with good noise immunity is well beyond the scope of very
>cost-sensitive devices including the Raspberry Pi.
applications need to assume that I2C *will* fail at some stage.
Reliabilty of a comms link does not mean that the link has no
errors, only that you will be able to detect the errors.
obruT
Nov 24, 2019, 5:27:45 PM11/24/19
to
On 2019-11-23, R.Wieser <add...@not.available> wrote:
>> - consumers do not need to know anything about I2C
>
> But instead need to know about the private interface/API instead of just
> being able to google the public (for the Pi) I2C one ...
Ok, I thought that consumers you are targeting are your own
>
> But instead need to know about the private interface/API instead of just
> being able to google the public (for the Pi) I2C one ...
applications, not some third party from unknown developers :)
Well, who knows, maybe you can invent some new standard (which
AFAIK exists for this kind of applications) :)
--
obruT
R.Wieser
Nov 30, 2019, 10:07:58 AM11/30/19
to
obruT,
> Ok, I thought that consumers you are targeting are your own
> applications, not some third party from unknown developers :)
For some reason I always try to come up with solutions that are usable for
an as broad as possible audience, even if what I make will only run on my
own machine. Call it a quirk. :-)
> Well, who knows, maybe you can invent some new standard
> (which AFAIK exists for this kind of applications) :)
It already exists* ? Any idea where I should look for it ?
*A bit of a "duh" actually - I'm rather certain I'm not the first, or even
the hundred-est one with this problem
Regards,
Rudy Wieser
> Ok, I thought that consumers you are targeting are your own
> applications, not some third party from unknown developers :)
an as broad as possible audience, even if what I make will only run on my
own machine. Call it a quirk. :-)
> Well, who knows, maybe you can invent some new standard
> (which AFAIK exists for this kind of applications) :)
*A bit of a "duh" actually - I'm rather certain I'm not the first, or even
the hundred-est one with this problem
Regards,
Rudy Wieser
R.Wieser
Nov 30, 2019, 10:08:00 AM11/30/19
to
Dennis,
My apologies for the late reply. I needed some time to rethink my position.
After I posted my reply talking about an I2C "backpack" for a simple
two-line LCD display I realized that even just monitoring the LCD's "busy"
line and subsequently feed it (more) data would require a level of
intelligence of the I2C driver that I could/should not expect from it.
In short, I realized I got a bit ahead of myself. :-|
>>The only question is if that has already been implemented, or if I need
>>to/can do it myself.
>
> https://www.kernel.org/doc/html/v4.14/driver-api/i2c.html
> """
> Note about combined messages: Some I2C controllers can only send
> one message per transfer, plus something called combined message or
> write-then-read.
...
> int i2c_transfer(struct i2c_adapter * adap, struct i2c_msg * msgs, int
> num)
[snip]
Thanks. You (again) gave me lots of stuff to look at. :-)
And as you described it an actually working-as-atomic sequence of multiple
(mixes of) read/write sequences is a bit of the luck-of-the-draw. IOW: It
/might/ work in one implementation, but doesn't need to in another. I can't
say I like that ....
> And just to be annoying:
> https://www.raspberrypi.org/forums/viewtopic.php?t=135928
Did you really /have/ to do that (being annoying) ? :-)
But yes, thats (multi-threading) also something to be looked at.
Regards,
Rudy Wieser
My apologies for the late reply. I needed some time to rethink my position.
After I posted my reply talking about an I2C "backpack" for a simple
two-line LCD display I realized that even just monitoring the LCD's "busy"
line and subsequently feed it (more) data would require a level of
intelligence of the I2C driver that I could/should not expect from it.
In short, I realized I got a bit ahead of myself. :-|
>>The only question is if that has already been implemented, or if I need
>>to/can do it myself.
>
> """
> Note about combined messages: Some I2C controllers can only send
> one message per transfer, plus something called combined message or
> write-then-read.
...
> int i2c_transfer(struct i2c_adapter * adap, struct i2c_msg * msgs, int
> num)
[snip]
Thanks. You (again) gave me lots of stuff to look at. :-)
And as you described it an actually working-as-atomic sequence of multiple
(mixes of) read/write sequences is a bit of the luck-of-the-draw. IOW: It
/might/ work in one implementation, but doesn't need to in another. I can't
say I like that ....
> And just to be annoying:
> https://www.raspberrypi.org/forums/viewtopic.php?t=135928
Did you really /have/ to do that (being annoying) ? :-)
But yes, thats (multi-threading) also something to be looked at.
Regards,
Rudy Wieser
druck
Nov 30, 2019, 11:38:26 AM11/30/19
to
On 23/11/2019 08:55, R.Wieser wrote:
> Hello all,
>
> I've got a few I2C modules (clock, temperature sensor, etc) that I would
> like to access using different programs.
>
>
> I've got a few I2C modules (clock, temperature sensor, etc) that I would
> like to access using different programs.
>
> The question is: how do I allow multiple programs to access the same I2C
> bus, but not interfering with each other ?
Normally for a device which requires reading and writng you would create
> bus, but not interfering with each other ?
a driver providing an API to clients, which would serialise access to
the device.
However if it is only reading the value of sensors, it is probably
easiest to have one program which regular reads the values, and
publishes them for other programs to use.
For example, to get a running average of the CPU temperature over a
period of 15 minutes, I wrote a python program which runs as a daemon at
start up, reading the CPU temperature every second calculating the
running average, min and max values. The values are read by running
another instance of the program which communicates with the daemon
instance via a named pipe.
---druck
R.Wieser
Nov 30, 2019, 12:56:56 PM11/30/19
to
Dennis,
> Not so easy to do when the "sections" are in completely separate
> processes
Which was/is the situation I'm thinking of (just imagine the OS accessing
the RTC, while another program is trying to set one of its alarms).
> {Wow -- those 2x16 LCDs have mutated since I last looked at them...
> I think I have one or two of the pure 8/4-bit parallel models
Thats the model I was referring to (salvaged a number of them).
The "I2C backpack" is actually just a dumb 8-bit I2C expander plus a
backlight-feeding transistor and a potmeter for the contrast. In short,
everything you normally feed to the 4-bit interface of the LCD now has to go
over I2C - hence the previously mentioned checking of the LCD's busy line.
https://artofcircuits.com/product/i2c-io-expansion-interface-board-for-16x2-20x2-character-lcd-modules-black
By the way: There seem to be two major variants: One using the lower 4 bits
of the expander for data, and the other (ofcourse) uses the higher bits.
Regards,
Rudy Wieser
> Not so easy to do when the "sections" are in completely separate
> processes
Which was/is the situation I'm thinking of (just imagine the OS accessing
the RTC, while another program is trying to set one of its alarms).
> {Wow -- those 2x16 LCDs have mutated since I last looked at them...
> I think I have one or two of the pure 8/4-bit parallel models
Thats the model I was referring to (salvaged a number of them).
The "I2C backpack" is actually just a dumb 8-bit I2C expander plus a
backlight-feeding transistor and a potmeter for the contrast. In short,
everything you normally feed to the 4-bit interface of the LCD now has to go
over I2C - hence the previously mentioned checking of the LCD's busy line.
https://artofcircuits.com/product/i2c-io-expansion-interface-board-for-16x2-20x2-character-lcd-modules-black
By the way: There seem to be two major variants: One using the lower 4 bits
of the expander for data, and the other (ofcourse) uses the higher bits.
Regards,
Rudy Wieser
R.Wieser
Nov 30, 2019, 1:20:54 PM11/30/19
to
druck,
> Normally for a device which requires reading and writng you would create a
> driver providing an API to clients, which would serialise access
> to the device.
That would be the second-optimal solution (the first one being that its done
by the OS itself).
Alas, thats not always possible. Take for example an RTC. When its
installed the OS might access it whenever it pleases, and at the same time
another program might be trying to set one of its alarms. I don't think
I've got much control over when/how the OS does its thing, nor can I easily
put a gatekeeper inbetween the OS and the RTC ...
Next to that, such a driver providing an API to clients needs the
cooperation of the involved programs. Including those written by other
hobbyists like myself. Do you see the problem ?
Regards,
Rudy Wieser
> Normally for a device which requires reading and writng you would create a
> driver providing an API to clients, which would serialise access
> to the device.
by the OS itself).
Alas, thats not always possible. Take for example an RTC. When its
installed the OS might access it whenever it pleases, and at the same time
another program might be trying to set one of its alarms. I don't think
I've got much control over when/how the OS does its thing, nor can I easily
put a gatekeeper inbetween the OS and the RTC ...
Next to that, such a driver providing an API to clients needs the
cooperation of the involved programs. Including those written by other
hobbyists like myself. Do you see the problem ?
Regards,
Rudy Wieser
The Natural Philosopher
Nov 30, 2019, 2:34:20 PM11/30/19
to
to a contrilling web browser, but I didn't use a pipe. I created a
ramdiosk of a few K and mounted that and wrote a file in it. Daemon
writes: browser reads.
Very simple.
Cant ever fill up. It just gets overwritten by 'current state' every so
often...
> ---druck
--
Of what good are dead warriors? … Warriors are those who desire battle
more than peace. Those who seek battle despite peace. Those who thump
their spears on the ground and talk of honor. Those who leap high the
battle dance and dream of glory … The good of dead warriors, Mother, is
that they are dead.
Sheri S Tepper: The Awakeners.
R.Wieser
Nov 30, 2019, 2:56:59 PM11/30/19
to
Dennis,
> Odd -- I thought 4-bit mode on those displays always used the same
> four bits
They do, they do.
Its about which outputs of the I2C expander are connected to it. With
some you need to send the LCD 4-bit data in the upper nibble and the LCD
control signals in the lower to the expander, and others the other way
around.
> though the adapter is cheap (once I found a price in $... if you need
> a lot of them
I'm an hobbyist myself (don't need quantities) and got a single I2C backpack
for 2 Euros. Not a bad price.
Regards,
Rudy Wieser
> Odd -- I thought 4-bit mode on those displays always used the same
> four bits
They do, they do.
Its about which outputs of the I2C expander are connected to it. With
some you need to send the LCD 4-bit data in the upper nibble and the LCD
control signals in the lower to the expander, and others the other way
around.
> though the adapter is cheap (once I found a price in $... if you need
> a lot of them
I'm an hobbyist myself (don't need quantities) and got a single I2C backpack
for 2 Euros. Not a bad price.
Regards,
Rudy Wieser
druck
Nov 30, 2019, 4:12:02 PM11/30/19
to
On 30/11/2019 19:34, The Natural Philosopher wrote:
> On 30/11/2019 16:38, druck wrote:
>> For example, to get a running average of the CPU temperature over a
>> period of 15 minutes, I wrote a python program which runs as a daemon
>> at start up, reading the CPU temperature every second calculating the
>> running average, min and max values. The values are read by running
>> another instance of the program which communicates with the daemon
>> instance via a named pipe.
>>
>
> I actually did something simuilar to get data from a sound deamon back
> to a contrilling web browser, but I didn't use a pipe. I created a
> ramdiosk of a few K and mounted that and wrote a file in it. Daemon
> writes: browser reads.
>
> Very simple.
>
> Cant ever fill up. It just gets overwritten by 'current state' every so
> often...
The only problem being if someone tries reading while it being
> On 30/11/2019 16:38, druck wrote:
>> For example, to get a running average of the CPU temperature over a
>> period of 15 minutes, I wrote a python program which runs as a daemon
>> at start up, reading the CPU temperature every second calculating the
>> running average, min and max values. The values are read by running
>> another instance of the program which communicates with the daemon
>> instance via a named pipe.
>>
>
> I actually did something simuilar to get data from a sound deamon back
> to a contrilling web browser, but I didn't use a pipe. I created a
> ramdiosk of a few K and mounted that and wrote a file in it. Daemon
> writes: browser reads.
>
> Very simple.
>
> Cant ever fill up. It just gets overwritten by 'current state' every so
> often...
re-written. Did you use advisory locking, or a write and replace strategy?
---druck
Jim Jackson
Nov 30, 2019, 5:40:13 PM11/30/19
to
In comp.sys.raspberry-pi, you wrote:
>> {Wow -- those 2x16 LCDs have mutated since I last looked at them...
>> I think I have one or two of the pure 8/4-bit parallel models
>
> Thats the model I was referring to (salvaged a number of them).
>
> The "I2C backpack" is actually just a dumb 8-bit I2C expander plus a
> backlight-feeding transistor and a potmeter for the contrast. In short,
> everything you normally feed to the 4-bit interface of the LCD now has
to go
> over I2C - hence the previously mentioned checking of the LCD's busy
line.
I've made my own backpack for a 4x20 LCD using an MCP23017. Works fine. I
>> {Wow -- those 2x16 LCDs have mutated since I last looked at them...
>> I think I have one or two of the pure 8/4-bit parallel models
>
> Thats the model I was referring to (salvaged a number of them).
>
> The "I2C backpack" is actually just a dumb 8-bit I2C expander plus a
> backlight-feeding transistor and a potmeter for the contrast. In short,
> everything you normally feed to the 4-bit interface of the LCD now has
to go
> over I2C - hence the previously mentioned checking of the LCD's busy
line.
didn't bother with monitoring the busy flag. There are various timing
tables for HD44780 operations in the data sheet which can be used. Makes
it a lot simpler, and you would generate a hell of a lot of I2C traffic.
I've also programmed HD44780 character LCDs direct as well, without using
the busy flag - it is a very common prectice. I belive all the HD44780
look-a-likes maintain the timings.
Jim
The Natural Philosopher
Nov 30, 2019, 6:48:08 PM11/30/19
to
Disk writes are atomic operations as are disk reads below the sector level.
Did you use advisory locking, or a write and replace strategy?
>
> ---druck
>
There is something fascinating about science. One gets such wholesale
returns of conjecture out of such a trifling investment of fact.
Mark Twain
R.Wieser
Dec 2, 2019, 3:53:45 AM12/2/19
to
Jim,
> There are various timing tables for HD44780 operations in the
> data sheet which can be used. Makes it a lot simpler
I'm aware of the "just wait for a bit" solution (no pun intended :-) ). But
both the need to have to specify the timings for all kinds of different
actions (complicates the matter) as well as the doubt if it wil work for any
random connected display made me choose polling the busy line over it.
Dependability over simplenes I'm afraid.
> and you would generate a hell of a lot of I2C traffic.
:-) Thats why I normally stick a small delay into the loop. Long enough
to give other calls a chance, and short enough to keep the overall delay
small.
Regards,
Rudy Wieser
> There are various timing tables for HD44780 operations in the
> data sheet which can be used. Makes it a lot simpler
both the need to have to specify the timings for all kinds of different
actions (complicates the matter) as well as the doubt if it wil work for any
random connected display made me choose polling the busy line over it.
Dependability over simplenes I'm afraid.
> and you would generate a hell of a lot of I2C traffic.
to give other calls a chance, and short enough to keep the overall delay
small.
Regards,
Rudy Wieser
0 new messages