18F14K22 Timer question

[anzacinexile]

Hi team,
I'm trying to get a 18F14K22 to measure a pulse width between 500us and 1ms. I copied this example from the forum (apologies, but I can't find the original author but thanks) but strange things are happening.
The circuit is working but inputting various pulse widths reveals :-
1ms = 1033
500us = 553
Also, the circuit will only resolve to 30us - i.e. the display will only change after a pulse width change > 30us.
I'm suspecting that this behaviour is the result of the maximum frequency the interrupt can respond but doubling the clock seems to have no effect.
Any suggestions on how this can be resolved would be greatly appreciated as my project really requires a minimum of 2 to 3us resolution.
Thanks in advance
Chris

[QMESAR]

Any suggestions on how this can be resolved would be greatly appreciated as my project really requires a minimum of 2 to 3us resolution.

Hi ,
Looking at your FC chart I think at the first instance you will never be able to get a resolution of 3us due to running at 19.66080 Mhz clock
which is a Tcy of 204nSec, 3us/204nSec is 14 Tcy cycles ,to service the interrupt and do all the code in the main loop as you have it is much more than 14 cycles, that might be the reason you see a response after 30us

I would do the following
(1)use the max frequency of the device 64Mhz
(2) Use the IOC pin to trigger the interrupt then start the Timer
(3) wait for the IOC to Interrupt again then stop the timer and read the value(no need to poll for the pin in the main loop
this is short and fast code you can do that in the Interrupt Service routine

[Bachman]

Try to use different controller, where Timer 1 extended with Gate Control. Eg.: PIC18F26K22, PIC16F1825. If you're using Gate Control in Single-pulse mode (see datasheet), you have to do only three things: set T1GGO bit, wait for measure complete, read TMR1H and TMR1L registers to get the time. Only one thing can be tricky, calculate the lenght of a bit in Timer1.

https://microcontrollerslab.com/timers- ... ler-delay/

ScreenShot_380.png (101.9 KiB) Viewed 8425 times

[anzacinexile]

Thanks guys, much appreciated.
I should have explained that the 500us to 1ms pulses are arriving every 2 seconds. In my mind, after the interrupt occurs, the PIC is looping tightly around the input to detect when the pulse is over, its then got nearly 2 seconds to complete the display update.

Bachman, I like your solution, but it exceeds my limited knowledge by a country mile I'm afraid.

Qmesar, please indulge me a little as I wish to learn but in doing so, I'm going to ask some dumb questions. I understand the clock cycle issues, but I would have though that having the interrupt trigger the timer directly would be quicker than detecting the interrupt and then starting the timer or am I (most probably) missing something. Also, I can't see how (without additional decision branches) one interrupt can trigger 2 states i.e, start or stop the timer. Can I also ask one last favour please. If you have the time, would you mind constructing a quick and simple flowchart explaining your solution as this would help me with my limited knowledge, picturing the process.

Again, many thanks to you both for your time and patience.
Chris

[QMESAR]

please indulge me a little as I wish to learn but in doing so, I'm going to ask some dumb questions. I understand the clock cycle issues, but I would have though that having the interrupt trigger the timer directly would be quicker than detecting the interrupt and then starting the timer or am I (most probably) missing something. Also, I can't see how (without additional decision branches) one interrupt can trigger 2 states

Hi Chris,
There is no such thing as dumb questions ,it is the person who do not ask that is dumb
All the above is possible ,I will try to make a small example for you however have a bit of patience I am a few day out on business trip probably by the weekend I will do it.
Another full proof variant is using the CCP module in Pulse capture mode but for that you need to write some C code in a C Icon.

[anzacinexile]

Brilliant - many thanks Qmesar, very much appreciate your time.
Please, there is no time pressure, being retired, I forget some have still to earn a living.
Chris

[QMESAR]

Hi.
Just a short now I haven't forgotten about my promise ,I just got hung up ,I am in my lab this week ,I will push it this week for you
Sorry it just wasn't possible for the weekend

[anzacinexile]

Hi Qmesar
Please don't be concerned. As I said, being retired, unlike you, I've got all the time in the world

[anzacinexile]

OK team, seriously confused now.
What I've done is to replicate the real application as far as possible. I'm not trying to simply measure a pulse from a single source rather I have 2 sensors which each sensor triggers a 2us pulse and what I'm trying to measure is the time between each 2us pulse with a (hopefully) 3us resolution.
The good news is that by changing to a 16bit timer, using 2 interrupts to start and stop the timer and cranking the chip up to 64mhz I'm getting 1us resolution but what's confusing the 'ell out of me is that I have to subtract 4083 from the timer count whereupon I get accurate (+/- 1us) measurements between 100us and 1ms.
In the interests of trying to understand how this thing is working any insight into why/how I have to introduce the 4083 fudge factor (awfully close to 4096) to get accurate readings.
Attached is my flowchart if you fancy trying to fathom my quandary.
Many thanks guys 'n' gals

[Benj]

Hello,

I've had a look for you and that is a puzzler, hmm. I'm not aware of anything that might cause this and looking I can't spot anything obvious.

I'll think on it.

[anzacinexile]

Thanks Benj, very much appreciated
Chris