EEPROM for Propeller 1
Tymkrs
Posts: 539
in Propeller 1
Hi all,
Just wanted to see what eeproms folks have used with their Propeller 1 designs? We tend to use 24LC512 and aren't terribly interested in the problem associated with SD cards, so seeing if anyone has used any other options that can hold more?
Thanks!
Comments
The 24FC1026P obviously is a bigger EEPROM option. You can also just stick 4 of those on the bus for 512K total capacity.
Various SPI flashes should also work, but you may need to write the driver yourself.
There isn't really any problem at all with SD cards, the drivers for P1 are stable.
Me, too. On a recent project, however, I needed far more storage than we could get with an EEPROM, so we went with a Flash chip. I was able to prototype generic Spin routines on my P2 Eval and get them to work on the P1. To be honest, we didn't use the Flash very efficiently, but it served the customer's purpose.
I replaced the 64KB EEPROM on my USB Project Board with two AT24CM02 chips (256KB X 8 or 2Mb) for a total of 512KB X 8 (4Mb).
As it turns out I probably could have just used a single AT24CM02 because so far my C program is around 128KB in size, and likely won't exceed 256KB. But the extra storage is there if I need it.
Obviously if the code exceeded 512KB I would have to look into the Flash memory option that @JonnyMac mentioned above.
Thanks for these suggestions all!
We have been using the FM24VN10-G 1Mb F-RAM (Cypress) 128Kx8 (1024K bit) on I2C for program and data with good success. This is the largest F-RAM on I2C. Larger F-RAMs are SPI.
Is this the latest thread on this subject?
Looking to try something new...
This one looks like it might work:
https://www.digikey.com/en/products/detail/microchip-technology/24CSM01T-I-SN/22194132
Supports 3.4MHz I2C is bigger, costs less, and has extra features...
Think it would work?
That's got a lot of space but you'll have to write a custom object to deal with the addressing and other features. It puts bit16 of the byte address into the device ID -- writing a single byte would look something like this:
Might be worth it, though. I've got to order some parts this week so I might get one and give it a try.
Interesting... It is sorta like two 512k chips on same bus with different A0 addresses...
Imagining will show up as at least 3 devices in i2c scanner....
I think two devices: one at %1010_0000 and the other at %1010_0010 -- this assumes that the A1 and A2 pins on the chip are pulled low.
@Rayman,
It's interesting you posted this because I bought several of these a while back to replace the existing EEPROM on my FLiP module. BUT, I haven't installed it yet so I can't give you a report as to whether or not it works. The FLiP module victim appears to have "walked away" from my workbench so I will have to locate and retrieve it first. The TSSOP form factor is a precise match to the existing 64KB chip so physically it would be a drop-in replacement.
If it does work it will solve the Menu storage problem I was having some time ago by allowing a block of Menus to be stored in upper memory. I've tested this concept using the existing 64KB EEPROM and it worked. I assigned one Cog to handle the human interface and it ran under the XEPROM memory mode supported by Catalina and happily fetched the Menus from upper memory and displayed them. The speed was surprisingly acceptable considering the Cog kernel had to fetch both its instructions and Menu items from the EEPROM. Many thanks to @RossH for supporting direct Cog execution from EEPROM and a really cool way to store and fetch the Menu items. If the kernel was upgraded to support the 3.4Mbps mode then the Menus should really fly.
I look forward to your report on how this 128KB chip works, and if it does, that might serve as motivation for me to proceed to replace the 64KB chip with this 128KB one -- or perhaps "farm out" this modification to a company willing to do it. I'm hoping someday Parallax will offer a 128KB option for their future versions of the FLiP.