I'm going to say "Yes, it's a good idea". Some of the time. And "It depends".

A lot of projects with microcontrollers involve external components, and there's a period of experimentation involved in getting those components to work in the way that they need to. That's when the characteristics of the Arduino might make it very useful--the ability to set up a working system extremely quickly, and operate it interactively using the pre-designed monitor connection, and make rapid changes in the functionality. Once all that has been done to the designer's satisfaction, it would be time to shift over to a smaller and cheaper processor. Perhaps that processor would be the same as the one in the Arduino, and perhaps not.

The reason not to use an Arduino for the initial work would be if there has to be a lot of processing involved, with libraries being used that won't work in a different processor. When it's more of a programming project than a hardware one, you probably wouldn't want to do the work in two environments because you'd end up having to do it from scratch each time. But the Arduino makes it possible to get hardware running very quickly, and that can be a useful way to start a project.

 

Use something a little more universal to work out the logic like a flow chart. There are certain rules to think about when using a flow chart method. 1) Think of the flow chart as a state machine. 2) Design your flowchart with a fall-through approach (i.e. none of the Nodes within the flowchart should wait in a loop under any circumstance) 3) For more advanced options, each Node of the flowchart returns to a dispatcher. A Node can only change the "index" of where the dispatcher should execute the next Node. This allows for a multi threaded atomic flowchart approach where each unique Flow chart (or State Machine) is assigned it's own index value.

In this form, you can port the Flow Chart to just about any programming environment you want. There are many times at my job where one project my require several different programming languages. Any programmer worth their weight should be able to operate under multiple languages.

Another benefit of flow charting is that it is much easier to pickup your code where you left off to make changes .... in a week, in a month, in a year. Also it allows you to "switch gears" from one program to another without wasting much time.

 

I very rarely make flow charts, except when I work with others as a team. What I always do though, is write in plain and simple language every step (and why) of what the code is supposed to do.

We call that pseudo-code.
It is an alternative to flowcharts and serve the same purpose.
Both flowcharts and pseudo-code should be written in plain language with no computer jargon and independent of the computer processor. Thus the program can be implemented on any computer processor or programming language.

 

That is, in and of itself a form of a 'flow-chart'. It is a logic methodology that works for you. Flow-charts should be done by newer coders- it gives them a road-map that they can 'run' on paper and test scenarios and check their logic. More seasoned/veteran coders use flow-charting less because they have usually learned 'tried and true' methods to code defensively- like always niling pointers after use, and so forth.

I never found flow charts very useful for real world systems documentation until I learned (to use some features of) UML. With ability to notate blocking and non-blocking operations in particular, as well as a range of other enhancements, I found I could accurately describe the interaction of async and loosely coupled subsystems.

UML is huge and like most of these things you could make a career out of learning and using it. The utility, for me, was in a particular subset that enabled much more accurate and richer descriptions. Prior to that I would only use flow charts for explanations of isolated algorithms or data flow.

There are also data flow diagrams which are useful if that's the exclusive domain you are working in. I would choose which was best based on who I was trying to communicate with. DFDs for DB admins and UML-based descriptions for programmers who were also concerned with additional logic.

 

I'm going to say "Yes, it's a good idea". Some of the time. And "It depends".

Yes.

I neglected to add, and it had occurred to me yesterday as an example of something sensible, for a project with a more formal process, at a larger scale, rapid prototyping in the Arduino IDE is very useful for testing the ideas of the design even if the implementation will be on an entirely different platform.

You can use it the same way some software tools allow you to create non-portable prototype UIs to work out how the program should interact with the user. A UX specialist might use a tool to create the various UI components which is used to both test and document the ideas. The programmers then have a more complete idea and they, as specialists, can implement that idea in "real" code.

Similarly, you can test many aspects of a project using the Arduino IDE and supported development boards even though the code will be practically useless in the actual implementation, particularly if the design team is different from the development team, or even if it's the same group, the design phase is distinct from the development phase.

My director and I developed a lightweight framework designed to make projects more successful and focused. We called it 4D after the four phases of the process: Discover, Design, Develop, and Deploy. By calling these out explicitly, it allowed us to keep some QC working with a variety of skill sets and levels. It was good stuff, I should have written a book on it.

 

That is, in and of itself a form of a 'flow-chart'. It is a logic methodology that works for you. Flow-charts should be done by newer coders- it gives them a road-map that they can 'run' on paper and test scenarios and check their logic. More seasoned/veteran coders use flow-charting less because they have usually learned 'tried and true' methods to code defensively- like always niling pointers after use, and so forth.

I still use flow-charts for complex algorithms, or any production algorithm as a form of 'formal documentation' of it. Flow-charts are invaluable if you have to go back later, for example, to see how two or three interrupt driven algorithms work together to perform a task, or you have massage data in a way that is simply not obvious in code, an comments aren't enough, where other documentation is necessary.

I know, as an example, when I was doing 6DoF simulation code for not just creating the environments, but for the drawing engine as well, that I was so deep in my mind into the data and how things worked to shave of micro and nanoseconds of time, touch every pixel only once, prediction algorithms, etc, that the only way to even understand what I'd done years later was to have flow-charts and lots of other documentation.

Flow-charting is an underutilized and underappreciated tool that would solve so many 'bad code' problems of today if the coders were disciplined and made an effort to benefit from such tried and true tools.

Do you find that even when one does not draw out a flow chart , we still think and plan as if we were .

 

It being a good idea depends. I often use Arduino to test things. Like if I bought a new OLED display that I haven't used before I'll wire it up with an Arduino to make sure that it works. Or a sensor, so that I can see what output values to expect. But that usually doesn't involve writing any (or much) Arduino code, because there are tons of previously written libraries and examples.

 

One other example of breadboarding with one controller then switching to a different one for production:

My team was designing a subsystem and had proven a a technology using a Motorola controller because the main engineer was familliar with it and already had the tools on his computer.

When we heard that sales predictions were 6 million units in the first year, the team met to discuss on-chip hardware that would be needed, then assigned each team member three or four microcontroller manufacturers to study and get quotes from. We met every afternoon until we boiled our selection down to a single controller from a big name in semiconductor maker with a proven record of customer support, and and the business guy wrapped up the price commitment, making the project a "go". We began writing the complete application program for the selected controller.

Breadboarding with a familiar controller helped quickly develop the (partly analog) key technology and that lead to a successful demonstration to management and inclusion in a several products under development. Re-writing for a lower cost controller saved several million dollars in costs the first year, which directly translated into profit.

 

Breadboarding with a familiar controller helped quickly develop the (partly analog) key technology and that lead to a successful demonstration to management and inclusion in a several products under development. Re-writing for a lower cost controller saved several million dollars in costs the first year, which directly translated into profit.

A very cogent example of what I meant in #25 .