tags:

views:

55

answers:

4

Hi,

I hope you guys can help me out. I'm a 8 year ASIC/FPGA designer who's worked mainly on a system level. I'm quite familiar with C and Java but more of a test code role rather then production firmware/driver code.

I've been recently asked to be a Product Lead with the Software Group working on derivative products. What that means is that we'll be given lead product firmware that is tested well and we're supposed to proliferate that across different market segments. It is not going to be mere #define changes but it's probably not going to be major rearchitecting or starting from scratch work.

What do you think is the best starting point? Aside from jumping right into the code that is. Also any books to recommend?'

Thank you so much for your inputs.

A: 

Create a visual representation of the code using UML:

  • Create packages for each separate subject matter (electronics input/output, application-specific, persistent storage, safety, GUI, communications, data management, etc.).
  • Populate each package with the appropriate classes.

This will show everyone clearly the different technical areas. You can then modify each package depending on application requirements, hardware differences, communication protocols, or whatever. If you are careful, the package interfaces will remain constant, promoting reuse of code. Enterprise Architect from Sparx Systems is particularly good at helping keep code and model up to date.

Your packages will support your product line development. For a good background discussion of this method, see

FAST product-line architecture process

Bruce
A: 

One book I would recommend for embedded is Small Memory Software: Patterns for systems with limited memory.

Nikolai N Fetissov
A: 

I read Code Reading: The Open Source Perspective, which gives some techniques on reading through an unknown codebase. It might be worth a skim: http://www.spinellis.gr/codereading/

Stock up on some good tools to browse code. Eclipse is good at that. Here is a checklist for looking at new code: http://embeddedgurus.com/stack-overflow/2010/06/evaluating-embedded-code/

Good luck.

Adam Shiemke
A: 

A few thoughts...

First assess the quality and readiness of your team and its tools; most of the points in "The Joel Test apply.

The work you need to do will depend entirely in the quality and level of documentation of the codebase. The authors may have made your life hard or easy. You may over time need to make changes to the code simply to make adaptation more efficient where the author has specialised what you need to be generalised.

Ensure the build process is reliable and coherent and ideally "one-click". Write scripts and makefiles if necessary.

If not already done, work through and document all the known configuration points; i.e. all the macros, configuration files, constants, compiler options etc. that are likely to be needed to adapt the code to different targets. That way, when you adapt to a target, you have a check-list of areas than may need changing for each port, and can predetermine the workload an provide accurate schedules. Of course it make take one or two ports before all the config points are discovered and documented, and schedules are accurate.

If the documentation is incomplete and you have the budget, deploy a tool such as Understand to help navigate and visualise the code. Free alternatives include Doxygen, and your existing IDE or UML tool may have useful reverse engineering and code navigation tools.

Before you do anything else, of course your code must be under some sort of revision control and configuration management system. Don't change a line without one!

A test methodology and plan is probably necessary, either tool supported or manual so that all ports are tested to the same level, and so that regression testing (testing that fixed bugs remain fixed) is applied.

If you really want to get slick and efficient, deploy a continuous integration system CruiseControl, so that every change is built and verified automatically.

You may consider deploying some of your team not on the actual code adaptation, but rather developing and improving the code adaptation process.

Clifford