Hi,

On page 245 of the ATmega328 datasheet it says

Bit 7    6    5    4    3    2    1    0
    RXC0 TXC0 UDRE0 FE0 DOR0 UPE0 U2X0 MPCM0
Access R   R/W   R   R   R   R   R/W   R/W
Reset  0    0    1    0    0    0    0    0

For the frame error, data overrun and parity error bits it also says to always set them to zero when writing to UCSR0A, but they are all read-only. So I should only ever write xxx000xx to this register. But what does it matter if they are read-only?

 

Hi,

On page 245 of the ATmega328 datasheet it says

Bit 7    6    5    4    3    2    1    0
    RXC0 TXC0 UDRE0 FE0 DOR0 UPE0 U2X0 MPCM0
Access R   R/W   R   R   R   R   R/W   R/W
Reset  0    0    1    0    0    0    0    0

For the frame error, data overrun and parity error bits it also says to always set them to zero when writing to UCSR0A, but they are all read-only. So I should only ever write xxx000xx to this register. But what does it matter if they are read-only?

To answer this question you would need to see the Atmel design documents to see how the register is implemented in silicon. IMHO if they give you a recomendation like this you follow it without question. Maybe someone more in tune with chip design would have greater insight.

 

So read-only doesn't mean per se that it's enforced.

 

No, it means there is nothing meaningful to write and we'd prefer 0's on the data bus when you do write the register to the alternative for some unspecified reason which we are not going to bother explaining. If I had to guess the reason it would be that the input to those bits from the hardware is done with a gate for which a zero input does not change the result and chip designers do not like unterminated inputs. For example data bus lines that have no destination.

 

For the frame error, data overrun and parity error bits it also says to always set them to zero when writing to UCSR0A,

Are you sure it says YOU should zero them? I would expect it to zero them automatically if they ate RO.

Edited: Just read it. It says they shoukd be written zero for compatibility with future implementations. Meaning they might change it a way that it would not work in a future chip.

 

Hi,

On page 245 of the ATmega328 datasheet it says

Bit 7    6    5    4    3    2    1    0
    RXC0 TXC0 UDRE0 FE0 DOR0 UPE0 U2X0 MPCM0
Access R   R/W   R   R   R   R   R/W   R/W
Reset  0    0    1    0    0    0    0    0

For the frame error, data overrun and parity error bits it also says to always set them to zero when writing to UCSR0A, but they are all read-only. So I should only ever write xxx000xx to this register. But what does it matter if they are read-only?

Make sure your datasheet matches your MCU. Datasheet is for Atmega328P. You're clearly misunderstanding what they are telling you to do. When I look at page 245 on document you post, I get this:

 

Make sure your datasheet matches your MCU. Datasheet is for Atmega328P. You're clearly misunderstanding what they are telling you to do. When I look at page 245 on document you post, I get this:

Apologies for the confusion. On my PC I have a different, presumably older revision and did not bother to check the datasheet I linked. On the linked sheet the relevant bits are on page 159.

Just read it. It says they shoukd be written zero for compatibility with future implementations. Meaning they might change it a way that it would not work in a future chip.

I found the section you are referring to, thanks. Though this still confuses me:

Another equality for the Error Flags is that they can not be
altered by software doing a write to the flag location. However, all flags must be set to zero when the
UCSRnA is written for upward compatibility of future USART implementations.

Is "flags must be set to zero" the device itself doing the setting? If I write 11111111 to the register, will the read-only bits be ignored?
Edit: To expand on that, I cannot change the bits by writing to it ("alter by software") but when I do write to it it must be zero. This seems conflicting to me.
Edit2: Nevermind, I get it now given what you said in post #5, thanks againg BobTPH.