• State Not Answered
  • Locked Locked
  • Replies 9 replies
  • Subscribers 21 subscribers
  • Views 1699 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Accesing bit addressable variables

Elliot Chisholm

I was wondering what the "best" way to set a bit in a variable declared in the bit addressable area.

Originally I declared each bit as an sbit and therefore can set and clear them as follows

uint8_t bdata status ;
sbit enable = staus ^ 0 ;

enable = 1 ;
enable = 0 ;
I think it looks clearer to do as follows
#define ENABLE 0x01

uint8_t bdata status ;

status |= ENABLE ;
status &= ~ENABLE ;

but I am worried that this could less maintainable because there will be many #defines with the same values but related to different variables and confusion could ensue.

I was wondering what other people do and if there is a standard method for doing this?

Parents
  • 0 in reply to Graham Cole

    "Personally, I would always go for the first method as it is so much clearer." (my emphasis)

    I agree, although the OP thinks the opposite!

    "The only down-side is that the first method it is absolutly non-portable."

    But it can (I say should) be encapsulated in a macro, so that porting is simply a matter of suitably redefining the macro.
    Similarly for all other compiler-specifics.

    "The compiler will generate quite different code in each case."

    Absolutely.
    Why would Keil bother to dream up this special syntax if it made no difference?!

Reply
  • 0 in reply to Graham Cole

    "Personally, I would always go for the first method as it is so much clearer." (my emphasis)

    I agree, although the OP thinks the opposite!

    "The only down-side is that the first method it is absolutly non-portable."

    But it can (I say should) be encapsulated in a macro, so that porting is simply a matter of suitably redefining the macro.
    Similarly for all other compiler-specifics.

    "The compiler will generate quite different code in each case."

    Absolutely.
    Why would Keil bother to dream up this special syntax if it made no difference?!

Children
No data