andi r16,(0xff - (1<<wdrf))
No you are right, this is just plain wrong and a bug in the ATMEL datasheetAtmel confirmed the error and the need to change toCode: [Select]andi r16,(0xff - (1<<wdrf))
It's amazing how pervasive that error is about shifting zero to clear bits though, to even find it's way into the datasheet.
Sometimes I use something like that just for a place holder. Say I'm setting up a timer register, I might list every bit in the register, even the ones I'm not setting, and just put 0 in for the ones that I am leaving as 0. That way if I come back later and want to change a prescaler or some other bit all I have to do is change a 0 to a 1 and I don't have to go look up the name of the bit in the register or anything.
yes - but in the case of andi r16,(0xff & (0 << wdrf)) there is a AND mask & being done, so it's not just setting that specific bit to 0 but the whole r16... probably was not the intended idea
Yeah, I realized that after I typed and pulled my comment. This isn't the same as what I was talking about where they'd all be |=
In this context:Something = SomethingElse & (0 << WDRF);is, in a word stupid, as the entire expression evaluates to zero regardless of the values of SomethingElse or WDRF. In this context:Something = (1 << ABCD) | (0 << EFGH);I can see some logic to it as a means of documenting that the bit ABCD is being set, while bit EFGH is NOT being set. If it is instead desired to also set but EFGH, then simply change the 0 to a 1. This is not an uncommon practice, and does make clear what the intent of the operation is.Regards,Ray L.
Please enter a valid email to subscribe
We need to confirm your email address.
To complete the subscription, please click the link in the
email we just sent you.
Thank you for subscribing!
via Egeo 16