I\'m trying to read/write to a FM24CL64-GTR FRAM
chip that is connected over a I2C bus on address 0b 1010 011
.
When I\'m trying to write 3
Note that the method using the struct i2c_rdwr_ioctl_data
and the struct i2c_msg
(that is, the last code part you've given) is more efficient than the other ones, since with that method you execute the repeated start feature of I2c.
This means you avoid a STA-WRITE-STO -> STA-READ-<data>...-STO
transition, because your communication will become STA-WRITE-RS-READ-<data>...STO
(RS
= repeated start). So, saves you a redundant STO-STA
transient.
Not that it differs a lot in time, but if it's not needed, why losing on it...
Just my 2 ct.
Best rgds,
I do not have experience with that particular device, but in our experience many I2C devices have "quirks" that require a work-around, typically above the driver level.
We use linux (CELinux) and an I2C device driver with Linux as well. But our application code also has a non-trivial I2C module that contains all the work-around intelligence for dealing with all the various devices we have experience with.
Also, when dealing with I2C issues, I often find that I need to re-acquaint myself with the source spec:
http://www.nxp.com/acrobat_download/literature/9398/39340011.pdf
as well as the usage of a decent oscilloscope.
Good luck,
Above link is dead, here are some other links:
http://www.nxp.com/documents/user_manual/UM10204.pdf and of course wikipedia: http://en.wikipedia.org/wiki/I%C2%B2C
The NAK was a big hint: the WriteProtect pin was externally pulled up, and had to be driven to ground, after that a single write of the address followed by data-bytes is successful (first code segment).
For reading the address can be written out first (using write()), and then sequential data can be read starting from that address.
You had some mistakes!
The address of ic
is Ax
in hex, x
can be anything but the 4 upper bits should be A=1010
!!!