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

[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

[Jerson]

Hi Hank

I think You and Robert got the sequence correct.

Now, the counts between 2 Comp1 ints is proportional to the frequency and you have no problems here.

The counts2 that you refer, are these raw counts? or are they converted as per the formula you showed in an earlier post?

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

If it is this formula you are using, I think you will need to revise this like so
Phase(degrees) = ( Phase (Counts) * 360 degrees ) / Frequency (Counts)
The sequence of operation is significant and I have bracketed them on purpose.

As to why you cannot go below 325, I was wrong earlier. The latency cannot be so high. The explanation is like this
for a freq count of 500 (100Hz) the equation breaks down to 500/360 * 325
Now, Using integer math, 500/360 = 1, so 1*325

[HankMcSpank]

Hi Robert - yes, that's my take on the overall flow of things - so why on earth does the timer1 count not get any lower than 325 @1khz when the lagged signal causes an interrupt on comp2?(pretty much immediately after comp1 finishes it's interrupt routine)

Hi Jerson - just to confirm - those were raw counts.

The reason being, while debugging this, I didn't want incur any extra PIC 'overhead' calculating the phase in the PIC program itself (ie causing problems with the overall flow of things) ....so I stripped it back bare (for now, I calculate the phase separately on a spreadsheet based on the two timer counts I see onscreen)

My program is very small I'm at work & don't have it with me) but it's literally just ..

set registers up
set interrupts up (as per standard for DT's routines)
a Tiny main program loop ....just to get the stored timer1 count info out the HSEROUT pin onto my PC screen.
the two comp interrupts (as posted in my earlier post)

[HankMcSpank]

Ok, I think I've got to the bottom of the problem - & rather than have the soltuion posted in a thread with an unrelated title, I've tagged it on the end of a more appropriate on that I started...

http://www.picbasic.co.uk/forum/show...4006#post94006