> BTW I'm curious if you actually needed the + and - suffixes in practice?
> I can easily imagine how the = suffix will be useful in the real
> world, but + and -... Or maybe just for bus driver testing purpose?
Exactly for that. While you can send complex messages with my tool, it
should be cle
Hi Jean,
> If you think it's not enough, then the address modifier could go
> separately before or after the address byte, i.e. either r1@0x123t or
> r1@t0x123. I suspect that the latter should be easier to implement.
In deed, I would aim for maximum flexibility (i.e. possible to mix 7 and
10 bit
Hi Wolfram,
On Fri, 8 May 2015 16:38:26 +0200, Wolfram Sang wrote:
> > Having slept over it, I came up with a 3rd proposal:
> >
> > # i2ctransfer 0 w0x11@0x50 0xc0 0xbd= r1@0x51
> >
> > That is, combining the slave address, direction and length into a
> > single parameter. The advantage is that
Hi Randy,
On Fri, 8 May 2015 15:28:19 +, Randy Grunwell wrote:
> I'm curious why this would not be an extension of the i2c read and write
> commands? Would it not make sense to add a tier above "Block" (perhaps
> "Extended"), and use the same syntax?
>
> Forgive me if this is out of place -
Hello Randy,
On Fri, May 08, 2015 at 03:28:19PM +, Randy Grunwell wrote:
> I'm curious why this would not be an extension of the i2c read and write
> commands? Would it not make sense to add a tier above "Block" (perhaps
> "Extended"), and use the same syntax?
>
> Forgive me if this is out
I'm curious why this would not be an extension of the i2c read and write
commands? Would it not make sense to add a tier above "Block" (perhaps
"Extended"), and use the same syntax?
Forgive me if this is out of place - I'm quite new, both here and to Linux/C.
On Thu, 7 May 2015 22:08:12 +0200,
> Having slept over it, I came up with a 3rd proposal:
>
> # i2ctransfer 0 w0x11@0x50 0xc0 0xbd= r1@0x51
>
> That is, combining the slave address, direction and length into a
> single parameter. The advantage is that this is all more explicit and
> the risk of mixing up values is close to zero.
On Thu, 7 May 2015 22:08:12 +0200, Jean Delvare wrote:
> Hi Wolfram,
>
> On Fri, 27 Feb 2015 17:16:56 +0100, Wolfram Sang wrote:
> > This tool allows to construct and concat multiple I2C messages into one
> > single transfer. Its aim is to test I2C master controllers, and so there
> > is no SMBus
Hi Wolfram,
On Fri, 27 Feb 2015 17:16:56 +0100, Wolfram Sang wrote:
> This tool allows to construct and concat multiple I2C messages into one
> single transfer. Its aim is to test I2C master controllers, and so there
> is no SMBus fallback.
>
> Signed-off-by: Wolfram Sang
> ---
>
> I've been mi
On Tue, Apr 21, 2015 at 07:25:51AM +0200, Jean Delvare wrote:
> Hi Wolfram,
>
> On Mon, 20 Apr 2015 19:36:38 +0200, Wolfram Sang wrote:
> > On Fri, Feb 27, 2015 at 05:16:56PM +0100, Wolfram Sang wrote:
> > > This tool allows to construct and concat multiple I2C messages into one
> > > single trans
Hi Wolfram,
On Mon, 20 Apr 2015 19:36:38 +0200, Wolfram Sang wrote:
> On Fri, Feb 27, 2015 at 05:16:56PM +0100, Wolfram Sang wrote:
> > This tool allows to construct and concat multiple I2C messages into one
> > single transfer. Its aim is to test I2C master controllers, and so there
> > is no SMB
On Fri, Feb 27, 2015 at 05:16:56PM +0100, Wolfram Sang wrote:
> This tool allows to construct and concat multiple I2C messages into one
> single transfer. Its aim is to test I2C master controllers, and so there
> is no SMBus fallback.
>
> Signed-off-by: Wolfram Sang
> ---
>
> I've been missing s
This tool allows to construct and concat multiple I2C messages into one
single transfer. Its aim is to test I2C master controllers, and so there
is no SMBus fallback.
Signed-off-by: Wolfram Sang
---
I've been missing such a tool a number of times now, so I finally got around to
writing it myself
13 matches
Mail list logo
