Forum breadcrumbs - You are here:ForumGeneral: Report BugsATmega8 and PWM
You need to log in to create posts and topics.

ATmega8 and PWM

Hi,

(Trunk version 2259, Windows 7, 32)

I attached the example ‘ATmega8_PWM_01.zip‘, so that the following could be verified:

; 10-bit Fast PWM, Compare Output Mode
; OC1A disconnected, Normal port operation.
; Set OC1B on Compare Match, clear OC1B at BOTTOM, (inverting mode)
; MCU clk / 64 , 0.125 us * 64 = 8 us

Case_1: OCR1BH\L = 1023 (10-bit maximum).
In real, OC1B (PB2) is low always.
SimulIDE, a high pulse (8us) occurs at the end of the PWM period.

Case2, OCR1BH\L = 1024 (10-bit maximum + 1).
In real, OC1B (PB2) is high always; OCR1BH\L becomes 1024 & 0x03FF (zero).
SimulIDE, OC1B (PB2) is low always.

Regards,
Kerim

Uploaded files:

Hi.

Some of this is already solved, you can try last build for 1.1.0:
https://simulide.com/p/testers/

Case 1 now is working as you describe: PB2 always low.
But I don't see how case 2 should be always High:
Compare match never happens, so why PB2 should go High?

Quote from arcachofo on September 25, 2024, 7:42 pm

But I don't see how case 2 should be always High:
Compare match never happens, so why PB2 should go High?

After the user sets OCR1BH\L to 1024 (0x0400), the MCU follows the following rule (from datasheet):

Note that when using fixed TOP values the unused bits are masked to zero when any of the OCR1x Registers are written.

Therefore, OCR1BH\L becomes 0x0000 (since the TOP here is 0x03FF) and PB2 (in the inverting mode) becomes high always while following another note:

If the OCR1x is set equal to BOTTOM (0x0000) the output will be a narrow spike for each TOP+1 timer clock cycle.

In the case here (8 MHz), it is a 125ns low pulse.

 

Thank you, that helps.

I didn't really undertand this:
"Note that when using fixed TOP values the unused bits are masked to zero when any of the OCR1x Registers are written."

I suppose that the masking is only done for the compare purpose.
I mean the actual values in memory remain 1024.
Or are the registers actually cleared?

Also you reported:
"Case2, OCR1BH\L = 1024 (10-bit maximum + 1).
In real, OC1B (PB2) is high always;"

I guess it was a typo, can you confirm that with OCR1B=1024 you get a 125ns (one clock cycle) spike?

 

Quote from arcachofo on September 26, 2024, 11:56 am

I didn't really understand this:
"Note that when using fixed TOP values the unused bits are masked to zero when any of the OCR1x Registers are written."

I suppose that the masking is only done for the compare purpose.
I mean the actual values in memory remain 1024.
Or are the registers actually cleared?

I verified this by using AVR Studio simulator. The registers OCR1BH\L are actually cleared since the 10-bit TOP here is 0x03FF. Therefore 0x0400 (1024) & 0x03FF = 0x0000.

Quote from arcachofo on September 26, 2024, 11:56 am

Also you reported:
"Case2, OCR1BH\L = 1024 (10-bit maximum + 1).
In real, OC1B (PB2) is high always;"

I guess it was a typo, can you confirm that with OCR1B=1024 you get a 125ns (one clock cycle) spike?

You are right, it was a typo. Thank you.

Since, in real, OCR1BH\L=1024 becomes 0x0000, we get also a 125ns low spike; that is OC1B is not high always.

 

Thank you.

I verified this by using AVR Studio simulator. The registers OCR1BH\L are actually cleared since the 10-bit TOP here is 0x03FF. Therefore 0x0400 (1024) & 0x03FF = 0x0000.

This seems a little bit weird to me.
Let's say that Timer1 is configured as "Normal":  WGM = 0000, and OCR1B = 1024.
Then we configure as Fast PWM, TOP = 0x03FF: WGM = 0111, so OCR1B is cleared.
Now we change it back to Normal...
What happens with OCR1B? it remains 0?

Also the datasheet says:
"the unused bits are masked to zero when any of the OCR1x Registers are written."
So if OCR1B is writen first and later the Timer is configured to fixed TOP values, then... is OCR1B masked?
Supposedly it should not be be masked since it is masked when it is writen...

 

Quote from arcachofo on September 29, 2024, 11:24 am

Thank you.

I verified this by using AVR Studio simulator. The registers OCR1BH\L are actually cleared since the 10-bit TOP here is 0x03FF. Therefore 0x0400 (1024) & 0x03FF = 0x0000.

This seems a little bit weird to me.
Let's say that Timer1 is configured as "Normal":  WGM = 0000, and OCR1B = 1024.
Then we configure as Fast PWM, TOP = 0x03FF: WGM = 0111, so OCR1B is cleared.
Now we change it back to Normal...
What happens with OCR1B? it remains 0?

Also the datasheet says:
"the unused bits are masked to zero when any of the OCR1x Registers are written."
So if OCR1B is writen first and later the Timer is configured to fixed TOP values, then... is OCR1B masked?
Supposedly it should not be be masked since it is masked when it is writen...

What happens with OCR1B? it remains 0?

You are right to be confused. It is not clear if the masking of the unused bits is independent of OCR1B or not. I will try to check this on a real board in my next test.

I tend to think that once it is masked it loses its original value (this reduces the internal MCU hardware)

It's difficult to guess what is realy happening and what is the real circuit in there.
It would be great if you can do some tests and solve the mistery.
At this moment I have no chance to test it myself.

In general I consider 2 cases:

1- Masking before the Latch (at the input):
- The masking is performed at write time.
- This will ovewrite the actual value.
- It is consistent with your test with AVR Studio simulator.
- It is cosistent with the datasheet: "the unused bits are masked to zero when any of the OCR1x Registers are written".

My problem with this:
- If you first write a value and later change the Timer configuration to PWM fixed value, then the value should not change unless there is a circuitry that ovewrites the original value (perform a write operation).

- If you write a value in PWM fixed value mode, it is masked and the value lost. If now you change mode you need to write the value again AFTER changing mode.

2- Masking after the Latch (at the output):
- The masking is performed at read time.
- This will NOT ovewrite the actual value.
- It is consistent with your test with AVR Studio simulator.

This will keep the original value in memory in any case.
It is not consistent with the datasheet, but this happens all the time.

I think you are right too.

In other words, the internal fixed TOP register also plays the mask as in your case 2.