Reply by Tim Mitchell February 26, 20042004-02-26
In article <103rd2nouv2713c@corp.supernews.com>, Neil Bradley 
<nb_no_spam@synthcom.com> writes
>"andrew queisser" <andrew.queisser@hp.com> wrote in message >news:403cd65f$1@usenet01.boi.hp.com... >> I've got a Atmel 8051 (T89C51RD2) with 64K flash. Can >> I use part of the program flash for data storage? > >Yes. My product does this with this exact part (T89C51RD2). An upcoming one >does it with the AT89C51RD2. > >> datasheet it seems like I should be able to use the on-chip >> low-level routines to program up to 128 bytes with the >> PROGRAM DATA PAGE call and read bytes with the >> MOVC opcode. > >Correct. > >> I'm envisioning reading some data from flash into RAM, >> doing some processing and then writing it back to flash. >> >> Are there fundamental problems with this approach? The >> datasheet is a bit vague but it doesn't mention any restrictions >> on a user application reprogramming the flash, other than >> the process being a bit slow and good for only about 100K >> times. > >You'll find it'll take around 20-30ms for a write whether you're writing 1 >byte or 128 bytes. Fortunately you don't need to erase any pages - you just >write the data where you want it. Also, to help alleviate wear patterns, you >can consider doing a compare before a write so you don't rewrite the same >data and degrade the cell. > >> By the way, is the 100K per byte, per page or for the whole >> flash area? > >It's *PER CELL* (per bye that is) per my conversation with an Atmel engineer >(not a rep). >
It's 100K for each bit. i.e. you can change the state of a bit 100K times. Actually I have been told by an Atmel engineer that the Flash uses the same technology as the EEprom, so the number of rated cycles is actually 1 million, but they are not able to test it the same way because it's slow, so they are only claiming 100K. If you aren't aware, the T89C51RD2 is being discontinued. If this is a product for manufacture you should switch to the AT89C51RD2 (no EEPROM) or AT89C51ED2 (with EEPROM). The on-chip bootloader arrangements are different in the AT.. chips from the T.. chip. -- Tim Mitchell
Reply by Neil Bradley February 26, 20042004-02-26
"andrew queisser" <andrew.queisser@hp.com> wrote in message
news:403cd65f$1@usenet01.boi.hp.com...
> I've got a Atmel 8051 (T89C51RD2) with 64K flash. Can > I use part of the program flash for data storage?
Yes. My product does this with this exact part (T89C51RD2). An upcoming one does it with the AT89C51RD2.
> datasheet it seems like I should be able to use the on-chip > low-level routines to program up to 128 bytes with the > PROGRAM DATA PAGE call and read bytes with the > MOVC opcode.
Correct.
> I'm envisioning reading some data from flash into RAM, > doing some processing and then writing it back to flash. > > Are there fundamental problems with this approach? The > datasheet is a bit vague but it doesn't mention any restrictions > on a user application reprogramming the flash, other than > the process being a bit slow and good for only about 100K > times.
You'll find it'll take around 20-30ms for a write whether you're writing 1 byte or 128 bytes. Fortunately you don't need to erase any pages - you just write the data where you want it. Also, to help alleviate wear patterns, you can consider doing a compare before a write so you don't rewrite the same data and degrade the cell.
> By the way, is the 100K per byte, per page or for the whole > flash area?
It's *PER CELL* (per bye that is) per my conversation with an Atmel engineer (not a rep). -->Neil
Reply by Jim Granville February 25, 20042004-02-25
andrew queisser wrote:
> I've got a Atmel 8051 (T89C51RD2) with 64K flash. Can > I use part of the program flash for data storage? From the > datasheet it seems like I should be able to use the on-chip > low-level routines to program up to 128 bytes with the > PROGRAM DATA PAGE call and read bytes with the > MOVC opcode. > > I'm envisioning reading some data from flash into RAM, > doing some processing and then writing it back to flash. > > Are there fundamental problems with this approach? The > datasheet is a bit vague but it doesn't mention any restrictions > on a user application reprogramming the flash, other than > the process being a bit slow and good for only about 100K > times. > > By the way, is the 100K per byte, per page or for the whole > flash area?
The FLASH loaders are mainly for ISP/IAP, but you can use them for data storage,with these caveats - During WRITE, normally the core idles (ie your app needs to tolerate disable of INTS, and pause for the PGM time. This is because a single FLASH plane cannot write and read at the same time. - Some allow Partial page writes, some do not. You should also look at the newer Atmel AT89C51ED2/RD2/ID2 devices. -jg
Reply by Max February 25, 20042004-02-25
On Wed, 25 Feb 2004 09:03:33 -0800, andrew queisser wrote:

>Are there fundamental problems with this approach? The >datasheet is a bit vague but it doesn't mention any restrictions >on a user application reprogramming the flash, other than >the process being a bit slow and good for only about 100K >times.
It's the "about" 100K that's the only real problem. Flash (and EEPROM) memories wear out, but it's difficult to predict when.
>By the way, is the 100K per byte, per page or for the whole >flash area?
Per page, usually. You can only erase a page at a time. But endurance is very dependent on other considerations, particulalry the frequency of writing. If you are re-writing the Flash several times a second, then don't expect to get more than 10K or so cycles from it. Microchip provide documentation, and a free software tool, for estimating the endurance of their EEPROMs according to your design parameters. Do Atmel have anything similar? -- Max
Reply by andrew queisser February 25, 20042004-02-25
I've got a Atmel 8051 (T89C51RD2) with 64K flash. Can
I use part of the program flash for data storage? From the
datasheet it seems like I should be able to use the on-chip
low-level routines to program up to 128 bytes with the
PROGRAM DATA PAGE call and read bytes with the
MOVC opcode.

I'm envisioning reading some data from flash into RAM,
doing some processing and then writing it back to flash.

Are there fundamental problems with this approach? The
datasheet is a bit vague but it doesn't mention any restrictions
on a user application reprogramming the flash, other than
the process being a bit slow and good for only about 100K
times.

By the way, is the 100K per byte, per page or for the whole
flash area?

Thanks,
Andrew Queisser