I used to borrow the book from the library as a child, but never actually got to build the robot from the book. Recently, after finding the book online for free, I decided to finally build the robot for myself.

I used to borrow the book from the library as a child, but never actually got to build the robot from the book. Recently, after finding the book online for free, I decided to finally build the robot for myself.

Cost to build

Embedded video

Finished project

Number

Time to build

Type

wheels

URL to more information

Weight

Who owns Arduino? We don’t mean metaphorically — we’d say that’s the community of users and developers who’ve all contributed to this amazing hardware/software ecosystem. We mean literally. Whose chips are on the table? Whose money talks? It looks like it could be ARM!

The murky thing about privately held companies and out-of-court settlements is that all of the details remain private, so we can only guess from outside. We can speculate, however, that buying out half of the Arduino AG wasn’t cheap, and that even pooling all of their resources together, the original founders just didn’t have the scratch to buy [Musto] out. Or as the Arduino website puts it, “In order to make [t]his a reality, we needed a partner that would provide us with the resources to regain full ownership of Arduino as a company… and Arm graciously agreed to support us to complete the operation.” That, and the rest of the Arduino blog post, sure looks like ARM provided some funds to buy back Arduino.

We reached out to [Massimo Banzi] for clarification and he replied:

“Hi arm did not buy nor invest in arduino. The founders + Fabio Violante still own the company. As I wrote in the blog post we are still independent, open source and cross platform.”

We frankly can’t make sense of these conflicting statements, at least regarding whether ARM did or didn’t contribute monetary resources to the deal. ARM has no press release on the deal as we write this.

Announcing a partnership without details isn’t a new activity for Arduino. Recently we wrote about open questions on the Arduino Foundation. [Banzi] was willing to speak with Hackaday at length about that topic, suggesting more details were just weeks away but we have yet to see follow-through on that.

What we can tell is that [Banzi] and Arduino want us to know that they’re still independent. The Arduino post mentions independence and autonomy eight times in a 428-word post. (The lady doth protest too much?) They’re very concerned that we don’t think that they’ve been snapped up by ARM.

And there’s also good reason to believe that Arduino will remain autonomous even if ARM owns a big stake. ARM sells its intellectual property to a number of silicon manufacturers, who then compete fiercely by offering different peripheral sets and power budgets, and they’re very serious about providing them all with a level playing field.

Anyway, the various ARM chips are nice to work with from a hacker perspective. If the AVR-based UNO was the last non-ARM Arduino board ever made, we’d only shed a tiny little tear. On the other hand, if you’re an MSP430 or PIC fanboy or fangirl, we wouldn’t be holding your breath for a light-blue board sporting your favorite silicon but that is just conjecture.

So we have seemingly conflicting information on the details of this deal, but also promises of openness and transparency. On one hand we’re pleased that ARM is the apparent silent partner, but on the other hand we’re left confused and wanting more. Who owns Arduino?

Back in July, we announced that the original Arduino founders regained full control of Arduino as a company. It was the culmination of a project that lasted several months, which required a tremendous amount of effort in finding the right partner that could help us make it happen while keeping the spirit of Arduino true to itself.

Throughout the litigation we dreamed of reclaiming control of the company, bringing it back to its original principles while designing a strategy that would allow us to tackle the challenges of the contemporary IoT world.

In order to make his a reality, we needed a partner that would provide us with the resources to regain full ownership of Arduino as a company while keeping it independent and true to its values of openness.

It wasn’t easy, but more than a year ago, in the middle of the litigation, we started a conversation with an important technology company that is an essential building block of today’s digital world: Arm.

During a very hot day in spring I visited California to meet with Arm. It was a great meeting of minds and we determined that such a partnership was the right fit for us. Arm is an extremely innovative company whose processors can be found inside virtually every mobile device on the planet; but they don’t actually build silicon. Instead, they have created an ecosystem of a thousand-plus partners, some of whom compete with each other, but Arm works in harmony with all of them.

Arm recognized independence as a core value of Arduino. This was very important for us, as it meant full understanding of our need to work with multiple silicon vendors and architectures as long as they make sense for Arduino—without any lock-in with the Arm architecture.

