Any know issues for xtimer_now_usec64() on interrupt context?

Hi there!

I’m working on the PR to support the Wiegand protocol (Widespread protocol for RFID card readers) in RIOT (

The algorithm is fairly simple: It takes a timestamp on each data line change. Then the decoder function checks if the last activity took longer than 25ms (no more data) to decode the buffer.

Interrupt handling for both data lines works perfectly (Checked with an oscilloscope). But for some reason xtimer_now_usec64() is not returning a monotonic timestamp. This causes the decoder function to try to decode the buffer before a full Wiegand frame is received.

Current fix (Not yet included on the PR)(**) To make it work I removed the calls to xtimer_now_usec64 inside the ISR and instead I’m checking if the frame size counter stills the same for more than 25ms on the thread that is pooling for new cards.

The fix works perfectly, all the time. But is not elegant as I would like, because it lefts the user with the responsibility of pooling the driver. Also you still can miss or get wrong data if the user doesn’t pool the buffer fast enough because it would overwrite the previous buffer.

There is no length indicator on Wiegand protocol. The only indicator that the frame is received is no activity on the line for about 20-25ms.

So here are my questions:

What’s the best way in RIOT to record a timestamp if I need to store them inside an ISR?

If there is no (platform-agnostic) way to make it work that way:

What’s the best way to have a pooling thread within the driver (if that’s is an acceptable practice)?

Other options like using a timer could require to measure and syncronize the timer with the wiegand pulses. Take into consideration that some manufacturers use their own timings to make their RFID card readers “propietary”. Also It’s a lot more complex solution than the interrupt-based algorithm currently used.

Any ideas?

Regards, Mario.