On Mon, 25 Dec 2017 09:26:08 -0000
Paul  wrote:

>In article , address@not.available says...
>>
>> Andrew,
>>
>> > You might try writev(2)
>>
>> Thank you.  Its a good starting point to do some googeling and testing.
>>
>> > A target port is something related to your I2C device and not I2C itself,
>>
>> Just regard it as a second address byte - which is actually a thing -
>> indicating one outof 65536 devices.  Hmmm ... Is there a possibility to set
>> a two-byte device adddress ?
>
>NO I2C has special modes for extended addressing of the actual devices,
>(not the internal addresses used in devices such as EEPROM, RAM...)
>
>> > and you didn't say what that was, so no one is going to be able to answer.
>>
>> My question was aimed at I2C (or rather, the API talking to it), not a(ny)
>> specific slave device using it.  That I mentioned the target port was just
>> ment as an example, something to relate to.
>
>Actuallyy with all I2C devices your question IS related to the device
>AND the capabilities of the driver. When dealing with devices having
>many internal registers and/or internal memory locations how the data
>part of an I2C transaction is split by the device into
>
> Address and data
>or  command and data
>
>IS SPECIFIC to that device, over many devices I have seen many methods
>
>a) 12 bit address - 4 bits included in device address followed by a
> byte. So your device may exist at I2C addresses 16, 17, 18, and
> 19.
>
>b) Internal adresss after I2c device address (one to four bytes of
> address in correct order)
>
>c) Device internal command byte then an address byte(s)
>f) Multifunction Device, address byte, internal command byte then a
> further internal address byte(s)
>
>Then there is the issue of how data is transferred (most common method
>first)
>
>Writes
>a) Data immediately after address byte(s)
>b) Data is next I2C transaction to that device address
>
>Reads
>a) Internal Address byte(s), then I2C driver and hardware has to send
> a RESTART sequence then I2C transaction to read the data.
>
>b) Data is next I2C transaction to that device address
>
>So you have to know if driver and hardware can generate that RESTART
>sequence (some cannot). Can the API accept a simple command or data
>structure to do so.
>
>Then you have the issues of some higher speed devices usually (400 kHz
>and above), that have series resistors on their I2C lines in the
>hardware of the device (most common place seen as problem is some LCDs
>that are Chip On Glass - COG), which can have problems of driving SDA
>low enough to be recognbised as a '0', which is mainly a problem in the
>ACK phase of a I2C byte transfer (data or address. So can you tell the
>driver for this device assume the device is there and IGNORE ACK phase.
>
>> In my case the device I'm working with does not use a "target port",
>just a
>> single bit in the first "databyte" to indicate a read or write action -
>> which is rather indistinguishable from a "target port" though. :-
>
>The single bit for Read/write is part of the I2C basic spec NOT how the
>device works but how I2C works, which the device has to follow. The
>driver when sent a correct device address and form of write or read
>command will handle the state of the read/write bit. Especially
>after a RESTART sequence.
>
>> Though if you need to think of one you can pick any which accepts a
>(ny)
>> number of databytes preceeded by a single target port byte.  Any I2C EPROM,
>> I2C to RS232 or SPI convertor, I2C display, bluetooth, etc. will do.
>>
>> Regards,
>> Rudy Wieser
>
>There are many aspects of communicating with I2C devices and poor
>implementation or a manufacturers 'version' of the I2C spec to handle as
>well as the driver/API.
>
>Most I2C ioctl transactions I have seen configure a structure for the
>transaction including pointers to buffers for write and read data, it
>woulkd take me time to dig out any details
>
>I would suggest you need to look at how to talk to the i2c driver using
>structures and settings for
>
> write
> write and read with restart
> ignore ACK if required
>
>From memory of  a few years ago the linux i2c driver supports these
>

Exellent explanation of the problem, and the reason a few years ago I gave up
attempting to use I2C displays with Arduinos, and concentrated on
alpha-numeric ones with 4/8 line parallel or 'standard' serial comms.

--
W J G

--- SoupGate-Win32 v1.05