Following the meeting with Arm, I was thrilled. I shared my excitement with our new CEO Fabio Violante and my cofounders: Arduino could again be 100% ours, with the help of a supportive partner that leaves complete autonomy to our team and our community.

We worked very hard for many months to make this happen, and Arm graciously agreed to support us to complete the operation.

What should you expect from us in the future? A stronger Arduino, free to innovate with more firepower, and plenty of enthusiasm for future challenges and opportunities.

We will continue to work with all technology vendors and architectures moving forward. We stay independent; we stay open, and we still provide the most loved microcontroller development platform that has changed the lives of so many people around the world.

With an extended metaphor comparing Arduino use and physical addiction, [Vadim’s] writing is a joy to read. He chose to focus on the BluePill (aka the next Arduino Killer™) which is a $1.75 ARM board with the form factor of an Arduino Nano. After describing where to get the board and it’s an accompanying programmer, [Vadim] introduces PlatformIO, an alternative to the Arduino IDE. But wait! Before the Arduino die-hards leave, take note that PlatformIO can use all of the “Arduino Language,” so your digitalWrites and analogReads are safe (for now). Like any getting started guide, [Vadim] includes the obligatory blinking an LED program. And, in the end, [Vadim] sets his readers up to be comfortable in the middle ground between Arduino Land and the Wild West.

The debate for/against Arduino has been simmering for quite some time, but most agree that Arduino is a good place to start: it’s simpler and easier than jumping head first. However, at some point, many want to remove their “crippling Arduino dependency” (in the words of [Vadim]) and move on to bigger and better things. If you’re at this point, or still cling to your Uno, swing on over and give Vadim’s post a read. If you’re already in the trenches, head on over and read our posts about the BluePill and PlatformIO which are great complements for [Vadim’s].

If you use the Arduino IDE to program the ESP32, you might be interested in [Andreas Spiess’] latest video (see below). In it, he shows an example of using all three ESP32 UARTs from an Arduino program. He calls the third port “secret” although that’s really a misnomer. However, it does require a quick patch to the Arduino library to make it work.

Just gaining access to the additional UARTs isn’t hard. You simply use one of the additional serial port objects available. However, enabling UART 1 causes the ESP32 to crash! The reason is that by default, UART 1 uses the same pins as the ESP32 flash memory.

Luckily, the chip has a matrix switch that can put nearly any logical I/O pin on any physical I/O pin. [Andreas] shows how to modify the code, so that UART 1 maps to unused pins, which makes everything work. it is a simple change, replacing two parameters to a call that — among other things — maps the I/O pins. You could use the technique to relocate the UARTs to other places if you choose.

When it comes to microcontroller development boards, we have a plethora of choices at our disposal. Each has its strengths and weaknesses, be they associated with its support and community, its interface capabilities, or its choice of processor family. Most boards you’ll find in our communities come from niche manufacturers, or at least from manufacturers who started as such. Just occasionally though along comes one whose manufacturer you will have heard of, ever whose manufacturer the Man in the Street will have heard of.

The board is due to be available sometime early next year, and while it looks as though it will be an interesting device we’d sound a note of caution to Sony. It is not good enough to have an amazing piece of hardware; the software and community support must be more than just make-believe. If they can crack that then they might just have a winner on their hands, if they fail to make any effort then they will inevitably follow Intel into the graveyard of also-ran boards.

URL to more information

Weight

In a recent post, I talked about using the “Blue Pill” STM32 module with the Arduino IDE. I’m not a big fan of the Arduino IDE, but I will admit it is simple to use which makes it good for simple things.

I’m not a big fan of integrated development environments (IDE), in general. I’ve used plenty of them, especially when they are tightly tied to the tool I’m trying to use at the time. But when I’m not doing anything special, I tend to just write my code in emacs. Thinking about it, I suppose I really don’t mind an IDE if it has tools that actually help me. But if it is just a text editor and launches a few commands, I can do that from emacs or another editor of my choice. The chances that your favorite IDE is going to have as much editing capability and customization as emacs are close to zero. Even if you don’t like emacs, why learn another editor if there isn’t a clear benefit in doing so?

