Glitch filter active while doing bbSerialRead?

[davthomaspilot]

I'm think Guy was suggesting I do something like this to start receiving serial data after a gpio notification.

I'd like a notification whenever a GPIO has stayed high for a millisecond. When that notification occurs, a bbSerialRead needs to be done.

If I use a glitch filter so that the gpio changes are ignored unless they are longer than 1 millisecond, will that also impact an active serialRead from recognizing transitions (less than 1 msec pulse width) as start bits?

Can I flush (using the gpioSerialDrainTs function posted in another issue), and do a read without missing the first start character after the 1 msec? 48 usec bit time. (And, over the pipe interface so I don't have to run as sudo)

Or, if the serialRead function is still processing transitions faster than what's set up in the glitch filter for notifications, can I figure out what data to ignore (which characters were in the buffer before the 1 msec period was detected)

[davthomaspilot]

Thinking about this some more, I could use two, connected, GPIO.

One would have the glitch filter, the other the serialReadOpen.

The notification would flush (do a serial read so as not to require a hack to the pigpio library).

Comments? Or, maybe Guy was way ahead of me.

[davthomaspilot]

Thinking still more, that won't work as well.

While the callback on gpio change would have a timestamp, there would be latency between when the edge occurred and the callback. And, additional (unbounded) latency from when a command to flush (or read) the buffer was actually executed. So, there would be no way to guarantee another read after the flush would occur soon enough to avoid missing the first start bit.

[davthomaspilot]

Just brainstorming.