# On “Not using an Arduino”

#### Ya’akov

Joined Jan 27, 2019
6,856
[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.

Last edited by a moderator:

#### strantor

Joined Oct 3, 2010
6,338
My experience suggests that anyone who insists on "not an arduino" out of ignorance about what an arduino is, probably isn't worth your time to help. They'll insist on a bunch of other stupid stuff too. They'll take any perfectly logical suggestion and break it down into points which can't be reconstructed to resemble the original suggestion, and make further uninformed arguments against each of the points.

If you do manage to find some common ground and move forward with helping them with something resembling their original request, they put up some some resistance at every step of the process, taking only 90% of your advice at best. They always have to change something (and not tell you about it, typically) so they feel like they're in control. It's a hair-pulling experience that in the end you logically can't be held responsible for, but still feels like a failure and usually they see it as a failure on your part too.

We are not a business. Noobs are not clients. This is a forum of charitable experts donating their time to people who want to learn. Anyone taking a hard line stance on something they obviously know nothing about, is advertising that they aren't here to learn. So I won't help. Of course, to each his own. If anyone else would like to subject themselves to the whims of idiots, that's up to them. I deal with that too often in real life to abide it here too. I'll make an attempt to correct their bad assumptions but if they aren't receptive, I'm out.

#### Ya’akov

Joined Jan 27, 2019
6,856
We are not a business. Noobs are not clients. This is a forum of charitable experts donating their time to people who want to learn.
I agree, and I will add this: while this is true, I believe it is the case that the appropriate way to help, when we choose to, is the way we would help a paying client. Not in terms of effort but in terms of content.

That is, as you suggest I am unwilling to help those who will not take my advice. This is true when I am being paid as well. I have many times refused engagements because it was clear the client wanted to do something that would not actually solve their problem and wouldn't listen to my advice to take a different route.

Even if I had been hired, if the client would not allow me to do what I knew was best (not in the details but in the main structural parts), I would disengage from them. Firing a client is sometimes essential.

I wouldn't do that if I'd prefer something to be blue and they to be red, but if I knew that something required a truck and they insisted a use a team of horses, I would not continue.

#### ErnieM

Joined Apr 24, 2011
8,346
At my workplace we typically use dedicated systems with >500,000K of GPIB connected equipment to drive a patch panel where any custom interface circuitry can be placed to connect a test device to the nice stuff behind it. Runs off a custom program residing on a PC. System is >20 (30?) years old and has had much equipment added to it over the years. It works, sometimes badly, but it is what it is.

When going "off grid" to something not on the system, such as a burn in controller I worked on last year, you have a clean sheet of paper to start. Ive seen many systems also PC based, justified by the additional equipment needed to drive the unit. In my case, I just needed some simple switching to monitor some 20 points for current draw, and 3 high current switches. Test to run over 24 hours. What did I use? A cheap simple Raspberry Pi and touchscreen mounted on a PCB holding the switching (transmissive gates) and some mosfets to drive relays. Data logging goes right to the SD card, and a thumb drive can remote that data anywhere (as getting IT support to put this on our corporate network is not worth the hassle).

Simple, cheap, and it works.

Another project also off grid required a ton of GPIB equipment so using a PC was a given. But the unit also supplied a serial data stream of unusual format. For that I was hoping to use an Arduino, as it is cheap, documented, and works right out of the box, and could simply receive data and pass to the PC.

Unfortunately the business reason for the build was not met and this will not be built. Dang, I was going to have lots of fun with that one.

"Hobby" single board computers are not just for hobby work anymore.

#### nsaspook

Joined Aug 27, 2009
10,698
My problem with the Arduino universe is that it's archaic, simplistic and not much fun for a person that likes to control most of the hardware design and software engineering of a more than one off project. The properties that make it a good learning platform are also limiting factors for more advanced and efficient usage of internal hardware when you need task optimization.

#### MrChips

Joined Oct 2, 2009
27,686
It is about the comfort zone of the "client".
If the client needs to go from A to B across a span of water there are many solutions.

1) build a bridge
2) hire a water taxi
4) fly
5) swim
6) walk on water

Each solution requires a given amount of learning, knowledge, experience, expertise, skill, resources, effort, and risks.
The right solution is one that meets the needs and comfort zone of the client.

AAC is also an educational website. Besides helping others find solutions to their problems we strive to educate enquirers with other viable solutions with which they may not be familiar.

