Why I don’t ‘do’ Arduino

There is no question that the advent of the Arduino ecosystem has heralded in an explosion of microcontroller usage within the electronic hobbyist community, which I personally very much welcome.

From a hardware side of things, aside from the infamous spacing error on headers which still drives me mad to this day, I’m OK with it all. It’s good to be able to buy ready made MCU boards and peripherals I can plug together quickly to try stuff out.

As a professional embedded software developer, I cannot get on-board with the software side of things. It’s all great for hobbyist use and genuinely does make life easier, however from the prospective of building a career in embedded electronics, and building competitive commercial products, it’s my opinion that the Arduino ecosystem is a hindrance.

Readers of this website will note that despite having published a number of Arduino related projects, I’ve never produced a single sketch, and I never will.

Let me take a minute to explain myself. There are four main reasons why:

1) Bloat

In the Arduino world, everything is done in C++, a language which is almost never used on 8-bit microcontrollers outside of this setting because it adds significant complexity to the toolchain and overhead to the compiled code. Realistically, there just isn’t any need for it, so no-one bothers. On top of this, many Arduino libraries are poorly written and inefficient, often diving into floating point arithmetic even if it isn’t necessary, instantly adding several more kilobytes to your compiled code size.

Doing everything the Arduino way, it’s very easy to end up unable to fit into a large 32K part, then needing to reach for expensive larger 64K or 128K parts, which in reality, with efficient coding, you could probably get it into a 16K part. In production use this is going to save a lot of money, and ultimately, more profit from your product.

2) Portability

While portability within the Arduino ecosystem is excellent, in the real world you likely will not get the opportunity to specify exactly what kind of microcontroller is to be used. You are given something by the hardware team, or having to work with an embedded MCU of some obscure architecture in an application specific IC. There might be a C++ compiler for it, it might even vaguely work, more likely however, is that it’ll be programmed in C.

If you had prototyped on the Arduino platform, and discover that when going to production, another type of platform is best for commercial reasons, you’re not going to be very well positioned to port the code over as it’s likely in the wrong language, and, because Arduino has been taking care of all of the details for you all of this time, the learning curve is going to be steep, potentially you’ll be grappling with fiendish technical details at the worst possible time.

It’s never too early to start thinking about the long term prospects of the product you’re building. Will it always live inside Arduino?

3) Hidden details

Perhaps the biggest lure of Arduino is that you don’t have to care about any of the messy details of programming microcontrollers. Everything’s hidden from you by a cute IDE and target library code. Sure, it’s all open source so you can look into to it, but because you don’t have to, you don’t. I admit, it’s hard to argue against the overall concept. Ultimately we all just want to get on and focus on the bits we care about.

The problem is that in commercial product development, difficult problems emerge in those hidden details practically on a daily basis, and you as an Engineer have to deal with them. It’s a lot quicker and easier to solve these problems when you’ve been through the process of implementing everything from the ground up.

4) I don’t have to

Over the years I have built up a huge collection of drivers, libraries and full working samples for several different types of microcontrollers and applications I regularly use, all written in C. Over the past 3 years I’ve been moving some (particularly AVR targeted projects) of it into my public github repository. Much of it predates the introduction of the first Arduino.

It’s like that in a commercial setting too. You build up everything you need over time, optimised for your requirements, best performance and minimal cost, and in a way that makes it easy to move from platform to platform as needed.

I’m not offering my code as competition to the Arduino ecosystem, and indeed would state that if it is working for you, stick with it. If anything, you shouldn’t be using my code. So instead, I offer it more in the sense of: “If you’re interested in seeing how things are outside of the Arduino world, here is an example”.

In conclusion

The genius of the Arduino creators was identifying the gulf between creation and consumption of technology, and that there was a big market for something that fitted in-between, a product with the convenience of consumption, but offering the thrill of creation, and capturing that market. Others tried, but didn’t have the je ne sais quoi of the Arduino founders and their creation. On that basis, I have no problem with it. It’s a very successful technology product, and one that I buy.

What I have a problem with is the frequently touted narrative that these products will somehow galvanise the next generation of engineering and technology students that will go on to build other significantly more high-tech products. I would point out that today we live in a world of high-technology created by people who did not have these things. We are now 16 years from the Arduino genesis, and finding the right people is as difficult as it has ever been.

