Hello Victor, > Thank you for your response. As I think over about this issue, I wonder > how did Atmel guys thought this should have been addressed from the > compiler/linker perspective. > > In the AT89C51ID2 chip DATA/IDATA, XDATA and EEPROM are all overlapped > (i.e. all three begin at address 0x0000). The internal extended RAM can be > configured to have different sizes ranging from 256 bytes up to 1792 > bytes.
DATA/IDATA is a different memory space from XDATA. The mcs51 uses different instructions to access them. > The chip indeed has an external memory interface: "access to external data > memory locations higher than the accessible size of the XRAM will be > performed with the MOVX DPTR instructions in the same way as in the > standard 80C51, with P0 and P2 as data/address buses and P3.6 and P3.7 as > write and read timing signals". The higher addressable external memory is > 0xFFFF so there is no mirroring of the internal extended RAM. Ok, clear. I asked because there are other mcs51 derivatives that do not have this. > I will try to answer your first question this way: I would like the linker > could handle the EEPROM as an additional memory space so that addresses > are calculated by the linker automatically (i.e. by defining an alternate > descriptor like __eeprom) so that I don't have to maintain an EEPROM > address table. However, I don't think it would be the job of the compiler > to generate the code to write to the EEPROM because other chips might > handle the internal EEPROM differently. Going a step further, if I > switched to a 2 wire external memory I would only change the EEPROM > read/write drivers but use the same data definitions. Embedded C has defined named address spaces for this purpose. However, I don't know if this is supported yet by SDCC for the mcs51. If it is supported (please try it out, see the manual) then it's probably easiest to place the named address space at a different offset and subtract/mask that offset in the access functions. Maarten ------------------------------------------------------------------------------ _______________________________________________ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
