"theobee00" <yahoodump2@yaho...> wrote: [...] > > Ack, the 4 byte erase sector size is bad. Especially because it's > > hard to sort/align data to 4 byte boundaries. > In the files area on the board here is posted my solution to the > EE problem, it does a logical sort and allows 1, 2, or 4 bytes to > be stored, it aligns on boundaries etc. > Penalty is more work for the EE if you store one or two bytes or > across boundaries, benefit is never having to worry about aligning. That's the problem and what I meant - the program should arrange data on suitable boundaries to avoid data crossing a erase sector boundary. A compiler could do so by grouping different sized EEPROM "variables" and aligning them. Oliver Oliver -- Oliver Betz, Muenchen

--- In 68HC12@68HC..., "Oliver Betz" <list_ob@g...> wrote: > > Jefferson Smith wrote: > > [...] > > > Freescale's point is apparently that they make their EEPROM different > > now than they did with HC912 and earlier. Of course, that did make it > > harder for me since I had to erase 4 bytes (the small sector size) > > instead of one word size (2 bytes on the HC912) > > Ack, the 4 byte erase sector size is bad. Especially because it's > hard to sort/align data to 4 byte boundaries. In the files area on the board here is posted my solution to the EE problem, it does a logical sort and allows 1, 2, or 4 bytes to be stored, it aligns on boundaries etc. Penalty is more work for the EE if you store one or two bytes or across boundaries, benefit is never having to worry about aligning. Cheers, Theo

Jefferson Smith wrote: [...] > Freescale's point is apparently that they make their EEPROM different > now than they did with HC912 and earlier. Of course, that did make it > harder for me since I had to erase 4 bytes (the small sector size) > instead of one word size (2 bytes on the HC912) Ack, the 4 byte erase sector size is bad. Especially because it's hard to sort/align data to 4 byte boundaries. Oliver -- Oliver Betz, Muenchen

--- In 68HC12@68HC..., Steve Russell <stever@n...> wrote: > For additional confusion in HCS-12 parts, Freescale AN2400/D "HCS12 NVM > Guidelines" says: > > >Most HCS12 microcontrollers also incorporate EEPROM that may be used to > >store data variables. HCS12 microcontrollers that do not have EEPROM may > >use Flash to emulate EEPROM, refer to application note AN2302/D for > >details and example software. > > When it is referring to using the flash to store changing data on parts > without a separate "EEPROM" resource. > > Which is a different kind of "EEPROM emulation". > Thanks for the reply. I read that AN too and that makes sense to be called EEPROM emulation because they propose a software solution that makes the flash look like it has a much smaller erase size. To me the difference between EEPROM and flash has always been the erase size; the Freescale engineer apparently implied based on his answer that if the erase size is greater than a word then it is flash but to me a 4 byte sector size would qualify as EEPROM. Anyhow, thanks for the thoughts.

--- In 68HC12@68HC..., Doron Fael <doronf@n...> wrote: > > The term "emulated EEPROM" does not relate to the MC9S12XDP512. Without > going into details, It relates to a future S12X family. Well, good thing we won't go into details because it says the same about the EEPROM in my 9S12DP256. It's not unique to 9S12X, but started apparently with Star12 or S12 or whatever they called it. I don't know if it's easy to extract the simple explanation out of the previous answers, but any explanation is pointless. If there is a point, it is that EEPROM means used as ROM but is electronically erasable, and that does not say anything whatsoever about how it does it. Freescale's point is apparently that they make their EEPROM different now than they did with HC912 and earlier. Of course, that did make it harder for me since I had to erase 4 bytes (the small sector size) instead of one word size (2 bytes on the HC912)

The term "emulated EEPROM" does not relate to the MC9S12XDP512. Without going into details, It relates to a future S12X family. Hope this helps, Doron Nohau HC12 In-Circuit Emulators www.nohau.com/emul12pc.html At 02:53 19/01/2006 +0000, you wrote: >So I've been using the S12XDP512 for quite some time and someone told >me that the Freescale folks said the EEPROM is not "real" EEPROM but >is actually an "emulated" EEPROM. He says this is the case because the >S12X's EEPROM is not byte eraseable and is based on "flash >technology". Does one really call this "emulated EEPROM"? I'm not sure >of the formal distinction between EEPROM and Flash if there is one so >I wanted input from others. > >Thanks.

You've just run across another confusion in the historical progression of "Read Only Memory", a subject that seems unnecessarily confusing. The Answer to Your Question --------------------------- Some of the Freescale documentation explains that the resource called "EEPROM" in the HCS-12 data sheets is, in fact, the same technology used for the resource called "flash". The design of the EEPROM resource is optimized for many erase-write cycles, while the design of the "flash" resource is optimized to take much less die area per bit at the expense of fewer erase-write cycles. If you look at the controller descriptions for these two resources, you will see that they are nearly identical. This is the origin of what you were told. I'm not sure that there is much hope for getting precision in this area, see below. Another Confusion ----------------- For additional confusion in HCS-12 parts, Freescale AN2400/D "HCS12 NVM Guidelines" says: >Most HCS12 microcontrollers also incorporate EEPROM that may be used to >store data variables. HCS12 microcontrollers that do not have EEPROM may >use Flash to emulate EEPROM, refer to application note AN2302/D for >details and example software. When it is referring to using the flash to store changing data on parts without a separate "EEPROM" resource. Which is a different kind of "EEPROM emulation". The History ----------- This is merely the latest in a long line of confusions in naming this technology progression. It started with "Read Only Memory" (ROM), which was originally programmed in manufacture and could not be changed. Then the technology for making the memory write once was developed, and these devices were called "Programmable Read Only Memory" (PROM) rather than the self-contradictory and cumbersome "Write Once Read Only Memory". Then the technology for erasing a programmed part with a strong dose of UV light was developed, and was naturally called "Erasable Programmable Read Only Memory" (EPROM). Then the technology for electrically erasing the part appeared, giving us the "Electrically Erasable Programmable Read Only Memory" (EEPROM). Than the slow writing time was recognized as a problem and a faster write and erase technology was called initially "Flash EEPROM", but this was too long and it got shortened to "flash". Now we have a marketing war of words about "nand flash" and "nor flash". In spite of the layers of marketing hype, what we actually have is a large variety of "slow, complicated write, simple, fairly fast read" (SCWSFFR ?) memories to choose from, each with a different set of specifications. I expect that we will continue to see new technologies, new layers of marketing hype and new confusions in the future. Its traditional! Steve Russell Nohau Emulators At 06:53 PM 1/18/2006, "joshcurtz" <joshcurtz@josh...> wrote: >So I've been using the S12XDP512 for quite some time and someone told >me that the Freescale folks said the EEPROM is not "real" EEPROM but >is actually an "emulated" EEPROM. He says this is the case because the >S12X's EEPROM is not byte eraseable and is based on "flash >technology". Does one really call this "emulated EEPROM"? I'm not sure >of the formal distinction between EEPROM and Flash if there is one so >I wanted input from others. > >Thanks. > >Yahoo! Groups Links > >