I would like to know how to access the status of the bits in a byte. From the LineLeader, you can get a byte with each of the eight-bits corresponding with the status of one of the light-sensors. Each bit is either 0 for dark, or 1 for light. I want to do something like this:Is it possible? If so, how? If not, then my loop time will be reduced.

Figured it out. Found an example. Go me.

And... Now it turns out I didn't really need it in the first place.

Just for reference in case someone wants the answer, you can & the Byte (or other variable type) with a 1 left shifted n number of places (n being the bit, numbered 0-7), or a constant mask. See the following two code examples:

Just another reference for you. Look at joystickdriver.c. Joystick buttons are bits in a word. This is how each button is accessed by the joy1Btn() function.

Also, you can use the following generic macro.

So printing all the bits in a byte would be:

Thanks MHTS, that's much cleaner than what I was doing.

Of course, now I might need to use the bits Can't seem to make up my mind...

Some tips to help you making design decisions. For example, to answer the question "When do you use bits?". A bit (binary digit) can hold a value of two states (0 and 1, or FALSE and TRUE). In situations where you need to store data that has only two states, bits can be used. You can also use the "bool" data type. However, bool data type is either stored as a byte (8-bit) or in the processor's native word size (usually 32-bit) on some platforms. So if you have a lot of binary state data, it may not be an efficient way to store them as bool's. However, accessing a single bit within a byte or a 32-bit word can be tricky and hard to understand for beginners. So defining a set of bit accessing macros will make it easier to use and understand. For example:

<rant>
its a hardware vs software thing as well.

with hardware you often have to deal with bits - ie the button flags.

In software, since memory became cheap you seldom ever have to deal with them. The guys writing drivers are in between, although I see less and less bit usage even in hardware.

IMHO understanding the logic of bits AND OR XOR is much more important then the bits themselves, as it applies to IF statements and such.

bits are becoming slightly less used, because they do not reflect real world, Yes, NO, I don't know. Try doing that with a bit (you can't), and much software written today needs that functionality more than they used to. I was really hoping in my lifetime we would abandoned the simple binary computer for something a little more robust, but I don't think its going to happen soon enough. but for forward looking geniuses, its something to keep in the back of your mind.
</rant>

May be you are right. However, I do use bits a lot. I found myself using bits to generate very efficient code and data structures. Especially in an embedded platform where memory is a premium, I tend to optimize as much as possible on memory use.
And I agree it is very important to understand the logic of bits but avoid using bits won't get you there

"... Especially in an embedded platform where memory is a premium"

That would make you a hardware guy (even if you wouldn't admit it )
I can remember the good old days far too well, when a program that used 128k memory and ran for .012 seconds cpu time only cost $500, vs a program that used .014 seconds cpu but 512k cost $3,000 - ah the good old days, gone thank goodness.

the death of bits started around the 70's with ADA, a government sponsored language, required by the airforce for all software - NO bits, none, zero, not allowed. Both java and C# make it difficult to get directly at bits, although it can be done, it's not a feature of the languages by any stretch.

Hardware guys are easy to spot, they tend to do things like "&buffer[0]", rather than "buffer", even though they are the same

Then I suppose all robotics programmers are hardware guys. Well, I admit I am a hardware guy too. I do have an Electrical Engineering degree.

Actually, my first computer had only 2K ROM and 1K RAM running on the Z80 CPU and I was programming it with hex code, literally hand assembling the code and entering them as hex numbers.

Except when you are using RobotC then you never know if just "buffer" would work I think I tried that some time ago and it didn't work. But with all the releases, I am not sure any more. But one thing I know, "&buffer[0]" seems to always work

No I don't think I would say that at all. I can point to several libraries in ROS without one line of bit code in them. Granted what you call robotics, I probably call electrical engineering, and what I call robotics, I have no idea what you call it.

The Z80 was at least my 3rd computer, I'm thinking maybe 4th. My second was an IBM 370/158 But I got dabble later on a working 1401

Did &buffer[0] work on the old robotc? I don't think it did. Zander uses sendI2CMsg(link, data[0], replylen); in common.h, it was a workaround. Ever since pointers were allowed in robotc, "buffer" has worked fine for me.

Wow, you owned an IBM 370?

If by old RobotC you meant before 3.50 then no, the "&" syntax was not supported until 3.50. All I know is Xander's common.h was broken by 3.51 so you have to change data[0] to &data[0] for it to compile. And I did not try just buffer in the latest 3.51. So can't tell you if it works. I will try it tonight. But at some point of porting our library code to 3.50, I remember trying just buffer and it did not work for me, so I thought it wasn't working.