8 thoughts on “Why I don’t ‘do’ Arduino

  1. I can understand the point of view shared in this post, yet I partially disagree with some of the arguments:
    – Modern C++ compilers generate code that is equivalent in speed/size to C compilers in most cases. The bloat in Arduino comes from the core libraries themselves, not from the use of C++.
    – Most development in the Arduino world has moved the 32-bit camp with plenty of memory (i.e. SAMD21), along with a sensible form factor. Looking at Arduino through the lens of the Arduino UNO R3 doesn’t make as much sense as it used to.
    – For many people, including myself, being quickly able to try out an idea, using libraries already written by others, is a great benefit of the Arduino ecosystem. In some cases, the code generated can effectively be used in a real product. Even when it’s not the case, it gives you a headstart for building a project. The same applies to things like MicroPython.
    – I’ve seen an explosion of engineers, hobbyists, and artists using electronics, and that can largely be attributed to the movement that was initiated by Arduino. The fact that talent is still hard to find is not a failure of the “Arduino narrative” but likely due to the fact that demand and use of technology has also exploded. Also, today our industry still seems to financially reward people who can write software for cloud-deployed applications more than those who design hardware.

    1. > Also, today our industry still seems to financially reward people who can write software for cloud-deployed applications more than those who design hardware.
      That is a very valid point, and it is also my own story. I have not worked in embedded software for quite a few years now (should I call myself a “former” embedded developer?) and that is down simply to the greater reward of writing higher level software for business. Arduino is not an introduction to that career path.

      It’s with that I’d continue to challenge the Arduino narrative. There is no doubt that they created an entirely new industry of consumption – the “maker” industry, and I’m one of those consumers. I still very much have my doubts that it’s bought much (if any) more talent into the mix. For the most part the rewards just aren’t there anymore.

      I definitely do think that Arduino/Raspberry Pi’s should be in an educational setting however, because school is boring, and building robots is fun. Additionally it creates a space for those who are interested in that career path. It is however my firm belief that those students would still pursue it even if they weren’t offered these gizmos.

  2. FWIW, as someone who is not a very capable coder, period (other than shell/awk), I find that the Arduino makes Interfacing easy (as long as you don’t want to do anything other than what was intended by the original author), but actually makes writing the rest of your code much harder. This is especially true if you are trying to integrate code from multiple Arduino libraries, which was a bloody nightmare the last time I tried it (admittedly several years ago, maybe it’s gotten better.) If you’re willing to put up with the overhead of the Arduino environment anyway, I find I’m way better off with one of the Lua- or Python-on-bare-metal projects out there…

  3. I found myself in the unenviable position of having to port a (thankfully small) arduino library’s functionality to a different micro’s pure-C environment (Cypress PSoC4, for the curious). It was a library that had no value-added in being OOP C++, but it was done that way for inter-library consistency reasons, apparently. The main…. value? I can see for C++ is compartmentalization of a particular library’s functions.
    One BIG use case in favor is the Native-USB AVRs (ATmega16/32u2/4) as found in the Pro Micro or Leonardo, is Multi-Instance enumeration of a single type of HID device, such as two or more HID Joystick from a single hardware device
    I do agree that the Arduino Shield form factor is cramp-inducing if you find yourself doing a lot of breadboarding

  4. Whole-heartedly agree with this. It’s insanely frustrating when searching for libraries (device drivers, or even something as simple as an RGB LED effects library) you might be able to use or adapt to the platform you’re working with – *every* search turns up a dozen different Arduino libraries of various quality levels, it makes it impossible to find anything else half the time.

    Having been using ESP32s of various kinds for most of my projects lately, I really appreciate Espressif’s ESP-IDF v4 – it’s pure C code (on top of FreeRTOS), with the option to use CPP if you’d prefer, and it’s surprisingly pleasant to use with a lot of nice (optional) components and fairly decent documentation.

    Unfortunately almost no projects I’ve come across actually use raw ESP-IDF, instead using the “add Arduino as a component” feature – which adds nearly a gigabyte of code to your source tree, throws away multithreading/tasks/queues/all the other fun things, and generally ruins the point of it in my opinion.

    That or they use PlatformIO, which does the same thing (ESP-IDF with Arduino) but with friendlier dependency management and yet more code added to your source tree.

    I appreciate everything the Arduino platform has done to bring people into the world of embedded development, but it’s a curse as much as it is a blessing.

Leave a Reply

Your email address will not be published. Required fields are marked *