Storing eeprom images on SD for loading into the prop's ram
sharpie
Posts: 150
Probably didn't word that well, but I'm wondering how possible it is to take a .eeprom "image" from the ide and store it on an SD card... then write a program that reads that .eeprom file from the SD card and writes it the eeprom and reboots the prop to run that program.....·
I know there's plenty of discussion around here about how to get bigger apps than the prop can handle to run, etc...· Which isn't really what I'm interested in.· I know there has also been talk about the loader app, and so on...· I'm just wondering if it's possible and worth my time to store a bunch of those files on an SD card so I can load them up whenever I feel like it.· (Sort of the way you can on a gameboy memory cart).·
Or am I wasting everyone's time and totally missed the point of the previous posts?· But I really don't remember any talk of storing the programs as .eeprom files on a medium like SD, etc...
I know there's plenty of discussion around here about how to get bigger apps than the prop can handle to run, etc...· Which isn't really what I'm interested in.· I know there has also been talk about the loader app, and so on...· I'm just wondering if it's possible and worth my time to store a bunch of those files on an SD card so I can load them up whenever I feel like it.· (Sort of the way you can on a gameboy memory cart).·
Or am I wasting everyone's time and totally missed the point of the previous posts?· But I really don't remember any talk of storing the programs as .eeprom files on a medium like SD, etc...
Comments
There're two main issues here:
1. We haven't actually written any code.
2. We're not sure how to boot Spin images from an assembly program. This is fine for me -- I'm interested in booting Forth images, primarily -- but not for sane people. We'd need the entry point for the SPIN interpreter, since the standard bootstrap sequence (which I can trigger) erases RAM -- but Parallax (arguably with good reason) isn't documenting this info.
So, if someone else beats me to it, marvelous -- I'll use theirs instead! Otherwise, I may have something together next week.
I haven't written code either as of yet.. Just in a discovery process currently..
If I overwrite the eeprom with the file, and reboot the prop.. Am I wrong in making the assumption it'll boot as normal?
I would like to just stuff it into ram if possible, make reloading new images a lot easier..
Should work, yes.
That's what I'm hoping to do -- which is trivial with propasm binaries, because I know how they're laid out. The trick with Spin binaries will be figuring out how to invoke the interpreter once the binary's in RAM.
Does the OS_loaderInit object read the .eeprom files saved from the propeller tool?
Isn't there a way to just take the binary file from the propeller tool and shove it into the eeprom(using the i2c object), and reset the prop so it'll boot the new code?
I probably should do some more reading in this area(understatement). It just seems that it'd be nice to be able to write a program in the ide, store the .eeprom file on an SD card and be able to call it up in the field sans PC. If you've got a 1gb SD card, that's a whole lot of 32k .eeprom files to choose from.
Download the Propeller OS: <http://forums.parallax.com/forums/default.aspx?f=25&m=154815>. There's a Quick Start Guide and the beginnings of a manual that will explain how to download from the Propeller Tool, then store the downloaded program to some other place in EEPROM. The OS_loaderInit routine takes a starting address in EEPROM (usually a multiple of 32K) and a length, then reads the whole thing into a specified area of HUB RAM (usually starting at zero). After loading, it starts up the SPIN interpreter on what was just loaded. There are other routines in the OS that can lookup a file name (stored in the last 16 bytes of each 32K area) in order to pass its address to the loader.
Mike
Nico Hattink
The·data set would·be 400 bytes in length. There might be 50 to 1000 of these data sets of identical length in the SD. I would need to load·only 1·set at a time·into Prop RAM (speed for the download/upload not an issue < 10 seconds would be fine).
Is it possible to do this without a full blown FAT32 file structure. I have 2 Cogs free right now and this would be a nice feature.
Thanks,
Craig
I have some updates to it, so let me know if you end up using it. (Minor defect fixes.)
I am currently building a whole suite of SD support programs that are tailored to particular requirements.
I've got read-only and read/write versions. I've got versions entirely in Spin that are slow, and
a version with a small amount of assembly for brevity that is quite fast, and another version with
more assembly that is even faster.
This is the thread with the code:
http://forums.parallax.com/forums/default.aspx?f=25&p=1&m=126973
Anyone have some insight into what I mgiht be doing wrong?
Right now I'm just trying to get the autobaud to work and display the version number.....
s.str(string(13)) WaitCnt(500_000 + Cnt) s.str(string(13)) WaitCnt(500_000 + Cnt) s.str(string("v")) WaitCnt(500_000 + Cnt) s.str(string(13))Tried lot's of iterations of the above, and just ended up with this to keep it simple...· I just put the waits in there to make sure it got everything..· I tried a bunch of way more elaborate stuff too..·
Any help is appreciated.
Post Edited (sharpie) : 12/7/2006 12:33:20 AM GMT
The trick with it is that it is an RS-232 interface - somewhat like the DOSonChip.
I also see that the IDE uses an RS-232 to initiate a Reset via DTR [noparse][[/noparse]not really an rst/cts]
That seems to be a key to properly start the download.
And from there, it would have to emulate the download from the IDE to Propeller as a DOS file.
Can anyone tell me how that might be done? Just a read file command and a reset trigger [noparse][[/noparse]maybe I could have a BasicStamp do this AND select which file from the SDcard].· There appears to·be a 50ms resonse delay to account for.
It certainly would seem to be more compatible to save a DOS file image to the SDcard that EEPROMs.
Then have the SDcard file be presented seamlessly to the Propeller without using additional pins or EEPROMS [noparse][[/noparse] I2C or SPI].
NEED TO KNOW THE CORRECT BAYD RATE
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"If you want more fiber, eat the package.· Not enough?· Eat the manual."········
Post Edited (Kramer) : 12/7/2006 12:48:18 PM GMT