C Bit Assigning

[Suraj143]

I have another bit assigning problem with C.

I have a variable called Temp.I need to seperate its 8 bits into different PORT bits.

PORTB.B0 = Temp & 0b00000001;

PORTB.B2 = Temp & 0b00000010;

PORTC.B5 = Temp & 0b00000100;

PORTA.B6 = Temp & 0b00001000;

Is my method ok?

 

[Pommie]

Looks good to me. I don't know a better way.

Mike.

 

[Jon Wilder]

Can't you do it with the "volatile bit" directive as well?

 

[wkrug]

@Suraj143
It will work.
The point into the variable name isn't a good choice. Some compilers use it to seperate a variable name from a choosen bit in it.
But be warned, in your variables are stored the values 1, 2, 4, 8 an so on.
So, when testing don't test for 1 - if(PORTB_B2==1) - instead test for greater 0 - if(PORTB_B2>0) -.

Another possible writing is:
PORTC_B5 = Temp & (1<<2);

volatile bit PORTC_B1 ; Defination as bit
When using bit variables you have to set it with an if argument if((temp&0b00000001)>0){PORTC_B1=1;}
But this can help to save RAM space.

 

[3v0]

A bit of clarification for people new to c.

0 is false. Any other value is true.

So it is always safe to test for ==0 ane !=0 as wkrug indicated.

 

[Pommie]

In the light of day, I'm going to doubt my answer. Some compilers will cast a byte value to a bit by simply taking bit 0 of the byte. So you need to try it with your compiler. You may need,

PORTB.B0 = ((Temp & 0b00000001)!=0);

or

PORTB.B0 = (Temp & 0b00000001)? 1:0;

Mike.

 

[Mr RB]

This is still writing single bits to the port (the compiler will use BSF or BCF), which is in risk of a "read modify write" error that PICs are famous for.

A better system would be to use a shadow register for any output port, and manipulate the pits int he shadow register and then write the whole 8bit shadow register to the port. Once you have done the shadow register code I think the original problem would have been sorted.

 

[lebevti]

never knew about specifying the bits explicitly with b

ive always used hex, e.g., 0x0001, 0x0002, 0x0004, 0x0008, 0x0010, 0x0020, etc...

learn something new everyday

 

[Suraj143]

Ok guys thanks for the help.

I like to do as wkrug suggested.

PORTC.B5 = Temp & (1<<2);

@ Mike

PORTB.B0 = ((Temp & 0b00000001)!=0);

I can't understand whats that "!=0".I know it is not equals to zero but how the math does?

 

[3v0]

!= is a comparison so

(value != 0)

returns a 1 if the value is not zero and these give the same result

if (value) ...

if (value != 0) ...

 

[misterT]

I have another bit assigning problem with C.

I have a variable called Temp.I need to seperate its 8 bits into different PORT bits.

PORTB.B0 = Temp & 0b00000001;

PORTB.B2 = Temp & 0b00000010;

PORTC.B5 = Temp & 0b00000100;

PORTA.B6 = Temp & 0b00001000;

Is my method ok?

You could also use:

PORTB.B0 = (Temp & 0b00000001) ? 1 : 0;
PORTB.B2 = (Temp & 0b00000010) ? 1 : 0;
// etc.

I don't actually understand the question "Is my method ok". If it works, it is ok. Did you have some kind of trouble using your own method, or are you just insecure?
I don't know if the "PORTB.B0" expression is correct. It is not ANSI C, but some compilers implement extra features for convenience. What compiler do you use?

 

[Suraj143]

I use mikroC.

I have a doubt with the below statement.

PORTB.B0 = ((Temp & 0b00000001)!=0);

Will it write to PORTB.B0 if it is zero? or will it write to PORTB.B0 only if not zero? because it uses !=0 not equal to zero comparison.

 

[Suraj143]

Sorry MisterT I never use below method what you have mentioned.

? 1 : 0;

 

[Ian Rogers]

