Tried to connect the card reader with Wiegang interface to gpio.
Wiegang provides output data pulses every 2 msec. To detect pulse I used GpioController.RegisterCallbackForPinValueChangedEvent(Int32, PinEventTypes, PinChangeEventHandler) method. Looks like 2 msec is a fast data rate, because reading is not consistent, sometimes bites in the received package are randomly missing. What is the fastest data rate for libgpiod2 which can provide the warranty of the real time reading?
I couldn’t find a definitive “max data rate” for libgpiod online. However may I ask why you suspect it’s the data rate that is the issue here? Not saying your incorrect I’m just wondering how you narrowed down the issue to the data rate.
Have you done tests with a slower data rate than 2ms? If yes, then do you know around the speed things start to “break”?
This would help in the investigation to see if there is a hardware or software issue here.
Looks like system may ignore the short pulses. originally card reader provides 40 usec pulse width.
When it was increased up tp 150usec it became more stable. Regarding the pulses period , it slightly improves when frequency decreases , but system never detected 100% of pulses.
The following test was done:
Two gpio inputs were connected together and the number of events were counted in event handler subs.
These values were different, so system misses some events.
Also, when the same pin is programmed to detect both falling and rising events the number of falling is always less then the number of rising and this difference is increase for the smaller pulse width.
A 40usec pulse may be a bit too much for the standard libgpiod stack to properly process. I imagine you’d need some kind of custom/special driver for processing such rapid short pulses. As well as a special high priority interrupt for capturing each rapid pulse.
Before we go into much detail, what is your use-case/requirement here?
I’m curious if there’s a better approach we can look at.
I added the hardware to increase the pulse width from 40usec to 1msec. Now it became pretty stable. But sometimes the read data are wrong: one-two bits missing which means that event was not handled. Also the total amount of bits is correct, but bits (usually two) mixed like I see 10 instead of 01. I have the impression that high priority process may interrupt the application or screw up interrupts sequence.
So now the requirements are:
The packet length is up to 64 bits.
Pulses are negative (could be change to positive).
Pulse with is 1 mses (could be increased up to 2 msec)
Pulses period is 2 msec (This one cannot be changed).
Could you please provide more details about your case? It’s still not clear how the GPIO event get translated to bits and packets. Is it possible to use an SPI or UART for the same purpose?