Propeller & eprom requirement design

[Agent420]

So I finally have decided to investigate new controllers after many comfortable years using avr's...· The Propeller looks very exciting !

I am however a bit curious why the Propeller has no on-board eprom facilities, requiring the use of a secondary chip for program storage (and perhaps variable storage between runs).· It seems most of the common ucontrollers these days have eeprom as a standard feature.· Are there specific reasons why the eprom was not included in the Propeller?· Is there some beneficial aspect of this deisgn that I am overlooking (and thus not utilizing)?· Or is it perhaps simply a limitation of what could be incorporated within the silicon?

Just wondering...· With the Propeller available in hobbyist friendly dip40 form, you'd think it would be nice to have projects that are 'single chip solutions'... Not that the inclusion of a small eprom chip is that big a deal.

Along those lines...· Does the Propeller require specific types of eprom?· Limited to the 24LC256?

Thanks for any insight into this.

[Mike Green]

1) The manufacturing process used for the Propeller does not support the structures needed for an EEPROM.

2) Any I2C EEPROM should be usable. Only the first 32K is used by the bootloader. The Hydra uses a 128K byte EEPROM. The Propeller Protoboard uses a 64K byte EEPROM. In both cases, the rest of the EEPROM (above 32K bytes) is available for use by the user's program. There are programs available that will load "overlays" from this extra space or use it for data storage.

[Paul Baker]

Thanks for considering the Propeller,

The fab houses which have a dual CMOS EEPROM process require a huge scale (millions/year) to make using the process economically feasible. With it being our first custom designed microcontroller we couldn't be certain we would meet the minimum quantity requirements, so to have produced a chip with EEPROM onboard we would have to charge nearly double for the chip. Not only that but the current die size is 9mm square which is the absolute largest die size accomodated for 44 pin QFP/QFN package, so to fit the eeprom on board we would have had to make it a 4 core processor which we felt was too lacking in it's utility. By not including the eeprom on board we have provided a sweet spot of low power consumption and·fairly high computing power for the least amount of cost given the process and die size.

One last note, an benificial side effect to placing the eeprom external to the chip is that your·able to perform some on the fly program banking. It's somewhat complex but there are libraries already availible which enable you to fetch a binary image from eeprom or SD card and reboot the Propeller with the different image (the Propeller cannot be directly loaded from the SD card, but a simple bootstrap program can make it appear as though thats is what's happening).· I have used this ability to create a demonstration program which has an interactive (VGA + mouse) menu system to choose an example program which is then run on the same chip (to return to the menu you press the reset button)·I use this setup at trade shows to demostrate the Propeller's capabilites.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker (mailto:pbaker@parallax.com)
Propeller Applications Engineer
[/url][url=http://www.parallax.com] (http://www.parallax.com)
Parallax, Inc. (http://www.parallax.com)

Post Edited (Paul Baker (Parallax)) : 5/1/2008 11:48:17 PM GMT