我正在使用this库通过Beaglebone Black上的PRU通过I2C总线对一些传感器进行采样。似乎只有第一个事务工作正常,之后库似乎只尝试从寄存器地址0xFF读取,然后SCL线被拉低(见所附的图像捕获的逻辑分析仪)。我已经打开了一个问题,他们的github,但我不期待那里有答案,因为存储库已经多年没有更新,作者自2019年以来就没有在GitHub上活跃过。
x1c 0d1x的数据
在尝试自己查找问题时,我决定将寄存器地址和接收到的数据写入共享内存中,以使用prudebug进行检查。对于此测试,我尝试读取寄存器0x 00和0x 03。有趣的是,它将正确的寄存器地址写入内存(见图),但只有第一个返回值是正确的(0xEA)。写入共享内存中的接收数据缓冲区的值是0xFF,从逻辑分析仪可以看出,0xFF是它试图读取的地址。
的
我不知道我在这里做错了什么,但任何帮助都将不胜感激!我的主要代码如下所示,库函数可以在链接库here中找到。
uint8_t curr_data_idx = 0;
uint8_t tmp = 0;
uint8_t reg = 0x00;
volatile uint8_t * buf = ((volatile uint8_t*)(RESERVED_SMEM_ADDR + 32));
int main(void)
{
// enable OCP
CT_CFG.SYSCFG_bit.STANDBY_INIT = 0;
pru_i2c_driver_DelayMicros(500000);
uint8_t res = 0;
res = pru_i2c_driver_Init(1);
uint8_t saddr = 0x68;
pru_i2c_driver_ReadReg(1, saddr, reg, &tmp);
buf[curr_data_idx] = tmp;
pru_i2c_driver_DelayMicros(1000);
curr_data_idx++;
reg = 0x03;
pru_i2c_driver_ReadReg(1, saddr, reg, &tmp);
buf[curr_data_idx] = tmp;
pru_i2c_driver_DelayMicros(1000);
curr_data_idx++;
__halt();
return 0;
}
字符串
1条答案
按热度按时间ht4b089n1#
经过一些繁琐的调试,我发现了给定代码的问题;原来库中给出的延迟是不够的,库未能清除指示发生错误的位标志。因此,第一个事务将正常发生,但当试图从RX FIFO读取数据时,AERR标志将被置位,因为当由于延迟不够而试图读取时FIFO仍然是空的。然后,当试图执行第二次读取时,错误标志仍然被设置,从RX FIFO读取的数据实际上是以前的值。在事务之间增加几微秒的延迟并确保处理发生的任何错误后,一切都工作正常。我重写的库:
字符串
此外,delay函数是明显错误的。它没有延迟所请求的微秒,并且在优化打开后立即被编译器优化掉。我通过将其更改为:
型