Jump to content

Recommended Posts

Someone correct me if I'm missing something here...

 

I am trying to access bits like so:

 

intcon.GIE =1;

or

intcon.7=1;

 

and I get an error. is it not possible to get bit-level accessing like that?

I noticed in some example programs, it was done like this:

 

set_bit( intcon, GIE );

 

having to deal with bits by calling a function like that is a big annoyance for me, especially when I want to put a boolean expression on the right side, then I'd have to fill up 4 lines with an IF/ELSE statement to either set or clear the bit based on the result of the boolean expression.

 

If it's not possible currently, could it make it into a future version? considering how much bit accessing the average program contains, for setting I/O and such, I think it's kind of hard to live without. it seems like it would require nothing more in the compiler than a simple macro to convert it to the IF/ELSE statement I mentioned (from what I recall of CC5x, it compiled to pretty much an IF/ELSE statement in assembly anyway)

 

and I was surprised to get an error from it, considering the way I/O pin - tied variables are defined, ie - bit LED @ PORTB.1;

 

thanks!

Share this post


Link to post
Share on other sites
intcon.GIE =1;

or

intcon.7=1;

This isn't C language. More something like C language extension. The standars ways to access bits inside a variable are through the bitwise operations (which btw are used in the 'set_bit' macro) or using bit variables mapped to the bit that needs to be accessesed.

 

Is there any good reason to use this non standard way to access bits in a variable over the standard bitwise C operations or bit variables?

 

Regards,

Pavel

Share this post


Link to post
Share on other sites

I suppose if it's not ANSI C then I can't exactly EXPECT it to be included... But I notice that a lot of people on this forum seem to be converts from CC5x, like myself, and I think it is a very handy feature that makes code much cleaner; it's intuitive, very compact, and makes the code very easy to read... And as I said, it doesn't SEEM like it would be very hard to implement if all you'd have to do is translate that line of code into an equivalent bitwise operation... (although I know nothing of making a compiler, so that doesn't mean much)

 

And I know it's not ANSI C, but I think on a PIC you have some special needs as opposed to programming on a computer... especially when it comes to bitwise access to variables, which I have never really needed when using computers, but need on a very regular basis when programming PICs. And if it's just an extension, then it shouldn't interfere with all the other ways of doing it.

Share this post


Link to post
Share on other sites

OK I guess that simple constant assignments to certain bits of a variable should be relatively easy to add:

 

a.2 = 1; //set bit 2 of variable 'a'

b.5 = 0; //clear bit 5 of variable 'b'

 

Is this what are you asking or you also need support of more complex cases when such bit can be used as an operand in any expression.

 

Regards,

Pavel

Share this post


Link to post
Share on other sites

Well ideally I would like to be able to do either... granted, the first way (assigning a boolean value to the specific bit of a register) I would use more often, so that would be a bigger priority, but using a bit of a register as part of a boolean expression on the other side of the equation is something that I have use for occasionally as well.

 

I was thinking, could the compiler just detect any bits that were used in the program, and declare them at the top automatically? then they should be usable in any situation, as any other bit variable would be.

 

ie:

if

 

a.7 =1;

 

were in the program, at the top it would make the assumed definition:

 

bit a.7 @ <address of a>.7;

 

In other words, it would work the same as if I declared them myself, but without having to do it manually, and without cluttering the header or top of the source listing. Of course, I don't know how bit variables are stored or dealt with, so I don't know if that would require extra memory.

Share this post


Link to post
Share on other sites
Well ideally I would like to be able to do either...  granted, the first way (assigning a boolean value to the specific bit of a register) I would use more often, so that would be a bigger priority, but using a bit of a register as part of a boolean expression on the other side of the equation is something that I have use for occasionally as well.

 

I was thinking, could the compiler just detect any bits that were used in the program, and declare them at the top automatically? then they should be usable in any situation, as any other bit variable would be.

 

ie:

if

 

a.7 =1;

 

were in the program, at the top it would make the assumed definition:

 

bit a.7 @ <address of a>.7;

 

In other words, it would work the same as if I declared them myself, but without having to do it manually, and without cluttering the header or top of the source listing.  Of course, I don't know how bit variables are stored or dealt with, so I don't know if that would require extra memory.

 

Yes this is a nice idea. I need to think about it more.

 

Regards,

Pavel

Share this post


Link to post
Share on other sites
Yes this is a nice idea. I need to think about it more.

 

