??? 03/24/10 14:21 Read: times |
#174476 - Sample code? Responding to: ???'s previous message |
It seems like you have a chip where the EEPROM can store 3kB of runnable (boot) and 1kB of variables.
The 32kB of flash is the normal code area. Flash is a kind of EEPROM that allows large sectors (or sometimes the full chip) to be erased in a single operation. A normal EEPROM performs erase and write cycles for the individual bytes, which is quick and works well for storing configuration. But it takes more time to reprogram several kB of data into an EEPROM than into a flash chip. Without reading the datasheet for your specific chip, you should normally be able to keep the EEPROM area mapped into the XDATA memory space. But that means that you must make sure that the compiler doesn't put variables you need access to into the same memory range. The compiler will assume that the configuration bit is correct, so that accesses to the XDATA range does access the intended variables. It almost seems like the EEPROM memory is flash memory. When you modify data, the memory is splitted into many small (and aligned) 128B pages. The processor allows you to write from one and up to 128 bytes into a small memory buffer before permanenting the data into the EEPROM. Most probably, the datasheet will mention a single bit or a byte somewhere in the EEPROM configuration registers that will force a "flush" of this little buffer, making your changes (of between 1 and 128 bytes) permanently written into the EEPROM. Stretching MOVX in this case is that you reconfigure the memory interface so that the processor adds extra dummy clock cycles when performing the memory accesses. These extra wait states makes sure that the EEPROM memory will manage to keep up. Most non-volatile memory technologies are slower than RAM - especially when comparing to static RAM. The EEPL bits are the acknowledge bits that any pending changes you should result in an erase/copy/burn of a 128 byte page of the EEPROM memory. Besides the datasheet - haven't you found any sample applications for the processor? Documented sample code can come a long way helping to explain the very technical text from the datasheet. |
Topic | Author | Date |
Atmel 89C5131A-UM Internal memory programming | 01/01/70 00:00 | |
compiler specific | 01/01/70 00:00 | |
Reply | 01/01/70 00:00 | |
Sample code? | 01/01/70 00:00 | |
Timers | 01/01/70 00:00 | |
Timers Reply | 01/01/70 00:00 | |
Have you looked at the tutorials yet? | 01/01/70 00:00 | |
it's all for assembler - but that doesn't matter! | 01/01/70 00:00 | |
Huge amounts of data | 01/01/70 00:00 | |
disregard the large numbers | 01/01/70 00:00 | |
No compiler support for EEPROM | 01/01/70 00:00 | |
compiler handling the EEPROM transparently | 01/01/70 00:00 | |
I did not know Keil helper functions. | 01/01/70 00:00 | |
It's part of the "xdata banking" support | 01/01/70 00:00 | |
Previously, on 8052.com...![]() | 01/01/70 00:00 |