Support for ATmega169*

[kolbma]

I'm currently working on adding support for the ATmega169* mcus in my atmega169p branch.

Now I came to a problem, maybe a misunderstanding, I'm in hope you could clarify...

Shouldn't this

lcdcra.write(|w| w.lcdie().set_bit());

has the same result like

lcdcra.modify(|_, w| w.lcdie().set_bit());

???
I'm thinking of it would set the single LCDIE bit to 1 and all other bits have the same value like before.

And if not, why not, or what is the purpose of lcdcra.write_with_zero(|w| w.lcdie().set_bit()) then?
lcdcra.write(|w| w.lcdie().set_bit()) and lcdcra.write_with_zero(|w| w.lcdie().set_bit()) seems to do here the same.
It sets only the single bit and all other controlable bits to 0.
At least for this register. The LCDCRA and LCDCCR are the only ones I have a problem with the nulling so far.
Did I anything wrong in patching?
I'm checking this with the old atmega169 (out of support and so no atdf provided). I've copied and modified the atmega169p.atdf file for the changes between the two.

[Rahix]

.write() and .modify() are fundamentally different operations:

• .write() writes the entire register to its reset-value except the bits which were explicitly changed in the closure.
• .modify() is a read-modify-write operation. First, the register is read, then all changes from the closure are applied to the value and then it is written back.

Also see this comment and the svd2rust API Documentation.

[kolbma]

@Rahix Ok, thx, I think I got in conflict with the .write_with_zero(). But yes reading all API docs to the methods makes it clear.

[Rahix]

Closing this issue because I think the original question is resolved. Feel free to open a new issue if there is more to discuss regarding ATmega169.

[kolbma]

@Rahix ok. I'm still waiting for a working llvm/rustc on the AVR platform. Stumbled on this floating point division bug and went back to gcc-avr.