1
\$\begingroup\$

This may be a trivial question.

I have a microcontroller that will attempt to recognize the rising and falling edges of a pulse. This pulse is not in sync with the microcontroller's clock or any clock. For my intents and purposes, the voltages are adjusted to the voltages that the microcontroller requires. How should I expect the microcontroller to behave if it tries to detect the rising edge when...

  1. ...the pulse begins near the beginning of the clock cycle?

  2. ...the pulse begins in the middle of the clock cycle?

  3. ...near the end of the clock cycle?

As well, what should I expect if I try to detect the falling edge with the same timings? (1. near the beginning, 2. in the middle, 3. near the end)

I don't know if this question depends on the specifics of the MCU or the pulse. If so, I can provide specs. Thanks!

EDIT: I think I worded my question poorly. I understand that the MCU will only sample each clock cycle. I was mostly asking what would happen if the pulse were to change polarity in the 1. beginning, 2. middle, 3. end of a clock cycle. Will this affect what the MCU samples?

Specs: ARM9 MCU http://www.nxp.com/documents/data_sheet/LPC3141_43.pdf

Pulse: Pulses are generated by an avalanche photodiode. Each pulse represents the arrival of one photon. Pulse high lasts 30 ns, pulse dead time is minimum 50 ns. The current goal of my project is to use the internal timer to time these pulse arrivals.

\$\endgroup\$
  • \$\begingroup\$ I think it would be helpful if you could tell us what pulse signal that is and what µC you are using. =) \$\endgroup\$ – Magic Smoke Apr 24 '15 at 15:32
  • \$\begingroup\$ IS this an interrupt pin configured as rising edge, or polling GPIO, or some other type of input? In either case, it'll certainly detect the edge provided the pulse is wide enough, but there will be a minimum latency. \$\endgroup\$ – pjc50 Apr 24 '15 at 15:32
3
\$\begingroup\$

Here is the way it works. If you have a pulse, assuming voltages are OK, it will be detected at clock N if it meets the setup and hold time for clock N. If it is too late to be detected at clock N, it will be detected at clock N+1. If the timing is marginal, it may be detected either at clock N or clock N+1, there is no way to know ahead of time.

Please note that there is a minimum detectable pulse width. If the pulse is too narrow, it may not be detected at all. Generally, "too narrow" means less than one sample clock period (but you need to work it through with the setup and hold time specifications to fully understand the minimum pulse width). So if the minimum pulse is less than one clock cycle, then there is the possibility of missing a pulse. Welcome to the joys of asynchronous design.

Depending on what you are interested in, there are all kinds of things you could do. You could have the pulse enable an analog integrator so that pulses can be counted in an analog way, then occasionally sample and reset the integrator to avoid overflow.

If pulse timing is what you are most interested in, you can start an integrator on the pulse rising edge, then sample the analog voltage output of the integrator with an ADC synchronous to the digital sampling. Then you convert the ADC voltage to elapsed time. This will allow you to figure out the time of the pulse with sub clock accuracy and precision.

Have fun!

| improve this answer | |
\$\endgroup\$
  • \$\begingroup\$ Thank you for the detailed response. Since my pulse cycle is a minimum of 80 ns, I assume that the integrator method is too slow. I understand that it can measure with a high degree of accuracy, but I am concerned that I will not be able to take thousands of measurements, as I intend to. \$\endgroup\$ – Paul Terwilliger Apr 24 '15 at 16:16
  • \$\begingroup\$ No, it is not too slow. It just forces you into very specialized high-speed analog design. There are people out there who know exactly how to do it. I am just not one of them. Current steering type stuff, like ECL. You should be able to count the pulses with a digital circuit. Maybe a simple counter will do it (you would want to make sure it can run at around 100 MHz or more) or if not, a CPLD or FPGA could certainly do it. If you want precision timing, however, you will need to get into the analog stuff. \$\endgroup\$ – mkeith Apr 24 '15 at 16:36
  • \$\begingroup\$ Here is a simple idea for you, to help explain. If you pass the pulse train through an RC filter, you can stretch out the rising and falling edges. If you use an ADC to sample this stretched out pulse train, you can guestimate the exact time that the pulse began, based on the rise time characteristics. If the pulse reaches full amplitude, then it must have started just after the previous sample clock. If the pulse is middle height, it must have happened midway between the last clock and this one. If the pulse is very low, it must have just happened. This is just the concept sketch. \$\endgroup\$ – mkeith Apr 24 '15 at 19:33
  • \$\begingroup\$ I like it very much. I will likely implement this in my optimization once I at least have a rough pulse-detector working. \$\endgroup\$ – Paul Terwilliger Apr 27 '15 at 15:39
1
\$\begingroup\$

The sampling theorem states that you should at least sample with double the frequency of the signal. (very basically speaking)

There's no such thing as the beginning, middle or end of the sample, because the sample is the atomic unit of time so to speak. You do not have more resolution.

If the next rising edge comes in before you can finish the current one, interrupts queue up and data can be lost. The theorem is not all that matters here, because you need some cycles to run your code, too.

µCs often come with dedicated peripherals for such tasks. capture/compare units for example can run a timer until a rising edge is detected and write the timer value into a register. This is very quick because it is done in hardware. The register can then be copied to some block/array of memory, in order to save it from being overwritten by the next incomming timer value.

| improve this answer | |
\$\endgroup\$
1
\$\begingroup\$

The relationship between input data and input clock for a gate is specified by its setup and hold times. For an individual flip-flop, this provides a window when the change will be registered properly and a small time in which it may not (possibly resulting in a "metastable" state). Since there is not really such a thing as an edge, only a slope of finite time, the risk window cannot be made zero size.

So the normal solution is to cascade several flops one after the other, with special metastability resistance. There will be a fixed multi-cycle delay between the signal arriving at the pin and it registering internally. There will also be an interrupt latency if you are triggering an interrupt.

For practical purposes, if you read two pulses from an input pin the timings may be off in each direction by up to one whole clock cycle. Your signal may be up to 20MHz; trying to read this on a microcontroller with anything other than a dedicated serial input peripheral is likely to have issues. You can probably measure a pair of signal timings with a capture/compare peripheral though.

Edit: this is related to your previous post, isn't it? This would be much easier if you described where the pulses are coming from and what protocol they mean.

| improve this answer | |
\$\endgroup\$
1
\$\begingroup\$

Directly using interrupts or polling values will anyway make you depended on digital sampling rate. Instead, use a flip-flop buffer. After polling the data, reset it. May there be numerous signals that be lost until you poll? Than use a fast counter IC, poll the value in a statistically meaningful period (I mean, considering some tolerance for the counting that may be lost in poll and reset sequence) and reset.

| improve this answer | |
\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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