Pulse width measurement without input capture

It's as accurate as you manage to make it with your strange, unknown, processor of unknown capabilities and running at an unknown clock frequency.

ok

Any reason why you don't want to use some input capture hardware functionality? Capture hardware is as useful for measuring pulses as UART hardware is for receiving serial data - workarounds in software will never work as well.

Because no timer is available for input capture, all are used.

But if you know something about the pulse width, you might be able to use a high-speed SPI channel to measure, limiting the measure precision to the bit rate of the SPI.

I will think about it.

Can external interrupt functionality be solution???

>>Can external interrupt functionality be solution???

Depends what the accuracy requirements are, interrupts can have variable latency and this will results in roughness/jitter in the measurement.

What part are you using, and what time base to you expect to make the measurements against?

You can get better precision with a busy-loop sampling a pin (assuming you can afford to turn off interrupts while polling) than you get by use of external interrupts.

The external interrupt adds a fixed error from the response time - and a variable jitter depending on if there are other interrupts that must end before the external interrupt can be handled.

Note that it is often possible to use a single timer for more than one thing. So a free-running timer can be concurrently used for:
1) Software delays where the free-running timer is polled.
2) Capture to measure external signals
3) Periodic interrupts, by having the ISR constantly updating the match register(s)
...

A single timer that supports multiple match registers can be used to generate multiple interrupts at different frequency by avoiding the auto-reload feature. So there may be huge differences in the "quality" of timers between different processor manufacturers.

The schoolbook descriptions of how to use timers tends to be rather light on how to maximize the use of the hardware. Possibly because very few teachers has spent a significant amount of time implementing professional-grade software.

I need 10u Second resolution.(It should detect 10u Second time interval).

I am using RX610 Cortex M3.

Busy loop sampling will add delay.

Note that it is often possible to use a single timer for more than one thing. So a free-running timer can be concurrently used for:
1) Software delays where the free-running timer is polled.
2) Capture to measure external signals
3) Periodic interrupts, by having the ISR constantly updating the match register(s)

Yes this i want to try. if you see datasheet of RX610 then Timer unit0 having different functionality.

If i wanna use unit0 channel0,then only one counter is their.
So suppose i want to use this timer for internal counter and for input capture.

So if i will modify or reset main counter then it will disturb other other one.

In this case how to handle???

10us resolution isn't the same as being able to detect a 10us interval. You would normally want much higher resolution if the pulse is around 10us long.

Anyway - 10us means 100kHz. So it's possible to use continuous SPI receive at 100kHz to get 10us resolution. In some situations, it's also possible to have the pulse be detected as a start bit by an UART.

Busy loop sampling will add delay?

On one hand, it will require the main loop to enter a busy loop delay.

But when it comes to timing precision, it can manage much better than 10us resolution because almost any modern processor will manage a compare/repeat loop at much higher iteration speeds than 10us. A busy loop is likely to manage 0.1us or better resolution with most ARM chips - as long as there aren't interrupts that burns lots of us.

Does the RX610 have the Debug/Trace option implemented? Could always time stamp with DWT_CYCCNT

Other than that you'd want to look for a 32-bit (or 16-bit) counter register that you can read and make measurements against.