in byte registers ,it declares sfr CMP1 = 0xAC; sfr CMP2 = 0xAD; while in bit registers it declares sbit KB7 = P0^7; sbit T1 = P0^7; sbit KB6 = P0^6; sbit CMP1 = P0^6; sbit KB5 = P0^5; sbit CMPREF = P0^5; sbit KB4 = P0^4; sbit CIN1A = P0^4; sbit KB3 = P0^3; sbit CIN1B = P0^3; sbit KB2 = P0^2; sbit CIN2A = P0^2; sbit KB1 = P0^1; sbit CIN2B = P0^1; sbit KB0 = P0^0; sbit CMP2 = P0^0; Is it a error? IDE-Version: uv ision3 V3.30 C Compiler: C51.Exe V8.02 thanks
the problem here is that Keil "mindlessly" makes a .h file (no blame, what else can they do). Then when the chip has a SFR, a bit and a pin with the same name which may not be too confusing in a datasheet, the "mindlessly" generated .h end up with such errors. for this reason and the one below I never use the "canned" .h files. A real problem with the "usual" names of SFRs and bits is that a global search will never get all uses of a certain bit and I can tell of numerous cases where a "hidden" use of a bit caused a lenghty debugging session. you may have setb TR0 and mov TCON, #010h and you will miss one or the other when you search. my .h files look like this (an extract related to TR0)
sfr SF_TCON = 0x88; sbit SB_TCON_TR0 = 0x8C; #define SM_TCON_TR0 0x10 making the above setb SB_TCON_TR0 and mov TCON, #SM_TCON_TR0
"the problem here is that Keil "mindlessly" makes a .h file..." The problem is the file that doesn't even compile! The file should not have been released if it doesn't even compile!
The file should not have been released if it doesn't even compile! agreed Erik