Lost spin program - can I retrieve from EEPROM?
softex
Posts: 27
Just got caught in the propeller tool quirk of not saving when compiling, so I have a couple of days work in ya-ya land. My quirk is often compiling to EEPROM instead of just to RAM so I have a recent version now residing on EEPROM. I don't like my chances, but is there any way I can retrieve this back to spin code?
-Dave
-Dave
Comments
The original program does not exist in the Propeller. The Propeller Tool compiles the program into interpretive code which is quite compact. It's possible to read the EEPROM with another program in RAM and dump the contents of the EEPROM to a PC for example. There is a debugger that is available that can disassemble the information from the EEPROM into Spin interpretive code source, but this is not something that can be recompiled. It could painstakingly be hand translated into Spin, but there are no variable names or method names and the deconstruction is difficult at best. Practically speaking, you can't retrieve it as Spin source, certainly not meaningful Spin source code.
-D
That is where you want a nice deep undo buffer [noparse]:)[/noparse] You can save to your hearts content and as long as you have not close the editor you can always "ctrl+z" your way back to where you want to be.
The Propeller tool appears to save a recovery of some sort prior to each compile..
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
Personally I think an editor should snap shot frequently such that if it crashes or your computer goes down most of your work is intact somewhere.
A save before compile usually suffices if you are in the habit of at least checking what you have done so far is at least syntactically correct.
Then I think a save of what actually does compile without errors is more important than the intermediate junk and should be identifiable as such. But then whatever compiles and actually runs in some way is even more important and should be identifiable as such.
But now we are in the world of backups and version control which probably don't belong in an editor and people should get into the habit of using anyway[noparse]:)[/noparse]
By the way I seem to have a problem where the Parallax tool gets into a mode where it compiles what was last saved and not my recent, unsaved, edited version. Gets very confusing when I make a change and everything runs the same. Perhaps I have an old version now.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Post Edited (heater) : 2/9/2009 3:09:55 PM GMT
Seriously. I've heard that proposed as a software engineering practice.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
--Rich
* Something like the number of seconds since the world began.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Engineering
As to recreating Spin ( and any PASM ) from Eeprom; I estimate it is technically 98% doable, but not doable at present, and human readable stuff like variable, constant and object names etc would be lost. May be useful if desperate or determined to thieve someone else's code but I'd usually take a lost source as a golden opportunity for a rewrite in half the time and have a result twice as good.
Spin is easier to decompile and reconstruct source from than most compiled languages because there's almost zero optimisation, it's all bytecode and the bytecode is predictable for each Spin language construct. It's all in a well defined order and format so it's relatively easy to take a bytecode sequence and deduce what it was created from. The biggest challenge I think is in determining array sizes.
It should be possible to decompile Eeprom to source and be able to recompile that back to the exact same image but I haven't tried it because, while a fun challenge and worthy of a kudos badge, there didn't seem a lot of point to it when there are other things to do. But if someone has a couple of large suitcases full of dollar bills ...
Are you certain that your code is lost softex?
If so, bite the bullet, rewrite your code, and realize that the second time around you will probably do it better anyways.
So I would argue that save on compile is a no no, a file should not be changed unless I say so. But the thing loaded in the editor should not be lost unless I say so either, like when the editor or computer bombs out. So there should be periodic snapshots somewhere other than the original file. Or perhaps I log of changes until those changes are committed. Editors like vi will do that.
Or perhaps we should use VMS with its versioning file system. I do miss that some times.
Still that brings us back to version management. Its very comforting to know every version of everything you ever did is safe in cvs or svn or something.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
-D
Wherever you have an "editor" and a "compiler" rather than a properly integrated environment then save-on-compile is a must, as the compiler has no other way of getting the information out of the IDE.
Some people like it, some people don't. Its not hard to make it an option unless you are using a poorly integrated "IDE" and have no choice, in which case you are stuck with it.
Personally I don't like save-on-compile for precisely the reasons detailed by Chris and Hippy, but I would have no problem with the Propeller Tool having an option to do just that.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Post Edited (Paul Baker) : 2/10/2009 12:35:39 AM GMT
Exactly why I said keep it as an option. I typically use source level control with the minimum being a self hosted SVN repository. I am very paranoid about losing code and if I need to make large changes in the trunk I will create a branch, otherwise I make sure I "post small and post often". Proper CM techniques and programmer discipline should prevent most "accidents". The only thing it doesn't prevent against is catastrophic failure or the lack of discipline in saving - which is something I've unfortunately acquired using a "poorly integrated IDE".
my advice is to attached the propeller IDE with a subversion repository and setup 3 environment:
- Development
- Test
- Production
Check-in/Check-out the files
Backup regulary the subversion repository
I promise you that no file are going to be lost
Regards
Gianni
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Check out: Protoboard Introduction , Propeller Cookbook 1.4 & Software Index
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card connected? - PropDOS
With the program already in the EEPROM how is it possibile to _run_ another program into the RAM, since on boot time the chip will discard it in favour of the EEPROM program?
Question anyway is: can the original (in EEPROM) program be retrieved at least in bytecode/compiled code, i.e. can be backed up at least in that form, so that I can do my things (rewrite it
Gio
You can always program from the Prop Tool or BST or whatever into RAM without messing up the EEPROM. Be careful not to hit the program EEPROM buttons.
So if you want to read the old programs binary from EEPROM you can write yourself a program which is run from RAM and:
1) Reads the EEPROM bytes. There must be I2C drivers in OBEX that can do this.
2) Sends them to the PC. Use the FullDuplexSerial object.
Personally if the EEPROM content is valuable to you I would remove it from the Prop Programming pins and connect it to some others. Just to be sure you don't accidentally over write it with the Prop Tool or whatever.
Also I'd probably want to do the programming into RAM of the recovery program from a command line loader. Then use hyperterminal or some Linux terminal program to capture the HEX bytes that come out.