OK, so i have a project where i have to be able to interface with an Arduino which has a unknown program saved on it and I need to find out whats going e.g what pins are being used. It also hasn't been explicitly programmed to send this information, but isn't programmed to prevent this.
how would i go about doing this?
thanks in advance
You can't
Mark
even if the program is running you cant retrieve anything of what is going on
(deleted)
It can be done (most likely).
copy flash and EEPROM
disassemble all code
find all port usages (harder than it reads)
alternative approach:
write an Arduino simulator that tracks port usage
feed it flash and eeprom
All quite hard and tedious.
Whandall:
It can be done (most likely).copy flash and EEPROM
disassemble all code
find all port usages (harder than it reads)alternative approach:
write an Arduino simulator that tracks port usage
feed it flash and eepromAll quite hard and tedious.
part of my project is building a disassembler, could this help me with this if so how?
A tiny part of that project would be a working disassembler.
I consider it not worthwhile (the dissecting not your disassembler).
I have done things like that back in the days, it's a pain in the ...
unfortunately this is my project build a disassembler and find out as much of what the program is doing to the borad and generate pseudo-code of this
unfortunately this is my project build a disassembler
Why waste your time? There already exist good disassemblers. Use Atmel Studio.
Project issued by whom?
It depends on the complexity of the program to dissect/understand replicate.
A sketch doing some led blinking in the standard way would (probably) be quite easy.
Start by creating a dump of the flash, identify code (can be hard), disassemble.
Create some easy samples (empty, the classical blink, ...) find out what gets where,
what is sketchcode and what is linked in...
As I said, it can get tedious.
I'm a computer science student so I'm quite ignorant to the world of electronics. basically I've spent most of my time building applications using high level languages. simple programs are all I'm intending it for due to the tediousness of it.
so what your saying it will be easier to use the assembly code to generate pseudo-code e.g.
pin 1 is doing something intresting
the led is on!
As the code gets translated to assembly, yes you have to use a disassembler
(writing it yourself will enhance the understanding of the processor but is not neccessary).
After understanding what gets translated in which assembly sequence
(which can be made very hard by the optimizer),
you could create C code that has the same functionality as the original source.
All symbolic information is gone in the flash image.
translating to C code won't be necessary (thankfully). but will the assembly code tell me which pins are used
What you want to do is a bit like trying to figure out the original questions for a cryptic crossword when all you have is the completed puzzle. In fact figuring out the dis-assembled code would probably be harder.
Unless the end product is extraordinarily valuable (many £000s) I suspect it would be more cost effective just to write new code from scratch having observed how the existing system operates.
An oscilloscope or logic analyzer will tell you quickly which pins are used.
...R
It depends.
If the pins are computed you will have to (mentally) simulate it,
if the pins and the corresponding bit-pattern come from constants
they could be directly visible in the assembly.
If pinMode, analog/digitalWrite/Read routines are used it could be easy.
Robin2:
An oscilloscope or logic analyzer will tell you quickly which pins are used.
You will not be able to see digitalReads or analogReads with this technique.
Whether it will be possible to tell a INPUT_PULLUP from a digitalWrite( ,HIGH)? I don't know.
then how would identify a pin in assembly
benbo999:
then how would identify a pin in assembly
By the fact that it's referenced in a port access instruction?
I expect you would see a register being written high or low.
See Table 36, Register Summary, of the '328P datasheet. Page 615 specifically.
Lastly through the register(memory) access and there are some possibilities for that.
If the normal sketch compile mechanism was used
and only standard calls (pinMode etc) were used,
you could identify the routines, their calls and the parameters.
It's an iterative process in my view, I
Whandall:
You will not be able to see digitalReads or analogReads with this technique.
Very true. But it also implies that the OP hasn't the slightest idea what the program is trying to achieve.
It can be difficult enough to figure out what a program is intended to do when I have the source code and I wrote it 
I was assuming that some knowledge of the program's effect on the outside world (i.e. its outputs) would provide most of what is needed to make another program that did the same job, but not necessarily with identical code.
...R