View Full Version : Smaller memory EEPROMS

01-07-2009, 02:04 PM
Just curious if other eeproms can be used, besides the 24LC256? How about the 24LC128 since these are a little cheaper... I'm sourcing parts for a high volume product using the propeller and the standard eeprom, but I want to keep costs to a bare minimum. Can these chips be used?

01-07-2009, 02:22 PM
Make sure you look at both Microchip and Atmel parts. The Atmel parts don't have a L in the part number (24C256 instead of 24LC256), so they might not come up on product searches on Mouser / Digikey. Atmel tends to be cheaper than Microchip for eeproms, although this is somewhat dependent on the distributer.

Phil Pilgrim (PhiPi)
01-07-2009, 02:28 PM
This identical question was raised just a couple weeks ago here (http://forums.parallax.com/showthread.php?p=771981).


01-07-2009, 03:22 PM
Ah ha! So it was, Phil. However, Mike said that the process will fail when the propeller tries to program the eeprom. He did not say that the eeprom couldn't be programmed... just that it would give an error upon verifying it... If you reset the propeller with the eeprom programmed, would it read it in like normal?

Phil Pilgrim (PhiPi)
01-07-2009, 03:36 PM
It would not even program correctly, because the second 16K of EEPROM data would overwrite the first 16K when the EEPROM is programmed. Also, when read, the first 16K will be duplicated in the second 16K of RAM. Even if the EEPROM had been programmed correctly, this could cause a problem since unprogrammed (i.e. upper memory) bytes are supposed to be zeroed. These may not be insurmountable issues, but they'd be a mess to work around. In my mind, it's not worth the effort.


01-07-2009, 03:40 PM
You're right. This trouble isn't worht $0.50 on a $150 unit. LOL Thanks anyway.

Beau Schwabe (Parallax)
01-08-2009, 12:55 AM
The only way that I see that it might work is if you program the smaller memory separately and then insert it into the Propellers circuit. Otherwise as it has been said the "blank code" in the upper memory will overwrite the "valid code" in the lower memory due to the memory address wrapping around. Programming the smaller memory separately will prevent it from being overwritten. The consequence would be, and I'm not sure that it would matter much anyway, would be that when the Propeller reads the smaller memory, there will be two copies within the Propeller. As I said it may not matter much, because the internal second copy will never be executed in code because the programming pointer will never reach it. (never say never) With a few programming tricks you could make the jump, but again since it would be identical code I don't think you could benefit much.

Beau Schwabe (mailto:bschwabe@parallax.com)

IC Layout Engineer
Parallax, Inc.

01-08-2009, 01:35 AM
You might want to consider buying them from MicroChip direct. The site is showing 1.08 in single volume pricing versus 1.30 from mouser.

I am not sure how but in the past when I order parts from MicroChip direct, they come from Thailand, but I get them faster than I get parts from mouser, Digikey, or newark using UPS. Usually I get them in 3 days. On the west coast.

Dont be hesitant to order direct from microchip. In my experience they are quite fast in shipping even though they come from Thailand, and the shipping was no more than a distributor cost for UPS ground.


Phil Pilgrim (PhiPi)
01-08-2009, 01:45 AM

Short of preprogramming the EEPROM, the .eeprom file could be massaged by copying the first half to the second half. Then it would upload and program okay -- I think.

I was also concerned about stack initialization, since that will be in upper memory and won't receive the usual zero initialization. OTOH, it's a stack and shouldn't need initializing. Non-zeroed extended variable and video buffer space may be a problem, though, so a zeroing phase would have to be performed upon startup (being careful not to encroach upon an already-growing stack). The way to do this would be to zero every long in upper RAM that has a non-zero counterpart in lower RAM.

If the Prop performs a checksum upon reading EEPROM, the duped image shouldn't cause a problem, since both halves will sum to zero anyway.

But all in all, it's too messy just to save a few pennies, IMO.