Searching \ for '[pic]:Accessing a var as a byte or bits in C' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/languages.htm?key=c
Search entire site for: 'Accessing a var as a byte or bits in C'.

Exact match. Not showing close matches.
PICList Thread
'[pic]:Accessing a var as a byte or bits in C'
2001\12\03@123728 by mike

flavicon
face
In Hitech C, is it possible to access the same variable as two
different types in C, specifically bits and bytes ?
For example I want some bit variables for various option flags, but
want to access them all as a single byte when saving/loading them to
eeprom.

Can unions be used to do this ?  
--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\12\03@145135 by Andrew E. Kalman

flavicon
face
Re:

>In Hitech C, is it possible to access the same variable as two
>different types in C, specifically bits and bytes ?
>For example I want some bit variables for various option flags, but
>want to access them all as a single byte when saving/loading them to
>eeprom.
>
>Can unions be used to do this ?


Yes.
--

 ______________________________________
  Andrew E. Kalman, Ph.D.   spam_OUTaekTakeThisOuTspampumpkininc.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\12\03@153125 by Sean H. Breheny

face picon face
Hi Andrew,

Is this specific to HiTech? I have never seen a "normal" C compiler which
had a bit variable type, and I thought that either the ANSI or K&R
standards did not call for such a type.

Sean

At 11:31 AM 12/3/01 -0700, you wrote:
{Quote hidden}

----------------------------------------------------
Sign Up for NetZero Platinum Today
Only $9.95 per month!
http://my.netzero.net/s/signup?r=platinum&refcd=PT97

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\12\03@155233 by Martin Peach

