(0 << bitPosition) What?

I’ve seen that construct - and the related (0 << bitPos1) & (0 << bitPos2) etc - used a few times in code that people have posted, and TBH I’ve always thought it was just noobs being noobs.

Anyway, yesterday I needed to use the Watch Dog Timer so I started reading that section of the datasheet, and I came across the following nugget right in the official atmel datasheet.

codeEample.jpg

This really surprised me. So now I’m wondering if I’ve been wrong all along? Or perhaps there’s a parallel universe with a different compiler/pre-processor where that isn’t just an obscure way of writing zero?

No you are right, this is just plain wrong and a bug in the ATMEL datasheet

Atmel confirmed the error and the need to change toandi r16,(0xff - (1<<wdrf))

You can read this discussion where this is mentioned (or here too)

J-M-L:
No you are right, this is just plain wrong and a bug in the ATMEL datasheet

Atmel confirmed the error and the need to change to

andi r16,(0xff - (1<<wdrf))

Thanks J-M-L. :slight_smile:

Yes I would normally use “andi r16, ~(1<<wdrf)” there, but basically the same thing. It’s amazing how pervasive that error is about shifting zero to clear bits though, to even find it’s way into the datasheet. :o

stuart0:
It's amazing how pervasive that error is about shifting zero to clear bits though, to even find it's way into the datasheet. :o

Yeah, what happens in the Internet stays in the Internet for a looooooong time.. So always good to use judgement the way you demonstrated. :slight_smile:

Delta_G:
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 [color=red]&[/color] (0 << wdrf)) there is a AND mask [color=red]&[/color] being done, so it’s not just setting that specific bit to 0 but the whole r16… probably was not the intended idea

J-M-L:
yes - but in the case of andi r16,(0xff [color=red]&[/color] (0 << wdrf)) there is a AND mask [color=red]&[/color] 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 |=

Delta_G:
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 |=

fair enough - yeah ORing is fine

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.

RayLivingston:
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.

Indeed - as always, as long as you understand what you do then all is fine :slight_smile: