Searching \ for '[PIC] problem using INT0 + Timer0 on 18F258' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/time.htm?key=time
Search entire site for: 'problem using INT0 + Timer0 on 18F258'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] problem using INT0 + Timer0 on 18F258'
2005\01\20@172621 by Ake Hedman

flavicon
face
Friends,

I need some advice on a project I am working on where I got stuck.

I need to measure the duty cycle for a signal with a frequency between 1-4 kHz. Previously I have done this by sampling "signal high" and "signal low" for a large number of cycles. This works fine and is a solution I can use now as well as a last resort. But I thought about using the external interrupt and a timer instead just because they are available and I really would like to know if imy initial thinking works.

I use an 18F258 running at 40MHz using HS-PLL (10MHZ resonator)  with the signal connected to INT0

This is my thinking:

For timing my worst case scenario is  a 4 kHz  signal  giving me 1250 instruction cycles between interrupts. This sounds workable as  the interrupt only need to read and store a timer value.

By changing the trigger flank for the INT0  IRQ in the interrupt routine I can get interrupts both on the rising and the falling edge. I set up timer0 as a timebase  read the timer content on rising and falling edges of the signal. Now I have something like 1250/2 cycles between worst case interrupt timing which I feel should be OK.

If I now set a high prescaler on timer0 this works fine. The problem is that if I use a high prescaler value I get  to bad resolution. So I lower the prescaler and also count timer owerflows.  Now I just get very strange and random results.

I can't figure out what I am doing wrong. The overflow interrupt from timer 0 will add to the interrupt frequency but not to bad.

If anyone have a suggestion or can point out an error in my thinking above  it would be very much appreciated.

Regards
/Ake

--  ---
Ake Hedman (YAP - Yet Another Programmer)
eurosource, Brattbergavägen 17, 820 50 LOS, Sweden
Phone: (46) 657 413430 Cellular: (46) 73 84 84 102
Company home: http://www.eurosource.se      Kryddor/Te/Kaffe: http://www.brattberg.com
Personal homepage: http://www.eurosource.se/akhe
Automated home: http://www.vscp.org

2005\01\20@190156 by Jinx

face picon face
> If I now set a high prescaler on timer0 this works fine. The problem
> is that if I use a high prescaler value I get  to bad resolution. So I
> lower the prescaler and also count timer owerflows.  Now I just get
> very strange and random results.

Are you clearing TMR0 and the roll-over counter at each IRQ ?

2005\01\20@200556 by Jan-Erik Soderholm

face picon face
Ake Hedman wrote :

> I need to measure the duty cycle for a signal with a
> frequency between 1-4 kHz...

> I use an 18F258 running at 40MHz using HS-PLL (10MHZ resonator)  with
> the signal connected to INT0
>
> This is my thinking:
>
> For timing my worst case scenario is  a 4 kHz  signal  giving me 1250
> instruction cycles between interrupts. This sounds workable as  the
> interrupt only need to read and store a timer value.

But you also have the "timer0 overflow interrupts" to take are of, right ?

> By changing the trigger flank for the INT0  IRQ in the
> interrupt routine I can get interrupts both on the rising and the
> falling edge. I set up timer0 as a timebase  read the timer
> content on rising and falling edges of the signal.

Do you use 8 or 16 bit mode ?

Why not clear the timer on one of the edges, then you don't have
to subtract the two to get the time for (at least) one of the edges.

> Now I have something like 1250/2 cycles between worst
> case interrupt timing which I feel should be OK.
>
> If I now set a high prescaler on timer0 this works fine.

So all edges falls within one timer0 cycle, right ? That is, well
between two overflows ?

> The problem is that if I use a high prescaler value I get
> to bad resolution. So I lower the prescaler and also count timer
> owerflows.

How ? Using the timer0 overflow interrupt ?

> Now I just get very strange and random results.

How do you calculate the result ? How do you add the
count of overflows to the total ?
It should be something like :

<timer value> + X * <number of overflows>

X = 2**8 or 2**16 depending on if you use 8-bit or 16-bit
mode in tmr0.


> I can't figure out what I am doing wrong. The overflow interrupt from
> timer 0 will add to the interrupt frequency but not to bad.

And what do you *do* when the tmr0 overflow interrupt happens ?

Regards,
Jan-Erik.



2005\01\21@024858 by Ake Hedman

flavicon
face
Jinx wrote:

>>If I now set a high prescaler on timer0 this works fine. The problem
>>is that if I use a high prescaler value I get  to bad resolution. So I
>>lower the prescaler and also count timer owerflows.  Now I just get
>>very strange and random results.
>>    
>>
>
>Are you clearing TMR0 and the roll-over counter at each IRQ ?
>
>  
>
Yes I do that on the falling edge.

/Ake

