Shop OBEX P1 Docs P2 Docs Learn Events
Smaller memory EEPROMS — Parallax Forums

Smaller memory EEPROMS

PhilldapillPhilldapill Posts: 1,283
edited 2009-01-07 18:45 in Propeller 1
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?

Comments

  • Harrison.Harrison. Posts: 484
    edited 2009-01-07 07:22
    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)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2009-01-07 07:28
    This identical question was raised just a couple weeks ago here.

    -Phil
  • PhilldapillPhilldapill Posts: 1,283
    edited 2009-01-07 08:22
    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)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2009-01-07 08:36
    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.

    -Phil
  • PhilldapillPhilldapill Posts: 1,283
    edited 2009-01-07 08:40
    You're right. This trouble isn't worht $0.50 on a $150 unit. LOL Thanks anyway.
  • Beau SchwabeBeau Schwabe Posts: 6,560
    edited 2009-01-07 17:55
    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

    IC Layout Engineer
    Parallax, Inc.
  • TJHJTJHJ Posts: 243
    edited 2009-01-07 18:35
    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.

    TJ
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2009-01-07 18:45
    Beau,

    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.

    -Phil
Sign In or Register to comment.