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

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
  • The two methods that you have given are not at all the same. Personally, I would always go for the first method as it is so much clearer.

    The only down-side is that the first method it is absolutly non-portable. The second method will be much more familiar to an ANSI C programmer.

    The compiler will generate quite different code in each case. I'd predict that the first method will cause SETB and CLR instructions to be used (quick and compact) whereas the second method will require a read, ORL or ANL, and a write.

Reply
  • The two methods that you have given are not at all the same. Personally, I would always go for the first method as it is so much clearer.

    The only down-side is that the first method it is absolutly non-portable. The second method will be much more familiar to an ANSI C programmer.

    The compiler will generate quite different code in each case. I'd predict that the first method will cause SETB and CLR instructions to be used (quick and compact) whereas the second method will require a read, ORL or ANL, and a write.

Children
  • The compiler generates the same code. It is smart.

  • "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?!