#### BobTPH

Joined Jun 5, 2013
6,080
Coming from a programming background and a long dormant electronics hobby, microcontrollers re-ignited my hobby. So I am naturally one of the “micro for everything” proponents here.

But I can understand the non-electronics, non- programming DIY enthusiast who knows how to solder but not much more. Asking him to learn programming of micros to do his little project is almost abuse.

So, we need to evaluate who we are dealing with before proposing solutions.

#### Papabravo

Joined Feb 24, 2006
19,592
Such a condition on a solution strongly demotivates me from offering anything at all.

#### Irving

Joined Jan 30, 2016
3,190
#1
6) walk on water
#2
Firing a client is sometimes essential.
There have been a few occasions in my career when requirement #1 led, sadly and sometimes expensively, to situation #2...

But the "Not an Arduino" issue can be applied to many situations:

Recently (as some of you are aware) there have been a spate of 'projects' aiming to measure 'mains AC' or 'high-voltage DC' (from rectified AC mains) with an MCU but without any understanding of the risks of floating DC, need for isolation, implications of bypassing the PE, etc. In more than one of these a newly qualified (or seemingly so based on the knowledge presented) EE has been tasked to do something the more experienced of us would balk at if asked by a client (or boss). In those cases I feel almost duty-bound NOT to walk away but to keep pushing 'our client' towards the safe options.

#### KeithWalker

Joined Jul 10, 2017
2,616
Thank you Ya'akov for your very interesting and comprehensive posting. Your views of the choice and use of "Arduinos" are very similar to mine. I also have similar thoughts to you on how we can best help the people who seek our help.
I feel that I have been instrumental in helping many to find an answer to their technical problems, which is very satisfying. I have also encountered a few who stubbornly demanded solutions using impossible constraints. One even became quite abusive. I have learned to wish those luck and to walk away.
I have very many years of experience in electronic measurements, analog. digital and microprocessor/microcontroller hardware and programming and it gives me great satisfaction to be able to pass on some of that accumulated knowledge by helping to solve other people's technical problems.

#### Ya’akov

Joined Jan 27, 2019
6,856
In those cases I feel almost duty-bound NOT to walk away but to keep pushing 'our client' towards the safe options.
I certainly agree here. Safety issues are very important to address, if not for the current person who may be refractory, for the people who will find and read about the dangers and maybe take the advice.

In a related though less grave example, people wanting to build or use radio transmitters are often completely ignorant of the regulations about them. The seem to assume if they can buy it, they can use it.

If it was just a matter of that, it wouldn't be so bad, but much of that regulation is to preserve the utility of the spectrum for others to use.

Because of this, I try to thoroughly educate people proposing extra-legal uses in the facts and consequences.

#### Papabravo

Joined Feb 24, 2006
19,592
#1
#2

There have been a few occasions in my career when requirement #1 led, sadly and sometimes expensively, to situation #2...

But the "Not an Arduino" issue can be applied to many situations:

Recently (as some of you are aware) there have been a spate of 'projects' aiming to measure 'mains AC' or 'high-voltage DC' (from rectified AC mains) with an MCU but without any understanding of the risks of floating DC, need for isolation, implications of bypassing the PE, etc. In more than one of these a newly qualified (or seemingly so based on the knowledge presented) EE has been tasked to do something the more experienced of us would balk at if asked by a client (or boss). In those cases I feel almost duty-bound NOT to walk away but to keep pushing 'our client' towards the safe options.
That is a solid argument with which I mostly agree. The situation is not dissimilar to the dilemma faced by an attorney who is asked to represent a difficult client. One who:
1. Will not listen to the good advice you give
2. Will not keep their mouth shut
3. Will insist on the veracity of their own alternate reality
4. Will not pay their bills
Nobody has a "duty" to deal with crap if the costs outweigh the rewards.

#### Ya’akov

Joined Jan 27, 2019
6,856
I feel that I have been instrumental in helping many to find an answer to their technical problems, which is very satisfying.
I have seen you do this, so it's not just your feeling.

#### SamR

Joined Mar 19, 2019
4,492

#### Irving

Joined Jan 30, 2016
3,190
it gives me great satisfaction to be able to pass on some of that accumulated knowledge by helping to solve other people's technical problems.
Likewise, and its one of the reasons, in semi-retirement, I've mentored, both in person and online, budding EEs, and teach 'Basic Electronics' as a module for non-EE MSc students.