There are ways, of course, to use other tools with the Arduino and other frameworks and I decided to start looking at them. After all, how hard can it be to build Arduino code? If you want to jump straight to the punch line, you can check out the video, below.

Turns Out…

It turns out, the Arduino IDE does a lot more than providing a bare-bones editor and launching a few command line tools. It also manages a very convoluted build process. The build process joins a lot of your files together, adds headers based on what it thinks you are doing, and generally compiles one big file, unless you’ve expressly included .cpp or .c files in your build.

That means just copying your normal Arduino code (I hate to say sketch) doesn’t give you anything you can build with a normal compiler. While there are plenty of makefile-based solutions, there’s also a tool called PlatformIO that purports to be a general-purpose solution for building on lots of embedded platforms, including Arduino.

About PlatformIO

Although PlatformIO claims to be an IDE, it really is a plugin for the open source Atom editor. However, it also has plugins for a lot of other IDEs. Interestingly enough, it even supports emacs. I know not everyone appreciates emacs, so I decided to investigate some of the other options. I’m not talking about VIM, either.

I wound up experimenting with two IDEs: Atom and Microsoft Visual Studio Code. Since PlatformIO has their 2.0 version in preview, I decided to try it. You might be surprised that I’m using Microsoft’s Code tool. Surprisingly, it runs on Linux and supports many things through plugins, including an Arduino module and, of course, PlatformIO. It is even available as source under an MIT license. The two editors actually look a lot alike, as you can see.

PlatformIO supports a staggering number of boards ranging from Arduino to ESP82666 to mBed boards to Raspberry Pi. It also supports different frameworks and IDEs. If you are like me and just like to be at the command line, you can use PlatformIO Core which is command line-driven.

In fact, that’s one of the things you first notice about PlatformIO is that it can’t decide if it is a GUI tool or a command line tool. I suspect some of that is in the IDE choice, too. For example, with Code, you have to run the projection initialization tool in a shell prompt. Granted, you can open a shell inside Code, but it is still a command line. Even on the PlatformIO IDE (actually, Atom), changing the Blue Pill framework from Arduino to mBed requires opening an INI file and changing it. Setting the upload path for an FRDM-KL46 required the same sort of change.

Is it Easy?

Don’t get me wrong. I personally don’t mind editing a file or issuing a command from a prompt. However, it seems like this kind of tool will mostly appeal to someone who does. I like that the command line tools exist. But it does make it seem odd when some changes are done in a GUI and some are done from the command line.

That’s fixable, of course. However, I do have another complaint that I feel bad for voicing because I don’t have a better solution. PlatformIO does too much. In theory, that’s the strength of it. I can write my code and not care how the mBed libraries or written or the Arduino tools munge my source code. I don’t even have to set up a tool chain because PlatformIO downloads everything I need the first time I use it.

When that works it is really great. The problem is when it doesn’t. For example, on the older version of PlatformIO, I had trouble getting the mBed libraries to build for a different target. I dug around and found the issue but it wasn’t easy. Had I built the toolchain and been in control of the process, I would have known better how to troubleshoot.

In the end, too, you will have to troubleshoot. PlatformIO aims at moving targets. Every time the Arduino IDE or the mBed frameworks or anything else changes, there is a good chance it will break something. When it does, you are going to have to work to fix it until the developers fix it for you. If you can do that, it is a cost in time. But I suspect the people who will be most interested in PlatformIO will be least able to fix it when it breaks.

Bottom Line

If you want to experiment with a different way of building programs — and more importantly, a single way to create and build — you should give PlatformIO a spin. When it works, it works well. Here are a few links to get you started:

Bottom line, when it works, it works great. When it doesn’t it is painful. Should you use it? It is handy, there’s no doubt about that. The integration with Code is pretty minimal. The Atom integration — while not perfect — is much more seamless. However, if you learn to use the command line tools, it almost doesn’t matter. Use whatever editor you like, and I do like that. If you do use it, just hope it doesn’t break and maybe have a backup plan if it does.