--  ---
Ake Hedman (YAP - Yet Another Programmer)
eurosource, Brattbergavägen 17, 820 50 LOS, Sweden
Phone: (46) 657 413430 Cellular: (46) 73 84 84 102
Company home: http://www.eurosource.se      Kryddor/Te/Kaffe: http://www.brattberg.com
Personal homepage: http://www.eurosource.se/akhe
Automated home: http://www.vscp.org

2005\01\21@030441 by Ake Hedman

flavicon
face
Jan-Erik Soderholm wrote:

{Quote hidden}

yes of course.

{Quote hidden}

16-bit mode and I clear both the overflow counter and the timer on the falling edge.

{Quote hidden}

yes!

>>The problem is that if I use a high prescaler value I get
>>to bad resolution. So I lower the prescaler and also count timer
>>owerflows.
>>    
>>
>
>How ? Using the timer0 overflow interrupt ?
>
>  
>
Yes! I increase a value representing the MSB third byte of the counter value on each interrupt so i get
0verflow << 16 + timerh << 8 + timerl

{Quote hidden}

See above

>>I can't figure out what I am doing wrong. The overflow interrupt from
>>timer 0 will add to the interrupt frequency but not to bad.
>>    
>>
>
>And what do you *do* when the tmr0 overflow interrupt happens ?
>
>  
>
Just increase the overflow counter ans server other interrupts if there flags are active.

>Regards,
>Jan-Erik.
>
>
>  
>

Some extra info. If I use the ICD and check the interrupt sequence it looks like the INT0 interrupt is always active. I reset the flag by reading PORTB and have checked that it is reset. But I suspect this being a problem with the flag being set when the debugger has hit the breakpoint. Anyway if I step the interrupt routine after an overflow interrupt the INT0 flag is always active also.


General:

I am self employed and I often miss the thing you Jan-Erik and Jinx give now. You state your problem and someone ask intelligent questions giving a differnet view into the problem.. This is always much better then a strait answere.

/Ake










--  ---
Ake Hedman (YAP - Yet Another Programmer)
eurosource, Brattbergavägen 17, 820 50 LOS, Sweden
Phone: (46) 657 413430 Cellular: (46) 73 84 84 102
Company home: http://www.eurosource.se      Kryddor/Te/Kaffe: http://www.brattberg.com
Personal homepage: http://www.eurosource.se/akhe
Automated home: http://www.vscp.org

2005\01\21@033939 by Jinx

face picon face
> >Are you clearing TMR0 and the roll-over counter at each IRQ ?
> >
> Yes I do that on the falling edge.

Hmmm. OK, you think the values you get are "random". But are
they really - is there any kind of pattern or similarity ? Have you
looked at the difference between consecutive readings ? Is there
any change if you put TMR0 in 16-bit mode ? INT0 and TMR0
IRQ bits are all in INTCON - no mix-up with bit numbers ?

2005\01\21@035639 by Ake Hedman

flavicon
face
Jinx wrote:

>>>Are you clearing TMR0 and the roll-over counter at each IRQ ?
>>>
>>>      
>>>
>>Yes I do that on the falling edge.
>>    
>>
>
>Hmmm. OK, you think the values you get are "random". But are
>they really - is there any kind of pattern or similarity ? Have you
>looked at the difference between consecutive readings ? Is there
>any change if you put TMR0 in 16-bit mode ? INT0 and TMR0
>IRQ bits are all in INTCON - no mix-up with bit numbers ?
>
>  
>
Good (and helpful) questions. I shall do a double check on these parameters. You guys gave me some energy now again :-)

/Ake

--  ---
Ake Hedman (YAP - Yet Another Programmer)
eurosource, Brattbergavägen 17, 820 50 LOS, Sweden
Phone: (46) 657 413430 Cellular: (46) 73 84 84 102
Company home: http://www.eurosource.se      Kryddor/Te/Kaffe: http://www.brattberg.com
Personal homepage: http://www.eurosource.se/akhe
Automated home: http://www.vscp.org

2005\01\21@044957 by Jan-Erik Soderholm

face picon face
Ake Hedman wrote :

> So I lower the prescaler and also count timer owerflows.
> Now I just get very strange and random results.

Now, how do you know they are "strange and random"  ?
Or in other words, how are you "reading" those results ?
On an LCD ? Dumped on a serial line ?
Could it be some conversion problem between the internal
binary format and whatever "display" format you use now
that you get larger results ?

Regards,
Jan-Erik.



2005\01\21@052735 by Ake Hedman

flavicon
face
Jan-Erik Soderholm wrote:

