patch: make i2c(8) usable for scripting

[Poul-Henning Kamp]

Here is a patch to make i2c(8) much more usable from scripts and scripting languages:

http://phk.freebsd.dk/misc/i2c.patch

That patch applies only to -current, I had to give i2c.c a good wash first.

If you are not -current, it will be easier to fetch:

http://phk.freebsd.dk/misc/i2c.c

http://phk.freebsd.dk/misc/i2c.8

The patch adds two new modes "-i" and "-iv"

"-i" mode is intended to use from hardware-initialization scripts etc, and treats any error as fatal.

"-iv" on the other hand treats no error as fatal, and is targeted more at python classes, continous
data collection etc.

In both cases i2c(8) takes (argv/stdin) commands like:

r 0 0x50 16BE 24 8

or

w 0 0x50 16BE 24 48656c6c 6f20576f 726c6421 0a

(see manpage for details)

These modes always use the I2CRDWR ioctl, which works on all the hardware I have.

The /dev/iic%d filedescriptor is opened and closed for every single
command, in the hope that it will aid multiple separate programs
sharing I2C busses. I have not actually tried that yet, so it may
need more work (exclusive opens etc.).

Comments & inputs welcome...

Poul-Henning

[Ian Lepore]

Post by Poul-Henning Kamp
The /dev/iic%d filedescriptor is opened and closed for every single
command, in the hope that it will aid multiple separate programs
sharing I2C busses. I have not actually tried that yet, so it may
need more work (exclusive opens etc.).

There should be no need to do that. The i2c bus is arbitrated in
iicbus/iiconf.c and most all the in-tree drivers now use either
explicit iicbus_request_bus() calls, or use iicbus_transfer_excl().
Certainly users of iic(4) don't need to be protected from each other;
everything in the driver that uses the bus does so inside of
request_bus / release_bus calls.

-- Ian

[Poul-Henning Kamp]

--------

Post by Ian Lepore

Post by Poul-Henning Kamp
The /dev/iic%d filedescriptor is opened and closed for every single
command, in the hope that it will aid multiple separate programs
sharing I2C busses. I have not actually tried that yet, so it may
need more work (exclusive opens etc.).

There should be no need to do that. The i2c bus is arbitrated in
iicbus/iiconf.c and most all the in-tree drivers now use either
explicit iicbus_request_bus() calls, or use iicbus_transfer_excl().
Certainly users of iic(4) don't need to be protected from each other;
everything in the driver that uses the bus does so inside of
request_bus / release_bus calls.

How does that work when i2c(8) (by default) issues discrete start/stop commands ?

Related to that: Should i2c(8)'s -m default be changed to 'tr' ?

[Ian Lepore]

Post by Poul-Henning Kamp
--------

Post by Ian Lepore

Post by Poul-Henning Kamp
The /dev/iic%d filedescriptor is opened and closed for every single
command, in the hope that it will aid multiple separate programs
sharing I2C busses. I have not actually tried that yet, so it may
need more work (exclusive opens etc.).

There should be no need to do that. The i2c bus is arbitrated in
iicbus/iiconf.c and most all the in-tree drivers now use either
explicit iicbus_request_bus() calls, or use
iicbus_transfer_excl().
Certainly users of iic(4) don't need to be protected from each other;
everything in the driver that uses the bus does so inside of
request_bus / release_bus calls.

How does that work when i2c(8) (by default) issues discrete
start/stop commands ?
Related to that: Should i2c(8)'s -m default be changed to 'tr' ?

Start locks the bus and stop releases it. Yeah, that's a marginal
design, it lets userland keep everybody including kernel drivers off
the bus indefinitely. i2c(8) is very much a "you have all the power,
use it wisely" type of tool.

-- Ian

[Ian Lepore]

Post by Poul-Henning Kamp
--------

Post by Ian Lepore

Post by Poul-Henning Kamp
The /dev/iic%d filedescriptor is opened and closed for every single
command, in the hope that it will aid multiple separate programs
sharing I2C busses. I have not actually tried that yet, so it may
need more work (exclusive opens etc.).

There should be no need to do that. The i2c bus is arbitrated in
iicbus/iiconf.c and most all the in-tree drivers now use either
explicit iicbus_request_bus() calls, or use
iicbus_transfer_excl().
Certainly users of iic(4) don't need to be protected from each other;
everything in the driver that uses the bus does so inside of
request_bus / release_bus calls.

How does that work when i2c(8) (by default) issues discrete
start/stop commands ?
Related to that: Should i2c(8)'s -m default be changed to 'tr' ?

I just realized I didn't reply to the second question...

Yes, I think -m tr should be the default. It should work on all
hardware. The only real reason I can think of to support discrete
start and stop commands in i2c(8) is for testing drivers.

-- Ian

[Mark Murray]

Post by Poul-Henning Kamp
These modes always use the I2CRDWR ioctl, which works on all the hardware I have.

Please could you list what you have, for the record?

Thanks!

M
--
Mark R V Murray

[Poul-Henning Kamp]

--------

Post by Poul-Henning Kamp

Post by Poul-Henning Kamp
These modes always use the I2CRDWR ioctl, which works on all the

hardware I have.
Please could you list what you have, for the record?

Rpi4 & BBB

[Mark Murray]

Post by Poul-Henning Kamp
--------

Post by Poul-Henning Kamp

Post by Poul-Henning Kamp
These modes always use the I2CRDWR ioctl, which works on all the

hardware I have.
Please could you list what you have, for the record?

Rpi4 & BBB

Thank you! I had to jump through hoops to get I2C to work at all on RPi4 8GB. What was your method for getting this right?

At some point, when I have enough circular to-its, I want to attend to the differences between BCM2835 and BCM2711, the list of which is growing.

M
--
Mark R V Murray