使用LSM6DS3TR-C的FIFO,先获取了FIFO的WaterM标志,该标志置位之后再去获取当前存在FIFO缓存的数据长度,再去读取FIFO中对应长度的数据,会出现读取数据出错的现象; 配置为: accel full scale: 8g gyro full scale: 2000dps accel odr: 104Hz gyro odr: 104Hz fifo: gyro、accel、ds3 and ds4 no decimation fifo odr: 104Hz fifo threshold level: 24 * 80 fifo mode: Continuous mode (110) 以下测试数据均在设备不移动的前提下; 正常数据如下: ![]() 错误数据如下: ![]() 相关代码如下: ![]() |
[size=14.6667px] Read water mark Disable fifo stop on threshold Read fifo length L. Read first date pattern If (pattern == 0 ) go to G If (pattern!=0) , read data from pattern number to 8 (maximum pattern number in you configure -three sensor), EX, first pattern is 3 , you should read data bytes of (8-3+1)*2 ,and discard all these fifo data. Re-caculate the number of date left in fifo , L_left , U16 (L_left/8) Read fifo data u16(L or L_left/8) Enable stop on fifo threshold
这个波形不是很好抓,因为fifo读取的数据比较大,而且这个问题并不是必现,错误的数据偶尔会出现,随机性 ...
我在用LDS3的时候,就犯过一个错误,因为I2C驱动写的不好,导致读取标志位时,多读取了两个字节的加速度值寄存器,比如X寄存器。发生的问题就是加速度的值会有一定几率是不对的。修改I2C驱动后,解决该问题。
改成一次性把所有数据都读取出来试试。然再进行数据内容判断和处理。
改成一次性把所有数据都读取出来试试。然再进行数据内容判断和处理。
这就是一次性从sensor中把所有数据读出来的结果,对读出的数据做处理判断过滤是可以,但治标不治本,还是希望能找到问题的根因;thx
这就是一次性从sensor中把所有数据读出来的结果,对读出的数据做处理判断过滤是可以,但治标不治本,还是 ...
用示波器看一下读取I2C的过程,一定要注意不要把数据寄存器读取。一旦发生数据寄存器读取后,在下次数据转换完成前,这里面的数据是错误的。
用示波器看一下读取I2C的过程,一定要注意不要把数据寄存器读取。一旦发生数据寄存器读取后,在下次数据 ...
这个波形不是很好抓,因为fifo读取的数据比较大,而且这个问题并不是必现,错误的数据偶尔会出现,随机性比较高,波形不好抓到刚好出错的时候;这边条件限制,手头也没有逻辑分析仪; 你说的一定要注意不要把数据寄存器读取指的是什么,不好意思,这里没理解; 读fifo数据前,我会先去去waterM这个标志,这个标志被置位的话,证明imu的fifo数据准备好了(或者换句话说满了),然后我再去读当前能读取的数据有多少个字节,然后再按这个字节数长度去读FIFO的;
读取FIFO数据的时候,要以6的整数倍读取?如果对数据的实时性要求不是特别高,可以试着保证读完FIFO后,FIFO里还有数据:比如FIFO长度为11时,只读6个字节;如果FIFO长度为12时,也只读6个字节;如果FIFO为13时,读12个字节。
读取FIFO数据的时候,要以6的整数倍读取?如果对数据的实时性要求不是特别高,可以试着保证读完FIFO后,FIF ...
有的,我设置的threshold是24*80=1920byte,每次读取前先判断了watermark标志位,该标志置位之后就获取data的长度,每次打印出来都是1920个byte,24byte对齐的;
我在用LDS3的时候,就犯过一个错误,因为I2C驱动写的不好,导致读取标志位时,多读取了两个字节的加速度 ...
按目前的分析来看,我觉得你说的这个可能性比较大了,但是我们用的i2c驱动是linux的驱动,理论上应该是不会有问题,这个i2c驱动code的review你有什么建议吗?