Programming, retrieving source code from micro-controller (cpu)?

[jgraber]

Here is a problem and some potential solutions.
Can you think of other solutions with different tradeoffs?
Are there likely to be any difficult implementation problems with solution #4?

Problem: Can’t upload code from micro-controller to see whats on it,
and even if you could, it wouldn’t be the source code, it would be binary.
A. Find a spare microcontroller, what code does it have on it? no way to know.
B. One of several teams you support asks for help in fixing/debugging code on their microcontroller, but doesn’t have the source.
C. Can’t help some other team that didn’t bring their programming computer.
D. Lost source, can we recover it from cpu? no.

Potential solutions:

1. EasyC/RobotC/misc change to store source in spare memory on cpu, and be able to retrieve it. Works for everyone (that uses these newer tools). I should post this solution to the EasyC new requests forum, and eqv RobotC forum.
2. Sticky note on cpu with pointer to website(eg google docs) that has current version of code.
3. Always store code on USBmemorystick, velcro it to the cpu.
4. Write programs to be self-replicating: The first thing a program does is output itself to terminal. You can recover the source by connecting a programming cable and starting cpu.

I’ll suggest solution 3 next year for teams I support. If this catches on with other teams that need help, they can be helped more easily at matches.

The tradeoff between 3 and 4 : 3 takes more hw, 4 takes more sw and uses
additional on-chip memory and is less likely to be compatible across teams.
Both take changes in habits, although 4 may be more automate-able once it is configured.

Automation for method 4 would be something like gzip the source, uuencode to printable base64 or similar, insert into a writestring at top of program; and use a corresponding decode program to accept the pasted writestring, uudecode, gunzip.

[esklar81]

@jgraber

Here is a problem and some potential solutions.
Can you think of other solutions with different tradeoffs?
Are there likely to be any difficult implementation problems with solution #4?

Problem:

Can’t upload code from micro-controller to see whats on it,
and even if you could, it wouldn’t be the source code, it would be binary.That’s why there are decompilers

Decompiler

and disassemblers
[

1. EasyC/RobotC/misc change to store source in spare memory on cpu, and be able to retrieve it. Works for everyone (that uses these newer tools). I should post this solution to the EasyC new requests forum, and eqv RobotC forum.

@jgraber

Potential solutions:

This approach appears to present a pair of challenges: size limitations and the need to download the text of the source along with the executable.

@jgraber

2. Sticky note on cpu with pointer to website(eg google docs) that has current version of code.

I’d vote for this one.

@jgraber

3. Always store code on USBmemorystick, velcro it to the cpu.

I’m not sure I’d trust it to stay there.

@jgraber

4. Write programs to be self-replicating: The first thing a program does is output itself to terminal. You can recover the source by connecting a programming cable and starting cpu.

I don’t think “self-replicating” will work, as the “self” is not the source code, it’s the executable.

Eric
](Disassembler - Wikipedia)

[jgraber]

@esklar81

That’s why there are decompilers
Decompiler - Wikipedia

Wiki: Machine language without such metadata or debug data is much harder to decompile.

Have you a pointer to a C decompiler for EasyC?
I heard that RobotC (for Vex0.5) is actually running a virtual machine.
If so, the p-code eqv may be easier to decompile than real Asm.

I don’t think “self-replicating” will work, as the “self” is not the source code, it’s the executable.
Eric

OK then, “computer aided nearly self-source repeating”.
While source-self-replication is an interesting and traditional computational exercise, I’m only trying for a method to carry and dump a copy of the unique part of the source payload.