Searching \ for ' Accessing bits using Hitech's PICLITE' 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/devices.htm?key=pic
Search entire site for: 'Accessing bits using Hitech's PICLITE'.

No exact or substring matches. trying for part
PICList Thread
'[PICLIST] Accessing bits using Hitech's PICLITE'
2000\06\24@224400 by itsjustmatt

picon face
   After reading the manual many times, I still can't figure our how to
access individual bits of varibles using Hitech's PICLITE C compiler. Such
as:

char RandNo ;

void main (void)
{
if ( RandNo.3 == 0 )    // is bit 3 clear?, this is how I'm used to doing it
using CC5X
   {
    RandNo.3 = Carry ;
   }
}

How can I do this, or something like this? Thanks much.
Matt B

2000\06\24@235120 by Dale Botkin

flavicon
face
On Sat, 24 Jun 2000, itsjustmatt wrote:

>     After reading the manual many times, I still can't figure our how to
> access individual bits of varibles using Hitech's PICLITE C compiler. Such
> as:
>
> char RandNo ;
>
> void main (void)
> {
> if ( RandNo.3 == 0 )    // is bit 3 clear?, this is how I'm used to doing it
> using CC5X
>     {
>      RandNo.3 = Carry ;
>     }
> }
>
> How can I do this, or something like this? Thanks much.
> Matt B

Matt,

I had the same problem when switching from CC5X to another compiler for a
project.  I had to do this:

#define RandNo3 RandNo.3
...
RandNo3 = CARRY;
...

It's a little silly, I thought.  If I can't use it in an expression, why
does it work in a define?  I have found a lot of things that CC5X will let
you do that some other compilers simply won't, or that you have to jump
through more hoops to do.  I'm presently --><-- this close to buying CCS
C, since I want to use PICs other than the 16F84 but don't want to spend
$250 (US) and up.

Dale
---
The most exciting phrase to hear in science, the one that heralds new
discoveries, is not "Eureka!" (I found it!) but "That's funny ..."
               -- Isaac Asimov

2000\06\24@235912 by Peter Schultz

flavicon
face
Hi Dale,
Here it is,

union status
{
 unsigned char byte;
   struct
    {
     unsigned motor_status :1; //bit0
     unsigned error_status : 1;        //bit1
     unsigned force_sensor : 1;        //bit2
     unsigned current_sensor : 1;      //bit3
     unsigned motor_voltage : 1;       //bit4
     unsigned encoder_voltage : 1;     //bit5
     unsigned motor_on_time : 1;       //bit6
     unsigned unused : 1;              //bit7
    }bits;
}update_status;

to load a value at byte level you can write:
update_status.byte =  0xC0;
to access individual bits:
update_status.bits.unused = 1;

If you carefully check the Hitech website you will find this information.
Peter


{Original Message removed}

2000\06\25@134032 by Bob Blick

face
flavicon
face
First of all, the manual is not a reference for that type of information,
it's a FAQ type of thing.

Second, if you are considering buying a compiler for bigger PICs, be very
suspicious of the less expensive compilers because they might not be so
good when using PICs with multiple banks of ram and more than 2k of rom.
Post that as a separate question to the list and you'll hear from a few
people who switched to Hitech after experiencing "issues" with certain
other compilers. I don't know, I've only used Hitech and it's great. If you
are using PICs with 1k of rom most compilers make good working code from
what I hear.

The basis for all bit tests is AND, so if you are trying to test bit 3 of a
variable, the compiler is doing this:
if(variable & 0b00001000)
or to see if it's clear:
if !(variable & 0b00001000)

All the special bits in a PIC are already defined, so if you want to test
or modify a port pin you can refer to it directly, as in:

if(RB3 == 0)

setting bits works the same way and you must still remember the caveats
about modifying individual pins on a port(they are single cycle
read-modify-write and if the port is forced externally or there is
capacitance slowing the port down you can get bits set differently than you
thought)

