Any Benifet Of Increasing EEPROM Memory?

soshimo

I just got a couple of sample 24aa1024 EEPROMs that I want to try out and was wondering if there is any benefit to using a larger EEPROM or not. Will I be able to access the memory in the EEPROM in my spin code directly or will I have to use i2c? I can always network the chip off the first one and just use straight i2c to access it but was wondering if there is anything built in. TIA

One thing I just thought of was addressing - if the propeller is expecting only 12bit addresses (for the 256k) then it might not know to send the MSBs for the address word.

Mike Green

Although the Propeller Tool and the boot loader don't know anything about EEPROM memory beyond 32K, there are several different I2C drivers that provide access to any other EEPROM attached either to the I2C bus used for loading or any other pair of I/O pins. FemtoBasic allows you to load and store Basic programs and data in EEPROM and can copy programs from the 1st 32K to other 32K "pages", then can later load and execute Spin programs from those 32K areas.· There's a "Propeller OS" that uses the same I/O routines as FemtoBasic and sets up filenames for each 32K area so you can run programs by name and your Spin programs can look up files by name for reading or writing up to 32K of data per file.· The lookup routines return the EEPROM address of the start of the data area.

I just set up 4 x 24C1024B EEPROMs on I/O pins 6 and 7 on a Propeller Protoboard and this'll give me an additional 512K for programs and data using FemtoBasic as the "operating system".

The FemtoBasic / PropellerOS routines use 23 bit EEPROM addresses so you can have up to 512K per pair of I/O pins and you can use multiple pairs of I/O pins for I2C busses.

Post Edited (Mike Green) : 12/23/2008 11:49:00 PM GMT

soshimo

Nice setup Mike! I'll have to take a look at FemtoBasic, it sounds like exactly what I need (or something similar). Correct me if I'm wrong, but it looks like you are using the propeller boot loader as a boot strap for your femtobasic os. If that's the case, very, very cool (if not, I'm sure it's just as cool ). I especially like the paging apsect, though I imagine you would have to be careful in your code (at least in time sensitive areas or tight loops) to avoid cross paging.

Mike Green

The FemtoBasic loader is unrelated to the Propeller's bootloader. It is part of the low level EEPROM I/O routines and SD card SPI I/O routines, runs in its own cog, and includes a loader function (a special case of a block read operation).

mikediv

Yea but Mike don't you need to use the prop IDE to load Femto???

soshimo

mikediv said...
Yea but Mike don't you need to use the prop IDE to load Femto???

That's kind of what I was getting at. A rough analogy to a modern computer would be that the bootloader acts the same as bios does today, rather instead of looking for a bootrecord (femtobasic in this case) on a disk, it looks for it on an eeprom.

On second look - I'm way off. Mike has some pretty cool stuff going on with the femtobasic. Way advanced and beyond my current understanding of the chip - but something to strive for!

Mike Green

Sure, FemtoBasic is written in Spin and assembler and has to be compiled and downloaded initially to the Prop.

Andrew E Mileski

Note that the Propeller boot code only handles 16 bit addresses, so though you can boot from a 32K or 64k part, you may have problems with anything larger that requires a wider address. However once booted, anything can be made to work.