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.
Why does declaring a bit within a function like this not work? void function() { data bit pushbutton_dn = (dwrxbuf[3] == PB_DN); } This results in the pushbutton_dn getting assigned to 0x0E.1 The list file places the results of this operation in 0x25.5 Any help?
That's the way it is - bits must be declared in 'global' space. IMO, The Keil documentation is not at all clear about any of their bit-handling extensions. The manual unhelpfully says, "A bit variable is declared the same as other C data types" - but, as you have just found, there are several Gotchas! because they are not "the same as other C data types!" See also the section "Trouble with the bdata Memory Type" in Appendix F BTW: Why did you entitle this, "Compiler Change?" AFAIK it's always been that way.
Actually Vers 4 and 5 of the compiler allowed this with no problem. I have compiled this code with all three versions of the compiler. The only one that has a problem is ver 6. I'm not using sbit or bdata, just bit. That should allow me to assign a bit in data space between 0x20 and 0x2F to the variable. BTW I removed 'data' from the original declaration 'data bit pushbutton_dn = ...' and it seemed to work. But will I have to dig through a few thousand lines of code to make sure that this isn't happening elsewhere?
Maybe the problem is with the 'data' declaration. Since the bit type is going to be placed in data space, perhaps the latest compiler gets confused. You might also consider using: #define BIT bit this allows you to port your code between different compilers without rewrite. As an example, in a target for an X86 - #define BIT would compile the code properly. You could also make version specific: #if __C51__ == 5 #define BIT data bit #endif #if __C51__ == 6 #define BIT bit #endif in case you need to compile with either.