Regards,

Pavel

 

Cool, thanks.

 

I just started my first real project with BoostC the other day, so I'm anxious to see how it works out. so far, with the exception of this bit access stuff, it's going pretty well.

Share this post


Link to post
Share on other sites

izakdude,

 

I havent tried it but hyou might be able to do somthing like this yourself.

If you make a typdef of a struct with 8 single bit values. Then create a pointer pointing to that type. You could then point the pointer to a port and use the pointer to struct bit to assign the bits of the port.

 

typedef struct {
                        unsigned 7:1;
                        unsgined 6:1;
                        unsigned 5:1;
                        unsigned 4:1;
                        unsigned 3:1;
                        unsigned 2:1;
                        unsigned 1:1;
                     } BITS;

 

then

 

BITS * PORTAbits = &PORTA;

 

then

*PORTAbits->7 = 1;

 

I havent tried anything like this, but it seems reasonable. The only thing I can see that might be a hastle is the bits might be in the wrong order here.

Anyway I hope this helps rather than confuses.

 

Darren J.

Share this post


Link to post
Share on other sites

that may work, however in some cases I access a variable both as an 8-bit char, AND access the individual bits

 

quick example: for some sort of serial display, to display a number, I would have to take the number and add the ASCII value of '0' to it to get the right ASCII character for that number. Then for bit-banging serial, I would send each bit one by one. Adding a value to a group of 8 bits that weren't also accessible as a byte would be a pain in that case.

Share this post


Link to post
Share on other sites

izakdude

 

Well in that case you could use the original variable name, or you could make a union with the struct and an unsigned char or something inplace of the struct.

 

I often do this with flag variables, so I can clear them all at once by clearing the byte and check if any of them are asserted by checking if the byte is 0, before checking them all individually.

 

Darren J.

Share this post


Link to post
Share on other sites

Well to get access to both the byte and the bits of that byte, I could just declare individual bit variables at each bit of that byte, which sounds simpler (and more compact) than doing structs and unions and such.

 

however, that's exactly what I already proposed that the compiler do automatically, so I don't have to manually declare something along the lines of:

(this is pseudo-code off the top of my head, I don't know if it would work as written)

char a @ <address>;

bit a.0 @ <address of a>.0;

bit a.1 @ <address of a>.1;

bit a.2 @ <address of a>.2;

bit a.3 @ <address of a>.3;

bit a.4 @ <address of a>.4;

bit a.5 @ <address of a>.5;

bit a.6 @ <address of a>.6;

bit a.7 @ <address of a>.7;

 

at the top of every program, because that's a lot of unnecessary typing and clutters things up. Having to only declare "char a;" at the top, and having the compiler realize that I am talking about bit 3 of that variable when I say "a.3 = 1;" (ie - basically assume that the above declaration was made, without having to write it myself every time) is much more intuitive.

Share this post


Link to post
Share on other sites

izakdude, i am agreee with you proposed.

 

I have some ideas with examples. Always suppossed what the compiler can do this in automatic form.

 

A) #### Asigning a label to a bit in a variable #### :o

This is a manual form of asignament of bit inside a variable

 

unsigned char state; /* may be declared as int for example*/

volatile bit flgOverflowProc   @state.4;  /* assign the label "flgOverflowProc" to state.4 bit if was necessary */

 if (state.4)    /* testing thought a  specific bit */
      state.4 = 0;
or
if (!flgOverflowProc) /* testing thought a  specific label defined to a bit before */
   flgOverflowProc = 1;

In some cases may be usefull define variables type like "int" instead of "char", like a multi byte configuration register, to be passed as argument function if this has been defined like a local variable,etc.

 

B) #### Assigning a label to a bit in an automatic position in RAM defined by de compiler#### :D

 

This is a automatic form of assignament of bit in an adress defined automatically by the compiler

This is a powerfull tool because i not must to think about where my bits flags are asigned.

But i assume this involves a challenge and too hardwork to the compiler developers.

 

example:

volatile bit flgProcOK;   /* Automatic adressing made by the compiler */

if (!flgProcOK)   /* testing thought a  specific bit asigned automaticlly */
   ...;

 

Thanx.

David A. Valdez

Share this post


Link to post
Share on other sites
:D #### Assigning a label to a bit in an automatic position in RAM defined by de compiler#### :o

 

