Searching \ for '[PIC] new disassembler' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'new disassembler'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] new disassembler'
2006\07\14@074639 by Tamas Rudnai

face picon face
Hi,

Just started to write a new disassembler for Microchip PICs. The project is
called unPIC and the main goal of this is that all disassembler I have seen
so far just made a very poor in results so I wanted to make a better one.
This tool would be useful to everyone that lost his/her source or just
wonderin what is in the HEX file (testing compilers / linkers for example).

Currently it is in alpha state and already have some features:

- loads HEX files and INC files which is coming from MPLAB
- produces ASM from it with meaningful names for register files and for jump
/ call labels.
- creates subroutine definitions
- follows program logic so it understands CPU state which is important to
determine which bank is used for the current instruction (later on might be
followed other CPU states as well)
- currently only 14bit PIC is supported, will be added 12bit very soon

The tool is written in Perl script, therefore platform independent, hence
need Perl to be installed. You would also need INC files from MPLAB.
It is free to use, GPL, and has naturaly source (as it is a Perl script).

http://sourceforge.net/projects/unpic/

I would appreciate if some of you could play with it and send back some
feedback.

Cheers,
Tamas

2006\07\14@090410 by Maarten Hofman

face picon face
1) I had to change your code a bit, because it otherwise gave a strange
error message ([error] Constant name 'HASH(...)' has invalid characters). I
changed the:

use constant ({ INC_NOTHING => '-nothing-',
  INC_REGFILES => 'RegFiles',
})

Into:

use constant INC_NOTHING => '-nothing-';
use constant INC_REGFILES => 'RegFiles';

And then it worked fine.

2) You should probably recognize a sequence of retlw statements as a table,
the way it looks now, with a comment before each retlw, makes it difficult
to see what is actually happening.

3) Similar with a series of gotos: that would be a jumptable. You could even
change the labels of that to read "jumptable_<>" if you want to.

In general, I think it looks good... Not that my code becomes more readable
with it, but it seems to do the job of disassembling.

Greetings,
Maarten Hofman.

2006\07\14@095321 by Tamas Rudnai

face picon face
Thanks for that!

I do not know why I keep put '{' instead of '(' when defining hash constants
:-) That will create an unnamed hash inside the real one, so that's why you
had that strange message -- I am not sure why was that ok for me.

So it should work like this:

use constant (
   # states for loading INC files
   INC_NOTHING => '-nothing-',
   INC_REGFILES => 'RegFiles',
);

Will change it anyway :-)

2. The recognition of retlw and goto tables are very good idea, will work on
it.

Forgot to mention how to use it but presumably you had been figured it out
already:

> unPIC.pl p16xxx.inc yourhexfile.hex > yourasmfile.asm

So that if you choose the correct INC file it has a chance to determine
register files.
Are all the register files were reversed correctly?

Thanks,
Tamas




On 14/07/06, Maarten Hofman <spam_OUTcashimorTakeThisOuTspamgmail.com> wrote:
{Quote hidden}

> -

2006\07\16@105023 by Tamas Rudnai

face picon face
Hi,

Updated in sourceforge, so now it handles those jump tables -- thanks
Maarten for the ideas! Also now you can recompile the code using MPLAB. I
had no problem by doing it so with my test package -- got back almost the
same HEX file. But if you can't build the disassembled code or if the HEX
differs, please raise your hand :-)

I have a new idea but I am not sure if it worth the effort: I was wondering
if it would be useful to write a tool that automatically translates a HEX
file to another PIC. So that you have a HEX file for 16F683 and would like
to use it for a different chip than that, you just apply this tool and
program it to your desired chip. You do not even have to modify / recompile
your source or the disassembled code. What do you recon?

Regards,
Tamas
http://sourceforge.net/projects/unpic



On 14/07/06, Tamas Rudnai <.....tamas.rudnaiKILLspamspam@spam@gmail.com> wrote:
{Quote hidden}

2006\07\16@130133 by Stef Mientki

flavicon
face

