Hi All,

I have just been given a project and have inherited a lot of code to get to grips to.

There is a main of 1000 lines and 20+ other .C files and 10+ .h files with similar line numbers.

Has anyone got any advice on how to start getting to grips with it and ways to break it down...

They use #if defined (Run Macro) a lot so it means there is a lot of searching for this macro...

I am using the IAR Workbench and a MSP430 Dev Board.

Regards
JSwale

 

Was any reasonable attempt made to document the code?

Start with the header files. That will give you the prototypes for functions that are meant to be used in other files. Hopefully the person didn't just put prototypes for every function in the header.

Then it might help to draw a high-level flow chart of the main() function and proceed to do the same for functions that are called directly by it.

 

Yeah the comments are mainly high level, so therefore;

'/* Unless we are in normal operating mode, we should wait to be
woken by a significant event from the interrupt routines. */'

There is very little line by line commenting.

Just seen the function description listings, which will help me....even though there are over 600 functions.

 

there are tools to help, any decent IDE will have "jump to definition"/"jump to implementation" type commands. As WBahn says tracing things through and documenting as you go is the only way really. It may help to try and get into the mind of the person who put it together originally, did they use a naming convention? why did they split out the functions in the way they did?

 

If this is a microcontroller project, it will have a typical structure, which gives you some starting points.

I'd look for a main() function first, and see what it does. It probably initializes some peripherals — which ones? Make a list. If it's an MSP430 Grace-generated project, main() will call Grace_init(), so you will need to go there to see what gets initialized.

The second place I'd look are the ISR (Interrupt Service Routines) — where do the interrupts get handled? In quality code, these routines will usually be very small, but will trigger something else, such as generate an event for a state machine.

Then I'd look at the state machine. You will likely already have found it by looking at main() or through ISRs — it either runs in a continuous loop, sleeping when there is nothing to do, or from a timer ISR.

 

Ask the guy who gave you the code what it does and try to gather as much information about the task as possible. Make sure the code compiles and runs fine. Don't look at the code beyond this. Unless you don't have a specific task to accomplish, it's pretty much useless.

 

The code wasn't written in a day, and you can't learn it in a day. Take your time and learn the code in chunks. If anybody gives you grief, tell them you'll be glad to manage anybody who can do it faster. Manager's make more money -- right??