10

On the Arduino / ATmega328p, the 16-bit Timer/PWM modules have a input capture unit that allows the precise time of arrival for an input edge to be recorded even if the processor is busy when the input edge arrives. (For details refer to the datasheet, section 20.9 on page 155.)

Does the Raspberry Pi have any kind of comparable hardware peripheral, or some other way to precisely timestamp an input edge that occurs while the processor is busy? I've tried searching through the BCM2835 ARM Peripherals datasheet, but I haven't been able to find anything that matches my needs so far.

I would suppose this could be accomplished by using the FIQ to trigger a DMA from the system timer to somewhere else, but from the register docs it seems like the FIQ can only be set up for GPU and base interrupts. I'm not sure how to get the FIQ to trigger on GPIO interrupts, and even if I knew how, I'm not sure if this is a correct way to proceed, or if there's some other way to do this more cleanly.

How can I precisely capture the arrival time of an input edge?

A small constant delay is not a problem since I can just subtract it back out, but for my application I need at least microsecond precision or better.

Improve this question
3
  • "precisely timestamp an input edge that occurs while the processor is busy" -> Since the GPIOs are genuine hardware interrupts and the Pi usually runs a genuine multi-tasking OS that responds appropriately to such interrupts, you should be able to get something with near millisecond level precision using normal techniques. Put another way, a "busy" Atmega328 is a very different beast than a "busy" BCM2835 because of the software they can support.
    – goldilocks ♦
    Mar 16, 2017 at 6:52
  • 1
    @goldilocks unfortunately, millisecond-level precision is not good enough - the events I am measuring are at most only a couple of milliseconds apart, and I need to be able to generate a series of output pulses with very precise timing offsets from the trigger. (Did this on ATMega328 using the PWM output compare blocks; a very similar technique should work for Pi, as long as I can actually get the timestamp off the PWM timer.)
    – AJMansfield
    Mar 16, 2017 at 21:44
  • They are still a little bit apple and orange in the sense that you can do things with one that you cannot do with the other. But they go together like chocolate and peanut butter IMO -- so if it's just the timestamp that's important, and not having the Pi respond to things in real time with sub-millisecond precision, then piggyback a nano on the Pi. There are various straightforward ways for them to communicate (UART, I2C, SPI, gpio interrupts). It's implicit here you need the Pi for something you can't do with the atmega, but it should be possible to use both.
    – goldilocks ♦
    Mar 17, 2017 at 9:28

1 Answer 1

Reset to default
7

For a general Linux solution pigpio is probably the best you are going to find.

It uses DMA to capture the GPIO levels and uses DMA to time-stamp the event time from the 1MHz system clock.

The latest samples are reported to the interested processes in 1 millisecond chunks. That means the average latency is about 500µs. However that wouldn't normally be a problem as each report has already been time-stamped.

If you go the interrupt route expect an average latency between GPIO event and process notification in the 50-100µs region, of course outliers can be much more, easily 10s of ms, and you will not know which is which.

pigpio will sample at 1Msps, but I wouldn't recommend it if the system is likely to be busy doing network stuff, you will get DMA timing jitter as the memory bus starts to get busy. I'd stick to 500ksps or less.

I don't see a way to meet your 1µs or better goal under Linux.

Improve this answer
4
  • Guess I'll have to use an auxiliary microcontroller to handle the input capture, and just talk to it over like I2C or something.
    – AJMansfield
    Mar 16, 2017 at 21:35
  • @AJMansfield How many level changes do you expect a second? Even at its fastest I2C on the Pi won't handle 1MHz sampling. SPI might but in either case the Pi is the bus master. What are you trying to achieve?
    – joan
    Mar 16, 2017 at 21:51
  • you're right but I can do most of the realtime processing on the external mc without needing to get the pi involved, since I only need to change the configuration on the order of once a second, and it only needs to report back basic statistics.
    – AJMansfield
    Mar 16, 2017 at 23:50
  • What I'm trying to do is generate a series of output pulses at a very precise time offset from the input trigger signal; the pulse pattern itself won't change that often.
    – AJMansfield
    Mar 16, 2017 at 23:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.