> I have a new idea but I am not sure if it worth the effort: I was wondering
> if it would be useful to write a tool that automatically translates a HEX
> file to another PIC. So that you have a HEX file for 16F683 and would like
> to use it for a different chip than that, you just apply this tool and
> program it to your desired chip. You do not even have to modify / recompile
> your source or the disassembled code. What do you recon?
>
>  
Sounds very interesting, if ...
... you could translate a 16F hex file to a 18F hex file.

Why, some compilers don't support (yet) the 18F series,
and although you wouldn't benefit (at least that's what I guess) of the
extended instruction set of the 18F,
you could use things like larger memory, faster clock etc.

I've played with this idea myself, but other things have higher priority ;-)

cheers,
Stef Mientki

2006\07\16@141516 by Wouter van Ooijen

face picon face
> I have a new idea but I am not sure if it worth the effort: I
> was wondering
> if it would be useful to write a tool that automatically
> translates a HEX
> file to another PIC. So that you have a HEX file for 16F683
> and would like
> to use it for a different chip than that, you just apply this tool and
> program it to your desired chip. You do not even have to
> modify / recompile
> your source or the disassembled code. What do you recon?

I don't see how you could do that, or you must restrict the
source/target pics so that a verbatim copy does the job.

For instance: the EEPROM registers can be in different banks, so you'd
have to add/remove bank switching, which might shift the code, so you
might have to add code page switching, etc.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2006\07\16@142613 by Marcel Birthelmer

picon face
and then you're basically looking at a PIC supercompiler. That might be
interesting.

On 7/16/06, Wouter van Ooijen <.....wouterKILLspamspam.....voti.nl> wrote:
{Quote hidden}

> -

2006\07\16@164905 by Wouter van Ooijen

face picon face
> and then you're basically looking at a PIC supercompiler.
> That might be interesting.

Only to check its algorithms and design a program that it would chocke
on.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu



2006\07\17@042934 by Tamas Rudnai

face picon face
The basic idea was that this disassembler I started to work on could find
all relevant places, bank switchings etc. It knows which address is
referenced by what instruction. For this one the tool has to know which
register file is what -- this part is already done. So I thought that if I
know these info about the other PIC than it should not be a big trouble to
change all of these info -- I may wrong on this, tough. Basically it is a
kind of compiler, except that the input is not an ASM file (aka text file)
nor a C or whatever else but a binary.

My doubt about this is that the other chip may have a different clock freq
so that all time related stuff would fail. For example you might have to
change time scaler for watchdog or timer interrupt, and also if the code
based on instruction cycles (aka an iteration calculating time, make delays
etc) then you have to put nops or change values for that. And that's very
hard to tell by a stupid tool which of these values have to be changed to
what.

Regards,
Tamas


On 16/07/06, Wouter van Ooijen <EraseMEwouterspam_OUTspamTakeThisOuTvoti.nl> wrote:
{Quote hidden}

> -

2006\07\17@050828 by Wouter van Ooijen

face picon face
> My doubt about this is that the other chip may have a
> different clock freq
> so that all time related stuff would fail. For example you
> might have to
> change time scaler for watchdog or timer interrupt, and also
> if the code
> based on instruction cycles (aka an iteration calculating
> time, make delays
> etc) then you have to put nops or change values for that. And
> that's very
> hard to tell by a stupid tool which of these values have to
> be changed to
> what.

Plenty more chances to make it fail. Just a few:
- A/D acquisition time varies, also depending on source impedance
- self-write algorithms are vastly different
- read all erata, some chips need interesting work-arounds in some
situations
- peripheral control structure varies (distribution of bits over bytes,
semantics of bits, etc)
- stack depth: 2/8/32
- interrupts: 0/1/2
- A/D resolution: 8/10
etc etc

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2006\07\17@062132 by Tamas Rudnai

face picon face
On 17/07/06, Wouter van Ooijen <wouterspamspam_OUTvoti.nl> wrote:
>
>
> Plenty more chances to make it fail. Just a few:
> - A/D acquisition time varies, also depending on source impedance


Yes, it could be the same problem as the timer one, isn't it?

