I have an 8Mhz ATM32u4 that is able to read external pulse inputs at 125ns ticks using InputCapture3 (PC7) on its 16-bit timer. Is there a magical way (bitbanging?) to get around 10ns tick resolution to read pulses? Edit: like ADC conversions to allow 16-bit systems 24-bit accuracy via creative coding, etc.

If there is no magic, I should use a faster CPU? I am limited in coding pretty much to AVR type CPUs in the Arduino IDE. So wondering what AVR CPU would be fast enough for a 10ns tick that is incorporated already into like a Nano, UNO, etc?

Unless I am able to use Pin Interrupts that are able to read at 10ns intervals, then I could use ARM CPU types with Arduino IDE code which does not require me to dive deep into register level language.

Or, is there a stand-alone analog or digital IC that is able to read at 10ns intervals pulses that an Arduino can process?

Thank you.

Edit: I would need to measure the length of a one-shot pulse only, not a continuous or changing signal. Down to 70us length with an accuracy of at least 18ns tick, but preferably 10ns to account for hardware, etc inaccuracies. This one-shot pulse could repeat not more frequently then 1 second apart, but likely several seconds apart. The signal is two positive square waves forming a pulse measuring not less than 70us from the positive rising edge to rising edge. The system measures the pulse length and sends it the user (serial, BLE, etc).

Edit 2: someone suggested a "one-shot pulse stretcher". Interesting concept... The more I am looking into it, the more I think it's a very viable hardware solution to the AVR's processing speed limitation. One may say that this is hardware "bitbanging" by streching out the short pulse to a proportionally longer one that the MCU capture process can measure reliably/accurately. An example is this old IC from Linear Tech. See Fig 12 and Fig 13. https://www.analog.com/media/en/technical-documentation/data-sheets/6752fc.pdf

http://www.anderswallin.net/2014/02/pulse-stretcher-v1/ enter image description here

enter image description here

The shortest expected pulse would be about 70us which needs to be measured at (around) a resolution of 18ns for the accuracy I need. So I went with 10ns for design to allow for some accuracy "overhead". That is between 4000-7000 counts/ticks (18ns-10ns ticks) for the 70us signal.

If I stretch this same 70us signal to be measured with the pulse-stretcher to 700us and use the currently available 125ns tick interval of the ATM32u4, I should arrive in theory to about the same accuracy as using an 18ns tick for a 70us signal to be measured.

Here is a similar problem that was answered: https://electronics.stackexchange.com/questions/46922/lengthening-a-5-ns-pulse

  • 1
    Delta_G could you address the other parts of my question which was not related to "bitbanging", which identify completely different potential solutions? Thank you for your constructive assistance! What makes this forum great is to hear suggestions from folks like you who are willing spend time on a positive guidance focused on the correct portions of one's questions while also pointing out the incorrect ones..
    – TommyS
    Sep 13, 2020 at 5:05
  • 1
    There are some Arduino-compatible boards based on the ATtiny85. This has a fast asynchronous timer that can be clocked off a PLL at 64 MHz. It's probably the fastest you can get on an AVR, but it doesn't have an input capture unit. Sep 13, 2020 at 8:48
  • 1
    Do you need to measure the length or the pulse, or just it's existence? If you latter you'd need to stretch this 10ns pulse to something longer that 125ns. Something like an RC filter.
    – Gerben
    Sep 13, 2020 at 13:48
  • 1
    Please edit your question to add information. I spent several minutes to find the relevant stuff down here, and I did this just for curiosity. Most others will not do it. Sep 14, 2020 at 7:01
  • 1
    someone suggested a "pulse stretcher". Interesting concept... anderswallin.net/2014/02/pulse-stretcher-v1
    – TommyS
    Sep 14, 2020 at 17:22

2 Answers 2


There is nothing you can do on the AVR processors that I know of, which can run on from a quite slow clock, and I think up to 24 MHz. Since your Uno / Leonardo / Micro run at 16 MHz that would be only an incremental speed improvement (to clock them at 24 MHz).

Your idea of bit-banging is interesting, but in general bit-banging is a last resort when you need extra things the hardware doesn't provide (like an extra SPI port) and in general will be slower, not faster, because it involves code rather than inbuilt hardware.

Running at 16 MHz each clock pulse is 62.5 ns which means that is the absolute most resolution it could count. I don't see why you can't count at the rate of 62.5 ns (rather than 125 ns), however that isn't 10 ns resolution.

Or, is there a stand-alone analog or digital IC that is able to read at 10ns intervals pulses that an Arduino can process?

Very likely. There are probably dedicated counting chips that would do that for you. I haven't looked, but it is the sort of thing there would be a market for. Such a chip would probably use I2C or SPI to communicate, which is easy enough to interface to.

  • Mr. Gammon. Really appreciate your input. I've been studying your website's Microprocessor guides/examples & incorporated them into various projects.They are very clear & cover exhaustively the topic for people like me that are not that experienced. Thank you very much for that, sincerely. So based on your and the other comments above, including Edgar Bonet's, the closet one for an AVR is an Atiny85 with an internal oscillator scaled 8x to 64 MHz via PLL that theoretically can give 15.625 ns ticks for a timer that needs to be set up, etc but beyond my skills. Will look for faster non-AVR CPUs.
    – TommyS
    Sep 13, 2020 at 19:24
  • Mr. Gammon If I may have the audacity to ask you two related questions? #1: reference the 328p and 32u4 using the InputCaptureCounter/Timer (16-bit) and implementing an external pulse-read (like in your #12 reply example under "Timers"). You used an ISR timer/counter and an ISR for overflow. Comparing that with using attachInterrupt based pulse-read on the INT0/1 pin(s) and accounting for the time it take to enter/leave the ISR (@5us), would both solutions have the same inherent accuracy?
    – TommyS
    Sep 13, 2020 at 19:37
  • Mr. Gammon This is the #2 related question: I combined your InputCaptureCounter/Timer example and your CPU Deep Sleep example for the 328p (using the 32u4). That is the code that I was hoping to "beef up" to read 70us pulses at 10ns resolution and is located here: arduino.stackexchange.com/questions/77978/…
    – TommyS
    Sep 13, 2020 at 19:46
  • Perhaps if you explain in more detail your project? Why do you need to measure such short pulses?
    – Nick Gammon
    Sep 14, 2020 at 8:39
  • 1
    If you make this work I suggest you post your own answer to your question, giving details about how you did it, for the benefit of future readers.
    – Nick Gammon
    Sep 15, 2020 at 5:50

1 ns is a billionth of a second. A 1 gHz clock has a cycle time of 1 ns. If you have a timer that's able to count single clock pulses you'd need a 1 gHz clock to get to 1 ns resolution. for 10 ns, you'd need a 100 mHz clock.

You won't get close to 10 ns resolution with an 8 mHz clocked device.

  • Duncan C, thank you for breaking it down to the numbers. Yes, clearly would need an MCU with a faster input capture/timer, or a dedicated external IC that can do the same. Wondering, if a fast ADC would do? I suspect that Freq-to-Volt converter would be too inaccurate at these periods. And using a Freq dow-counter by 10 or 12 for example is would not work with a single-shot pulse that is only 70us in length/period,
    – TommyS
    Sep 13, 2020 at 19:08
  • 10 ns is a very short duration. No way would you use something like frequency to voltage to measure durations that short.
    – Duncan C
    Sep 13, 2020 at 20:21

Your Answer

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

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