For the I2C-1 "file", is it possible to set/send the port address seperatily ?

Hello All,
When I open /dev/i2c-1 and want to send some data to a certain port on the
target device I currently always need to first combine the two into a single
buffer, and than call 'write' providing it that buffer. Which feels a bit
wastefull to me.
My question therefore is:
1) Is there a way, for the above I2C "file", to do a multi-part write which
gets accepted as a single one ?
- and/or -
2) Is there a way to set the target port in another way - maybe in the same
way the device address is currently set (using ioctl) ?
My googeling did not turn up anything like it, which I why I'm asking here.
Regards,
Rudy Wieser
Reply to
R.Wieser
Loading thread data ...
To do that it would have to write into a buffer, then send it ...
Reply to
Rob Morley
You might try writev(2) - this is not an I2C function, but a standard unix function to do a single write from multiple buffers which are gathered into a single syscall, and passed as an array of pointers and lengths. I haven't actually tried it with Linux I2C driver though.
A target port is something related to your I2C device and not I2C itself, and you didn't say what that was, so no one is going to be able to answer.
--
Andrew Gabriel 
[email address is not usable -- followup in the newsgroup]
Reply to
Andrew Gabriel
Rob,
The question is, why do you have to ? I mean, I can write a line to the console in multiple parts by simply not sending an EOL. No kind of buffer involved ...
Regards, Rudy Wieser
Reply to
R.Wieser
For many i2C devices you write a register address, followed by the value to be written to that register, and possibly data to be written to successive registers, these need to be atomic.
What happens if process A writes "hello" to the console one character at a time, while process B writes "goodbye" to the console, also one character at a time?
What if process A writes "1" followed by "2" to the I2C port and process B writes "3" followed by "4" to the I2C port?
Do you get 2 written to register 1, and 4 written to register 3? or 3 written to register 1 and 4 written to register 2? or 1 written to register 3 and 2 written to register 4? or ...
Your I2C controlled hardware is going to behave unexpectedly
Reply to
Andy Burns
Andrew,
Thank you. Its a good starting point to do some googeling and testing.
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 ?
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.
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. :-)
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
Reply to
R.Wieser
Andy,
I'm aware of that. However, the need for it to be atomic has no bearing on the speed of the transmission, or including the possibility of (long) pauses between clockpulses (between, or even inside a byte) (regardless of whom or what is introducing them).
Thats the problem with providing examples. Some people tend to focus on it, and forget to check if the response/counter example they give is actually applicable to the problem it tried to clarify. :-(
I the case of a console you would (often) just get a spagetti of letters/words.
However, when such a mash is not considered to be anything of a good idea - like with I2C and a slew of other devices - process B gets simply told to wait (gets forced into a wait state) until process A indicates its finished.
... which is what currently already happens when process A is busy with a length write and proces B also wants to say something.
Regards, Rudy Wieser
Reply to
R.Wieser
Andrew,
I just did so (with the help of an online man page). Alas, although the result is different from doing two seperate "write"s, its not the same to what its expected to do (and my origional code does).
Which is surprising, as the command seems to do pretty-much the same as my origional code (using a temporary buffer, although that one is most likely dynamic, not fixed).
It seems to work for screen output though.
Regards, Rudy Wieser
Reply to
R.Wieser
here is a silly idea why don't you identify the "Target device" so that someone can provide you with an example of how to access that specific item you will find you resolve your problem much faster if you provide all information.
--
Four fifths of the perjury in the world is expended on tombstones, women 
and competitors. 
 Click to see the full signature
Reply to
alister
Alister,
"Those who do not learn from the past are doomed to make the same mistakes in the present and future"
I've tried what you suggested there. Over the years quite a number of times. And than mostly the replies focus on the example instead of on the problem, meaning that in the end I've (again-and-again) been told not to want to do anything of the kind with that device, and not getting any answer even near to touching my actual question.
Also, the fact that you think you need to know the device means you are probably oblivious to where my/the problem is located (hint, its not anywhere near the device).
Experience tells me otherwise.
But, I'm accepting your challenge (for no othe reason than to enable you to see the erring of your assumption):
My device is an SSD1306 128 x 64 bit I2C OLED display. I need be able to write a few bytes (representing a bit pattern of a single 6x8 character/symbol), but also a "refresh" a single-or-few 128-byte "line(s)" (outof 8), or the whole display if need be. I would also like to be able to write a repeatable, multibyte pattern over part of, or the whole of the display.
Lets see if that info enables you to actually answer my question. I don't think it will. The only question to me is if you will fess up to it.
Just so you know: *any* answer which is specific to that device and cannot be used in a generic way means you automatically loose.
Yes, I'm quite the brutal asshole when challenged. So sue me. :-)
Regards, Rudy Wieser
Reply to
R.Wieser
NO I2C has special modes for extended addressing of the actual devices, (not the internal addresses used in devices such as EEPROM, RAM...)
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.
just a
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.
(ny)
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 
 Click to see the full signature
Reply to
Paul
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
Reply to
Folderol
Correct I am oblivious to your problem because your question is confusing, tell me the device you want to talk to & I may be able to tell you how to talk to it
This suggest that you are not very good at asking questions
The data sheet seems prety clear. I suspect you need to use memory addressing mode
then this is an impossible challenge as any solution has to be specific to this family of devices
only when challenged?
--
Home on the Range was originally written in beef-flat.
Reply to
alister
And yet another thread turns out to be pointless trolling.
---druck
Reply to
druck
Paul,
You are being ambigue there. But AFAIK the I2C *protocol* is fully agnostic to it.
No.
Yes.
Correct. But it has got zero to do with my question.
My apologies, but no. I was asking for and expecting an answer related to the usage of sysfs. I definitily do not want to go the low-level way (and by it most likely bind the resulting code to a specific version of the Raspberry Pi).
Regards, Rudy Wieser
Reply to
R.Wieser
Alister,
Than start with asking clarification about the part(s) you find confusing. There is no shame in that (other than in the eyes of people who are assholes - and who probably do not even know what to say/ask/think themselves). Heck, its the reason this newsgroup exists.
So, what do you need clarification for ? But mind you, just as you expect a good question from me, I expect a good question from you.
Whut ? You mean to say that you did not actually *read* my message before replying to it ? Its in there, on the line starting with "My device is an".
Fuck, its even, in your reply, just about ten lines down from where you wrote the above ...
And you have just proved - beyond a shadow of a doubt - that you simply cannot read a simple message, and than are pushing *your* inability to do so upon the other (me). :-D
Also, you're unwilling to ask for clarification for stuff you do not really understand, but will not be stopped by such a "triviality".
Kiddo, *you* are the experience I talked about. :-(
Thats for you to find out. Try it. Just answer honestly (within the limits of your knowledge) and I will probably (experience talking here :-) ) thank you for whatever you have to offer.
Regards, Rudy Wieser
Reply to
R.Wieser
Andrew,
An update to the proposed "writev" method.
I just attached an oscilloscope to the I2C bus, to see what actually happens when I use it to try to send two blocks of data as a single I2C one.
Alas, the 'scope shows the two provided blocks to be going over the I2C bus seperate, starting and ending both. :-\
Oh well, it was a good attempt. :-)
Regards, Rudy Wieser
Reply to
R.Wieser
That would be a bug in the driver, but I'm not surprised.
--
Andrew Gabriel 
[email address is not usable -- followup in the newsgroup]
Reply to
Andrew Gabriel
Andrew,
Possibly. I think I wil try to find its sourcecode, and see what I can glean from it. Than again, its possible that its defined that way (for some reason I currently can't think of).
How so ? (I would not mind getting some background info)
Regards, Rudy Wieser
Reply to
R.Wieser
Andrew,
I found *some* sourcecode (not quite sure if it is (still) applicable),
formatting link

and found it doesn't implement the "writev" method. Which, AFAICT, means that some layer above it does a "best effort", and does a few "write"s in a loop. Hence the result I got.
Too bad, it means that I will need to keep using that "gather in a buffer first" method. :-(
Regards, Rudy Wieser
Reply to
R.Wieser

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.