Read\Write Entire EEPROM?

christo1423

I need to know if it is possible to overwrite the entire EEPROM including the program that is running from the program that is running.I also need to know that if the EEPROM was overwriten with a new program wether or not that program would run.Lastly I need some code to read and write·to and from the EEPROM one byte at a time.The goal of this project is to have locally loadable dynamic code.I have a BS2 so multibanking is not an option and I am hopeing to interface to some higher capicity storage anyways.The information for the overwrite will need to come from this storage medium.·

allanlane5

Well, all you need is an infinite loop with 'WRITE' statements, while incrementing a counter from 0 to 2000.

So yes, it is possible. Now, the open question is, what happens when the write statements actually hit the executing statements. This will happen ON one of the WRITE statements, and probably erase the final GOTO. I don't know what will happen next.

So no, you can't overwrite the ENTIRE EEPROM, you at least have to leave alone the small executing program that is over-writing it. Now, in theory this small program could be a 'loader', which reads a program from an external eeprom and writes it to the 'local' eeprom, then does a 'GOTO' to the loaded location in the 'local' eeprom.

And the "READ Addr, Databyte" and "WRITE Addr, Databyte" commands do the one-byte at a time thing.

Note you are chasing a "chicken and egg" problem here -- in order to erase the eeprom, you need a program to erase the eeprom.· If you erase the program which is erasing the eeprom, then you have nothing left to load the eeprom from somewhere else.· And the built-in loader only loads the eeprom from the built-in serial port, so I assume you can't use that.

Yup, having a 'loader' as the first thing in each program, then use the first-version 'loader' to load the others (without over-writing the first-version 'loader') should work.
·

Jon Williams

Christo,

Probably not. At some point the program that's running will crash as you start replacing valid tokens with "blank" bytes -- once the program stops, you're toast until reset which may go nowhere fast since you've replaced the program with bad bytes. Get a BS2p-family module; you can read from or write to one bank from another without actually changing banks (use STORE to point to the target bank).

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax

christo1423

My Idea was to have a working program read off to the external storage beforehand and overwrite the current program with the one I had copied off. I guess one thing I could do I create a universal loader program but this would require finding out how big the loader was in memory and also how big the program is without the loader.Any Ideas on how to find this out?

Bruce Bates

Christo -

I'm still not sure exactly what you're trying to accomplish, but perhaps you'll find the Stache remote program loader of interest:
http://www.emesystems.com/stache.htm

Regards,

Bruce Bates

Jon Williams

This won't work -- once you clobber the working program area you're toast.· Again, you can do this *sort* of thing by using a BS2p-family module and using Slot 0 as your master loader; it can move things around in the other slots then launch the target with RUN.· You could set up some semaphore system in the SPRAM that allows a slot to move back to the master and with data passed through the Scratchpad.

christo1423 said...
My Idea was to have a working program read off to the external storage beforehand and overwrite the current program with the one I had copied off. I guess one thing I could do I create a universal loader program but this would require finding out how big the loader was in memory and also how big the program is without the loader.Any Ideas on how to find this out?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax

allanlane5

Sure.

Write your 'loader' program (basically, read from serial port (or external EEPROM)) and use the WRITE keyword to write to the EEPROM 'above' a certain address.

Then Click the 'red check' icon to compile, then the 'Percent' icon to bring up a memory map of your compiled program. Scroll the scroll bar all the way to the bottom -- and those are your loader tokens. My simple program, loaded as a test, leaves 7C0 down to 00 free.

So "7C0" becomes that 'certain address' mentioned above.

Now, you'll want to write a 'saver' program, which writes the eeprom space from 7C0 to 00 to an external eeprom.

So, the idea here is every program you write will have the 'loader' portion put in the front. The 'loader' portion will, on some condition (a select switch? A serial port time-out?) decide which external eeprom 'saved' program to load. If you don't want it to load, it will 'GOTO' a destination address following the loader, and run your program.

If you DO want it to load, it will over-write the destination address down to zero with your program read from externall eeprom, and THEN do a 'GOTO' to the same destination address -- which now holds your NEW program.

P.S. Note this process may be 'slow'.· The Bs2P "write to another program slot" approach Jon mentions is probably simpler and more robust.· And we still don't know what you are trying to accomplish by doing all this.· Concievably you can do the same thing just by loading different programs in the·8 program slots of the BS2P, and just selecting which slot to 'run'.

So what are you trying to do?

Post Edited By Moderator (Chris Savage (Parallax)) : 7/12/2005 6:32:47 PM GMT

christo1423

I am planning to create a interface with VB.Net to control the robot remotely and I want to be able to switch programs on the robot locally so I am not transmitting a program over wireless.This also means I can send one byte to change between 256 different programs to do entirely different things if I want to.Though more than likely I would reserve some of the 256 possibilities to choose between subroutines in each program. For example, If I was creating a battle bot , which I have considered, I could have a program dedicated to offensive manuveres and If I got into trouble I could switch to another program dedicated to defensive stratgies.This switch would need to occur quickly and a local transfer seems like it would be much faster than the wireless approach.The reason for not using the BS2P is the fact that I have a BS2 already and I am trying save some money even though I could perform the process more efficiently on the BS2P. With the BS2P I could probably dedicate a bank to the loader program thus allowing to be alot bigger and more complex, This is food for thought.I may get it later as I see how well this proceess will work.Before I can do to much I have to wait for external storage to arrive.Thank you all for your help in this matter.

Jon Williams

You're not going to be able to switch the programs locally on a BS2 -- it only has one program slot and once it's clobbered your robot is dead in the water. What you could do, since you are going to be connecting to a PC is download a new program image as you need it. No this is not fast, but is a solution that will work with your BS2.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax

allanlane5

Um, even if you COULD over-write the entire 2000 bytes, at 30 uSec per bit it would take 0.48 seconds just to read the data from an SPI EEPROM. THEN, I think it takes like 1 mSec per byte to write it to EEPROM. So I think you're at 2.5 SECONDS to load a new program and jump to it.

Now, some programs are really short, so won't take the entire 2000 bytes. Still, I think you're barking up the wrong tree. Perhaps you should use some other processor, like an SX28 or SX52. These have WAY more memory, run at 50 MIPS, and are cheaper per chip than the BS2.

P.S. Chris has pointed out to me (off-line) that the memory space is actually 2048 bytes, not 2000.· Neat, those 48 bytes will come in handy.

Post Edited (allanlane5) : 7/13/2005 6:43:53 PM GMT