or say you want to start the A/D converter:
ADGO = 1;

For general variable bit access you either need to use AND tests as most C
texts would suggest or do a union as described in another email answer, or
something like one of these two methods as described by Clyde.

from the hitech FAQ here are some approved ways to test, set and clear bits:

--------begin quote---------

Q: I want to be able to access single bits in a byte, but if I try to define
  a bit variable using the absolute variable construct, e.g.
static bit bitvar @ ((unsigned)&bytevar)*8+0;
  I get a compiler error. How can I do this?
A: The short answer is "you can't do this". The absolute variable construct
using
@ requires an address known at compile time.
The long (and more useful) answer will depend on what you're actually trying
to do. You may find all you need is some simple macros like:
#define  testbit(var, bit)   ((var) & (1 <<(bit)))
#define  setbit(var, bit)    ((var) |= (1 << (bit)))
#define  clrbit(var, bit)    ((var) &= ~(1 << (bit)))

--------end quote--------

If you have source code that's already in dot-format, the FAQ at htsoft.com
goes like this:

------begin quote-------

Q: I want to convert some Bytecraft MPC source code to the HI-TECH C PIC
compiler. The bit access notation has confused me. In MPC, the
Convention is FILE.BIT, where the file and bit are separated by a period.
Will HI-TECH C accept this notation, or is there a "slick" way to convert the
source code to compile with the HI-TECH C Compiler ?
A: This notation is not accepted by our compiler - it's non-ANSI. What I'd
suggest is this: do a global change (or several thereof) to convert
everything that looks like         FILE.BIT into        FILE_BIT
and then add to the program (or a header file) declarations like:
/* this line once only, of course */
#define PB(port,bit)    ((unsigned)&(port)*8+(bit))
/* as many like this as required */
static bit      FILE_BIT        @ PB(FILE,BIT);
I'm not sure if you are using symbols for the bit number, or an actual
number, either way it doesn't really matter.
How easy the global changes are depends on whether you are using the dot
character anywhere else, and how powerful your editor is.
The absolute variable notation (@ address) is non-ANSI too, but this is
only used
in declarations, not in the code itself, so it's a lot easier to port than
the Bytecraft dot notation, where you have to go and change all your code
instead
of just your declarations.

------end quote-------

All of these translate directly into the bit test and set instructions in
the PIC and are very efficient.

Cheers,

Bob

2000\06\25@171226 by Don B. Roadman

flavicon
face
On 25 Jun 2000, at 10:38, Bob Blick wrote:

> First of all, the manual is not a reference for that type of
> information, it's a FAQ type of thing.

I went through this stuff a while back. The simple fact is that the
compiler just doesnt have the facility to handle data as both a byte
variable and as individual bits. It just lacks that capability. There
are ways to do this by writing a whole lot of confusing code, but I
found the following method the simplest way. Just define a global
variable at an absolute address, then the bits can be defined as
normal without all the hassles. Here is an example. Note that foo is
the 8bit variable, and bar0, bar1...bar8 are the bits in foo.

unsigned char foo @ 0x4e;
       // Bit definitions for foo
       bit     bar7            @ (unsigned)&foo*8+7;
       bit     bar6            @ (unsigned)&foo*8+6;
       bit     bar5            @ (unsigned)&foo*8+5;
       bit     bar4            @ (unsigned)&foo*8+4;
       bit     bar3            @ (unsigned)&foo*8+3;
       bit     bar2            @ (unsigned)&foo*8+2;
       bit     bar1            @ (unsigned)&foo*8+1;
       bit     bar0            @ (unsigned)&foo*8+0;

The disadvantage of this is that the variable MUST be defined at an
absolute address (in this case, I used location 4E hex). The
compiler blythely does everything, but is oblivious to the fact that it
has assigned a variable to a location, so Its not smart enought to
check before it uses it for some other variable. Just look at the
variable map and be sure to assign your variable  to someplace
that isnt used.