flavicon
face
Normal C has bitfields in it. Usually you use them in structs or unions.
Problem is you don't usually know which bit is assigned, so I prefer
assembly at that level of detail.
/\/\/\/*=Martin

{Original Message removed}

2001\12\03@181754 by Dale Botkin

flavicon
face
On Mon, 3 Dec 2001, Sean H. Breheny wrote:

> Hi Andrew,
>
> Is this specific to HiTech? I have never seen a "normal" C compiler which
> had a bit variable type, and I thought that either the ANSI or K&R
> standards did not call for such a type.

All PIC C compilers I have seen have it.  CCS defines short as 1 bit,
int/char as 8 bits, long as 16 bits - you can of course change these.  I
would go out on a limb and say a bit variable type would be almost a
requirement for PICs - I can't waste a byte of RAM on a boolean.

Dale

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\12\03@181810 by mike

flavicon
face
On Mon, 3 Dec 2001 15:43:05 -0500, you wrote:

>Normal C has bitfields in it. Usually you use them in structs or unions.
>Problem is you don't usually know which bit is assigned, so I prefer
>assembly at that level of detail.
>/\/\/\/*=Martin

Hitech allows bit vars to be declared, and also to be assigned to
fixed addresses for hardware, e.g. static volatile bit     GP5     @ (unsigned)&GPIO*8+5;

GP5 = 1;
generates BSF GPIO,5
Unfortunately you can't use the @ operator on vars whose address is
not known at compile time, so this doesn't solve the original problem.


>{Original Message removed}

2001\12\03@181843 by Sean H. Breheny

face picon face
What is the syntax? I've been using C for 9 years (mostly on PCs but also
on microcontrollers) and don't recall ever seeing it!

Sean

At 03:43 PM 12/3/01 -0500, you wrote:
>Normal C has bitfields in it. Usually you use them in structs or unions.
>Problem is you don't usually know which bit is assigned, so I prefer
>assembly at that level of detail.
>/\/\/\/*=Martin

----------------------------------------------------
Sign Up for NetZero Platinum Today
Only $9.95 per month!
http://my.netzero.net/s/signup?r=platinum&refcd=PT97

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\12\03@190802 by Ashley Roll

flavicon
face
Hi

typedef union {
       struct {
               int Bit0 : 1;
               int Bit1 : 1;
               int Bit2 : 1;
               int Bit3 : 1;
               int Bit4 : 1;
               int Bit5 : 1;
               int Bit6 : 1;
               int Bit7 : 1;
       } Bits;
       unsigned char Value;
} BitDataByte;

BitDataByte myData;

myData.Value = 42;

myData.Bits.Bit0 = 1;

Will get you started.. the ": 1" tells the compiler to allocate 1 bit to the
element, but you can allocate any number. So you can have a 2 or 3 or 14 bit
number as you choose. more details should be in your local C language book
:)

Cheers,
Ash.

---
Ashley Roll
Digital Nemesis Pty Ltd
http://www.digitalnemesis.com
Mobile: +61 (0)417 705 718




> {Original Message removed}

2001\12\03@205957 by Bob Ammerman

picon face
ANSI "C" supports bitfields, which are a special type of structure field.

In ANSI "C" multiple bitfields are crunched together into one "int" sized
value (note: NOT a char!).

The syntax is like this:

typedef struct  {
   int        field_1 : 1;        // single bit field
   int        field_2 : 1;
   int        field_3 : 5;        // 5-bit field
} bitfield_struct;

you can do this too:

typedef union {
   int                    as_integer;
   bitfield_struct    as_fields;
} bitfield_union;

bitfield_union myvar;

myvar.as_fields.field_3 = 2;
myvar.as_fields.field_1 = 0;

save_it( myvar.as_integer );

Bob Ammerman
RAm Systems

{Original Message removed}

2001\12\03@214041 by Bob Ammerman

picon face
Note that this is great, but according to ANSI  sizeof(Bits) == sizeof(int),
not sizeof(Bits) == sizeof(char).

Also according to ANSI, int must be at least a 16-bit value.

Bob Ammerman
RAm Systems

----- Original Message -----
From: "Ashley Roll" <ashspamKILLspamDIGITALNEMESIS.COM>
To: <.....PICLISTKILLspamspam.....MITVMA.MIT.EDU>
Sent: Monday, December 03, 2001 3:30 PM
Subject: Re: [pic]:Accessing a var as a byte or bits in C


{Quote hidden}

the
> element, but you can allocate any number. So you can have a 2 or 3 or 14
bit
{Quote hidden}

> > {Original Message removed}

2001\12\04@065813 by mike

flavicon
face
On Tue, 4 Dec 2001 09:30:14 +1000, you wrote:

{Quote hidden}

Could you then simplify the access to the bits by doing #define modeflag myData.Bits.Bit0
modeflag=0;
etc.  ?

Could you also simplify the above declaration by using bit Bit0;
instead of int Bit0:1;


{Quote hidden}

>> {Original Message removed}

2001\12\04@072759 by Gerhard Fiedler

flavicon
face
At 11:28 12/04/2001 +0000, Mike Harrison wrote:
> >myData.Bits.Bit0 = 1;
>
>Could you then simplify the access to the bits by doing
>#define modeflag myData.Bits.Bit0
>modeflag=0;

yes, this is standard preprocessor stuff (replacement at the text level,
without any syntax checking etc.)

>Could you also simplify the above declaration by using
>bit Bit0;
>instead of int Bit0:1;

Not in ANSI C. Most microcontroller implementations of (ANSI) C have some
extensions to accomodate bit types, but these are compiler specific. So in
order to get a useful answer, you'd have to tell us which compiler you're
talking about.

ge

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\12\04@092436 by Michael Vinson

picon face
Ashley Roll wrote, in part:
>[perfectly correct information about bit-fields respectfully
>  deleted - mjv]
>more details should be in your local C language book

To be more specific, see section 6.9 (beginning on page 149) of
Kernighan and Ritchie, second edition (the only book on C I've
ever owned). Also section A8.3, if the C language reference is
the kind of thing that turns you on.

Michael V (who could never really follow that reference section...)

Thank you for reading my little posting.



_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\12\04@100442 by mike

flavicon
face
Thanks to all who responded to this - it works fine in Hitech C. One observation, though, hitech is very code-inefficient at doing
maths on bitfields longer that one bit, so you can often save a lot of
code by copying the bitfield to a temporary char, doing the maths,
then copying it back.
On Tue, 4 Dec 2001 09:30:14 +1000, you wrote:

{Quote hidden}

>> {Original Message removed}

2001\12\04@105108 by Douglas Butler

flavicon
face
> Note that this is great, but according to ANSI  sizeof(Bits)
> == sizeof(int),
> not sizeof(Bits) == sizeof(char).
>
> Also according to ANSI, int must be at least a 16-bit value.
>
> Bob Ammerman
> RAm Systems

Which is why most 8 bit C compilers don't cripple themselves by being
ANSI compliant!

Sherpa Doug

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\12\04@125619 by Paul Hutchinson

flavicon
face
Doug,

Besides the ones from CCS, which C compilers don't follow the ANSI int size
rule?

I haven't encountered any others in my evaluation and use of a few different
C compilers for PIC's, Mot 68XX, 80XX, etc.

Now that I've got a chance to start using the new V3.X version of CCS C, I'm
considering using the new #TYPE directive to make it more ANSI compatible.
This would allow greater portability between the various C compilers I use
but, if a lot of C compilers don't follow the ANSI int size rule I'd
probably be better off leaving the CCS int size at the default of 8 bits.

Thanks,
Paul

> Which is why most 8 bit C compilers don't cripple themselves by being
> ANSI compliant!
>
> Sherpa Doug

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\12\04@151325 by steve

flavicon
face
> Thanks to all who responded to this - it works fine in Hitech C. One
> observation, though, hitech is very code-inefficient at doing maths on
> bitfields longer that one bit, so you can often save a lot of code by
> copying the bitfield to a temporary char, doing the maths, then
> copying it back.

I was messing around with bits and bitfields last night, trying to
squeeze out a few more code words.
Because bit types aren't initialised, I had 16 of them, each getting
a bcf instruction. Ah, I thought. Put them in a union with an int or a
couple of chars and it will only take a couple of instructions to clear
them.
No. Can't do that. You can't have bit types within a structure. You
can define them as ANSI style bitfields (which are on byte
boundaries in HiTech C), unionise them and clear them with a
couple of instructions but then when you try to use them, unless it
is a single bit operation, the code bloats out to use shifts and
masks.
By single bit operation, I mean that MyBit = 0 compiles to bcf
MyBit, but MyBit = MyOtherBit compiles to get the byte, mask the
byte, test the result, get the byte, or in the mask, put the byte
back. That's regardless of where the bits are in the byte and with
having all bitfields one bit long.

You can get the best of both worlds if you put your bits at a
specified address in the same way you do for registers.

static unsigned char  bits1  @ 0x23;
static bit     MyBit         @(unsigned)&bits1*8+0;
static bit     MyOtherBit     @(unsigned)&bits1*8+1;
etc.

That way bits1 = 0 compiles to clrf 0x23
and MyBit = MyOtherBit compiles to bcf, btfsc, bsf.

The address I used is the address that PICC was putting them
anyway.

Steve.

======================================================
Steve Baldwin                Electronic Product Design
TLA Microsystems Ltd         Microcontroller Specialists
PO Box 15-680, New Lynn      http://www.tla.co.nz
Auckland, New Zealand        ph  +64 9 820-2221
email: EraseMEstevebspam_OUTspamTakeThisOuTtla.co.nz      fax +64 9 820-1929
======================================================

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


More... (looser matching)
- Last day of these posts
- In 2001 , 2002 only
- Today
- New search...