Post by thread:[PIC]: Reverse Engineer / Flowchart to document as

Hi, I have inherited an assembler project that has not been documented. I was wondering if anyone knows of a tool that will allow be to better understand the structure of the project, e.g. by creating some flowchart or equivalent. Any suggestions would be very much appreciated. Many Thanks!! ___________________________________________________________ Support the World Aids Awareness campaign this month with Yahoo! For Good http://uk.promotions.yahoo.com/forgood/

On 1/15/08, John Flynn <spam_OUTquery_me2001TakeThisOuTyahoo.co.uk> wrote: > I have inherited an assembler project that has not been documented. I > was wondering if anyone knows of a tool that will allow be to better > understand the structure of the project, e.g. by creating some flowchart > or equivalent. So you do have the source code and the hardware, right? Without reading the firmware, you need to be familiar with the hardware function first. And then you can start to read the firmware. If it is for a PIC, load the code in MPLAB, use the simulator (MPSIM) or a debugger (PICkit 2 or ICD2), or even an ICE (ICE2000) to run through the firmware. This may help you a lot. BTW, how big is the code and how complicated is the function? Sometimes it might be easier to start from scratch if the original code is not in good shape. Xiaofan

> On 1/15/08, John Flynn <.....query_me2001KILLspam@spam@yahoo.co.uk> wrote: > > I have inherited an assembler project that has not been documented. I > > was wondering if anyone knows of a tool that will allow be to better > > understand the structure of the project, e.g. by creating some flowchart {Quote hidden}> > or equivalent. > > So you do have the source code and the hardware, right? > Without reading the firmware, you need to be familiar with > the hardware function first. And then you can start to read the > firmware. If it is for a PIC, load the code in MPLAB, use > the simulator (MPSIM) or a debugger (PICkit 2 or ICD2), > or even an ICE (ICE2000) to run through the firmware. > This may help you a lot. > > BTW, how big is the code and how complicated is the function? > Sometimes it might be easier to start from scratch if the > original code is not in good shape. > Xiaofan, Thanks for the feedback. Yes I have the source code and the target hardware and a ICD2. I could step through the code to see the operation - I have been trying to do this but I felt that I would understand it better if there was some way of documenting the code. This would just give me that helping hand to get a better feel for the overall control. The code is not huge there is about 1000 lines of assembler. Thanks, John __________________________________________________________ Sent from Yahoo! Mail - a smarter inbox http://uk.mail.yahoo.com

Be prepared to sit down to read it........ The most painful way but worth the effort. I read undocumented code daily....... John --- John Flynn <query_me2001KILLspamyahoo.co.uk> wrote: {Quote hidden}> Hi, > > I have inherited an assembler project that has not > been documented. I > was wondering if anyone knows of a tool that will > allow be to better > understand the structure of the project, e.g. by > creating some flowchart > or equivalent. > > Any suggestions would be very much appreciated. > > Many Thanks!! > > > > > > > ___________________________________________________________ > Support the World Aids Awareness campaign this month > with Yahoo! For Good > http://uk.promotions.yahoo.com/forgood/ > > --

> > The code is not huge there is about 1000 lines of > assembler. > > Thanks, > John > Make comments in the code. Comment all subroutines. It makes things easier to understand. 1000 lines should not be a big problem unless the programmer starts to get creative with this coding..... I like challenges :) John ____________________________________________________________________________________ Looking for last minute shopping deals? Find them fast with Yahoo! Search. tools.search.yahoo.com/newsearch/category.php?category=shopping

There are programs to flowchart and format C code, but I've never seen one for assembly, and assuming there are I doubt one exists for the PIC. 1,000 lines isn't too bad to deal with, just take it a little at a time. I find that commenting it or even putting pseudocode in as comments makes it go much faster. Good luck! -Adam On 1/15/08, John Flynn <.....query_me2001KILLspam.....yahoo.co.uk> wrote: {Quote hidden}> Hi, > > I have inherited an assembler project that has not been documented. I > was wondering if anyone knows of a tool that will allow be to better > understand the structure of the project, e.g. by creating some flowchart > or equivalent. > > Any suggestions would be very much appreciated. > > Many Thanks!! > > > > > > ___________________________________________________________ > Support the World Aids Awareness campaign this month with Yahoo! For Good http://uk.promotions.yahoo.com/forgood/ > > -

www.fatesoft.com/s2f/ Not sure that it can be extended to PIC assembly though. >>> EraseMEkravnusspam_OUTTakeThisOuTyahoo.com 15 Jan 08 10:45:38 >>> Be prepared to sit down to read it........ The most painful way but worth the effort. I read undocumented code daily....... John --- John Flynn <query_me2001spam_OUTyahoo.co.uk> wrote: {Quote hidden}> Hi, > > I have inherited an assembler project that has not > been documented. I > was wondering if anyone knows of a tool that will > allow be to better > understand the structure of the project, e.g. by > creating some flowchart > or equivalent. > > Any suggestions would be very much appreciated. > > Many Thanks!! > > > > > > > ___________________________________________________________ > Support the World Aids Awareness campaign this month > with Yahoo! For Good > http://uk.promotions.yahoo.com/forgood/ > > --

