找到报错的位置:
是在 XXX_i2c_xfer () 中下的一的执行函数: octeon_i2c_simple_write()
cmd = __raw_readq(i2c->twsi_base + SW_TWSI);
printk(KERN_DEBUG "%s:after readq cmd = %llx\n",__func__,cmd);
if ((cmd & SW_TWSI_R) == 0) {
if (octeon_i2c_lost_arb(cmd))
goto retry;
ret = -EIO;
这个 EIO 在用户层上
printf("%s:error = %s\n",__FUNCTION__,strerror(errno));
会显示 input/output error
观察 dmesg:
[ 2656.285759] octeon_i2c_xfer: num = 1
[ 2656.285769] octeon_i2c_xfer:msgs[0].addr = 57, msgs[0].flags = 0, msgs[0].len = 2
[ 2656.285780] octeon_i2c_xfer:msgs[0].buf[0] = 0
[ 2656.285789] octeon_i2c_simple_write:
[ 2656.285797] octeon_i2c_simple_write:cmd = 8090570000000000
[ 2656.285808] octeon_i2c_simple_write:msgs[0].buf[1] = 10,cmd = 8090570000000010
[ 2656.285820] octeon_i2c_simple_write:msgs[0].buf[0] = 0,cmd = 8090570000000010
[ 2656.285948] octeon_i2c_simple_write:after readq cmd = 090570000000020
[ 2656.285955]
我将正确执行的程序 dmesg 打印出来作为对比:
[ 4312.259857] octeon_i2c_xfer: num = 1
[ 4312.259866] octeon_i2c_xfer:msgs[0].addr = 51, msgs[0].flags = 0, msgs[0].len = 2
[ 4312.259878] octeon_i2c_xfer:msgs[0].buf[0] = 2
[ 4312.259887] octeon_i2c_simple_write:
[ 4312.259895] octeon_i2c_simple_write:cmd = 8090510000000000
[ 4312.259906] octeon_i2c_simple_write:msgs[0].buf[1] = 30,cmd = 8090510000000030
[ 4312.259918] octeon_i2c_simple_write:msgs[0].buf[0] = 02,cmd = 8090510000000230
[ 4312.260227] octeon_i2c_simple_write:after readq cmd = 01905100ffffffff
第一次 write 执行成功,这说明代码没有问题,那么第二次执行失败,应该是有别的原因,上网查了一下 24C
02 的资料,原来是这样:
“数据写完之后,给一个停止信号后一定要延时 10MS,24C02 ”需要这么久载入数据
这是 24C02 的电气特性。
在 write 函数使一次用 usleep(10000) 。
补充一下:我们的 CPU 为 6 内核 500M 主频,计算处理能力极强。如果在用户层写一般的延时
程序根本不起作用,一般使用 2 个 for,一个 for 执行 10000 次,在 PC 上就有会明显的延时。 但
是在我们的嵌入式系统中,使用 8 个 for 语句,每个 for 执行 10000 次,丝毫没有影响,起不到
一丝的延时作用。另外,单纯的使用 for 作用延时,会将 CPU 处于满负荷阻塞状态,
评论14
最新资源