Hello Victor,
I think the first question should be: do you want the linker to locate the
variables in eeprom or would you like to have control over what ends up
where? The latter is often better if you intend to have firmware upgrades
in the future but with the same eeprom contents (e.g. calibration data).
Second, is there anything else mapped in xdata? Does the AT89C51ID2 even
have an external memory interface? Are xdata addresses by any chance not
completely decoded resulting in mirrored access? I.e. what happens when
you write 0x0000 and read 0x1000 (or 0x8000)?
Maarten
> Hello,
>
> I have a problem handling the internal EEPROM feature of an Atmel chip. If
> anyone could show me how this should be handled, I would be grateful.
>
> I have been using an AT89C51ID2 chip that features 2 kbytes on chip
> EEPROM.
> The address space of the EEPROM is shared with the on chip expanded ram as
> follows.
>
> On chip expanded RAM: Starts at 0x0000 and ends at 0x06FF
> On chip EEPROM: Starts at 0x0000 and ends at 0x7FF
>
> Both must be accessed using XRAM memory space (i.e. use either movx
> @dptr,a
> or movx a,@dptr.) In order to select the EEPROM, the EEE bit (bit 1) of
> EECON register (0x00D2) must be set.
> Up to this point this is straightforward for me; however, in order to
> handle the EEPROM memory I am defining variables and structures. For
> example for an structure I define the following:
>
> struct CONFIG {
> uint8_t item1; // 8 bits EEPROM item
> uint16_t item2; // 16 bits EEPROM item
> uint32_t item3; // 32 bits EEPROM item
> };
>
> Then I define variables in XDATA memory:
>
> __xdata CONFIG configuration;
> __xdata uint8_t eeprom_variable; // Independent EEPROM variable
>
> A set service function take the address of the variable and handles the
> EEPROM writing and reading:
> void eeprom_write_8 (unsigned int address, uint8_t data);
> void eeprom_write_16 (unsigned int address, uint16_t data);
> void eeprom_write_32 (unsigned int address, uint32_t data);
> uint8_t eeprom_read_8 (unsigned int address);
> uint16_t eeprom_read_16 (unsigned int address);
> uint32_t eeprom_read_32 (unsigned int address);
>
> As you may see, the problem with this approach is that the linker won't
> have any clue whether any of these variables belong to the EEPROM or the
> internal extended RAM. As a result, the extended RAM variables will be
> mixed with the EEPROM variables. A second drawback is that the useful
> space
> will be reduced for both devices due to the fact that their memory
> addresses are overlapped.
>
> In order to pack EEPROM variables in a contiguous space I can define the
> EEPROM variables in PDATA space. This puts RAM variables just after EEPROM
> variables but reduces the EEPROM address space to 256 bytes.
>
> The specific questions would be. Is there any way to tell the linker that
> the address space is shared? is there any possibility to define an
> additional address space?
>
> I have been looking for an answer online but the closest reference is
> this:
> https://sourceforge.net/p/sdcc/mailman/message/9280573/
>
> Thank you for taking the time to read.
>
> Best regards,
> Victor
------------------------------------------------------------------------------
_______________________________________________
Sdcc-user mailing list
Sdcc-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user