- self-write algorithms are vastly different


I am not sure what do you mean by?

- read all erata, some chips need interesting work-arounds in some
> situations


I think it could be done by a 'knowladge database', so that if it is known
that you should do something special to read data form here or there then it
could automatically rewrite / extand that piece of code.

- peripheral control structure varies (distribution of bits over bytes,
> semantics of bits, etc)


As long as those described in the INC file I think it is not a problem as it
disassembles the code completly so you will get a 'meaning' of the code. So
'btfss INTCON, T0IE' is always that and as long as INTCON and T0IE
definitions exists on both chips' INC file it could be translated fine.
There might be some problem if ANDLW or similar applied to test / change
more than one bits at a time.

> - stack depth: 2/8/32

The basic principle was to reuse a code in a higher PIC rather than in a
lower, but it might be possible to check the depth of a call flow if the
code is not recursive.

> - interrupts: 0/1/2
> - A/D resolution: 8/10
> etc etc

Yep, those are more hard to do. Maybe that's why it is not worth the effort
:-)

Regards,
Tamas

2006\07\17@064746 by Wouter van Ooijen

face picon face
> > - A/D acquisition time varies, also depending on source impedance
> Yes, it could be the same problem as the timer one, isn't it?

no. (most?) 16F's PICs have a recommended maximum source impedance of
10k, for (most?) 18F's this is 2.5k (IIRC). IIRC (but you might need to
check this) 18F's can still get the full accurcay but the acquisition
time needs to be (much?) longer. So whether the program's timing needs
to be changed depends on the circuit oustide the PIC.

> - self-write algorithms are vastly different
> I am not sure what do you mean by?

read a few datasheets, for instance 16F877 and 16F877A, check how
writing to the program flash is done from a running program.

{Quote hidden}

That's an easy one, because the semantics don't change. Now read the
various A/D modules.

> > - A/D resolution: 8/10
> > etc etc
>
> Yep, those are more hard to do. Maybe that's why it is not
> worth the effort
> :-)

That's my idea too.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2006\07\17@071029 by olin piclist

face picon face
Tamas Rudnai wrote:
> My doubt about this is that the other chip may have a different clock
> freq so that all time related stuff would fail.

That's only one of many problems.  I think it would be impossible to
properly track indirect addressing references.  Since often run time math is
used to calculate the target address, you don't know what is ultimately
being addressed.  This means you have to keep all RAM at exactly the same
addresses on the new machine, but of course that is either impossible or
leads to other problems.

I'm having a hard time thinking of purpose for this tool, even if it could
convert the code reliably.  Why would you want to convert PIC 16 code to run
on a PIC 18 at the *binary* level?  With properly written source code it's
not that hard but still takes some human intervention.  But even if this
tool worked mostly, how do you then fix the remaining bugs without source
code?  Normally I would say this is an answer to a question nobody asked,
but in this case it doesn't even seem to be an answer.


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2006\07\17@092332 by Xiaofan Chen

face picon face
On 7/17/06, Olin Lathrop <@spam@olin_piclistKILLspamspamembedinc.com> wrote:
> Tamas Rudnai wrote:
> > My doubt about this is that the other chip may have a different clock
> > freq so that all time related stuff would fail.
>
> That's only one of many problems.  I think it would be impossible to
> properly track indirect addressing references.  Since often run time math is
> used to calculate the target address, you don't know what is ultimately
> being addressed.  This means you have to keep all RAM at exactly the same
> addresses on the new machine, but of course that is either impossible or
> leads to other problems.
>

C compile will be quite good at this even though some people may not
opt for C.

Regards,
Xiaofan

2006\07\17@092354 by Xiaofan Chen

face picon face
On 7/17/06, Marcel Birthelmer <KILLspammarcelb.listsKILLspamspamgmail.com> wrote:
> and then you're basically looking at a PIC supercompiler. That might be
> interesting.
>

C is good enough, right? For example, it is relatively easier (comparing to
port PIC16F assembly to PIC18F assembly) to port Hi-Tech PICC code to
Hi-Tech PICC18.