For a small fee, I will do it for you. All I need is a schematic of the product and the source code. I've done this before... --Bob Axtell John Chung wrote: {Quote hidden}>> The code is not huge there is about 1000 lines of >> assembler. >> >> Thanks, >> John >> >> > Make comments in the code. Comment all subroutines. > It makes things easier to understand. 1000 lines > should not be a big problem unless the programmer > starts to get creative with this coding..... I like > challenges :) > > John > > > > > ____________________________________________________________________________________ > Looking for last minute shopping deals? > Find them fast with Yahoo! Search. tools.search.yahoo.com/newsearch/category.php?category=shopping >

> http://www.fatesoft.com/s2f/ > Not sure that it can be extended to PIC assembly though. It may be possible to use something like some UML tools that will derive sequence diagrams etc from source code. The 'Creating a UML project by Reverse Engineering' comes to mind that is on the Netbeans site. testhttp://www.netbeans.org/kb/55/uml-re.html I don't know if the java can be modified to deal with ASM instead. Probably not worth it for around 1000 lines, but longer term a larger project or very convoluted code might make it worth looking at.

There are many tool for such, for example if you google for the word "asmflow" you will get many relevant hits. Most of them are for 80x86 platform only, but there are some that knows 8051 too - have not seen any PIC related ones though. Anyway, reverse engineering a software is more or less what the guys here said before: commenting and naming the labels, functions and variables. One of the most popular tool in the PC industry is the IDA (Intelligent Dis Assembler) which makes reversing relatively easy. The newest version of it even creates a kind of graphical flow where you can name and fold code segments, putting them together etc making the complex flow easier understandable. But still, you need to understand the lowest parts, then commenting it and making nice labels makes easier to understand the upper level, which you comment and label again, and you go upper and upper on this circle till you reach a point you are happy and confident. The unPIC project I started a year ago or so supposed to help on reversing PIC codes but it works with HEX files (as the original goal was to disassamble the code) and also the project suspended as I have very limited amount of spare time at the moment. Anyway, the text editor is the best here as far as I concern, and maybe a piece of paper to draw. Good luck, Tamas On 1/15/08, Alan B. Pearce <@spam@A.B.PearceKILLspamrl.ac.uk> wrote: {Quote hidden}> > > http://www.fatesoft.com/s2f/ > > Not sure that it can be extended to PIC assembly though. > > It may be possible to use something like some UML tools that will derive > sequence diagrams etc from source code. The 'Creating a UML project by > Reverse Engineering' comes to mind that is on the Netbeans site. > testhttp://www.netbeans.org/kb/55/uml-re.html I don't know if the java can > be modified to deal with ASM instead. > > Probably not worth it for around 1000 lines, but longer term a larger > project or very convoluted code might make it worth looking at. > > > > -

Hi John: A very powerful method of simplifying code has to do with how you format the listing. For example put a page break at the beginning of each subroutine. For each new loop entry indent the listing. When this is done on what many would call good code there will be no case where more than one face of one sheet of paper is needed. If the main program has a long loop with a bunch of code (no subs) between the top and bottom of the loop it would take many sheets of paper to print the main routine. This is poor programming as it violates a span of control concept. Much better to make the intermediate code a routine that's called, now the main program fits on one face of one sheet of paper. Microsoft has a couple of paper back books on this general topic. Also see: Printed Page Formatting at http://www.prc68.com/I/PIC16F88.shtml#CL4PIC -- Have Fun, Brooke Clarke http://www.prc68.com/Alpha.shtml All my web pages listed based on html name http://www.PRC68.com http://www.precisionclock.com http://www.prc68.com/I/WebCam2.shtml 24/7 Sky-Weather-Astronomy Cam

Rikard Bosnjakovic wrote: > On 15/01/2008, Brooke Clarke <RemoveMEbrookeTakeThisOuTpacific.net> wrote: > > [...] >> Microsoft has a couple of paper back books on this general topic. > > I certainly hope not! :-) Actually, I have "Code Complete" and it's a really good book (IMO). I've seen some MS code and can honestly say that MS's coders should follow the book. It seems like a different coder writes a different function and coding/style standards are not followed. Oh before we get too far into the 'debate', while I like the book I found the variable names difficult to deal with. After a certain time the names became so long that they became noise in the code. At some point you have to decided between long names with meaning and shorter meaningful names. My tendency is towards the shorter as it makes reading the code easier. -- Linux Home Automation Neil Cherry spamBeGonencherryspamBeGonelinuxha.com http://www.linuxha.com/ Main site http://linuxha.blogspot.com/ My HA Blog Author of: Linux Smart Homes For Dummies