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
--
Paul Carpenter | paul@pcserviceselectronics.co.uk
PC Services
Logic Gate Education
Timing Diagram Font
For those web sites you hate
--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | FidoUsenet Gateway (3:770/3)
|