OT: How do you design your Microcontroller Code?

[Freddie]

How do you design your projects?

I used to start writing my code before I had a clear plan. That was always a disaster.

Now before writing any code I start with a clean piece of paper and sketch out a rough Finite State Machine. I then draw the state machine in Visio, have a few peers review it, and then code from Finite State Machines. All the hard work is done while designing the finite state machines. Writing the code from the Finite State Machines is usually quick and easy. For more complex projects I use Matlab/Simulink to model the Finite State Machines. I then build Simulink test case to test the design. If all goes well I write the code from the Finite State Machines.

I don't draw "Flow charts" much any more as they show the known happy paths. There always seems to be questions like "well what if this happens" with Flow charts so I don't use them any more.

I'm curious to know how others design their projects...

[dbotkin]

I always have a clear plan, but seldom any kind of design on paper. I have the luxury of developing my own projects, not working from a set of someone else's features and specs.

I've tried working up flow charts, diagrams, etc - so far I've found it works best for me to just work up a list of required specs, the a "wish list" of features to add as space permits. I'm sure I'd flunk a CS course miserably. On the plus side, I do tend to comment the crap out of any obtuse or non-obvious code I write so I can figure out later why I did what I did.

[SherpaDoug]

I usually do a flow chart and sometimes a state machine. There is not usually anyone in the office that would understand either, so I start coding from there.
_________________
The search for better is endless. Instead simply find very good and get the job done.

[Ttelmah]

Generally, I 'block structure'. First thing to do, is to work 'round' the whole project, thinking what sub-components are needed. So (for instance), if an LCD display is needed, this will be a 'block'. Similarly, if there are 4-20mA inputs and outputs, these would each be blocks. Keyboard interfaces, USB interfaces, RS485 links to other processors, etc. etc., would each be their own block. Then the protocols to talk between the blocks are defined. So if the RS485, talks to the outside worls, I'll either design a protocol, or if this is going onto an existing system, document the protocol in use for this. Each block at this point, will have a functional description, and what interface it'll use. So something like a keyboard scanner, will simply say 'scans keyboard, debounces same, returns byte giving key number, encoded as...', with the format described. If there are external interfaces, the block, may itself be several pages long.

Then each block, can be again sub blocked, into what is effectively a flow chart. If doing something like an LCD, this may be as simple as 'use existing CCS code'. However for something complex like an external bus, it'll range from a state machine for decoding the protocol, through notes on timings, and notes on anything that requires priority service, and any constraints this may be going to introduce. I will also include 'value limits', for the numbers concerned, and comments on whether these need to be tested, or are 'implicit'. So (for instance), the value from an internal ADC, if the entire range is going to be used, has an 'implicit' limit at 0 to 1023. While if the device is fed from a limited voltage range, which should not go below perhaps 128 on the ADC counts, there would be a note of this, and details of what error checking should apply.

Then the core operation, is laid out using these blocks.

Then coding can be carried out separately on each block. Often as simple as loading a CCS library, or one of my own (I have for example, standard modules for various external interfaces, and a text command parser language, that has been used on several dozen projects). The blocking, also improves debugging and emulation in particular, since (for example), in the case of a ADC input from a 4-20mA loop, if I have defined that it is sampled every xmsec, and returns a value from a to b, in the form of an int16, emulation, can be a simple interrupt routine feeding from a lookup table, or a random value. over the required range.
In a sense, the 'blocks', become a crude form of the encapsulated thinking associated with OOP. Then the components that form the block, and the flow for the whole system, can better be coded using something like the flow chart approach.

Each 'block', usually ends up as an individually testable element, while the main code flow, can also be tested, with simulations for the components.

An 'splitable' approach like this becomes essential at some point, especially if the code is going to be reliably able to deal with values that you don't expect. For example, the current project I am working on has reached 17,500 lines, plus the CCS libraries used, but actually ran (with a couple of minor faults on timings), the first time it was compiled as a 'whole', because each unit had been tested first.

Then, be generous in your documentation. The header for the block, can be a copy of the notes made, including range limits, and what is tested. Try to write the code, so that if you loaded it in a year's time, after having lost track of it, you could read the header, and inline comments, and know what a block is meant to do, and how it does it. One of the military companies I used to work for, had a general policy to reject code, that did not have at least 75% comments!. While a bit silly, especially on modern languages, where things like the function, and variable names used, can themselves become 'comments', it is still worth bearing in mind...

Best Wishes

[Guest]

A superb source of textbook information can be found in the book:

Code Complete: A Practical Handbook of Software Construction

By Steve McConnell

This is one of my all time favorite books on software design.

HTH - Steve H.

[bkamen]

I also have the luxury of building my own designs. In some cases they are based on the desires of others.

So with that, I write down what THEY want to accomplish and then write a starting outline that lists all the features I must write to meet those needs.

The outline helps. I fill in the outline of features with subcategories of how I would accomplish the tasks.

Then I start writing in the comments of the step by step to accomplish the task and eventually fill in with code - KEEPING THE COMMENTS.

The comments act as a fingerprint to the next poor slob to has to read my code. I try to pass on as much as possible on how I was thinking at the time.

From there, I try to separate files into major blocks of stuff (unless the code is really short).



-Ben
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D