>Ake Hedman wrote :
>
>  
>
>>So I lower the prescaler and also count timer owerflows.
>>Now I just get very strange and random results.
>>    
>>
>
>Now, how do you know they are "strange and random"  ?
>Or in other words, how are you "reading" those results ?
>On an LCD ? Dumped on a serial line ?
>Could it be some conversion problem between the internal
>binary format and whatever "display" format you use now
>that you get larger results ?
>
>  
>

I have an ICD 2 and  set a breakpoint in the main loop  where I do a calculation from a running mean of the sampled values every second. The results a "strange and random" (probaly not when I know why  as always :-) ) as they are not related to the actual  signal in any way (as seen on the scope and expected result).

But I will go over the code again (round 3275-- ;-) . Actually your posts  have helped me a lot already by not finding a big flaw in my thinking keeping my spitit up.

Does any one know if IRQ flags freezes when a breakpoint is hit using the ICD-2 debugger? This is what I would expect but practical results indicate that its not the case.

/Ake

--
---
Ake Hedman (YAP - Yet Another Programmer)
eurosource, Brattbergavägen 17, 820 50 LOS, Sweden
Phone: (46) 657 413430 Cellular: (46) 73 84 84 102
Company home: http://www.eurosource.se      Kryddor/Te/Kaffe: http://www.brattberg.com
Personal homepage: http://www.eurosource.se/akhe
Automated home: http://www.vscp.org

2005\01\21@054806 by Jan-Erik Soderholm

face picon face
Ake Hedman wrote :

> I have an ICD 2 and  set a breakpoint in the main loop  where I do a
> calculation from a running mean of the sampled values every
> second. The results a "strange and random" (probaly not when
> I know why  as always :-) ) as they are not related to the actual
> signal in any way (as seen on the scope and expected result).

OK. I see. I've never use any ICDx, so I've no idea what happens to
the timers and other "free-running" stuff when it hits a breakpoint.
I think I have seen something about problems to "debug" I2C and
similiar when using breakpoints and the ICDx, but I'm not sure.
Or was it interrupts ? Never mind...

But, I would guess that that info (that you use the ICD2 to read out
the values) could have been a great value to others if it had been
known earlier in the thread.

> But I will go over the code again (round 3275-- ;-).

What *I* would do in this case, would be to write up a short
test-case that only (more or less) has the duty cycle calculation.
Or are all those 3275 lines (or words) part of the calculation ?

Best Regards,
Jan-Erik.



2005\01\21@060035 by Jinx

face picon face
> I have an ICD 2 and  set a breakpoint in the main loop

Can't help with any ICD2 problems, but how about collecting
a block of values and then writing them to EEPROM ?

2005\01\21@060820 by Ake Hedman

flavicon
face
Jan-Erik Soderholm wrote:

{Quote hidden}

You misunderstood me here. Probably my fault... What I tried to say (write!) was that I have checked the code 3275 times all ready...

But as you say it's time to take it all apart and do check 3276... ;-)

Thanks for your kind help. Let you know what a I find....

/Ake

--  ---
Ake Hedman (YAP - Yet Another Programmer)
eurosource, Brattbergavägen 17, 820 50 LOS, Sweden
Phone: (46) 657 413430 Cellular: (46) 73 84 84 102
Company home: http://www.eurosource.se      Kryddor/Te/Kaffe: http://www.brattberg.com
Personal homepage: http://www.eurosource.se/akhe
Automated home: http://www.vscp.org

2005\01\21@060929 by Ake Hedman

flavicon
face
Jinx wrote:

>>I have an ICD 2 and  set a breakpoint in the main loop
>>    
>>
>
>Can't help with any ICD2 problems, but how about collecting
>a block of values and then writing them to EEPROM ?
>
>  
>
Very good idea. Haven't thought about that. Great. Thanks

/Ake

--  ---
Ake Hedman (YAP - Yet Another Programmer)
eurosource, Brattbergavägen 17, 820 50 LOS, Sweden
Phone: (46) 657 413430 Cellular: (46) 73 84 84 102
Company home: http://www.eurosource.se      Kryddor/Te/Kaffe: http://www.brattberg.com
Personal homepage: http://www.eurosource.se/akhe
Automated home: http://www.vscp.org

2005\01\21@062257 by Alan B. Pearce

face picon face
>OK. I see. I've never use any ICDx, so I've no idea what happens to
>the timers and other "free-running" stuff when it hits a breakpoint.
>I think I have seen something about problems to "debug" I2C and
>similiar when using breakpoints and the ICDx, but I'm not sure.
>Or was it interrupts ? Never mind...



Strange things do happen to the hardware peripherals when you stop the code
with an ICD. Interface things like I2C and UARTS send/receive corrupted
values, and timers keep running while the ICD code runs, resulting in weird
values in the timer if you are trying to set up specific intervals. Also if
you are single stepping, an interrupt will not fire off - you have to set a
breakpoint and let the program free run to allow the interrupt to happen.

