EEPROM size limit
Lucky
Posts: 98
Is the size of the EEPROM connected to the prop for program storage limited to 32KB or can it be larger?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"You do not really understand something unless you can explain it to your grandmother."
-Lucky[size=-1][/size]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"You do not really understand something unless you can explain it to your grandmother."
-Lucky[size=-1][/size]
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"You do not really understand something unless you can explain it to your grandmother."
-Lucky[size=-1][/size]
If you want your Propeller program to access data above 32K then you need to include an I2C driver in your program to do it.
How you actually program data into the EEPROM above 32K such that it is there on start up is up to you. I would use a Prop to do it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Catalina allows up to 64K of an EEPROM to be used as program space by segmenting programs to be loaded from EEPROM into two sections - first, a self-contained SPIN/PASM initialization program is loaded (as normal) from the first 32K of the EEPROM. This program sets up all the drivers and plugins - e.g. VGA/TV, keyboard, mouse, floating point libraries, real-time clock, SD card access etc etc. The last thing it does is load the C/PASM code from the second 32k of the EEPROM and kick it off.
The upshot of all this messing about is that larger C programs can be loaded into the Propeller, since the C program itself doesn't have to waste space on initialization code that is only executed once and then discarded - i.e. the full 32k is available as C program space if required.
Of course, Catalina only generates the 64K EEPROM image - actually loading the EEPROM in the first place is another problem - on the Hydra I use the Hydra Asset Manager. On other platforms you are on your own.
See the Catalina documentation for more detais on it's EEPROM Memory Model (EMM) mode - in particular, the file "Catalina_EMM_EEPROM_Loader.spin". This could be adapted for use with normal SPIN/PASM programs.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"You do not really understand something unless you can explain it to your grandmother."
-Lucky[size=-1][/size]
Yes they are.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"You do not really understand something unless you can explain it to your grandmother."
-Lucky[size=-1][/size]
·http://obex.parallax.com/objects/539/
Jim
FullDuplexSerial won't work. That's an asynchronous serial I/O driver and not everything serial is the same. I2C is a completely different serial protocol. There are Wikipedia articles on both that show the differences.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"You do not really understand something unless you can explain it to your grandmother."
-Lucky[size=-1][/size]
Easy. Just don't use the i2c driver to write addresses 0->$7FFF. Start writing at $8000 and you are good to go. The Propeller won't overwrite those when downloading an updated program, and your i2c driver won't overwrite the propellers code.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
BradC,
How do I get 32KB of information into the last 32KB of the EEPROM? I know the process, but I don't quite understand were to store the last 32KB of data. Would you save the 32KB you want to add to the EEPROM in a file on the computer and then the propeller reads it and transfers it to the EEPROM? You can't store 32KB of data on the propeller with the program to transfer the data to the EEPROM because that would be over 32KB for program space.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"You do not really understand something unless you can explain it to your grandmother."
-Lucky[size=-1][/size]
Sorry, yes.. that is precisely how to do it. As Ross pointed out above, seek out HAM (Hydra Asset Manager). Provided you run Windows, it will allow you to pre-program other parts of the EEPROM aside from the 32k program segment.
Or alternatively, grab some of the various X/Y modem objects around and write your own little downloader to stuff the data where you need it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
If you really want to write the whole 32k you can split the data into 2 files and create 2 such programs.
I think this is easier than having a program for XMODEM transfer from PC to Propeller to EEPROM.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Safety Tip: Life is as good as YOU think it is!
I have crossed over into the land of FPGA exploration and desire to upgrade my BeMicroCV to the largest compatible EEPROM so that it will still work with the original Propeller PNut loader.
Not all big EEPROMs are compatible, or so I have been led to believe.
I have a couple of 128Kx8 choices -- Atmel (at $1.90USD) and Microchip (at over $3 USD) - Digikey prices.
All claim to be I2C, all seem pin compatible -- but the feature that worries me is the Page Write Buffer. I am seeing 64B, 128B, and 256B Page Write buffers when I look at PDFs for a regular 32Kx8 from MIcrochip, the 128Kx8 from Microchip, and the 128Kx8 from Atmel.
So is the size of the Page Write Buffer critical to a correct purchase, or trivial? I will try to red the PNut loader to find out for myself, but I suspect others might enjoy knowing.
++++++++++
Eventually, I am hoping that the larger EEPROM will allow a modified SPIN compiller to create binaries that are 128K... just or the P1V devices.
That may imply rewriting the PNut loader as well... one thing leads to yet another. But being backward compatible is also useful.
It seems so far that Parallax Propeller 1 devices prefer the Microchip alternative, but I will confirm by reading in detail the various PDFs. I just didn't know what to look for.
PNut boot V0.10 does indeed have page buffer writes and uses 64bytes as its limit in code, but you have indicate that is only an issue with load speed.
I need only two EEPROMs for FPGA upgrades. But since shipping is so high, I wanted to order more to switch out existing Propeller 1 boards. These I cannot modify the PNut Boot code as it is built-in.
Thanks for the prompt reply.
A2 address pin must be held High for the chip to work and the Parallax Propeller 1 has always configured A0, A1, and A2 to Ground. The BeMicroCV board does the same as the Propeller 1. Whatever brand I use, I must have all three grounded as that is the way the boards are built.
I am still trying to sort out the ATMEL AT24CM01 and what it does with addressing.
I may have to look for other alternatives as well.
Other compatible choices from Digikey are the Atmel AT24CM01 or its 2Mbitbyte cousin, AT24CM02. And the ON Semi CAT24M01, the STM M24M01, STM M24M02 (2 Mbitbyte), Fremont Micro FT24C1024A. I'm currently using the AT24CM01 with no problems.
Ought not all those "byte" sizes be "bit" sizes?
I have used the M24M01 without any problems as the addressing and connections are the same. The larger page size of 128 bytes just means I can use a smaller page size or go program the large blocks twice as fast with a larger page size. There's also a 256 byte identification page at address $B0 so even detecting an ack from this address should tell you that it is this device and that you have 128kBytes available. Many EEPROM drivers automatically extend the upper address bits A16 etc onto the device address so that $0_0000 addresses device $A0 (I use 8-bit notation) and $1_0000 addresses device $A2 etc.
BTW, I was avoiding answering you has you should have started a new thread since this one is years and years and years old. Good forum practice is to consider these old threads "archival".
Thanks to both of you for your replies. It makes this all so much easier than just reading all the possible PDFs and the PNut boot code. I now know what to look for.
The 1Mbit or 128Kx8 EEPROMs (and larger) seemed to have forked into at least two different solutions on how to provide that 17th bit. And I certainly need the selection that doesn't mess with what the PNut boot v0.10 expects for any device.
I may try to go to 2Mbit or 256Kx8 devices as Digikey seems to be selling them in single quantities and the right package. I thought these were disappearing, no longer available. Ordering both the 1Mbit and 2Mbit sizes might be wiser, just to explore.
Oddly, I figured that since this was a question that repeatedly comes up, it was more polite if I at least demonstrated that I sought the answer before adding a new thread to ask the same question again.
I did start a fresh thread about the EEPROM upgrade to the BeMicroCV and will pursue further specifics in that thread. That makes good sense.
For anyone wondering....
The existing PNut Boot v0.10 will limit any loading to 64byte Page Banks and to a 32Kbyte binary size. This cannot be modified in the physical Propeller 1 chips, but can be revised in an FPGA.
So it is very important to get the right EEPROM for a physical Propeller 1 or it may be ignored.
IOW, I should just shut up, read and think.
-Lucky[size=-1][/size][/quote]
Don't know if you have already fixed this, but I have the same need for transfering data into the P1 EEPROM (or other). I have written an I2C driver and some code to do the stuff, including batch transfer. At the PC end you need a terminal software that has the option of transfering from a file.
Erlend
I do see your point. And I rarely do use old threads. But I can't help but wondering why your Tachyon thread is the exception ;-)
Erlend,
Do you desire to interactively program the Propeller?
Lucky may no longer be around to reply and seemed to be having some difficulty with grasping that the Propeller code is first created in SPIN and then cross-compiled and downloaded as a binary image to EEPROM to be stored when power is turned off. When power is restored, the binary information in the EEPROM (usually only for the first 32K) is copied to HubRAM. A larger EEPROM required other support software to achieve anything, and are special case - like Catalina C.
The Propeller Manual explains this more clearly in the first few pages.
One must send 'ones and zeros' to the HubRam and finally a Cog to program the Propeller. The EEPROM is just a binary storage device (like a tiny floppy disk). You may have notice that you can load a compiled SPIN program to HubRam and leave the EEPROM empty. The program runs fine, it is just not saved when you turn off the Propeller.
Having a serial terminal interface in the Propeller write directly to the EEPROM isn't really programing much of anything. It is an interesting exercise that justs saves whatever you input from the serial terminal. Do you have a particular goal for this or just desire the challenge and learning experience?
If that's what you desire, it can certainly be done. Or if you want to program the actual Propeller interactively, that can be done in Forth or maybe a form of Basic (I don't recall what is available right now).
Any computer can be your serial terminal, or you can build a dumb terminal with a Propeller chip.
Including the Serial Terminal with video and keyboard in the same Propeller as the interpreted Forth is also possible. PropForth did that early on, but found that the remaining space was tiny. Video display takes up quite a bit of HubRam. PropForth later quit the scheme as too confined.
So I actually built a separate Serial Terminal (Dumb Terminal) that uses one whole Propeller and can connect via asynchronous serial to any Propeller interactively. I just happen to use it with Forth. That ends up being two Propellers for the complete scheme.
I hope this helps you get to where you want to go.
I am indeed aware of the difference, and aware of the problem I have created. But the Tachyon thread is still absurdly long.
I have tried to give a sensible reply here, but have not looked into Erlend's code because I am unclear what is really wanted as a final result.