Hi all.
Something wrong with my eyes,what changed in val1 after masking?
val1 = 0x1ABCDEF2, applying mask 0x1ABCDEF2
Before and after masking is the same values?
Sorry val1 is already 29 BITS nothing to mask off.
My BAD!
noiasca:
we don't know why you struggle at that topic.
But you could put the posted codes in your Arduino and try to follow what we are saying.so, mask the 32bit variable with
0b00011111111111111111111111111111
and you will see, that the first 3 bits are gone.
Yeah, sometimes they are gone, sometimes not. But it always alters the value I would like to mask
BetaCarotin:
Yeah, sometimes they are gone, sometimes not. But it always alters the value I would like to mask
Masking works. So you are doing something else wrong.
sherzaad:
It's YOU who FAILS TO UNDERSTAND!!!!
The masking suggested WORKS!!!
Here's another example code to demostrate it:const uint32_t BIT_MASK_29Bits = 0x1fffffff;
void setup() {
uint32_t val1 = 0x1abcdef2;
uint32_t val2 = 0xff456789;
Serial.begin(115200);
Serial.print("val1 = 0x");
Serial.print(val1, HEX);
Serial.print(", applying mask 0x");
Serial.println(val1 & BIT_MASK_29Bits, HEX);
Serial.print("val2 = 0x");
Serial.print(val2, HEX);
Serial.print(", applying mask 0x");
Serial.print(val2 & BIT_MASK_29Bits, HEX);
}
void loop() {
// put your main code here, to run repeatedly:
}
and the result:val1 = 0x1ABCDEF2, applying mask 0x1ABCDEF2
val2 = 0xFF456789, applying mask 0x1F456789As you can see, in val2, the 3 most significant bits WERE MASKED
Lets stick to your first example before you get more confused.
I enter a 32 bit variable, lets say with all bit set to 1 for the fun of it. This will be:
FFFFFFFF (8fs) or beter in Binary: 11111111111111111111111111111111 or 4294967295 in dec
What I want is to cut of the first three bits! Now pay attention please, this will get you:
11111111111111111111111111111 (29bits) or easier to read: 00011111111111111111111111111111
And this will translate to: 1FFFFFFF or 536870911
Do you see now that your suggested bit masking is wrong? It does not deliver 1FFFFFFF so it does not do the right thing. Easy as that.
The OP will be all set if they ever program in a language with bit shifting but no nonsense like this logic masking stuff.
Shift right 3 shift left 3 boom!
Clever, effective and evidently easier to grasp.
On the other hand, I estimate you are looking at a combined experience with perfectly functioning bit masking of several thousand programmer-years, so:
Yeah, sometimes they are gone, sometimes not. But it always alters the value I would like to mask
isn't working for us: post code that clearly demonstrates these wild assertions. IF there is some problem you've managed to stumble across, we'd better know about it. And get it fixed at whatever level it needs fixing. On.
a7
alto777:
The OP will be all set if they ever program in a language with bit shifting but no nonsense like this logic masking stuff.Shift right 3 shift left 3 boom!
Clever, effective and evidently easier to grasp.
On the other hand, I estimate you are looking at a combined experience with perfectly functioning bit masking of several thousand programmer-years, so:
isn't working for us: post code that clearly demonstrates these wild assertions. IF there is some problem you've managed to stumble across, we'd better know about it. And get it fixed at whatever level it needs fixing. On.
a7
Thanks.
alto777:
The OP will be all set if they ever program in a language with bit shifting but no nonsense like this logic masking stuff.Shift right 3 shift left 3 boom!
Clever, effective and evidently easier to grasp.
On the other hand, I estimate you are looking at a combined experience with perfectly functioning bit masking of several thousand programmer-years, so:
isn't working for us: post code that clearly demonstrates these wild assertions. IF there is some problem you've managed to stumble across, we'd better know about it. And get it fixed at whatever level it needs fixing. On.
a7
I am somehow really tired of this standard reply "post code", I would like to reply "read the question". Every code needed has been posted. I made my point clear. You just use the code posted and check if it can turn 8F into 1FFFFFFF, If it does not (and I have also posted it, and the author aditted happily taht it does not) than the function- whatecer 35 year old magic it holds, is NOT WORKING.
I am out of this discussion now- have fun with posting code and congrating yourselves for not getting the point.
There is an axiom, "extraordinary claims require extraordinary evidence". You're asking us to believe that something that has been in wide application for at least 50 years, in millions of programs, is flawed. Most people would want to see some hard evidence. A reproducible example is not too much to ask.
The example you posted was flawed, and it was explained to you why it was flawed. Reply #17 presented an actual working counter-example which proved that you are wrong.
Funny, it works when you set it up correctly:
uint32_t y = 0xffffffff;
Serial.println(y, HEX);
y = y & 0x1fffffff;
Serial.println(y, HEX);
Anyway, it is the same with datasheets, libraries and webforums. When you are able to understand the answer/information you dont need it. For people searching to actually understand what is going on this is no help.
I am out of this discussion now...
Promise? We ready to give up on you, too.
a7
I enter a 32 bit variable, lets say with all bit set to 1 for the fun of it. This will be:
FFFFFFFF (8fs) or beter in Binary: 11111111111111111111111111111111 or 4294967295 in dec
What I want is to cut of the first three bits! Now pay attention please, this will get you:
11111111111111111111111111111 (29bits) or easier to read: 00011111111111111111111111111111
And this will translate to: 1FFFFFFF or 536870911
Do you see now that your suggested bit masking is wrong? It does not deliver 1FFFFFFF so it does not do the right thing. Easy as that.
the example I've provided in #10 does exactly this.
If you still can't believe that masking works bullet proof, I suggest you come up with code
One more try to explain it:
11111111111111111111111111111111 // the "Input"
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // the Operator
00011111111111111111111111111111 // the "Bitmask"
00011111111111111111111111111111 // the Result
alto777:
The OP will be all set if they ever program in a language with bit shifting but no nonsense like this logic masking stuff.Shift right 3 shift left 3 boom!
How is this logic masking stuff "nonsense"? What if you need to mask 31st and 29th bit? How would shifting solve that vs masking with 0x5fffffff?
I totally give up on this thread...
alto777:
Promise? We ready to give up on you, too.a7
No, I love too much beeing the grain in the gears and challenge you
BetaCarotin:
Thanks.I am somehow really tired of this standard reply "post code", I would like to reply "read the question".
The request to post a clean, complete code that demonstrates the problem (and only the problem) is not an onerous one. Especially given the extraordinary claim you're making.
So, let's see your MRE. Any thing is possible, but Occam's Razor suggests that you've screwed it up.
BetaCarotin:
I tried & and | but I end up with weird results
{drums fingers impatiently}
TheMemberFormerlyKnownAsAWOL:
{drums fingers impatiently}
Guys, I already admitted it works.
Do you want me to suffer?
Ok Ok
Yes bitmasking works, again? Yes your soliution works
again? No- the example you made and the way it had not been explained did not help
So back to case:
Does bit masking actually check the values stored in the variable?
Or does it just aply on the adress or pointer?
Because when you use masking in the explanaitions it looks like it is altering the stored variable (0,1) not the appearance of that bit in general
So, YES you get your code:
101 & 010 = ?
4 & 2 = 2?
How does that take away bits? Because what will happen when my beloved 29bits payload contain also 0. Will tehy also been taken away ?
Thats what I dont wnat.
And why is that an odd demand? I looks like everyone is snipping bits all day long but nobody cares about explaining it- obviousley because it is a no brainer ? So, enlighten me 
It's a simple bitwise AND.
It doesn't "check" anything.
Simple truth table
A B O
0 0 0
0 1 0
1 0 0
1 1 1
4 & 2 = 0
101 & 010 = 0 (both in binary and your specified octal)
I don't recommend the bitwise AND on pointers.
Still trying to figure bit masking out, Wow.
Anyways.
About those leading zeros.
What's the difference between these numbers and the effect of leading zeros on your precious?
1b = ?
01b = ?
001b = ?
0001b = ?
00001b = ?
000001b = ?
0000001b = ?
00000001b = ?
0000000000000000000000000000000000000000000000000000001b = ?
Idahowalker:
Still trying to figure bit masking out, Wow.Anyways.
About those leading zeros.
What's the difference between these numbers and the effect of leading zeros on your precious?
1b = ?
01b = ?
001b = ?
0001b = ?
00001b = ?
000001b = ?
0000001b = ?
00000001b = ?
0000000000000000000000000000000000000000000000000000001b = ?
Yes, and I still dont get it.
uint32_t y = 0xFFFFFFF8;
Serial.println(y, HEX);
y = y & 0x1fffffff;
Serial.println(y, HEX);
I am entering: 11111111111111111111111111111000 into this
I expect 00011111111111111111111111111000 to come out of it
That works. But why? Whu are the lest significant zeros not also affected by bit masking as the most significat positions are altered by ANDing them with 11111111111111111111111111111
Why does it work?!
I dont need leading zeros, I just need to make sure that my datatype only contains 29bits. Thats why I asked how to cut datatypes.
like :
received29bit= cutOut(received,0,29);
Same problem by the way with assembling a 29bit long message out of single bytes, as because of word() only holds 16bit
I genuinely do not know what you are asking.