On 03/26/2018 07:20 AM, Jean-Baptiste Maneyrol wrote:
Hello, we should have 1 interrupt every time a sensor data has been acquired. So in theory this is not something that should happen. But real world is always a different story.
Agreed.
Do you have a case where you saw that happen?
Yes, I'm seeing this on a board I'm working with. I'm also seeing I2C bus lockups at high frequencies, so my best guess (though speculation) is that the interrupts are being generated by the bus is dropping some of the messages. I'm seeing that, when the data ready interrupt fires, there are multiple messages in the FIFO, so all but the first get filled in with 0 timestamps. I plan to investigate why I'm getting bus lockups, but since this is exposed a bug, I wanted to first work on improving the resilience to such conditions.
The best way if this happens would be to create the timestamp based on the sampling rate since we know it (last timestamp + sampling interval). That would be very similar to the real value since the only difference is the clock drift between the chip and the system.
That sounds reasonable. Let me make sure I understand what you're proposing. Let's say we have set the sample rate to 10 Hz. Every time we get an interrupt, we already take a timestamp, which should be the correct timestamp for the most recent sample. Imagine that after an interrupt, we see there are 4 samples in the FIFO instead of just 1. In that case, we mark the samples with timestamps:
sample 0 (oldest timestamp): interrupt timestamp - 0.3 seconds sample 1: interrupt timestamp - 0.2 seconds sample 2: interrupt timestamp - 0.1 seconds sample 3 (newest timestamp): interrupt timestamp Does that sound right to you? If so, I will revise my patch to do it. -- To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
