Addressing additional EEPROMs

Bill Chennault

All--

During my perusal of myriad data sheets and other documentation today, I ran across a reference to the ability of the BS2 to address a "bank of EEPROMs" as made possible by SOME PBASIC COMMAND. It was my intent to look it up when I got home. (I really wish work did not interfere! It won't much longer.)

When I got home, I couldn't exactly remember what the reference said. But, the PBasic's EEPROM command seemed logical, so I read it . . . again. Once again, I found nothing in it that seemed to imply an EEPROM other than the "on-board" device.

Is there more to the EEPROM command than I am understanding or is there another command or commands I should read about? (I am reading all of them, but I am doing a lot of parallel reading regarding things that interest me the most.)

--Bill
ps I have the Stampworks kit, the Homework stuff, and some other kits, I have not cracked them open, yet, due to an ENORMOUS tile job I took on here on the home front. Although it·is turning out very well, I could not even SPELL mortar when I·started it. Do you have any idea of the restraint this entails? [noparse]:)[/noparse]

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You are what you write.

Mike Green

The BS2 program memory space is divided up into 2K "banks". Clearly, the BS2 has only one "bank", but the other Stamp BS2 models have from 4 to 8 "banks". On the BS2 prior to the BS2p series, you could only address the current "bank" for the READ/WRITE statements. You could have a separate program in each bank and they could transfer control from one bank to another (from the beginning of the program) and have common variables. The BS2p introduced the STORE statement which allowed you to store and retrieve data from another "bank". That way you could use the BS2pe's 16K of EEPROM for data logging much more easily.

It is possible to connect external EEPROM to a Stamp. It's easiest with the BS2p series' I2CIN and I2COUT statements. You can add up to 512K for each of two sets of two pins you can dedicate to this. It can't be used for program storage, but you can use it for data (not variables, kind of like having a disk drive attached).

Gadgetman

It can be used for program storage, but on the BS2p/pe/px series, where you can store 2K program images on the extra EEPROMs, then copy them into a slot on the BS2p whenever you need to run code stored in the EEPROM.

I wouldn't reccommended it for often-used program-parts, though, as it'll burn out the EEPROM on the BS2p sooner.

It can also be used for 'customisation data' like a set of language-dependent text strings. When the unit starts, it asks the user which language he prefers, then loads those blocks into free slots. (Assuming the user doesn't switch languages every time, it shouldn't burn out the EEPROM too soon, and the speed increase from using 'internally accessible' EEPROM instead of external I2C EEPROMs wouldn't hurt... )

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...

Bill Chennault

Mike and Gadgetman--

Thank you. I simply could not remember the STORE command for the life of me. Additionally, I understand your caveats in using the EEPROM.

--Bill

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You are what you write.

Chris Savage

Mike Green said...(trimmed)
The BS2 program memory space is divided up into 2K "banks". Clearly, the BS2 has only one "bank", but the other Stamp BS2 models have from 4 to 8 "banks". On the BS2 prior to the BS2p series, you could only address the current

Mike,
·
·· Just a small correction…The BS2 does have a single 2K EEPROM for program/data, however all other BASIC Stamps past that have 8 slots for program/data, while the BS2pe adds an additional 8 slots for data only.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support

allanlane5

You CAN use external SPI interfaced EEPROMS pretty simply, and those are MUCH more easily replaced when they wear out.

Tommy Bot

Gadgetman said...

... I wouldn't reccommended it for often-used program-parts, though, as it'll burn out the EEPROM on the BS2p sooner. ...

I understand consecutive writes (millions) to an EEPROM burning one up·but reads from them should have no effect at all.

Did I miss where the conversation went or am I mistaken?

If you have program data stored in the EEPROM (semi permanantly) and copy from it from·when needed, it should last forever...theoretically.... in a vacuum.... in a controlled environment.... on a Tuesday ..... if you breath right...


Now if I missed the boat, and you meant data that is aquired (by the program) and thus stored in EEPROM, then please forget the rambling.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
(Frequently heard from other's)

Tommy, I know it wasn't designed to·x, but can you make it·do x·anyway?

·

Mike Green

I think Gadgetman was referring to data acquired by a program and stored in EEPROM.

It's the writing to the EEPROM that's the problem eventually. The chip is forcing charges into an oxide layer where they indicate a zero. An erase clears the charges out, but it's not 100% efficient. Eventually some charge stays there and can't be removed. That's the wear-out.

Gadgetman

One point...

There's talk about 'millions of writes', but some chips can fail already after 10.000 writes to the same location.
(I believe that 100.000 is more common, though)

Anyway, it could have been worse...
[noparse][[/noparse]trivia]
One of my vintage PDAs store the user's data on EPROMs(yes, the oldfashioned ones with a small glass window), and you have to use an UV-light to erase the chips when they become full. Those chips usually fail at much fewer write/erase cycles.
[noparse][[/noparse]/trivia]

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...