I cant find any documentation on how they assign space to
variables, but so far, best I can tell, If you use the upper space
you'll be ok. They seem to start at the end of the special registers
and work up, but this may not be true in general...I just don't know.

I was pretty dissappointed that this limitation exists. I am aware
that it isnt in the ansi standard, but neither is the above stuff that
exists mainly for accessing the SFRs. I guess it would be a very
difficult thing to modify the compiler to respect variables assigned
to fixed locations or it would probably have been done before now.
All in all, it is a good compiler, and since the light version is free,
its worth taking the time to look through all the workarounds and
choose the one you like the best.

2000\06\25@204843 by Bob Blick

face
flavicon
face
>I went through this stuff a while back. The simple fact is that the
>compiler just doesnt have the facility to handle data as both a byte
>variable and as individual bits.

Huh? That's exactly what the setbit, clrbit, testbit macros do. Having
three lines at the top of a program seems pretty easy.

-Bob

2000\06\25@215505 by Don B. Roadman

flavicon
face
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.

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.

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.

2000\06\25@234843 by Bob Blick

face
flavicon
face
I'd bet it's not impossible to have a simple macro that'll do just that -
maybe Clyde knows one.


>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.

'[PIC]:RE: Accessing bits using Hitech's PICLITE'
2000\06\26@031400 by Michael Rigby-Jones

flavicon
face
I've added a PIC tag, I feel this is definately PIC related :o)

{Quote hidden}

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.

{Quote hidden}

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

2000\06\26@090602 by Bob Ammerman

picon face
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 <mrjonesspamKILLspamNORTELNETWORKS.COM>
To: <.....PICLISTKILLspamspam.....MITVMA.MIT.EDU>
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 removed}

2000\06\26@100902 by Don B. Roadman

flavicon
face
On 26 Jun 2000, at 8:12, Michael Rigby-Jones wrote:

> 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
>
I sure agree with this. It amazes me that they work as well as they
do, given the limited resources of a pic. For a long time, I wouldnt
even try any compiler because I thought the whole idea was
ludicrous, but now I believe they are worth using. It seems to me
that in addition to standard C, the extensions that a vendor
supplies are very valuable additions to make better use of the pic
using C code. However, they all have different extensions, and that
defeats some of the purpose, so some of us are loathe to use
extensions that we wish they had :) :) :) Its too bad that they dont
talk to each other and try to provide a set of extensions that are
pretty much equivalent....sort of like a gentlemen's standard.

2000\06\26@101934 by Don B. Roadman

flavicon
face
On 26 Jun 2000, at 8:40, Bob Ammerman wrote:

> So, the original 'struct within a union' scheme from this thread would
> seem, IMHO, to be an excellent way of doing this.
>
>
> Bob Ammerman

Of the several schemes I've seen to do this, the one you reference
seems to be the best way to do it. Lots of code to produce such a
simple result, but no other drawback. I saved that stuff somewhere
so I could study it, but now I can't remember where I stored it.
When I find it, I plan on playing with it and saving it as a
commented worked out example to include in other programs. I've
never used the Union feature of C, so I'll have to study that too (I'm
not a great C programmer, so this gives me an excuse to learn
something new about C)

'[PICLIST] Accessing bits using Hitech's PICLITE'
2000\06\28@163426 by Clyde Smith-Stubbs

flavicon
face
On Sun, Jun 25, 2000 at 04:10:30PM -0500, Don B. Roadman wrote:

> compiler blythely does everything, but is oblivious to the fact that it
> has assigned a variable to a location, so Its not smart enought to
> check before it uses it for some other variable. Just look at the

It's not a question of not being smart enough, it's an issue
of whether that's how the compiler should behave. I've looked
at this issue several times, and asked various people for
opinions on which way it should work, and so far there has not
been any convincing reason to make the compiler/linker take note
of absolute variable placements when allocating space.