Regards,
Xiaofan

2006\07\17@094626 by William Couture

face picon face
On 7/16/06, Tamas Rudnai <RemoveMEtamas.rudnaiTakeThisOuTspamgmail.com> wrote:
>
> Updated in sourceforge, so now it handles those jump tables -- thanks
> Maarten for the ideas! Also now you can recompile the code using MPLAB. I
> had no problem by doing it so with my test package -- got back almost the
> same HEX file. But if you can't build the disassembled code or if the HEX
> differs, please raise your hand :-)

I've written a PIC disassembler (PICDIS at http://www.picemualtor.com), and would
like to try yours.

However, I'm running a Win2K system.  What would I have to install to try it?

Bill

--
Psst...  Hey, you... Buddy...  Want a kitten?  straycatblues.petfinder.org

2006\07\17@095436 by Tamas Rudnai

face picon face
All the thing is that C generates larger and slower code which does not
always meet the target (lack of space or timing). But once again, my
original approach was that you do not have the source, not C, nor Assembly.
In my case I have downloaded a HEX file and wanted to make tiny app for my
RC airplane model for a safer flying. That original project used a 12F683
and I was wondering if I could put it into a 10F200 or 202. (smaller,
lighter and cheaper) It seems that the original prog was written in C as I
have written that disassembler to see what is going inside. It tured out
that this code was full of with redundancy, and could not fit into smaller
equipment -- so I have to rewrite it from scratch, anyway.

But because that disassembler works fine and I am sure it could be extend it
to produce even better job I thought I could go further -- but it seems that
it is far from possible. Maybe just put as many comments to the disassembled
code as possible to make such an implementation easier by the engeneer. I
mean I could put comments like "This routine seems to be EEPROM writing" or
"delay loop takes 5 cycles / 5 ms per iteration". So that using those info
the engeneer could find relevant places faster. And then he/she could
compile that disassembled and reimplemented source.


On 17/07/06, Xiaofan Chen <spamBeGonexiaofancspamBeGonespamgmail.com> wrote:
{Quote hidden}

> -

2006\07\17@095941 by Tamas Rudnai
face picon face
I have written it in Perl, so it is platform independet (..or Perl dependent
:-), so as long as you have Perl 5.x installed should work fine. Maybe later
on will compile to Win32 exe from it as well. It is in Alpha stage and works
with 14bit PICs only at the moment.

You can download it from

http://sourceforge.net/projects/unpic

However, I am having trouble to access your web site, could you check the
url please?

Thanks,
Tamas



On 17/07/06, William Couture <RemoveMEbcouturespamTakeThisOuTgmail.com> wrote:
{Quote hidden}

> -

2006\07\17@100124 by olin piclist

face picon face
Xiaofan Chen wrote:
>> That's only one of many problems.  I think it would be impossible to
>> properly track indirect addressing references.  Since often run time
>> math is used to calculate the target address, you don't know what is
>> ultimately being addressed.  This means you have to keep all RAM at
>> exactly the same addresses on the new machine, but of course that is
>> either impossible or leads to other problems.
>
> C compile will be quite good at this even though some people may not
> opt for C.

I think you are missing the point that the OP is trying to convert just the
raw binary from one PIC type to another.  This therefore has nothing to do
with whatever language was used to create the code in the first place.


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2006\07\17@103801 by Alan B. Pearce

face picon face
>However, I'm running a Win2K system.  What would I have to install to try
it?

To run his disassembler, goggle for a distribution of Activeperl.

OK, here is the site ...
http://www.activestate.com/Products/ActivePerl/?_x=1


2006\07\17@111405 by Tamas Rudnai

face picon face
To answer to myself:

the correct URL of William's site is:

http://www.picemulator.com/

PS: I was too lazy to see the typo in the URL at the first glance :-)


On 17/07/06, Tamas Rudnai <EraseMEtamas.rudnaispamgmail.com> wrote:
{Quote hidden}

More... (looser matching)
- Last day of these posts
- In 2006 , 2007 only
- Today
- New search...