TMR1 Compare not matching 0x0000 ?

Log in or register to post comments
Go To Last Post
7 posts / 0 new
Author
Message
nallic
nallic's picture
Level: New Member
Joined: Mon. May 22, 2006
Posts: 7 View posts
Location: Denmark
#1
Posted by nallic: Thu. Jan 24, 2008 - 05:29 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello,

Im using an AT mega88, and in AVRstudio I dont get a match on CompareB when running in normal mode, if the compare register is 0x0000. Is this the way its supose to be ? - I can se there is some issues in the datasheet when setting TMR1 to TOP or BOTTOM in some of the PWM modes, but in normal mode, there should not be anything special about zero?

I am generating a signal, by interrupts and then add an offset to the TCNT1 value and store it in OCR1B. I do not at any time store in TCNT1

I have only tested in AVRstudio simulations - not on real hadware.

Am I missing a point somewhere ?

Sincerely Per Hansen

Tags:

AVR Microcontrollers, megaAVR and tinyAVR, ATmega8, ATmega88
Top
Bronze Marktheusch
theusch's picture
Level: 10k+ Postman
Joined: Mon. Feb 19, 2001
Posts: 39996 View posts
Location: Wisconsin USA
Posted by theusch: Thu. Jan 24, 2008 - 05:36 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It could very well be the simulator.

You could also use overflow instead to match at 0.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Top
nallic
nallic's picture
Level: New Member
Joined: Mon. May 22, 2006
Posts: 7 View posts
Location: Denmark
Posted by nallic: Thu. Jan 24, 2008 - 05:48 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I suspect it might be the simulator. But I just wanted to assure I didn't do something wrong.

The OCR1B is loaded with 0 by coincidence sometimes, when TCNT1+offset adds up to zero (0xFFFF+1). So OVF interrupts wont work.

If the Compare interrupt does not occur, the next event will not be setup either - so its critical in my application that there is a match every time, no matter what value OCR1B has. But I could of cause check before writing to OCR that the value is not 0. It happens in an interrupt though, so I want to keep it small and fast.

Sincerely Per Hansen

Top
Gold Markclawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 101081 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Thu. Jan 24, 2008 - 05:50 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As it's an 88 it is Dragon-able, that's a far better way of "simulating" than relying on some half baked software simulation (roll on the full implementation of Simulator V2!)

Top
GroovBird
GroovBird's picture
Level: New Member
Joined: Wed. Dec 5, 2007
Posts: 18 View posts
Posted by GroovBird: Thu. Jan 24, 2008 - 07:46 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I ran across a problem with my code a while ago, and it was something similar. It does match on 0x0000, but it needs to roll over first.

I suspect the reason is that the comparison is done every time the timer counts, *after* it has incremented the counter value. That would mean that if the counter started from 0, it wouldn't be compared yet, but it would be compared the next time, when it becomes 1. But then it wouldn't match, of course.

I'm sure the solution is to either initialize the counter to 0xFFFF before starting the timer.

Dave

Top
Lajon
Lajon's picture
Level: Raving Lunatic
Joined: Fri. Mar 12, 2004
Posts: 2606 View posts
Location: Linköping, Sweden
Posted by Lajon: Fri. Jan 25, 2008 - 07:37 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
then add an offset to the TCNT1 value and store it in OCR1B.
Not that I know exactly what you are doing but if possible you should not offset from TCNT1 but instead from the previous compare value like:

OCR1B += offset;

That way the timing will not be affected by interrupt latency.
/Lars

Top
nallic
nallic's picture
Level: New Member
Joined: Mon. May 22, 2006
Posts: 7 View posts
Location: Denmark
Posted by nallic: Sun. Jan 27, 2008 - 12:16 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Lajon: You are right about that point. It is not critical in my application though, but still its the right way to do it.

I dont yet have the hardware to try it on. But im hoping the problem is a simulator bug - or a bug somewhere in my code.

/Per

Top