The bit vs. byte issue is the only one that comes up regularly,
and there are several other (and IMHO better, i.e. more portable)
ways to address this problem. You do not have to "write a lot
of confusing code" - you may need to write a small amount of
confusing declarations or macros, but our FAQ gives the boilerplate
to do that, and the code itself can be reduced to the same degree
of complexity as for any other approach.

The manner in which e.g. port bits are defined in terms of the
(absolute) port address is in fact something of a hack, and can
be justified only because I/O ports and SFRs in general are
very tightly coupled to the hardware, and therefore it's ok
to have non-portable constructs to access them. For non-hardware
related issues, non-portable code is a Bad Idea. You may not
believe this now, but you will one day.

There are, OTOH, a couple of reasonably good reasons to allow you
to place absolute variables anywhere without it affecting anything
else, so for the forseeable future, the status quo will rule.

Cheers, Clyde

--
Clyde Smith-Stubbs               |            HI-TECH Software
Email: EraseMEclydespam_OUTspamTakeThisOuThtsoft.com          |          Phone            Fax
WWW:   http://www.htsoft.com/    | USA: (408) 490 2885  (408) 490 2885
PGP:   finger clydespamspam_OUThtsoft.com   | AUS: +61 7 3355 8333 +61 7 3355 8334
---------------------------------------------------------------------------
HI-TECH C: compiling the real world.

2000\06\28@164258 by Clyde Smith-Stubbs

flavicon
face
On Sun, Jun 25, 2000 at 08:52:43PM -0500, Don B. Roadman wrote:
> 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

That's exactly what the last suggestion in the FAQ achieves, at
the expense of a little complexity in setting up (but that is
provided for you in the FAQ, so all you have to do is copy it).
And the beauty of it is that it is 100% portable ANSI code, you
can use it on *any* ANSI compiler. That's about as close
to a free lunch as you're going to get.

OR - if all you want is a bit variable, then you can just declare one.
E.g.

bit     myvar;

This is non-ANSI, but to port it to a compiler without bit variables
only requires

#define bit     char

So there are several answers, depending on what the question is - all of
them protect your code investment. And as I've said before, you may not
think that's important now, but one day you will wish you had.


Regards, Clyde

--
Clyde Smith-Stubbs               |            HI-TECH Software
Email: @spam@clydeKILLspamspamhtsoft.com          |          Phone            Fax
WWW:   http://www.htsoft.com/    | USA: (408) 490 2885  (408) 490 2885
PGP:   finger KILLspamclydeKILLspamspamhtsoft.com   | AUS: +61 7 3355 8333 +61 7 3355 8334
---------------------------------------------------------------------------
HI-TECH C: compiling the real world.

2000\06\28@164508 by Don B. Roadman

flavicon
face
On 29 Jun 2000, at 6:34, Clyde Smith-Stubbs wrote:

> t's not a question of not being smart enough, it's an issue
> of whether that's how the compiler should behave.

Well, all that answers my questions. The compiler is brilliant, and
all the users want it to ignore the fact that it has assigned an
absolute address somewhere, then just use that address for a
variable. I guess I'm pretty stupid, but maybe you are right and
some day, I will appreciate the fact that this is what it should do. I
won't bother you over this issue anymore. I got my answer, and I'll
live with it. :)

2000\06\28@165917 by Don B. Roadman

flavicon
face
On 29 Jun 2000, at 6:42, Clyde Smith-Stubbs wrote:

> That's exactly what the last suggestion in the FAQ achieves, at
> the expense of a little complexity in setting up (but that is
> provided for you in the FAQ, so all you have to do is copy it).
> And the beauty of it is that it is 100% portable ANSI code, you
> can use it on *any* ANSI compiler. That's about as close
> to a free lunch as you're going to get.

The purpose of a compiler is to simplify code, not to increase the
complexity. When one supplies workarounds for a compiler that
include dozens of lines of code to do what could/should be done
with a line or two, well, thats pretty lame, Bubba. If you gave a
person 25 lines of C code to insert a NOP into the code, I don't
think they would be that happy with it, but so be it.

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