How do you plan for project?

I am intrested to know how do you plan for project. many people make flochart, state diagram before writing code

How do you plan before writing code ? Do you make state machine if yes so what should be in your state machine if you are planning for RTOS ?

I do not have a standard work flow. To me the important thing is to find a good model for the project at hand. Some people swear by UML or compatible tools, but I find them too restrictive. I go through a lot of pencils, paper and brain cells to find a “Bird eye view” control flow that looks like a fair approximation of the thing to realize. There is a lot of experience and intuition involved. Once I have a good feeling about it, I generally code upside down.

But that is my personal, very individual approach. Others come up with equally well working architectures through very different work flows.


I understand that you make models with pencil on paper for the project. I’m curious to know what you draw in this model. if you have a sample model can you post it i would like to see it

Sorry, no. It’s all customer proprietary information that I am not at liberty to disclose.

Best of luck!

My first step is to divide the project into the pieces that need to work together and to define what information they need to communicate/share. If the system has ‘Major State’ (like a ‘Standby’ state), that might show up here. The sequence of operations would tend not to show up at the top-level diagram.

Then each of these piece get defined with their inputs and outputs, and what they do in the middle. At this point I haven’t even defined what operations are to be put into a ‘Task’ and what are just operations that just happen ‘somewhere’ (They might be subroutines the sending operation runs in its task space, and not a message that gets sent to a task In this operation task space.

Only at this point do I work on defining what are my tasks, and how various requests get into the task.

Note, sometimes several pieces get merged into a single task, if they are interrelated enough. Things like, first we do operation A, then we do operation B on the results, then we do operation C, might make more sense as a single task that does A, B, then C.

Sometimes an operation just becomes a function library that does the interaction. I/O is often a major case for this, Most I/O doesn’t create a base task to handle it, but is just a library that doesn’t use a task. ‘Stateful’ I/O like USB or Ethernet is a major exception, those tend to need a task to process them.

1 Like