Automatic analyzing a MCU project and generating an overview - Page 1
Forum section: electronics / general

author: Psi
author_rank: Super Contributor
timestamp: February 28, 2015, 03:10:19 am
content: I'm taking over a embedded software project from someone leaving the company. The code is well documented with comments but has no global overview of all the units/librarys and how they all tie together.Is there any software i can run on the code which will look at all the units/headers and automatically generate a graphical overview showing how the units talk to each other.I'm thinking something like a flowchart which has the main unit and all the subunits as boxes with lines running between them labeled with function names to represent function calls that interact between units.Perhaps functions with lots of code could be colored darker than ones with only a few lines. etc..I'mnotlooking for something that breaks all the code down into flowchart logic, just something that can give a good overflew of the entire project.Does anyone know of software that will automatically generate something like this?

author: sleemanj
author_rank: Super Contributor
timestamp: February 28, 2015, 04:27:13 am
content: http://en.wikipedia.org/wiki/Call_graph#Free_software_call-graph_generators

author: Mechanical Menace
author_rank: Super Contributor
timestamp: February 28, 2015, 07:29:17 am
content: Quote from: Psi on February 28, 2015, 03:10:19 amSounds like a job for doxygen.http://www.stack.nl/~dimitri/doxygen/

author: VK3DRB
author_rank: Super Contributor
timestamp: February 28, 2015, 11:58:37 pm
content: Yep, definitely try Doxygen, but Doxygen takes a little learning to set up... maybe a half a day to get it working nicely enough. Definitely install the open source Graphviz tool as an add-on support for Doxygen. This creates really nice linkage diagrams. Graphvix is simple to install and Doxygen has a radio button in its Wizard to use Graphviz to generate diagrams.You can document everything in RTF for Word if you like, but the headings and table of contents will look sparse at first glance. Right click on the generated document in Word and get it to refresh and it will look superb. I hate Word, being antiquated and now quite bug infested but most people use it. You can also generate a Latex document if you like.Also for code already created, try doing a mass change of commented function headings to support Doxygen. If the previous coder was consistent, use Notepad++ to replace strings throughout the function commented headings to support Doxygen. To save time on old projects, consider using the/verbatimkeyword to simply use the commented function headings verbatim.Good luck taking over someone else's code. It is a worry the previous coder does not have any detailed design or architecture document. You might realise it is a mess as you tread into the unknown. It might be well commented, but hopefully it is not crap commented (not telling you WHY, but telling you the obvious WHAT). Good commenting is LESS commenting if the code is intuitive and well written, ie: you can read the code like a novel, not like a book on calculus. Consider using Eclipse to refactor the code if necessary. It can refactor things quickly, but unfortunately its refactoring tools are buggy for large projects and you have to recompile regularly to make sure Eclipse has done its job properly. Refactoring is a lot of work, but it may pay dividends down the track for bug fixing, additions and improvements.All the tools I mention are free to a good home.If you don't already have them, I suggest write or download/modify some CODING STANDARDS for your company. Our coding standards is mostly about the coding style and we also have a document that details stuff outside the actual code for each project, eg: user requirements, software or engineering requirements, risk analysis, software architecture, detailed design documents, traceability matrices, and review and approvals processes. An extreme amount of documentation to be honest, but the detailed design document references the automatically generated Doxygen generated document, which saves a heap of work.A detailed design document and the actual code is iterative. The detailed design document can be used as an initial framework for the code and as the code matures, the code updates the detailed design document. This way seems to work OK from my experience.