This is a automatic form of assignament of bit in an adress defined automatically by the compiler

This is a powerfull tool because i not must to think about where my bits flags are asigned.

But i assume this involves a challenge and too hardwork to the compiler developers.

 

example:

volatile bit flgProcOK;   /* Automatic adressing made by the compiler */

if (!flgProcOK)   /* testing thought a  specific bit asigned automaticlly */
   ...;

 

 

This feature was in the compiler ever since bit data types were implemented.

 

Regards,

Pavel

Share this post


Link to post
Share on other sites

B) Ops, what idiot :D

I am tried this now and your are right. :D

 

But, i make some test based in your Compiler help file:

 

Bit variables can also have fixed addresses. Their address includes bit position and can have 2 forms:

bit b1@0x40.1; //variable located at bit 1 of register 0x40

bit b2@0x202; //variable located at bit 2 of register 0x40 (0x40*8 + 2)

 

I read the word "can" but never think about that like "the compiler can deal with bit variables with fixed adresses, so the compiler assign automatically the adress when I not, like conclusión". :o

 

For avoid dumies like me, in your next release, please ¿can you add more examples of various definitions forms of bit type in the help file, or better like a simple example file with all definitions possible of type bit?.

 

David A. Valdez

Share this post


Link to post
Share on other sites
...For avoid dumies like me, in your next release, please ¿can you add more examples of various definitions forms of bit type in the help file, or better like a simple example file with all definitions possible of type bit?...

 

Done. Put some more info about the subject into the BoostC help.

 

Regards,

Pavel

Share this post


Link to post
Share on other sites

so... is it possible that this bit accessing scheme will make it into the compiler? if so, when do you think a compiler version with it will be available? because that's probably the compiler version that will convince me to shell out for a license :o

Share this post


Link to post
Share on other sites
so... is it possible that this bit accessing scheme will make it into the compiler? if so, when do you think a compiler version with it will be available? because that's probably the compiler version that will convince me to shell out for a license  :o

 

We like this scheme and seriously plan to add it to the compiler.

 

Regards,

Pavel

Share this post


Link to post
Share on other sites
sweet  :D well I'll keep an eye out.  any idea when a compiler version might be released that includes it?

 

I don't know. We work on this feature but we also work on other ones. Some have higher priority than this one and to make things more complex proirities of different tasks changes over time. All I can say that when this feature is done we won't hide it :o

 

Regards,

Pavel

Share this post


Link to post
Share on other sites

Hey, just curious if this was any closer to being implemented.

 

I was working on some code today, porting it over to BoostC, and I translated this code:

 

(CC5x)

    value.0=DB0;
   value.1=DB1;
   value.2=DB2;
   value.3=DB3;
   value.4=DB4;
   value.5=DB5;
   value.6=DB6;
   value.7=DB7;

 

into this:

 

(BoostC)

    value=DB7;
   value*=2;
   value+=DB6;
   value*=2;
   value+=DB5;
   value*=2;
   value+=DB4;
   value*=2;
   value+=DB3;
   value*=2;
   value+=DB2;
   value*=2;
   value+=DB1;
   value*=2;
   value+=DB0;

 

(which, by the way, i haven't tested yet, since other compile errors are preventing me from testing it on the actual PIC circuit, but it seems to me that it should at least work)

 

The first one sure looks cleaner. oh, and feel free to point out any better methods for implementing that better than the way I did it...

 

anyway, I'm keeping my fingers crossed for this addition :)

Share this post


Link to post
Share on other sites
so... is it possible that this bit accessing scheme will make it into the compiler? if so, when do you think a compiler version with it will be available? because that's probably the compiler version that will convince me to shell out for a license  :)

 

For what it's worth, once this addition is made to the compiler I intend to purchase a license as well.

Share this post


Link to post
Share on other sites

Guys,

 

value.0= 1; // set bit 0
value.1= 0; // claer bit 1

 

WILL be in the next compiler release :)

 

Regards

Dave

Share this post


Link to post
Share on other sites

Awesome!

 

while this may seem like a weird question, since I know that using this nomenclature in different situations involves different things in terms of compilation, I'll ask this:

what about these, will they work?:

bit a;
char b;

b.3 = a;
a = b.3;
a = !b.3;
b.3 = !b.3;
if( b.2 ){}
if( b.2 && !b.3 ){}

 

