How do you plan for project?

Kernel
1

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 ?

2

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.

2 Likes
3

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

4

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

Best of luck!

5

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