# Simple Question

Discussion in 'General Electronics Discussion' started by Horn, Jun 13, 2012.

1. ### Horn

42
0
Jun 4, 2012
I wrote a program to read weather a bit of a hex number is either 1 or 0.

Example: is the 4th bit of 0xFF (1111 1111) 1 or 0?

I applied an if statement reading as such:

if((0xFF & (0x01 << 3)) != 0)
True

else
False

All results returned False?

I tried another way too:

sto = 0xFF >> 3

if((sto & 0x01) !=0)
True
else
False

This gets me my result. The only difference from the first and the second is the final result of the first is 0000 1000 and the second is 0000 0001. In both cases I assumed they were true. Is it only reading my least significant bit to determine true or false because i use 0x01?

2. ### Harald KappModeratorModerator

11,295
2,586
Nov 17, 2011
I tested your code fragment (had to use C++ Compiler due to lack of another one):

...
if((0xFF & (0x01 << 3)) != 0)
std::cout << "True";
else
std::cout << "False";
...

Result is "True", as expected. Can you post the real code you used? Maybe there is a subtle error that is not present in the short form you posted first.

Harald

3. ### Horn

42
0
Jun 4, 2012
#include <pic.h>
#include <string.h>
#include <stdio.h>

#define uchar8 unsigned char

void main( void )
{
uchar8 ch,sto;
unsigned int c;

while(1)
{
ch = 0xA3;
for(c=7;c>0;c--)
{
sto = ch >> c;
if((sto&0x01)!=0)
SEND('1');
else
SEND('0');
}

}
}

Last edited: Jun 13, 2012
4. ### Horn

42
0
Jun 4, 2012
Sorry for the mess. I tried to clear out as much of the unneeded code as possible.

5. ### Horn

42
0
Jun 4, 2012
New code. I cleaned it up much more sorry about the first one.

6. ### Harald KappModeratorModerator

11,295
2,586
Nov 17, 2011
That's not helpful, your code is the one that does it. How does the original code look like, that does nor work?

Harald

7. ### Horn

42
0
Jun 4, 2012
#include <pic.h>
#include <string.h>
#include <stdio.h>

#define uchar8 unsigned char

void main( void )
{
uchar8 ch;
unsigned int c;

while(1)
{
ch = 0xA3;
for(c=7;c>0;c--)
{
if((ch & (0x01 << c)) != 0)
SEND('1');
else
SEND('0');
}
}
}

8. ### Harald KappModeratorModerator

11,295
2,586
Nov 17, 2011
Apart from
for(c=7;c>0;c--) /* misses bit 0 since c==0 is not part of the loop */
which should be
for(c=7;c>=0;c--)
the code works fine

Harald

9. ### Horn

42
0
Jun 4, 2012
Yeah when I run it in MPLAB it does not work but in Turbo C it works. I caught that c=0 was not in the loop just a few minutes ago. I'm not sure what the deal is in MPLAB. It may be a setting I need to change somewhere...

Thanks again for the help Harald!

10. ### Harald KappModeratorModerator

11,295
2,586
Nov 17, 2011
Maybe a problem in MPLAB with correct handling of operator precedence?
Or an "overoptimization" of the code?

Does MPLAB know the keyword "volatile"? It could help (not sure) to declare
volatile uchar8 ch;

Harald

11. ### Horn

42
0
Jun 4, 2012
Found the problem. I declared to be an unsigned int but it actually goes to a final value of -1 and this for some reason ruins everything down the wash. Got an explanation as to why it does such a drastic thing?

12. ### Harald KappModeratorModerator

11,295
2,586
Nov 17, 2011
I'm not sure what happens.
I assume you're talking about the variable "c" which is declared as unsigned int. The complier may have trouble with his statement:
for(c=7;c>=0;c--)

Consider the loop pass where c is decremented from c=1 to c=0. This should run without problem. But in the next pass c is decremented by 1 which would lead to c=-1 which is 0xff for an 8 bit variable. On the other hand, since c is an unsigned integer, 0xff can be interpreted as c=255. I don't know how the compiler handles this dilemma.

Harald

13. ### Horn

42
0
Jun 4, 2012
Yeah I meant 'c' sorry about that. Just another secret to the computer world...

Thanks for your continued help Harald so far you have handled all my questions. I owe you.