TMR1 Compare not matching 0x0000 ?

Go To Last Post
7 posts / 0 new
Author
Message
#1
  • 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

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

  • 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

  • 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!)

  • 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

  • 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

  • 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