Hello all. I'm using 0x80000(, 0x90000..) as a mspace for external eeprom(s). Is there a way to avoid to check the (valid) mspace of constants? Or even better, to add a 'new' memory space?
#define T_SIZE 16 #define P_SIZE 4*T_SIZE #define Params_E (0x080000 | 0x0140) #define ParamTab_E(n) (Params_E+n*T_SIZE) #define Param_Chk_E (Params_E+P_SIZE) unsigned char * pp; unsigned char tmp = 0; // This doesn't work pp = (unsigned char *)0x80050; // This does work pp = (unsigned char *)(0x80000 | tmp); // This doesn't work pp = (unsigned char *)Params_E; // This doesn't work pp = (unsigned char *)ParamTab_E(0); // This does work pp = (unsigned char *)ParamTab_E(tmp); // This doesn't work pp = (unsigned char *)Param_Chk_E;
I'd suggest reading the compiler manual sections on "far" pointers and pointer types. Non-far pointers in Keil C are only 16 bits wide. You can't stuff an address like 0x80000 in them. That would require an "unsigned char far *". You'll also be interested in the contents of absacc.h, including the FVAR / FCVAR macros. These macros take care of the conversion for the memory type byte in the "generic" pointer.
Thanks Drew, That's just what I have been searching for. I'll have to write an ASM-driver and voila. I have used something like this to avoid the error message:
unsigned int temp; unsigned int * anypointer; temp = 0x1234; // some address in eeprom anypointer = 0x80000 | temp; if ( (*(char *)anypointer) == 8 ) .. // special routine for eeprom else .. // ordinary memory handling
Look in your Keil\C51\Examples folder for examples of accessing EEPROM like this. I think the driver or compiler handles the decision on which memory handling to use - I don't think it needs to go in your application software?