#### bidrohini

Joined Jul 29, 2022
98
A very common reason for not wanting to use an Arduino is, that sometimes teachers do not allow using an Arduino. For example, if it is a Digital Electronics project at the University, teachers do not let students use a microcontroller at all. This is a common scenario in academic projects.

#### strantor

Joined Oct 3, 2010
6,338
My problem with the Arduino universe is that it's archaic, simplistic and not much fun for a person that likes to control most of the hardware design and software engineering of a more than one off project. The properties that make it a good learning platform are also limiting factors for more advanced and efficient usage of internal hardware when you need task optimization.
As an uncontested expert you are >100% welcome to shun arduino simply because you don't like how the name sounds or for any reason you need not even explain because you won't need someone on this forum to come up with the alternative solution for you. You know enough to know why you don't want it on your workbench, what the alternatives are, how to implement them, and how to make your implementation better than arduino would have been.

I have no problem with you rejecting arduino. I have a problem with Joe Noob asking me to design his project around unnecessary constraints that the isn't qualified to specify.

#### MrChips

Joined Oct 2, 2009
27,686
A very common reason for not wanting to use an Arduino is, that sometimes teachers do not allow using an Arduino. For example, if it is a Digital Electronics project at the University, teachers do not let students use a microcontroller at all. This is a common scenario in academic projects.
In my university electronics and computer program, students were tasked with designing and creating an ultrasonic range finder without using an MCU.

Why the restriction?

Because the MCU solution was coming up in the following semester.

#### ag-123

Joined Apr 28, 2017
269
Arduino (API) did what Mbed wants to do
https://os.mbed.com/
A 'universal' api across microcontrollers.
I think the roots are in the Wiring API, I'm not sure which is the chicken and which is the egg
( edit: oh it seemed 'in the beginning' there is wiring:
https://electronics.stackexchange.com/questions/866/wiring-vs-arduino)
http://wiring.org.co/reference/
https://www.arduino.cc/reference/en/
These days it is the API that matters.
Projects like Marlin Firmware
https://marlinfw.org/
would have been more difficult if not for the API, at least things like blinking a led can be 'standardized' using
Code:
pinMode(pin,OUTPUT);

digitalWrite(pin,HIGH or LOW);
it probably saved some #ifdefs as otherwise it could be
Code:
#if defined(a)
do this;
#elif defined(b)
do that;
#elif define(c)
do it another way
...
#elif
...
endless
there are some very fine codes e.g. this is *really good* btw
probably one of the very widely used for LCDs and I'd not be surprised if it drives some 'commercial' products.
the amount of #ifdefs is kind of modest for now.

oh by-the-way, I preferred CMake.
https://cmake.org/
RPi Pico did just that
https://github.com/raspberrypi/pico-sdk
by putting things in 'configurations' and swapping them in 'configurations' e.g. CMakeList.txt, it makes for less of those #ifdefs littered in c/c++ codes.

in cloud 9, someone wished there is an 'universal OS' or more correctly 'universal API' for microcontrollers, it is light years away from that ideal, but there is some "lowest common denominator" for now with Arduino API, Wriing API, Mbed etc. i.e. if you throw away 99.99% of things the last 0.01% may after all be common.
you see, just like in Java, they say "write once, run everywhere", it will remain a pipe dream for a foreseeable future I'd guess.
(JavaScript in browsers, come maybe 5-50% closer to the ideal, but yet it falls off cliffs at times, some browsers don't run Javascript, boo)

Last edited:

#### ag-123

Joined Apr 28, 2017
269
They are rapidly moving from the "Toy" category to the factory floor. They have come a long way since first entering the marketplace ~15 years ago.
Meet the industrialized Arduino
Meet the industrialized Arduino (controldesign.com)
the other "industralized" Arduino is all the 3d printers, it isn't just Arduino but
Marlin firmware (which used Arduino API to some extent)
https://marlinfw.org/
Cura slicer
https://ultimaker.com/software/ultimaker-cura
Slic3r
https://slic3r.org/
is higly jazzed up
https://www.prusa3d.com/page/prusaslicer_424/
and not least Reprap
https://reprap.org/wiki/RepRap
and I think a lot many (much) more, including all the manufacturers who used this framework.
together the whole lot forms the (FDM) 3d printing *industry*, the *whole* FDM 3d printing industry