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

[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

[rsocor01]

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

Hmmm, that explains the phase shift part. But, how do you explain getting a reading of 3000 instead of 329 on Comp2 when you change the frequency at Comp1 to 100Hz?

Robert