Retrieving the value of a timer, quickly

[Rainwater]

I have been working on a project that needs to record the timing of a pin being toggled and have reached the limits of arduino controllers available to me. The basic setup is a timer counting up and an isr that stores the current timer value into a ring buffer, anytime the intrupt pin goes high.

A variable delay has shown up in the timer values from the start of this project. Caused by a delay between when the pin goes high, to the start of the isr. As the frequency of intrupts increase, this varable has become my limiting factor, lowering the precision of the results stored in memory.

I needed more processing power, so the project was ported into an esp32 with faster timers than arduino nano, but the variable delay in isr execution increased aswell. I am really looking foward to moving this from the 10KHz into the MHz range. After reviewing what it would take to construct a circuit that would perform this task, that quickly became unreasonable.

The next step being considered is moving to an fpga. I have never worked with one but have my eye set on something like the tang nano 9k and other entry-level kit that is ready to plug-n-play. Before I spend the money and time leaning a new programming language, and from the reads a completely new architecture and style, I would like to ask the people here, if this type of component would be appropriate for the task or is their something better?

The final parameters I am aiming for are data logging of the timer up to 50MHz, with timer clock speed at 1GHz or more

[DavidAlfa]

This is a job for a timer in capture/compare mode.
What's the required resolution?
1GHz won't be easy task, though there are some really fast mcus in the market.

[ajb]

Yes, there's hardware built into many lines of MCUs specifically for this purpose, it's a standard feature of timers. Some MCUs even allow some timers to run faster than the core clock for better resolution.

[HwAoRrDk]

It sounds like you might be taking the wrong approach with your Arduino code. If you're using the input capture facilities of a hardware timer correctly, the latency of an interrupt should not be affecting the timer counter value you record in your buffer. The timer itself should capture and store the counter value immediately upon the rising edge of the input signal, then trigger an interrupt, where you simply read the captured value and insert it into your buffer. So long as that happens before the next edge, you're good.

If you're just reading the value of a free-running timer in a pin-change interrupt, then it's unsurprising you have inaccurate values being captured.

[Rainwater]

Thank you all for the references to the timer mode. It's easy to miss 2 paragraphs (page 437 of the esp32 tech ref manual) in the 680 page reference. I have not found any reference to this function on youtube. If someone needs a topic for a video, this would be a good one.

This has almost completely removed the variations in the timer values (3 ticks +/-), which is in the error margins of the cheap signal generator used for testing. The mcu is still limited by the reaction time of the isr at high interrupt frequency.

I set up a latched led to an AND gate, connected to both the interrupt signal, and "irs is running" signal to it.
toggling a pin HIGH during the start of the isr and LOW at the end revealed that the routine doesn't have time to finish before the next interrupt occures. Counts are lost as a result. This was expected and anticipated but not verified. Now it has been

Shifting all tasks to a single core and forcing the isr to run on the other did slightly increase the maximum trigger frequency before losses, but im far from my goal.

I would like to move away from interrupts completely.

If doing this with descrete components, start by piping a clock source into a counter.
Use the trigger rising edge to clock the counter value directly into a parallel fifo buffer.
Use the trigger falling edge to check if the fifo buffer is full, if TRUE then switch to another buffer and set an output pin HIGH to signal a read circuit.
This would provide continued uninterrupted service while the data is processed separately.

Building this with individual components is not my goal and undesirable.

I know from reading a few tutorials on fpga programming that multiple logic and arithmetic steps can be performed almost instantly, but memory timing, Dram access. Pointer assignments and operations. I simply dont know enough about this technology yet.

Is it worth studying and experimenting just to find out that it won't work and the same limitations will be the dominating factor?
Or is this a step in the correct direction or hopefully a single chip solution?
Thank you for your time and replies.

[ajb]

What's the frequency and number of events you're attempting to capture?

Have you looked at DMA? I don't know how sophisticated the ESP32's DMA options are, but on many MCUs you can configure a timer capture event to trigger a DMA transaction to copy the register value into RAM automatically with no CPU involvement. After a specified number of transactions the DMA controller can fire an interrupt.

[Rainwater]

Looks like dma is only supported by 13 peripherals. Timers are not among them. Mostly just com protocols
The final design will triggered no more than 50MHz for a period of 500us.

Ultimately the number of samples stored will be determined by how much memory is available. And if possible, the 500us will be expanded to a few seconds.
Roughly 50000 32bit samples are being be stored by the prototypes now.
Prototyping the trigger circuit, has revealed the problems with the controller. Which is preventing progress on the trigger.
Currently im limited to 22kHz
I always new I would have to change controllers, so im hoping to make the switch only once more. To a device that will meet my future needs as well. Its a situation where I outgrown what I had laying on the bench.

[ajb]

50MHz at what resolution? I'm not sure what the fastest mcu timer peripheral on the market is, maybe 200ishMHz? Even with DMA you could swamp the bus matrix on many MCUs if you're trying to capture every event.

FPGA might be the way to go, but still could run into limitations on frequency that push you into higher tier parts depending on what sort of resolution you're looking for.

[Rainwater]

Im not completely confident in the definition of "timer resolution".
Assuming a description of the least significant bit, the goal for this project is for 1nS or 1.0×10^-9 seconds.
This project is a proff of concept, if it works as expected then femtoseconds would the ultimate goal, but that will be the topic of a different post.

[Someone]

Im not completely confident in the definition of "timer resolution".
Assuming a description of the least significant bit, the goal for this project is for 1nS or 1.0×10^-9 seconds.
This project is a proff of concept, if it works as expected then femtoseconds would the ultimate goal, but that will be the topic of a different post.

Wow, sub picosecond is doable with effort but aiming for 2 orders of magnitude further!

[ajb]

Im not completely confident in the definition of "timer resolution".
Assuming a description of the least significant bit, the goal for this project is for 1nS or 1.0×10^-9 seconds.
This project is a proff of concept, if it works as expected then femtoseconds would the ultimate goal, but that will be the topic of a different post.

Yes, the period of the least significant bit of a timer would be the thing you're looking at with a conventional timer capture arrangement.  Measuring down to femtoseconds is well beyond conventional timers, though.  A resolution of 1fs (1x10^-15) would mean a corresponding frequency of 1EHz (1x10^15), which is the kind of frequency you deal with in visible wavelengths of light--actually a little beyond, 10E15Hz is ~300nm in vacuum, so it's UV!  Aside from just running a counter that fast you'd have multiple other problems, such as how you convey the signals involved without introducing phase errors and jitter that swamp your measurement resolution.  In short that quickly becomes a physics problem, not an electrical engineering problem. 

A resolution of 1ns is probably doable in an FPGA, but that's a 1GHz counter so still not necessarily a cheap little thing.  Have you looked at off-the-shelf solutions?  Considering the complexity and time involved in rolling your own solution it's worth seeing if National Instruments or someone like that has an off-the-shelf solution.

[Rainwater]

Thank you DavidAlfa and ajb for pointing out the different modes of timers.
This was the solution to the immediate problem and has let me reach the limits of the current hardware
The esp32 can clock a 64bit timer at 460MHz but the capture and hold register only works with an 80MHz clock,
the isr method of acquisition is to slow for the rate of capture desired. Memory speeds of the esp32 are also variable with more than 200k avaliable sdram @ 80MHz and an addition 8m available at 40MHz

It appears that fpga will help meet so many of the other design requirements, its worth exploring and a development kit will be a practical starting point.

apologies for mentioning femtoseconds, this was off topic and a distraction from the original questions.