Oscillators, counts, clock cycles, config settings ......& women

[Jerson]

Hehehe - I guess you saw the color red in that post

Congratulations on a job well done.

[HankMcSpank]

Oh dear - I spoke to soon! (5 nights & counting for this seemingly simple task! Eek!)

by & large the overall process works, however.....

If I take the phase shift control of my all pass filter circuit down to as near as damnit zero degrees phase shift (ie no lag for the second signal feeding into comparator 2), then there ought to be almost a zero count when the second comparator interrupts, alas, in actual fact there appears to be count of about 325 for comparator2 in this scenario (@1khz). If I take the tst frequency down to 100Hz, I see a comparator2 count of a whopping 3000 (albeit comparator1 reads 50,000 in this scenarion - so it's pro rata)

this means @1khz, with that error I'm getting a phase shift of about 23 degrees being erroneouly calculated - ie 5000 (1st timer count) divided by 360 (degrees) muyltiplied by 325 (second timer count) - but I know for a fact there's actually no phase shift present at all (I can see this on my scope).

Now I know I'm relatively new to all this, but I can't help feeling there something going seriously wrong 'behind the scenes' (or a config register setting?).... my reasoning is that there's virtually no code for me to screw up with here!

here's my interrupt handler...

Comp1_Int:
        Comp1Time.Lowbyte = TMR1L 'Store away the timer1 count         
        Comp1Time.Highbyte = TMR1H     'Store away the timer1 count.
        TMR1H = 0                     'Set the high part of the timer value to 0
        TMR1L = 0                      'Set the low part of the timer value to 0
@ INT_RETURN

Comp2_Int:
        Comp2Time.Lowbyte = TMR1L      'Store away the timer1 count 
        Comp2Time.Highbyte = TMR1H     'Store away the timer1 count
@ INT_RETURN

Anyone got any ideas?!

[Jerson]

Hi Hank

Assuming the phase difference is near zero. There is still a finite amount of time it takes for Comp1Int to complete(CPU cycles) and Comp2Int to be services. It is possible you are seeing the interrupt latency values.

AFAIK there is no config register setting that should mess things up.

Regards

[rsocor01]

If I take the phase shift control of my all pass filter circuit down to as near as damnit zero degrees phase shift (ie no lag for the second signal feeding into comparator 2), then there ought to be almost a zero count when the second comparator interrupts,

Hi HankMcSpank,

I think that is a wrong assumption. If both triggering pulses for Comp1 and Comp2 are traveling at the same time (0 degrees phase diference) then by the time the Comp1_Int interrupt is finished, then the triggering part (rising or falling edge) of the Comp2 pulse has already being gone. So, the interrupt Comp2_Int has to wait for the next triggering event. This is pretty much what Jerson is trying to tell you in the previous post.

Now, if you are getting a reading of 325 for Comp2, that is a reading for 65 microsecs. So, having a period of 1 ms for your triggering pulses this means that all the interrupt latency values that Jerson is talking about are (1,000 uSecs - 65 uSecs) = 935 uSecs. This is assuming the next pulse is triggering Comp2. This latency value could be 935 uSecs or 1,935 uSecs or 2,935 uSecs or ....

Does anybody know how long the DT interrupts take to execute?

Robert

[HankMcSpank]

Thanks for both your comments - re latency of the interrupts.......remember, here that the comp1 count is rock solid....ie at 1khz into comparator1, I'm seeing a steady count of 5,000 (plus or minus 4) .....if DT's interrupts had latency.....wouldn't it show up there too?

remember all I'm doing here...


Comp1 interrupts....store count
comp1 interrupts again....store count reset timer

Comp2 interrupts....store count.

Therefore the only thing that differs is resetting the timer - does it really take soo long (in clock cycle terms) to reset a timer?

Also, I wanted to avoid any situation where there was almost no time span between the comp1 interrupting & comp2 interrupting (& causing diffs), so as an experiment, I've also put the tiniest amount of lag (as visible on a scope) in to avoid this too....no change - that 325 doesn't move until I take the all pass filter lag way up past 23 degrees....at which point comp2 count starts incrementing as I'd expect.

(also why would the comp2 count move when I take the frequency down - the period for 100hz is much longer so comp1 count is 10 times higher at 50,000, but the comp2 count also went 10 times higher at 100Hz to approx 3,000. weird.)

[rsocor01]

Thanks for both your comments - re latency of the interrupts.......remember, here that the comp1 count is rock solid....ie at 1khz into comparator1, I'm seeing a steady count of 5,000 (plus or minus 4) .....if DT's interrupts had latency.....wouldn't it show up there too?

The 5,000 are being counted when the program is out of the interrupt routine --> So, no interrupt lag.

[HankMcSpank]

The 5,000 are being counted when the program is out of the interrupt routine --> So, no interrupt lag.

I guess I'm not grasping that - why is comp1 out of the interrupt routine?

here's the sequence...

Comp1 interrupts - store a number (an interrupt)

(returns to main program)

Comp1 interrupts again - clear a timer (another interrupt)

(returns to main program)

Comp2 interrupts - store a number (another albeit different interrupt)

(returns to main program)


could it be something specific to the Comp2 interrupt? incurring extra delay? (but that said, it's clearly not a static delay - seems to be pro rata to the incoming frequency on comp2....ie at 1000hz, the lowest number comp2 will go is 325, at 100hz the lowest number comp22 will go is about 3,000)

[rsocor01]

Well, I think it goes like this (please, somebody correct me if I'm wrong)

(main program) --> Do the counting (5000 for Comp1Time) Uses TMR1 to count
Comp1 interrupts: store Comp1Time -> clear TMR1
(returns to main program) --> Do the counting (X for Comp2Time) Uses TMR1 to count
Comp2 interrupts: store Comp2Time
(returns to main program) --> Do the counting (5000 for Comp1Time) Uses TMR1 to count
Comp1 interrupts: store Comp1Time -> clear TMR1

and so on ..... This is for the last code that you have posted.

Robert