Actually, ANSI "C" _does_ support bit variables, as elements of a 'struct'. As indicated before in this thread: struct { int bit0 : 1; int bit1 : 1; etc. } abyte; Unfortunately, the standard does _not_ define the order in which the bits are assigned (ie: top-to-bottom or bottom-to-top), nor when to start on the next byte (a conforming compiler can just put each bit in its own byte if it wants), nor the size of the integral value that gets broken into bits (it can be a 16-bit integer for example). In addition, you cannot take the address of a bit variable. However, a reasonably intelligent C compiler for a microcontroller will map this ANSI standard structure in a consistent and intelligent manner to the underlying hardware. It certainly seems like Hitech's C does this. So, the original 'struct within a union' scheme from this thread would seem, IMHO, to be an excellent way of doing this. Bob Ammerman RAm Systems (high performance, high function, low-level software) ----- Original Message ----- From: Michael Rigby-Jones To: Sent: Monday, June 26, 2000 3:12 AM Subject: [PIC]:RE: Accessing bits using Hitech's PICLITE > I've added a PIC tag, I feel this is definately PIC related :o) > > > -----Original Message----- > > From: Don B. Roadman [SMTP:bjmcpher@USIT.NET] > > Sent: Monday, June 26, 2000 2:53 AM > > To: PICLIST@MITVMA.MIT.EDU > > Subject: Re: Accessing bits using Hitech's PICLITE > > > > On 25 Jun 2000, at 17:47, Bob Blick wrote: > > > > > Huh? That's exactly what the setbit, clrbit, testbit macros do. Having > > > three lines at the top of a program seems pretty easy. > > > > > > -Bob > > > > I guess you misunderstood. This isnt the same as a bit variable. > > The idea is to be able to use each bit of the variable as a BIT type > > variable, ie, a variable which occupies one bit of memory, and can > > have the values 0 or 1. This means that it can (or should) be able to > > be used in any C expression just as any other variable, the only > > difference is that it only represents from 0 to 1. So, I could have a > > statement like a=b&c, where all these are bit variables. Using > > macros, this would take a few more lines to do. This is just an > > example and probably not a good one. > > > This is exactly where you can use a union/struct arrangement to be able to > access a memory location as a byte or as bits. > > > I'm sure there are many ways to get around it, such as set,clear > > and test macros, and I've seen other C language manipulations to > > do it (even assembly language will do it :) :) :), but its still not the > > same as a BIT type variable. You CAN have Bit types which do > > this, but then you can't access them also as a byte because you > > don't know where the compiler puts them. You can define bit types > > at absolute addresses and then be able to access them also as a > > byte, but the compiler doesnt know where you put them, so you > > have to be carefull that it doesnt use your locations for itself. I > > believe this latter functionality is what the original poster was > > looking for, as I was some time ago, but it just doesnt exist. > > > It dosen't exist directly within the ANSI C language, but it can be done in > an ANSI compliant manner as I suggested. > > > I think the problem stems from the fact that C was never intended > > as a language for a microcontroller, and consequently it is a poor > > choice, but it is popular language so thats what we use. > > > Possibly, but to be honest I can't think of many other languages that give > you the flexibility and the possibility to benefit from a high level of > hardware abstraction whilst being able to work at a much lower level. BASIC > is far worse, and yet is very popular for small controller applications, > esp. in robotics. > > The bottom line is that the PIC itself is not especialy suitable for the C > langauge due to certain hardware limitations. Given that, it is a credit to > the PIC compiler vendors how well their compilers do work, especialy if they > maintain a good level of ANSI compatibility. > > Regards > > Mike