I use mikroC.

I have a doubt with the below statement.

PORTB.B0 = ((Temp & 0b00000001)!=0);

Will it write to PORTB.B0 if it is zero? or will it write to PORTB.B0 only if not zero? because it uses !=0 not equal comparison.

It will work ok if you drop the " !=0" at the end.... (Temp & 0b00000001) will return true (1) if Temp.0 = 1, and false if Temp.0 = 0

It wont work if you don't drop the "!=0" at the end.... (Temp & 0b00000001) returns true which isn't 0 (!=0), and true as well if (Temp & 0b00000001) returns false which IS != 0.

 

[Pommie]

It will work ok if you drop the " !=0" at the end.... (Temp & 0b00000001) will return true (1) if Temp.0 = 1, and false if Temp.0 = 0

It wont work if you don't drop the "!=0" at the end.... (Temp & 0b00000001) returns true which isn't 0 (!=0), and true as well if (Temp & 0b00000001) returns false which IS != 0.

Sorry Ian, Temp & 0b00000001 returns 1 or 0, Temp && 0b00000001 returns True or False. However, Temp && 0b00000001 with Temp=128 will return true which is not the desired result. (They are both non zero)

The next line is also a problem,

PORTB.B2 = Temp & 0b00000010;

It will return 2 or 0. Some compilers when casting a byte to a bit simple use the bottom bit and so this will also be wrong.

Changing to,

PORTB.B2 = ((Temp & 0b00000010)!=0);

Will return True if the bit is set and so will work.

Mike.

 

[Ian Rogers]

Ok Pommie.. but every C compiler I've worked with states the a 0 is false ANYTHING else is true... If the compiler tries to assign an integer, will not generate a warning it will set the bit to true. I think the ambiguity is with c++ compilers... they DO need the correct syntax.

But the test has to be (Temp & 0x01) other wise the option that Mister T applied.

 

[Pommie]

But you are not doing a boolean operation, you are doing a bitwize AND so it doesn't return Ture/False but 0,1,2,4,8,16 in these cases.

I just did this in HiTech C (I don't have MikroC),

    Temp = 0b00000010;
    RC0=Temp & 0b00000010;          //RC0=0 wrong
    RC0=((Temp & 0b00000010)!=0);   //RC0=1 correct
    RC0=(Temp & 0b00000010)?1:0;    //RC0=1 correct
    RC0=(Temp && 0b00000010)?1:0;   //RC0=1 correct but see below
    Temp=0b00000100;                //Temp=4
    RC0=(Temp && 0b00000010);       //RC0=1 wrong
    RC0=(Temp && 0b00000010)?1:0;   //RC0=1 wrong

The reason Temp & 2 is wrong is because it produces 2 and bit 0 is not set.

Edit, & is bitwize, && is boolean.
I also just looked at the MicroC manual and it states it uses the lowest bits when casting.

Mike.

 

[Ian Rogers]

Right O. I stand corrected... The first really should evaluate true or false, for our purposes... I really don't know why it isn't

Why he just does't use RC0 &= Temp is beyond me...

Sorry about the confusion.....

 

[Pommie]

The first really should evaluate true or false, for our purposes... I really don't know why it isn't

No it shouldn't, it should evaluate to 0 or 2. On the line RC0=Temp & 0b00000010; there is no reason for the compiler to treat it as boolean and if it did then it would be wrong. That is also the reason I added !=0 to force it to boolean. I'm sorry to keep going on about it but it's really important that the OP understands the difference.

Mike.

 

[misterT]

Sorry MisterT I never use below method what you have mentioned.

? 1 : 0;

If you mean "I never use below method what you have mentioned.":
That is OK. The ternary conditional is difficult to read and easy to replace with if/else statement:
https://embeddedgurus.com/stack-overflow/2008/06/

If you really mean "What is this '? 1 : 0' thing":
Google "C ternary operator".
https://en.wikipedia.org/wiki/Ternary_operation