whiteglint143:
Do you guys have notebooks where you make a summery of what will be done, how to do it, where to get more information, essentially schematics for the sketch?
While I doubt many do it - one proper way to go about this is known as "process mapping" - aka, flowcharting. Visio (if using Windows - there are similar apps for other platforms) is your friend here, but you can also use pencil and paper if need be.
Start "high level" with the task or idea you want to flesh out; this level should consist of only a few steps (three for a minimum - your "start" label, your process block (a square or rectangle, with a description of what is happening at that level), and your "end" label - in the case of the Arduino, since it loops forever, this label will probably never be reached, but include it for completeness, perhaps).
Break out your high-level process block into a set of smaller sub-process blocks; you may at this stage need flow branching "blocks" (diamonds) - at each branch, there is only one of two paths that may be taken (corresponds to "if test then branch1 else branch2") - if you need multiple checks, use multiple stacked or other methods for the branching (but don't -ever- put multiple paths off a single branch - that is an "ambiguous" case, and will confuse you and others).
Lines between each section have a singular arrow at the end of the line, to show flow thru the flowchart. Lines connecting elements of the flowchart are "one-way" streets only, so to speak. NEVER put an arrow at both ends of a line; this is ambiguous. Instead, draw another line to show the flow back to an element.
On process blocks, you can add comments or such to represent data - you can also represent data variables being set using a parallelogram. With that said, let me try my hand at some bad ASCII art to detail a simple process flowchart - here's what you might start off with:
+--------------+
| Start |
+--------------+
|
v
+-----------------+
|Do Something Here|
+-----------------+
|
V
+--------------+
| End |
+--------------+
Then you flesh out the "Do Something Here" block:
+--------------+
| Start |
+--------------+
|
v
/-----------------/
/ Get Some Input /
/ Into Variable X /<----------------------------------------+
/-----------------/ |
| |
V |
+ |
/ \ |
/ \ |
/ \ +-----------------------+ |
/ \ | | |
+ X>5? +----YES----->| Display Output On LCD |------+
\ / | |
\ / +-----------------------+
\ /
\ /
+
|
NO
|
V
+--------------+
| End |
+--------------+
Ok - so maybe that's fairly basic, but it should show the concept of what I'm getting at; what you'll find about this process is a few things:
- You want to start small, and break those process blocks into smaller tasks
- NEVER try to start at the detailed level; you'll get bogged down in the details, and won't complete the process (or you'll get lost)
- If you find you have lines crossing all over the place, this is an indication of a problem:
a) make that area a process block, and lay out the details on another page
b) reorganize your logic - you are building "spaghetti code"
c) have you missed a step?
d) have you put too many steps in place?
- Think closely about the steps as you write them down; once you have them down - take a step back/breather - and come back later...
- You may find you missed something
- Keep in mind the idea of "soft process steps" - that is, steps that are done outside of the computational process, that are necessary to the completion of the main process - these MUST be mapped too.
- Think in terms of "inputs to a process" and "outputs of a process"; all processes have inputs and outputs.
- Finally - I can't stress enough the importance of starting high-level, and working down to the details!
Something else you may find interesting (though it is usually used for management and business details, but some of the info is useful for programming), is the concepts, ideas, and such behind a methodology called "Six Sigma"; it can be applied to software design - although on the scale of small personal projects for microcontrollers, it might be overkill. However, for larger software systems and processes, it can be used to identify problems long before they crop up, or to identify issues in processes that might be causing problems, but it is unknown why...
Note that the above flowcharting is "bare bones basic" - there are other methods out there (entire books have been written on the subject over the past 60 years); one involves situations where data may flow to other sub-processes outside the main process; and you place the flowchart in a "timeline" format (flowing generally "downward"), with the different sections layed out in a horizontal fashion. This can be useful when you want to see how the data is truely flowing between separate but interrelated "layers" of a larger overall process.
There are other methods out there which could be used, but I think for basic projects, flowcharting and simple data modeling may be all that is needed (for instance, for larger complex processes, a method of software modeling could be used; but I think that may be well outside the scope - except perhaps for larger programs written for a Mega, or maybe larger overall systems in which the Arduino or other microcontroller plays a supporting role - such as a complex robotics system or such).
It will also be useful to use some kind of versioning controls for your source, so you may want to set that up in order to keep track of your revisions (both for the code as well as your flowcharts, and the rest of project).
