[This is long, and probably has some typos and/or editing errors in it. While I have proofread it once, it often takes more than once to weed it all out since I know what I mean and gloss over some errors. Please excuse this, and if you spot something please point it out so I can revise. If you are inclined to read this, I would be exceedingly interested in your own opinions and ideas. Responses—positive and negative—would be greatly appreciated —Ya’akov]
Many times folks will post that they have some problem to solve but they “don’t want to use an Arduino” to do it.
Of course, they have various reasons, sometimes good and sometimes not so good. There is also some confusion over that “an Arduino“ is, exactly that often seems to play a role in these cases. I wanted to outline my understanding of this situation, not as a set of rules but as a starting point for consideration of the a non-exhaustive set of topics including “Arduino”, the overhead and ease of whichever choice is made, the nature of microcontrollers vs circuits comprised of discrete parts, and the possibility of a false dilemma.
What does “an Arduino“ Mean?
Firstly, addressing the idea of an “Arduino” it is important to work out what this very fuzzy word means. There are, of course, MCU development boards designed and sold by Arduino, which is an organization (read about it on the linked page). These boards are open source and so are also manufactured and sold by many others, sometimes as simple clones and sometimes altered in various ways or even enhanced.
The venerable Arduino Uno R3, based on the Atmel ATMega 328P MCU
The quintessential ”Ardunio“ is the Uno R3 (pictured above). It is based on the Atmel ATMega 328P. This series of MCUs was the first supported by Arduino. The arrangement of the connectors, though unfortunate since they include a gap between pins 7 & 8 that causes various practical problems, has become a very important standard. They accommodate an enormous variety of “Shields” which are Uno specific modules that include hardware for specialist functions like displays, storage, enhanced or alternative I/O, and the like. For this reason “Uno compatibility“ became very important but it can range from being a copy to simply provide the same pin geometry to make using Shields possible.
Arduino also maintain the Arduino IDE and (part of) the tool chain it uses to turn code into working programs and get them into the MCU. This includes the descriptions of the boards, including their MCU, pinout, peripheral hardware, and the like, so that the user doesn’t have to change the higher level abstraction used to program the hoards. Effectively, it makes all boards the same except for what is available, but how to use whatever is available remains (mostly) constant across the “officially“ supported range of boards.
But one of the most powerful things about the Arduino development environment is that “unofficial” support for non-Arduino boards is easily done so that completely different architectures of MCU, many with advantages for particular applications, more capacity, or lower cost are completely “Arduno compatible”. Note that in our first case, were the hardware copies or mimics Arduino official hardware, “Arduino compatible“ meant the board could use Arduino targeted hardware, Arduino board descriptions and tool chain, or both. While here it means compatibility with the Arduino software, that is, the IDE.
Third party support can use entirely different toolchains. For example the support for Espressif ESPx MCUs and development boards is extensive. The Espressif boards are very different from the Ardunio hardware, yet by installing the board descriptions and the associated tools, the ESPx boards are completely compatible with the environment and with little or no change can run Arduino code. The IDE knows how to interpret the meaning of constants (such as BUILTIN_LED). and compile and upload the programs to the boards, thanks to the flexibility of allowing the definitions to include everything relevant.
All of the foregoing means that the user can simply write a program in the Arduino subset of C++ usually not needing to know the idiosyncrasies or the board they’e selected, and expect it to run. A very large number of libraries for support of third party hardware like sensors, communication devices, and motor controllers, among many others, support any architecture. Some require particular targets, but in every case I have seen, an important library will be patched by the community to support any new hardware that is at all broadly sold.
So this comes down to a few ideas:
Arduino can mean boards designed and sold by Arduino (the organization), or those copied and sold by third parties;
It can mean hardware or software compatibility, or both, for third party boards not copied from Ardunio designs, or not even the same architecture of any official Arduino board;
Arduino can refer to the development environment and its toolchain and so compatible can refer to this, even if there is nothing similar about the hardware.
To confuse this further, there are other development environments which some people choose to use like VSCode, and PlatformIO that are “Arduino compatible” since they provide access to the Arduino version of C++ and the use of “Arduino” libraries though they are in other ways very different.
So, ”Arduino” is not one thing, and “I don‘t want to use an Arduino” is not the same as “I don’t want to use an MCU”.
Why would someone not want to use an Arduino?
First, let’s dispose of a particular idea: if someone says, “I just don’t want to use an [MCU]” well, it’s their project and they get to decide how to do it. Those inclined to help certainly will, and some might look at the project and decide something other than an MCU is a bad idea and choose to remain silent (possibly after politely and cogently pointing out the MCU is far better for the application, even considering the constraints described by the TS). Let others help and don’t harp on the MCU route once it is (nominally) rejected by the TS after being disabused of any ignorance that might have given rise to the rejection of an MCU-based solution.
But many times the very utterance “I don’t want to use an Arduino” is a sign of ignorance concerning the nature of MCUs. For example it is often the case a person might imagine that “an Arduino” means an Uno R3 since that is, for most not well versed in this area, the “face of Arduino”. Many times the poster might even have played around with an Uno and had difficulty making it work. Developing in the Arduino environment can be initially daunting, and the Uno is a big piece of hardware.
On the other hand, the 8-bit, 8-pin ATtiny85 can be ”an Arduino”. It can be programmed and then placed separately on a board with very few passive components in support (one or two) and used as if it was an sort of ASIC. This, too, is “an Arduino”, yet is looks nothing like the Uno. So if the poster’s objection is based on picture the extremely large and complicated Uno to implement logic, or timer, or the like they are very correct to reject the Arduino path.
There are also various levels between Uno and 8-pin DIP. There are very small boards that are much more capable than the ATtiny, and though larger than it, may not be too large for the application at hand. This includes boards that support things like WiFi and Bluetooth which might be desirable to the poster but seem completely impossible to accomplish.
Sometimes, the objection is based on the poster’s actual experience with “Ardunio”. This often takes the form of a brief encounter with an Uno and attempts to make things work. If the poster is not familiar with programming, in addition to be a circuits neophyte, the (failed or very painful) experience of their encounter might push them away. But while this seems to be an informed decision, it often isn’t. It is an emotional reaction to the discomfort of being thrown into a complicated environment with not just one but many new things to learn.
In these cases, it may well be, and has proven to be many times, that when a helpful community provides both the missing information and as much handholding as is required to get up—what appears to the poster to be—the shear cliff of the start of the learning curve, the outcome is success all around and happiness. This does depend on the community’s willingness to help as much as the poster‘s interest in being helped.
But if the objection is about complexity, then other considerations are in order. Many times it is almost the case that a simple circuit, with something like a couple of transistors and a 555, will fit the bill. But often these turn out to be a false hope as one more requirement is tossed in making the simple circuit completely inappropriate. This raises two things.
First, before a non-MCU solution can be proposed, all of the features expected by the poster much be revealed. Just as they don’t have enough information to know how to do this, they also don’t have enough information to know which things are easy and which hard. Even more than in the case of an MCU-based solution, the discrete solution needs a complete specification at the start.
MCUs vs. Analog and Discrete Digital
For a person well versed in using analog circuits, or designing with TTL/CMOS logic working out a circuit is a simple business. The use of simulations to vet possible candidates, and the metal catalog of options for circuits and chips make this a simpler approach in a large number of cases where MCUs actually are applied.
But, for the person who doesn’t know these things, the allure of the simplicity may well be a siren’s song luring them to dash themselves against the rocks of their cheap breadboards. I have seen many times where a circuit-based solution has gone swimmingly and the community has help admirably to get it to that point. But there are the other cases where the TS’ rejection of the “complicated” MCU extends itself into “complicated“ circuits and they are unwilling to take the expert advice and take shortcuts instead, ending of in a “working” circuit that actual does only part of what they said they wanted to do, and does it badly.
This is because the choice of a circuit- vs. MCU-based solution was not made based on knowledge but ignorance and that ignorance doesn’t go away. Some of use have favorite tools, and we make choices based on our own facility with those tools. But unlike the neophyte, we know that we can solve the problem with the tool at hand, even if it would be better, all other things being equal, to use something else we are less conversant in.
So it is easy to sympathize with the MCU-averse person initially until we see the same behavior in the case of the circuit-based solution. It is very important to remember if the poster is a clean slate, insofar as they don’t have a toolset in either domain the “simplicity“ of either solution is rally just a false hope. There will be a learning curve no matter what, and when viewed dispassionately the complexity and difficulty if either solution is not independent of the person who is doing the implementation.
In those cases where a circuit is helpfully provided by community members, and all the troubleshooting is also done by them, and modifications as the requirements (almost inevitably) change, well that’s no test of simplicity. It would be the same for the case of a code being handed to the poster, and all of the debugging done for them. This sometimes makes circuit-based solutions seem simpler. It is my observation (subject to scientifically motivated revision) that people proposing circuits are more likely to provide a turnkey solution than those assisting with MCU efforts.
The Real Differences Between Circuits and MCUs
So, if the choose is not ignorance driven, what distinguishes one from the other? Here are some heuristic launching points in the analysis. I am very interested in additions, deletions, and revisions to this list from others. This is how I see things.
Logic is Required
This is my first flag in favor of MCUs over circuits. It is certainly the case that TTL logic chips are cheap, effective, and “simple” to the initiated. When something proposed by a neophyte includes logic, it also most likely includes revisions to the specification presented and last minute additions. Obviously, in the case of discrete logic, revising code is far simpler than revising wiring or even worse PCBs.
Timing is Required
While it is certainly true that a 555 is an amazing, versatile timer with a myriad applications, it is very important ot pin down what the timing is about. If precision, repeatability, or flexibility is required then the MCU is probably better. Alternatively, if someone appears wanting help to make an Uno R3 isn’t a ~10 second timer, it is clearly time to move them to the 555.
Communication is Required
If the problem involves communicating with some other device or system, it is rarely the case the circuit makes more sense than the MCU. This is true whether the communication is complex and requires a protocol, or if it is simple and just needs logic levels. This goes back to the idea that requirements are bound to change thanks to the missing but necessary design skills that can create a clear, concise, and comprehensive specification. To offer a circuit that definitely works in the case as presented and have something thrown in that makes it unsuitable is very frustrating.
Some Part of the Solution is Best Left to an IC
In some cases there is a relatively complex need for which there is an IC offering immediate functionality which would require a large, complex circuit to provide. If this IC is designed to work with an MCU, through SPI or I²C, clearly the MCU becomes essential and the solution is greatly simplified.
Experience Suggests that Additional Functionality Will Soon be Required
Sometimes, we can see very clearly the poster will be expediting to extend the solution. In these cases accommodating the future growth in a circuit-based design may be very difficult if not impossible due to the ever-present lack of clear specifications. While it is often possible to predict the need for future functionality—either because the poster explicitly says this or because the nature of the solution suggests it—it is sometimes an unknown.
If the poster can’t do either circuits or programs themselves, the question becomes “which will be simpler when it is required?”. It is my belief that learning to program is much easier than learning circuit design. This is for two reasons.
Firstly, revisions to circuits is tedious, quick changes cannot always be made, and while sometimes rapid A/B troubleshooting is possible many times the revisions must be made in multiple locations which is difficult and prone to error. On the other hand, software can be revised rapidly and restored instantly if it has been mangled.
Instrumenting hardware takes hardware and expertise in using it, Many times the hardware is unavailable and it means buying something. Instrumenting software, on the other hand, is a matter of print() statements, which are quick and free and require no expertise.
A False Dilemma
The truth is, a good solution that might include an MCU as the controller or to implement complicated logic almost always works better with, or even requires circuits in support. From simple MOSFETs to switch large loads, to outboard logic to extend the functionality of a smaller MCU, both domains work together to create a good solution.
If an MCU is legitimately called for at all it is very likely to be only part of the solution. It is important not to cut off either possibility when creating a good solution. I want to reiterate that the human factors: skills, experiences (good or bad) with technologies and methods, and just plain preference are as important. But I believe that it is appropriate and most helpful not to take the immediate rejection of an MCU as a requirement and instead to investigate the nature of the objection and properly advise the person seeking a solution on the value and flexibility offered by “an Arduino”.
As consultants to the people who arrive here seeking help, it feels most proper to avoid our own prejudices and preferences when making suggestions on the overall nature of a solution. Because I am better at one thing than another doesn’t mean I can‘t see how using the things I am less good at would be better for someone good at nothing. I can help with the things I have strengths in, but I might find the need to point at an area I am not able to help with to get the best results for the “client” who I am trying to assist.
Many times folks will post that they have some problem to solve but they “don’t want to use an Arduino” to do it.
Of course, they have various reasons, sometimes good and sometimes not so good. There is also some confusion over that “an Arduino“ is, exactly that often seems to play a role in these cases. I wanted to outline my understanding of this situation, not as a set of rules but as a starting point for consideration of the a non-exhaustive set of topics including “Arduino”, the overhead and ease of whichever choice is made, the nature of microcontrollers vs circuits comprised of discrete parts, and the possibility of a false dilemma.
What does “an Arduino“ Mean?
Firstly, addressing the idea of an “Arduino” it is important to work out what this very fuzzy word means. There are, of course, MCU development boards designed and sold by Arduino, which is an organization (read about it on the linked page). These boards are open source and so are also manufactured and sold by many others, sometimes as simple clones and sometimes altered in various ways or even enhanced.
The venerable Arduino Uno R3, based on the Atmel ATMega 328P MCU
The quintessential ”Ardunio“ is the Uno R3 (pictured above). It is based on the Atmel ATMega 328P. This series of MCUs was the first supported by Arduino. The arrangement of the connectors, though unfortunate since they include a gap between pins 7 & 8 that causes various practical problems, has become a very important standard. They accommodate an enormous variety of “Shields” which are Uno specific modules that include hardware for specialist functions like displays, storage, enhanced or alternative I/O, and the like. For this reason “Uno compatibility“ became very important but it can range from being a copy to simply provide the same pin geometry to make using Shields possible.
Arduino also maintain the Arduino IDE and (part of) the tool chain it uses to turn code into working programs and get them into the MCU. This includes the descriptions of the boards, including their MCU, pinout, peripheral hardware, and the like, so that the user doesn’t have to change the higher level abstraction used to program the hoards. Effectively, it makes all boards the same except for what is available, but how to use whatever is available remains (mostly) constant across the “officially“ supported range of boards.
But one of the most powerful things about the Arduino development environment is that “unofficial” support for non-Arduino boards is easily done so that completely different architectures of MCU, many with advantages for particular applications, more capacity, or lower cost are completely “Arduno compatible”. Note that in our first case, were the hardware copies or mimics Arduino official hardware, “Arduino compatible“ meant the board could use Arduino targeted hardware, Arduino board descriptions and tool chain, or both. While here it means compatibility with the Arduino software, that is, the IDE.
Third party support can use entirely different toolchains. For example the support for Espressif ESPx MCUs and development boards is extensive. The Espressif boards are very different from the Ardunio hardware, yet by installing the board descriptions and the associated tools, the ESPx boards are completely compatible with the environment and with little or no change can run Arduino code. The IDE knows how to interpret the meaning of constants (such as BUILTIN_LED). and compile and upload the programs to the boards, thanks to the flexibility of allowing the definitions to include everything relevant.
All of the foregoing means that the user can simply write a program in the Arduino subset of C++ usually not needing to know the idiosyncrasies or the board they’e selected, and expect it to run. A very large number of libraries for support of third party hardware like sensors, communication devices, and motor controllers, among many others, support any architecture. Some require particular targets, but in every case I have seen, an important library will be patched by the community to support any new hardware that is at all broadly sold.
So this comes down to a few ideas:
Arduino can mean boards designed and sold by Arduino (the organization), or those copied and sold by third parties;
It can mean hardware or software compatibility, or both, for third party boards not copied from Ardunio designs, or not even the same architecture of any official Arduino board;
Arduino can refer to the development environment and its toolchain and so compatible can refer to this, even if there is nothing similar about the hardware.
To confuse this further, there are other development environments which some people choose to use like VSCode, and PlatformIO that are “Arduino compatible” since they provide access to the Arduino version of C++ and the use of “Arduino” libraries though they are in other ways very different.
So, ”Arduino” is not one thing, and “I don‘t want to use an Arduino” is not the same as “I don’t want to use an MCU”.
Why would someone not want to use an Arduino?
First, let’s dispose of a particular idea: if someone says, “I just don’t want to use an [MCU]” well, it’s their project and they get to decide how to do it. Those inclined to help certainly will, and some might look at the project and decide something other than an MCU is a bad idea and choose to remain silent (possibly after politely and cogently pointing out the MCU is far better for the application, even considering the constraints described by the TS). Let others help and don’t harp on the MCU route once it is (nominally) rejected by the TS after being disabused of any ignorance that might have given rise to the rejection of an MCU-based solution.
But many times the very utterance “I don’t want to use an Arduino” is a sign of ignorance concerning the nature of MCUs. For example it is often the case a person might imagine that “an Arduino” means an Uno R3 since that is, for most not well versed in this area, the “face of Arduino”. Many times the poster might even have played around with an Uno and had difficulty making it work. Developing in the Arduino environment can be initially daunting, and the Uno is a big piece of hardware.
On the other hand, the 8-bit, 8-pin ATtiny85 can be ”an Arduino”. It can be programmed and then placed separately on a board with very few passive components in support (one or two) and used as if it was an sort of ASIC. This, too, is “an Arduino”, yet is looks nothing like the Uno. So if the poster’s objection is based on picture the extremely large and complicated Uno to implement logic, or timer, or the like they are very correct to reject the Arduino path.
There are also various levels between Uno and 8-pin DIP. There are very small boards that are much more capable than the ATtiny, and though larger than it, may not be too large for the application at hand. This includes boards that support things like WiFi and Bluetooth which might be desirable to the poster but seem completely impossible to accomplish.
Sometimes, the objection is based on the poster’s actual experience with “Ardunio”. This often takes the form of a brief encounter with an Uno and attempts to make things work. If the poster is not familiar with programming, in addition to be a circuits neophyte, the (failed or very painful) experience of their encounter might push them away. But while this seems to be an informed decision, it often isn’t. It is an emotional reaction to the discomfort of being thrown into a complicated environment with not just one but many new things to learn.
In these cases, it may well be, and has proven to be many times, that when a helpful community provides both the missing information and as much handholding as is required to get up—what appears to the poster to be—the shear cliff of the start of the learning curve, the outcome is success all around and happiness. This does depend on the community’s willingness to help as much as the poster‘s interest in being helped.
But if the objection is about complexity, then other considerations are in order. Many times it is almost the case that a simple circuit, with something like a couple of transistors and a 555, will fit the bill. But often these turn out to be a false hope as one more requirement is tossed in making the simple circuit completely inappropriate. This raises two things.
First, before a non-MCU solution can be proposed, all of the features expected by the poster much be revealed. Just as they don’t have enough information to know how to do this, they also don’t have enough information to know which things are easy and which hard. Even more than in the case of an MCU-based solution, the discrete solution needs a complete specification at the start.
MCUs vs. Analog and Discrete Digital
For a person well versed in using analog circuits, or designing with TTL/CMOS logic working out a circuit is a simple business. The use of simulations to vet possible candidates, and the metal catalog of options for circuits and chips make this a simpler approach in a large number of cases where MCUs actually are applied.
But, for the person who doesn’t know these things, the allure of the simplicity may well be a siren’s song luring them to dash themselves against the rocks of their cheap breadboards. I have seen many times where a circuit-based solution has gone swimmingly and the community has help admirably to get it to that point. But there are the other cases where the TS’ rejection of the “complicated” MCU extends itself into “complicated“ circuits and they are unwilling to take the expert advice and take shortcuts instead, ending of in a “working” circuit that actual does only part of what they said they wanted to do, and does it badly.
This is because the choice of a circuit- vs. MCU-based solution was not made based on knowledge but ignorance and that ignorance doesn’t go away. Some of use have favorite tools, and we make choices based on our own facility with those tools. But unlike the neophyte, we know that we can solve the problem with the tool at hand, even if it would be better, all other things being equal, to use something else we are less conversant in.
So it is easy to sympathize with the MCU-averse person initially until we see the same behavior in the case of the circuit-based solution. It is very important to remember if the poster is a clean slate, insofar as they don’t have a toolset in either domain the “simplicity“ of either solution is rally just a false hope. There will be a learning curve no matter what, and when viewed dispassionately the complexity and difficulty if either solution is not independent of the person who is doing the implementation.
In those cases where a circuit is helpfully provided by community members, and all the troubleshooting is also done by them, and modifications as the requirements (almost inevitably) change, well that’s no test of simplicity. It would be the same for the case of a code being handed to the poster, and all of the debugging done for them. This sometimes makes circuit-based solutions seem simpler. It is my observation (subject to scientifically motivated revision) that people proposing circuits are more likely to provide a turnkey solution than those assisting with MCU efforts.
The Real Differences Between Circuits and MCUs
So, if the choose is not ignorance driven, what distinguishes one from the other? Here are some heuristic launching points in the analysis. I am very interested in additions, deletions, and revisions to this list from others. This is how I see things.
Logic is Required
This is my first flag in favor of MCUs over circuits. It is certainly the case that TTL logic chips are cheap, effective, and “simple” to the initiated. When something proposed by a neophyte includes logic, it also most likely includes revisions to the specification presented and last minute additions. Obviously, in the case of discrete logic, revising code is far simpler than revising wiring or even worse PCBs.
Timing is Required
While it is certainly true that a 555 is an amazing, versatile timer with a myriad applications, it is very important ot pin down what the timing is about. If precision, repeatability, or flexibility is required then the MCU is probably better. Alternatively, if someone appears wanting help to make an Uno R3 isn’t a ~10 second timer, it is clearly time to move them to the 555.
Communication is Required
If the problem involves communicating with some other device or system, it is rarely the case the circuit makes more sense than the MCU. This is true whether the communication is complex and requires a protocol, or if it is simple and just needs logic levels. This goes back to the idea that requirements are bound to change thanks to the missing but necessary design skills that can create a clear, concise, and comprehensive specification. To offer a circuit that definitely works in the case as presented and have something thrown in that makes it unsuitable is very frustrating.
Some Part of the Solution is Best Left to an IC
In some cases there is a relatively complex need for which there is an IC offering immediate functionality which would require a large, complex circuit to provide. If this IC is designed to work with an MCU, through SPI or I²C, clearly the MCU becomes essential and the solution is greatly simplified.
Experience Suggests that Additional Functionality Will Soon be Required
Sometimes, we can see very clearly the poster will be expediting to extend the solution. In these cases accommodating the future growth in a circuit-based design may be very difficult if not impossible due to the ever-present lack of clear specifications. While it is often possible to predict the need for future functionality—either because the poster explicitly says this or because the nature of the solution suggests it—it is sometimes an unknown.
If the poster can’t do either circuits or programs themselves, the question becomes “which will be simpler when it is required?”. It is my belief that learning to program is much easier than learning circuit design. This is for two reasons.
Firstly, revisions to circuits is tedious, quick changes cannot always be made, and while sometimes rapid A/B troubleshooting is possible many times the revisions must be made in multiple locations which is difficult and prone to error. On the other hand, software can be revised rapidly and restored instantly if it has been mangled.
Instrumenting hardware takes hardware and expertise in using it, Many times the hardware is unavailable and it means buying something. Instrumenting software, on the other hand, is a matter of print() statements, which are quick and free and require no expertise.
A False Dilemma
The truth is, a good solution that might include an MCU as the controller or to implement complicated logic almost always works better with, or even requires circuits in support. From simple MOSFETs to switch large loads, to outboard logic to extend the functionality of a smaller MCU, both domains work together to create a good solution.
If an MCU is legitimately called for at all it is very likely to be only part of the solution. It is important not to cut off either possibility when creating a good solution. I want to reiterate that the human factors: skills, experiences (good or bad) with technologies and methods, and just plain preference are as important. But I believe that it is appropriate and most helpful not to take the immediate rejection of an MCU as a requirement and instead to investigate the nature of the objection and properly advise the person seeking a solution on the value and flexibility offered by “an Arduino”.
As consultants to the people who arrive here seeking help, it feels most proper to avoid our own prejudices and preferences when making suggestions on the overall nature of a solution. Because I am better at one thing than another doesn’t mean I can‘t see how using the things I am less good at would be better for someone good at nothing. I can help with the things I have strengths in, but I might find the need to point at an area I am not able to help with to get the best results for the “client” who I am trying to assist.
Last edited by a moderator:
