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:
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.
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”.
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.