Download from RC back to computer?

[geeknerd99]

I know it's been covered, but searching is rather tough for it, and I took the time to try.

We just started our 5 hour fix-it window, and our test sled (last year's bot) has a broken gearbox. We're going to switch out test sled to our tetrabot, but we don't have the code backed up anywhere. While it wouldn't be that hard to reprogram it, we'd like to extract the code to dump back onto it after we're done.

Is this possible to do, and if so, how do we do it?

Ladies and gentlemen, you have 5 hours to provide answers.

[EHaskins]

You can use IFI Device Reader to read the hex file from the robot(I think).

I have never tried it and you won't be able to modifiy code, but it should work.

[bear24rw]

There is no way to get the source code back off the RC. You can get the hex file back but its not something that you can edit.

http://ifirobotics.com/docs/device-reader.zip

[geeknerd99]

Thanks. I'll give it a try. We don't need to edit the source code, we just needed to keep a copy of the hex so that we could reload it after we're done.

[whytheheckme]

Wow. I didn't know that this existed! Very cool.

Jacob

[Jared Russell]

Note that you can also (through long, tedious, and often error-prone methods) generate assembly code from the HEX file. Not that I think that anyone really uses assembly for RC programming when C is available, but if you just absolutely need to change one constant or something and re-download (assuming you know PIC assembly reasonably well), it is an option.

[Eldarion]

To avoid this type of problem in the future, maybe it would be a good idea if teams taped a CD with the code on it to the robot before mothballing it?

That way, 5 years down the line when no one on the team had the code, it will be sitting there on the CD with the robot.

Just a thought!

[EricH]

Originally Posted by Eldarion

To avoid this type of problem in the future, maybe it would be a good idea if teams taped a CD with the code on it to the robot before mothballing it?

That way, 5 years down the line when no one on the team had the code, it will be sitting there on the CD with the robot.

Just a thought!

CVS server. (CVS stands for Concurrent Versioning System.) What it does is it keeps old versions of code and changes to said code around for until they are removed. This way, you can make a change and still get your working code back if the new code "dies". Not only that, but multiple programmers can work on the same code without having to send each other code bits or even talk to each other. (To use here: keep the most recent code for each year on the server, until that robot dies totally and completely. Then use code to teach newbies...) Just be careful--mechanicals and photographers may also want to use the CVS to share stuff! (By the way, I'm not a programmer and don't know how to set one up.)

[Astronouth7303]

Originally Posted by EricH

CVS server. (CVS stands for Concurrent Versioning System.)

I'd recommend Subversion over CVS. It is less painful to set up, more flexible in terms of operations, and less quirky.

Just be warned: The 2004-2005 controllers used the PIC18F8520, while the 2006-2007 controllers use the PIC18F8722. Code compiled for one will not work on the other. It may be easier to swap the controllers.

[ericand]

We used subversion, but when we tried using branches late in the project, we had a lot of trouble getting things to merge back and sync up. If you have a pointer to any documents that cover this with examples I would greatly appreciate hearing about it.

We used the command line and tortise SVN for a windows GUI. I've read the SVN manual and tortise documentation about branches, but I think I'm missing something since I don't think it should be so hard.

Originally Posted by Astronouth7303

I'd recommend Subversion over CVS. It is less painful to set up, more flexible in terms of operations, and less quirky.

Just be warned: The 2004-2005 controllers used the PIC18F8520, while the 2006-2007 controllers use the PIC18F8722. Code compiled for one will not work on the other. It may be easier to swap the controllers.

[ericand]

We used the device reader to unload code (and subsequently reloaded that code later). We found it worked well and was easy to use.

Our plan (never fully realized) was to archive a binary copies of "good" versions, after they had proven themselves by running in a robot. We have been burned on a few occasions by archiving out of the build (after testing on the robot) only to find out later that what we archived was not exactly what we had been testing. Either someone had made "just one little tweak" while we were off testing, or the person who did the archiving got a path a bit wrong and saved a different version than intended.

Saving the binary off the robot eliminates any chance of confusion. You save exactly what was running.