basically, will the nomenclature allow us to use a certain bit of a byte in all the ways we would use a normal bit variable?

 

I was holding out on buying a license until this feature was added, however I got a little impatient and bought one anyway... glad to see that it's still on the way :)

 

oh, and jtribbet... is that you justin? from UMaine?

Share this post


Link to post
Share on other sites

izakdude,

 

bit a;
char b;

b.3 = a;
a = b.3;
a = !b.3;
b.3 = !b.3;
if( b.2 ){}
if( b.2 && !b.3 ){}

 

Yes these will work.

 

Regards

Dave

Share this post


Link to post
Share on other sites

Alright, bringing this one back up again with another question.

 

How about being able to use a variable as the index?

 

ie:

 

char a, i;
a=01010101b;
for(i=0; i<8; i++)
{
    if(a.i)
    { //do something  }
}

 

that seems to be the only barrier left to total freedom with this bit accessing scheme... not that it's terribly hard to achieve the same goal by just accessing a specific bit like "a.0" and then using the rotate operator to cycle through... but I thought i'd point it out anyway. of course, if it would produce crazy code overhead to do it at run time then careful planning and use of rotates would be preferable anyway.

Share this post


Link to post
Share on other sites

I have yet another issue with bit addressing ....

 

Have an array

Unsigned char SlaveReg[8];

 

Wanted to access at the bit level each of the 8 locations.

 

added

unsigned char *svstat = &SlaveReg[0];

This placed the correct address in svstat as shown below

 

U8 SlaveReg[8];

U8 *svstat = &SlaveReg[s_status];

07F2 0E00 MOVLW HIGH(gbl_SlaveReg+D'0')

07F4 6E40 MOVWF gbl_svstat+D'1'

07F6 0E2D MOVLW LOW(gbl_SlaveReg+D'0')

07F8 6E3F MOVWF gbl_svstat

 

The compiler will not accept

*svstat.bit = 1; // it sees svstat as a non-pointer

 

It does accept *svstat = 1; // or a byte wide operation.

 

If I instead use the array 0th element (luckily this is the major location that I need)

the correct code is generated (also note address of 9th element is > 0x100)

 

SlaveReg.bit1=1;

0144 822D BSF gbl_SlaveReg,1

 

Need to have a uniform bit operation methodology

 

Like many I need to use the bits as tests in loops and easy set clear operation.

This should be usable over the entire addressing range.

 

Would love to see bits enhancement in the next compiler.

Share this post


Link to post
Share on other sites
I have yet another issue with bit addressing ....

 

Have an array

Unsigned char SlaveReg[8];

 

Wanted to access at the bit level each of the 8 locations.

 

added

unsigned char *svstat = &SlaveReg[0];

This placed the correct address in svstat as shown below

 

U8 SlaveReg[8];

U8 *svstat = &SlaveReg[s_status];

07F2 0E00 MOVLW HIGH(gbl_SlaveReg+D'0')

07F4 6E40 MOVWF gbl_svstat+D'1'

07F6 0E2D MOVLW LOW(gbl_SlaveReg+D'0')

07F8 6E3F MOVWF gbl_svstat

 

The compiler will not accept

*svstat.bit = 1; // it sees svstat as a non-pointer

 

It does accept *svstat = 1; // or a byte wide operation.

 

If I instead use the array 0th element (luckily this is the major location that I need)

the correct code is generated (also note address of 9th element is > 0x100)

 

SlaveReg.bit1=1;

0144 822D BSF gbl_SlaveReg,1

 

Need to have a uniform bit operation methodology

 

Like many I need to use the bits as tests in loops and easy set clear operation.

This should be usable over the entire addressing range.

 

Would love to see bits enhancement in the next compiler.

 

No C compiler would accept '*svstat.bit = 1', it is an illegal assignment, you cannot use the dot operator with a pointer. Also, you have a pointer to an unsigned char not a pointer to a type which specifies a bit. You could create a new type with a union of an unsigned char and an 8 bit bitfield and use the -> to access different members, but I am not sure if bitfields can be created in structures in BoostC. Otherwise do what everyone else does and use statements like:- *svstat |= (1 << bit); to set a bit or use the predefined macro setbit(). I would suggest looking at a C tutorial on pointers and their usage. Hope this helps.

Share this post


Link to post
Share on other sites

Your content will need to be approved by a moderator

Guest
You are commenting as a guest. If you have an account, please sign in.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×