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.
I tried to submit this via the email to tech support page but it gave me a 500 error. I have a hard time believing that I am the only person this has happened to, but clearly this is a compiler bug in Keil 8051 version 7.5 compiler. I hope that someone can get this to the correct person at Keil.
4747 1 if(chksum != CWORD[0xF800]) 4748 1 { 4749 2 cstate=1; 4750 2 } 4751 1 if(chksum != CWORD[0xF900]) 4752 1 { 4753 2 cstate=1; 4754 2 } 4755 1 if(chksum != CWORD[0xFA00]) 4756 1 { 4757 2 cstate=1; 4758 2 } 4759 1 if(chksum != CWORD[0xFB00]) 4760 1 { 4761 2 cstate=1; 4762 2 } 4763 1 if(chksum != CWORD[0xFC00]) 4764 1 { 4765 2 cstate=1; 4766 2 } 4767 1 if(chksum != CWORD[0xFd00]) 4768 1 { 4769 2 cstate=1; 4770 2 } 4771 1 4772 1 if(chksum != CWORD[0xFE00]) 4773 1 { 4774 2 cstate=1; 4775 2 } ; SOURCE LINE # 4747 0645 90F000 MOV DPTR,#0F000H <<<<<<<<<<<< should be F800 0648 7800 R MOV R0,#LOW chksum 064A E6 MOV A,@R0 064B FE MOV R6,A 064C 08 INC R0 C51 COMPILER V7.50 MEDBEST040_LCD 10/03/2012 12:30:27 PAGE 300 064D E6 MOV A,@R0 064E FF MOV R7,A 064F 7401 MOV A,#01H 0651 93 MOVC A,@A+DPTR 0652 6F XRL A,R7 0653 7003 JNZ ?C1279 0655 E4 CLR A 0656 93 MOVC A,@A+DPTR 0657 6E XRL A,R6 0658 ?C1279: 0658 6006 JZ ?C0032 ; SOURCE LINE # 4748 ; SOURCE LINE # 4751 0660 90F200 MOV DPTR,#0F200H <<<<<<<<<<<<<<<<<<< should be F900 ... ; SOURCE LINE # 4755 0674 90F400 MOV DPTR,#0F400H <<<<<<<<<<<<<<<<<<< should be FA00 ... ; SOURCE LINE # 4759 068F 90F600 MOV DPTR,#0F600H <<<<<<<<<<<<<<<<<<< should be FB00 ... ; SOURCE LINE # 4763 06AA 90F800 MOV DPTR,#0F800H <<<<<<<<<<<<<<<<<<< should be FC00 ... ; SOURCE LINE # 4767 06BE 90FA00 MOV DPTR,#0FA00H <<<<<<<<<<<<<<<<<<< should be FD00 ... ; SOURCE LINE # 4772 06D9 90FC00 MOV DPTR,#0FC00H <<<<<<<<<<<<<<<<<<< should be FE00 While this works. 15430 01 FLSCL=0x01; // enable flash write/erase 15431 01 PSCTL=0x01; // BUGG NOT 2, which would erase flash, but 1write to flash 15432 01 *write_ptr=CBYTE[0xFA00]; 15433 01 PSCTL = 0x00; // MOVX writes target XRAM 15434 01 FLSCL=0; // disable flash write 000C 75B701 MOV FLSCL,#01H ; SOURCE LINE # 15431 000F 758F01 MOV PSCTL,#01H ; SOURCE LINE # 15432 0012 90FA00 MOV DPTR,#0FA00H 0015 E4 CLR A 0016 93 MOVC A,@A+DPTR 0017 8F82 MOV DPL,R7 0019 8E83 MOV DPH,R6 001B F0 MOVX @DPTR,A ; SOURCE LINE # 15433 001C E4 CLR A 001D F58F MOV PSCTL,A ; SOURCE LINE # 15434 001F F5B7 MOV FLSCL,A
You missed the point. You can put an int or a long at any address in the 8051. There is no requirement for an int to live at an address that is even. A macro that allows you to access an integer, should like the char macro, allow you to specify ANY location, even or odd as the base address and index from there in 2 byte increments. The same should hold true for a long.
The two macros should operate identically, just that one returns an integer, and one returns a char. You can after all, says mov dptr,#0xFA01 just as validly as saying 0xFA00.
The point is that macros that access memory, as chars, ints and longs, should allow byte alignment, to be consistent and logical in the 8051 address space.
CBYTE should return a byte at an arbitrary address CWORD should return an integer at an arbitrary address not limited to an even boundary CLONG should return a log at an arbitrary address, not limited to an even boundary, or long aligned boundary
You missed the point.
Actually no, you did. You insist that things "SHOULD" behave in certain ways just because you would like them to. Neither you nor any outside insitution specified the original requirements for those macros' semantics; Keil (or possibly Franklin) did. So you don't get to decide what they should do.
In the absense of any applicable outside standard, the only requirement that could possibly govern what those macros should do is what their author(s) decided. They documented that decision reasonably well. The implementation correctly matches the documentation, and apparently has been the same for more than a decade. That means there's just no way those macros will change semantics now just to satisfy your wishes. It's way too late for that.
In exchange nothing in this world forces you to use those macros if you don't like them --- if you like macros that do things differently, you can go ahead and write them and use those.