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

[Jerson]

Hi Hank

The second comp int should not reset the timer to 0. Comp1 int is your reference point and you zero the timer in there. Comp2 int will not come if there is no comp1 signal. This is from your circuit.

So, if you see my previous postings on the other thread,
COMP1 int
read the timer (gets you frequency counts)
Timer Reset

COMP2 Int
read the timer (gets you phase counts)


These should be the only steps involved. I think you will be successful in this

Regards

[HankMcSpank]

BINGO! .....I've got it working at about 1.30am this morning shortly after making that last post

Jerson - many thanks ....re your post above - you were bang on the money.

In conclusion to brigng the thread back on topic, for anyone wanting a pointer wrt configuring their PIC to run on an external clock - well, for a 16f690 @20Mhzthese settings work for me....

@ __CONFIG _FCMEN_OFF & _HS_OSC & _WDT_OFF & _MCLRE_OFF & _CP_OFF & _IESO_OFF & _BOR_OFF & _PWRTE_OFF

DEFINE  OSC 20          ' set Oscillator at 20Mhz.
OSCCON.0 = %0001000

(for the above to work, you need to be using MPASM)

And if you're doing anything with timers/counting clocks, bear in mind what Alain said above ....ie that the number of clocks counted during your own particular timeframe will be the oscillator frequency divided by 4. (which caught me out nicely)


Many thanks to both Alain & Jerson for taking the time to help me out......you've made a happy man very old (or should that be the other way round?)

Got to start learning about LUTs & arrays now - there's no end to all this learning!

[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.