Linux 内核中的 I2C 写入确认轮询
这里平淡的反应让我想知道这个< /a>.
我已经配备了一个设备 （Analog Devices 525x）（来自数据表，第 16 页）：
在内部 [EEPROM] 写入周期期间禁用 I2C 接口。
这似乎不公平，就像“我现在要离开沙发，所以暂时不要使用它，因为我的座垫被一个撕裂了”。 老实说，为什么这会是我的问题呢？
无论如何，数据表表明确认轮询就是答案 - 进入 Linux 内核...Linux GPIO 位攻击的 I2C 驱动程序是否提供了执行此操作的机制？本质上是发送带有写入位的地址设置并继续这样做，直到出现 ACK。
我在 ARM 上使用 2.6.14，带有向后移植的 GPIO 位 bashing 驱动程序（我认为是从 2.6.19 开始）。
The lackluster response here made me wonder this.
I've been saddled with a device (Analog Devices 525x) that (from the data sheet, pg 16):
disables the I2C interface during the internal [EEPROM] write cycle.
That doesn't seem fair, as in "I'm getting off the couch now, so don't use it for a while because I let one rip in the seat cushion". Honestly, why should that be my problem?
Anyway, the data sheet suggests that acknowledge polling is the answer - enter the Linux kernel... does the Linux GPIO bit bashed I2C driver provide a mechanism for doing this? Essentially send a address with the write bit set and keep doing so until an ACK appears.
I'm using 2.6.14 on an ARM with back ported GPIO bit bashing driver (from 2.6.19 I think).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
它看起来不太现成，但
您可能需要查看协议修改标志，例如 Flag I2C_M_NOSTART
只是在你的补丁中有所不同。
至少有一种方法可以做到这一点（诚然是一种混乱的方法），
我希望为了您的利益，您不需要将普通的 i2c 设备放在同一总线上。
老实说，硬件供应商一直在做这样的事情。 只要问题成为你的问题，他们就认为问题“已解决”。
我看到很多 I2C 损坏，你可以让其他人的生活变得更美好。
It doesn't seem too off the shelf, but
You probably will need to look at having a protocol modification flag like Flag I2C_M_NOSTART
only different, in your patches.
At least there is a way to do it (admittedly a messy way)
I hope for your sake you don't need to put a normal i2c device on the same bus.
Honestly, hardware vendors do stuff like this all the time. They consider the problem "solved" as long as it becomes yours.
I see lots of broken I2C out there and you could make life nicer for other people.
听起来您需要重写 I2C 系统的内核驱动程序才能实现这一点？
另外，升级内核怎么样，看看自 2.6.14 以来发生了什么，这是一个相当旧的内核版本。
Sounds like you need to rewrite the kernel driver for the I2C system to allow this?
Also, what about upgrading the kernel and see what has happened since 2.6.14 which is a pretty old kernel version by now.