To do reasonable debugging with an ICD, I found it good practice to set up
some labels specifically for setting breakpoints on the ICD, at points where
I knew that I/O things had properly completed, and one at a suitable point
inside the interrupt routine so I could see what was happening here. When
debugging inside the interrupt you can single step OK, and return to the
mainline code alright, but another interrupt will not fire off until you let
the processor free run again.

2005\01\21@065240 by Ake Hedman

flavicon
face
Alan B. Pearce wrote:

{Quote hidden}

Good info. Thanks Alan. Helps me a lot when I move further into this problem.

I find the ICD2 very useful most of the time and well worth its low cost. The lack of multiple breakpoints is the worst limitation in my opinion. Knowing things like this also helps.

/Ake

--  ---
Ake Hedman (YAP - Yet Another Programmer)
eurosource, Brattbergavägen 17, 820 50 LOS, Sweden
Phone: (46) 657 413430 Cellular: (46) 73 84 84 102
Company home: http://www.eurosource.se      Kryddor/Te/Kaffe: http://www.brattberg.com
Personal homepage: http://www.eurosource.se/akhe
Automated home: http://www.vscp.org

2005\01\25@095902 by Ake Hedman

flavicon
face
Though I give an update to my problem.

The problem was me nulling TMR0L before TMR0H on one of the edges.

I still don't understand what the differens is but reversing the order resolves my problem. If anyone know why this is like this I'm very interested to learn why!?

Thanks for all kind help!

/Ake

--  ---
Ake Hedman (YAP - Yet Another Programmer)
eurosource, Brattbergavägen 17, 820 50 LOS, Sweden
Phone: (46) 657 413430 Cellular: (46) 73 84 84 102
Company home: http://www.eurosource.se      Kryddor/Te/Kaffe: http://www.brattberg.com
Personal homepage: http://www.eurosource.se/akhe
Automated home: http://www.vscp.org

2005\01\25@101458 by Jan-Erik Soderholm

face picon face
Ake Hedman wrote :

> The problem was me nulling TMR0L before TMR0H on one of the edges.
>
> I still don't understand what the differens is but reversing
> the order  resolves my problem. If anyone know why this is
> like this I'm very interested to learn why!?

You should write the *high* byte before the *low* byte.
See the data sheet for details (section 11.4, page 111).

(And read the *low* byte before the *high*, if reading...)

Jan-Erik.



2005\01\25@103759 by Jan-Erik Soderholm

face picon face
He he, that was a bit short answer, wasn't it :-)

A better answer :

The high TMR0 byte is actualy a "shadow" register
that is read/written to the real TMR0 high byte
whenever the *low* byte is read/written.

So if you write the low byte first, the high byte will
be written with whatever was left over in the
shadow regsiter since last time. The current
write to the high byte will just update the shadow
register (and maybe be used as the high TMR0
value *next* time you update TMR0).

In the same way, you should *read* the *low*
byte first.

All this is to be able to make a full 16-bit read or
write at the same moment (while TMR0 is running).

That is, in short, what section 11.4 in the data sheet says...

Jan-Erik.



Jan-Erik Soderholm wrote :

> You should write the *high* byte before the *low* byte.



2005\01\25@112832 by Ake Hedman

flavicon
face
Jan-Erik Soderholm wrote:

{Quote hidden}

I will never forget that again... Promise... (I must admit there is a small memory fragment of it somewhere deep inside ) ;-)   As usual there is a simplistic solution to a problem that  have taken a lot of time from the project. And in this case just RTFM.... Strange really why one sell dome spend more then budgeted time with the hard parts but underestimate the easy parts...

Thanks again!

/Ake

--  ---
Ake Hedman (YAP - Yet Another Programmer)
eurosource, Brattbergavägen 17, 820 50 LOS, Sweden
Phone: (46) 657 413430 Cellular: (46) 73 84 84 102
Company home: http://www.eurosource.se      Kryddor/Te/Kaffe: http://www.brattberg.com
Personal homepage: http://www.eurosource.se/akhe
Automated home: http://www.vscp.org

2005\01\25@113055 by Ake Hedman
flavicon
face
Jan-Erik Soderholm wrote:

{Quote hidden}

No need to look up the section then. Thanks. Now I understand why and also why it makes sense.

/Ake

--  ---
Ake Hedman (YAP - Yet Another Programmer)
eurosource, Brattbergavägen 17, 820 50 LOS, Sweden
Phone: (46) 657 413430 Cellular: (46) 73 84 84 102
Company home: http://www.eurosource.se      Kryddor/Te/Kaffe: http://www.brattberg.com
Personal homepage: http://www.eurosource.se/akhe
Automated home: http://www.vscp.org

More... (looser matching)
- Last day of these posts
- In 2005 , 2006 only
- Today
- New search...