We've been using this driver and so far it's been great. We're using an encoder which is a 4 Byte Special Terminals and noticed a discrepancy - There were random spikes in the data every so often, but it was only the one value and would immediately go back to the correct value.
Upon looking at the data more closely, we found that we may not be reading the entire 4 bytes as a single atomic operation. Here's a snapshot of the data
The value was counting down. For packet 2, the least significant byte was read just before bit 8 was going to be decremented. It appears the next byte was read as a separate read, because by the time it is read, the value of bit 8 has already been decremented. The value of bit 8 should still have been 1 when the LSB was read.
Hi,
We've been using this driver and so far it's been great. We're using an encoder which is a
4 Byte Special Terminals
and noticed a discrepancy - There were random spikes in the data every so often, but it was only the one value and would immediately go back to the correct value.Upon looking at the data more closely, we found that we may not be reading the entire 4 bytes as a single atomic operation. Here's a snapshot of the data![image](https://user-images.githubusercontent.com/10639113/81592105-6c9a2500-938b-11ea-9661-c4e3c722f2b5.png)
The value was counting down. For packet 2, the least significant byte was read just before bit 8 was going to be decremented. It appears the next byte was read as a separate read, because by the time it is read, the value of bit 8 has already been decremented. The value of bit 8 should still have been 1 when the LSB was read.