Posts | Comments

Planet Arduino

Archive for the ‘Hackaday Columns’ Category

The Consumer Electronics Show in Las Vegas is traditionally where the big names in tech show off their upcoming products, and the 2020 show was no different. There were new smartphones, TVs, and home automation devices from all the usual suspects. Even a few electric vehicles snuck in there. But mixed in among flashy presentations from the electronics giants was a considerably more restrained announcement from a company near and dear to the readers of Hackaday: Arduino is going pro.

While Arduino has been focused on the DIY and educational market since their inception, the newly unveiled Portenta H7 is designed for professional users who want to rapidly develop robust hardware suitable for industrial applications. With built-in wireless hardware and the ability to run Python and JavaScript out of the box, the powerful dual-core board comes with a similarly professional price tag; currently for preorder at $99 USD a pop, the Portenta is priced well outside of the company’s traditional DIY and educational markets. With increased competition from other low-cost microcontrollers, it seems that Arduino is looking to expand out of its comfort zone and find new revenue streams.

That’s a Lot of Pins

The Portenta H7 is obviously a far cry from the relatively dinky 8-bit Arduinos that we’ve all got filling up our parts drawers. Developed for high performance edge computing applications, the new board is powered by a 32-bit STM32H747XI that utilizes both an ARM Cortex M7 and an M4 running at 480 MHz and 240 MHz respectively. The two cores can work independently, allowing for example one core to run interpreted Python while the other runs code compiled in the Arduino IDE. When they need to work together, the cores can communicate with each other via a Remote Procedure Call (RPC) mechanism.

The new 80-pin connectors on the Portenta

Outwardly, the new board doesn’t look far removed from the modern Arduino form factor we’re used to. The USB connector has been upgraded to a Type-C, but the Portenta still retains the dual rows of pads ready for hand-soldered headers — that’s their more recent pinout that they call the Arduino MKR form factor.

If you look on the back of the board however, you’ll see that they’ve added two 80-pin high density connectors. According to the product page, these are intended to allow the Portenta to simply be plugged into a device as a removable module. The idea being that devices in the field can easily have their Portenta swapped out for an upgraded model. Some digging into the product page documentation section turns up a schematic that lists the connectors as Hirose DF40C-80DP-0.4V(51).

The base model Portenta features 8 MB SDRAM and 16 MB NOR flash, but it can be custom ordered with up to 64 MB of memory and 128 MB of flash should you need it. It’s also possible to delete various interfaces from the board when ordering, so if you don’t want network connectivity or the NXP SE050C2 crypto chip, they can simply be left off. However as of this writing it is unclear as to what minimum order quantity is necessary to unlock this level of customization, or or how much these modifications will change the unit cost.

Year of the Arduino Desktop?

The Portenta Carrier Board

The Portenta H7 is an impressive enough piece of hardware on its own, but when it’s plugged into the optional Carrier Board, things really start to get interesting. The Carrier Board provides full size connectors for all of the onboard peripherals, and according to documentation, turns the Portenta into an eNUC-class embedded computer. There’s even support for DisplayPort to connect a monitor, and miniPCI for expansion cards.

With a fully loaded Portenta H7 slotted into the Carrier Board, it would seem you have the makings of a low-power ARM “desktop” computer. Albeit one that wouldn’t outperform the Raspberry Pi Zero, and which costs several times more.

The Arduino press release and product page doesn’t make any mention of what kind of software or operating system said computer would run, so presumably that’s left as an exercise for the customer. While not particularly well suited to it, the ARM Cortex-M family of processors is capable of running the Linux kernel, so spinning up a “real” OS image for it should be possible. Of course with a maximum of just 64 MB of RAM, you’ll want to keep your performance expectations fairly low.

Where Does Portenta Fit?

We can’t even speculate what a maxed out Portenta would cost, and there’s no pricing or release date for the Carrier Board. But even at $99, the base model Portenta H7 would be a tough sell for hackers and makers who are used to buying dual-core ESP32 boards at 1/10 of the price, or the Teensy 4.0 which has a 600 MHz Cortex-M7 at 1/4 of the price. Which is fine, since this board isn’t intended for the traditional core Arduino audience.

Seeing the carrier board, we can’t help but notice some parallels here with the Raspberry Pi Compute Module. With connections broken out to a SODIMM header, the idea of the Computer Module was to help bridge the gap between the DIY community and the commercial one by offering up a Raspberry Pi in a more rugged form factor that would be easier to integrate into end-user products. But since it wasn’t any cheaper than the stock Pi, there wasn’t a whole lot of incentive to switch over. We haven’t seen consumer products advertising “Raspberry Pi Inside!” so it’s hard to tell if there has been any meaningful adoption from industry.

One has to wonder why any company that has the resources to integrate such an expensive board into their products wouldn’t just come up with their own custom design around the Portenta’s STM32H747XI chip, which even in single quantities, can currently be had for less than $15. The difference may end up coming down to the world-renowned community that surrounds the Arduino brand, and the company’s efforts to modernize their toolchain.

The Consumer Electronics Show in Las Vegas is traditionally where the big names in tech show off their upcoming products, and the 2020 show was no different. There were new smartphones, TVs, and home automation devices from all the usual suspects. Even a few electric vehicles snuck in there. But mixed in among flashy presentations from the electronics giants was a considerably more restrained announcement from a company near and dear to the readers of Hackaday: Arduino is going pro.

While Arduino has been focused on the DIY and educational market since their inception, the newly unveiled Portenta H7 is designed for professional users who want to rapidly develop robust hardware suitable for industrial applications. With built-in wireless hardware and the ability to run Python and JavaScript out of the box, the powerful dual-core board comes with a similarly professional price tag; currently for preorder at $99 USD a pop, the Portenta is priced well outside of the company’s traditional DIY and educational markets. With increased competition from other low-cost microcontrollers, it seems that Arduino is looking to expand out of its comfort zone and find new revenue streams.

That’s a Lot of Pins

The Portenta H7 is obviously a far cry from the relatively dinky 8-bit Arduinos that we’ve all got filling up our parts drawers. Developed for high performance edge computing applications, the new board is powered by a 32-bit STM32H747XI that utilizes both an ARM Cortex M7 and an M4 running at 480 MHz and 240 MHz respectively. The two cores can work independently, allowing for example one core to run interpreted Python while the other runs code compiled in the Arduino IDE. When they need to work together, the cores can communicate with each other via a Remote Procedure Call (RPC) mechanism.

The new 80-pin connectors on the Portenta

Outwardly, the new board doesn’t look far removed from the modern Arduino form factor we’re used to. The USB connector has been upgraded to a Type-C, but the Portenta still retains the dual rows of pads ready for hand-soldered headers — that’s their more recent pinout that they call the Arduino MKR form factor.

If you look on the back of the board however, you’ll see that they’ve added two 80-pin high density connectors. According to the product page, these are intended to allow the Portenta to simply be plugged into a device as a removable module. The idea being that devices in the field can easily have their Portenta swapped out for an upgraded model. Some digging into the product page documentation section turns up a schematic that lists the connectors as Hirose DF40C-80DP-0.4V(51).

The base model Portenta features 8 MB SDRAM and 16 MB NOR flash, but it can be custom ordered with up to 64 MB of memory and 128 MB of flash should you need it. It’s also possible to delete various interfaces from the board when ordering, so if you don’t want network connectivity or the NXP SE050C2 crypto chip, they can simply be left off. However as of this writing it is unclear as to what minimum order quantity is necessary to unlock this level of customization, or or how much these modifications will change the unit cost.

Year of the Arduino Desktop?

The Portenta Carrier Board

The Portenta H7 is an impressive enough piece of hardware on its own, but when it’s plugged into the optional Carrier Board, things really start to get interesting. The Carrier Board provides full size connectors for all of the onboard peripherals, and according to documentation, turns the Portenta into an eNUC-class embedded computer. There’s even support for DisplayPort to connect a monitor, and miniPCI for expansion cards.

With a fully loaded Portenta H7 slotted into the Carrier Board, it would seem you have the makings of a low-power ARM “desktop” computer. Albeit one that wouldn’t outperform the Raspberry Pi Zero, and which costs several times more.

The Arduino press release and product page doesn’t make any mention of what kind of software or operating system said computer would run, so presumably that’s left as an exercise for the customer. While not particularly well suited to it, the ARM Cortex-M family of processors is capable of running the Linux kernel, so spinning up a “real” OS image for it should be possible. Of course with a maximum of just 64 MB of RAM, you’ll want to keep your performance expectations fairly low.

Where Does Portenta Fit?

We can’t even speculate what a maxed out Portenta would cost, and there’s no pricing or release date for the Carrier Board. But even at $99, the base model Portenta H7 would be a tough sell for hackers and makers who are used to buying dual-core ESP32 boards at 1/10 of the price, or the Teensy 4.0 which has a 600 MHz Cortex-M7 at 1/4 of the price. Which is fine, since this board isn’t intended for the traditional core Arduino audience.

Seeing the carrier board, we can’t help but notice some parallels here with the Raspberry Pi Compute Module. With connections broken out to a SODIMM header, the idea of the Computer Module was to help bridge the gap between the DIY community and the commercial one by offering up a Raspberry Pi in a more rugged form factor that would be easier to integrate into end-user products. But since it wasn’t any cheaper than the stock Pi, there wasn’t a whole lot of incentive to switch over. We haven’t seen consumer products advertising “Raspberry Pi Inside!” so it’s hard to tell if there has been any meaningful adoption from industry.

One has to wonder why any company that has the resources to integrate such an expensive board into their products wouldn’t just come up with their own custom design around the Portenta’s STM32H747XI chip, which even in single quantities, can currently be had for less than $15. The difference may end up coming down to the world-renowned community that surrounds the Arduino brand, and the company’s efforts to modernize their toolchain.

As the name implies, the OSEP STEM board is an embedded project board primarily aimed at education. You use jumper wires to connect components and a visual block coding language to make it go.

I have fond memories of kits from companies like Radio Shack that had dozens of parts on a board, with spring terminals to connect them with jumper wires. Advertised with clickbait titles like “200 in 1”, you’d get a book showing how to wire the parts to make a radio, or an alarm, or a light blinker, or whatever.

The STEM Kit 1 is sort of a modern arduino-powered version of these kits. The board hosts a stand-alone Arduino UNO clone (included with the kit) and also has a host of things you might want to hook to it. Things like the speakers and stepper motors have drivers on board so you can easily drive them from the arduino. You get a bunch of jumper wires to make the connections, too. Most things that need to be connected to something permanently (like ground) are prewired on the PCB. The other connections use a single pin. You can see this arrangement with the three rotary pots which have a single pin next to the label (“POT1”, etc.).

I’m a sucker for a sale, so when I saw a local store had OSEPP’s STEM board for about $30, I had to pick one up. The suggested price for these boards is $150, but most of the time I see them listed for about $100. At the deeply discounted price I couldn’t resist checking it out.

So does an embedded many-in-one project kit like this one live up to that legacy? I spent some time with the board. Bottom line, if you can find a deal on the price I think it’s worth it. At full price, perhaps not. Join me after the break as I walk through what the OSEPP has to offer.

What’s Onboard?

There are plenty of input and output devices:

  • 7 Push Buttons
  • Potentiometers (3 rotary and 1 slide)
  • Passive Infrared Sensor (PIR)
  • Light Sensor
  • Sound Sensor
  • LM35 Temperature Sensor
  • 10 LEDs (various colors)
  • Servo Motor
  • Stepper Motor
  • DC Motor
  • LCD Display
  • Buzzer
  • Speaker
  • RGB LED

In addition, the kit comes with an ultrasonic distance sensor in a little bracket that can connect to the stepper motor. That’s the only part that needs power and ground that isn’t already wired up.

Because the heart of the board is an Arduino UNO clone, you can do anything you like to program it. However, OSEPP touts their visual block diagram language that is basically Scratch. You can use it for free on most platforms and there is even a Web-based version although it can’t download code. It looks like Scratch or other block-oriented systems you’ve seen before.

I’m not usually fond of the visual block languages, but this one at least shows you the actual Arduino code it generates, so that isn’t bad. But you can still use any other method you like such as the standard IDE or PlatformIO.

You can see a video about the board, below.

The Good and the Bad

The board feels substantial and able to withstand a good bit of abuse. There’s a good range of components, and I like that the arduino is a real daughter board and not just built onto the PCB. Despite using the block language, I do like the tutorial booklet. It is very slick and has projects ranging from an IR doorbell to a mini piano. You can see a page below — very colorful and clear.

Of course, the suggested retail price of $150 is a bit offputting. You might think a breadboard with a handful of LEDs and other parts would be a much lower-cost option but just look around for arduino kits for beginners and you’ll find prices are all over the place. On the other hand, with a parts kit you would have to know how to wire up things like stepper motors or DC motors, so there is some value to having it already done for you. There’s also value in not having a bag of parts to misplace.

The jumper wires in the kit have pins on one side and sockets on the other. The pins go into the Arduino’s connector and the sockets go over pins on the components. These aren’t quite as reliable as a spring clip and not as versatile either.

In my mind the worst part of the kit design is that the pins are right next to each of the components. That’s good for understanding, but it makes a mess of wiring. For instance, there are ten LEDs, and connecting them all means stretching jumper wires to both edges of the board The jumpers aren’t very long either, so any complex project is going to have wires crisscrossing the sensors and LCD.

Granted, in this image I could have removed some of the wires from the bundles but that wouldn’t help that much, either. If you need to hook up more than a few of the available components you will have a mess. I would have put some sort of spring clip or even screw terminals and put them all on the top and bottom of the board with clear color-coded marking about where they connect. Then the wiring would all be out of the way. There are probably a few other ways they could have gone, and at this price, they could afford the few extra inches on the PCB.

There are a few other things that would have been nice touches to finish off this kit. I would have enjoyed a short chapter in the booklet about using the Arduino IDE directly so that people know it exists. And having even a small breadboard attached for your own exploration would make sense, but would then call for a different type of jumper wire.

Short Example Using the Distance Sensor

I wanted to do something with the board so I decided to play with the distance sensor and the servo. The distance sensor is a bit annoying both because you have to wire it all up and it has a tendency to fall off when you transport the board.

The demo (you can find it online) won’t win any originality prizes. The program moves the servo to scan from 0 to 180 degrees in 5 degree increments. It measures the distance of what’s in front of it. When it completes a scan, if it saw something close (you could adjust the sensitivity), it moves the sensor back to that position and waits 30 seconds. Otherwise, it keeps scanning.

Really, this is no different from any other Arduino program. That’s kind of the point. Despite the emphasis in the book on the point-and-click language, this is really just an Arduino.

In Summary

For the deep sale price I found, the board will work well for its intended audience of students or anyone starting out with Arduino or microcontrollers. Even a more advanced audience who just wants a way to hammer out a quick prototype might find it worth the $30 or $40 you can sometimes pay. But at full price, it is hard to imagine this makes sense because of the mess of wire routing and limited expansion options.

If you want to integrate a nice graphical interface with a microcontroller or single-board computer for a useful piece of custom equipment, how will you go about it? MyOpenLab is a platform that makes it easy to design virtual interfaces your electronic builds. If you want controls and readouts for Arduino, Raspberry Pi, Android, or anything with a serial port, this is worth a try.

MyOpenLab reminds me of LabView. Not so much modern LabView with all of its add-ons and extras, but LabView back when it did just a few things but did them really well. The open source MyOpenLab project has been around for a while. The website and documentation are not in English, which may have kept some people from giving it a try, but the software itself is available in German, English, and Spanish. I took the plunge and found the language barrier didn’t cause me trouble.

As an example of what you can do, image you want to build a custom bench tool. You build virtual device (they call it a “VirtualMachine”) that uses your computer as the control panel and readout, and your electronic project as the physical interface. In myOpenLab your device will consist of two parts: a diagram and a front panel. Some things only live on the diagram, like a timer or a connection to an Arduino. But some things live on both like switches, LEDs, graphs, and so on. You can connect all the little boxes together to build up applications. They can stand alone, but the power comes in being able to connect to an Arduino or Raspberry Pi (or a few other options) for I/O.

A Quick Project

Before getting into the gritty detials, let’s look at a simple demo I cooked up to try things out. There are also plenty of substantial examples already in the VirtualMachines folder you can examine.

You can see the front panel here. The Jolly Wrencher is just a graphic added for decoration along the other items and labels that make the front panel look nice but don’t show up in the working diagram. The diagram is where you specify connections between your virtual front panel and actual hardware you want to control. You also have the power to add logic to existing hardware inputs.

The Firmata block (Firmata is a protocol for communicating with microcontroller boards) is used to represent the hardware interface of your project and has a few interesting properties. First, you really need your board hooked up and working before you put the block down as it reads things even before you run your virtual machine. You can set the serial port to use and the refresh interval for inputs (apparently in milliseconds).

Checking the Active box on the pin editor makes the pin show up on the Firmata component

I wired two buttons connecting an Arduino’s pins 7 and 8 to ground, each with a 10K pull-up resistor. This biases the pin values so that MyOpenLab can read a 1 on those input pins when the buttons idle and a 0 when the buttons are pressed. I use this to illustrate the cool logic abilities of MyOpenLab. On the right side of the firmata block I invert the buttons since they are active low and then feed the result to an RS flip flop. A virtual LED on the front panel shows the state of the flip flop.

To the left of the firmata block, I have a slow timer and a virtual switch. This goes through an OR gate and an inverter to drive pin 13 of my Arduino (the LED built into the board). The net effect is the LED will blink unless you turn the virtual switch on the MyOpenLab front panel on. It is MyOpenLab that times the blinking.

 

You can also right-click on a wire and set a testpoint. During operation, you can open a window from the Window menu and display the test points easily. You can also open a little oscilloscope display that will show you all your digital or analog signals.

Signal 1 is the “set” button, signal 2 is the “reset” button and signal 3 is the LED output.

Pretty simple and while this is a silly example, you can see from the components you could put together a pretty significant system. There are quite a few examples in the VirtualMachines folder if you want to look at some meatier examples.

Now lets get into the details of working with MyOpenLab.

Working with the User Interface

The user interface is not bad at all. On a high-DPI monitor I found it is a bit small and there wasn’t a clear way to zoom it (but I’ll tell you how I fixed that later). Things work about how you’d expect. You pick components of the horizontal palette above the workspace then click on the workspace to place them. Note the palette changes if you are on the diagram (circuit panel) or the front panel.

Once in a while, you’ll see something that didn’t get localized for the English version of the software (the contadores de tiempo folder has timers in it). I also ran into a few components that insisted on throwing Java errors pretty much nonstop related to painting. They seemed to work, they just threw some Java exception. I did work out some Java fixes under Linux which I’ll detail later on.

Drawing interconnecting lines was a bit difficult. You have to start from the source, click, and then move to the destination and click again. The green lines were hard to see on my monitor and there was no way I could see to change the colors. You can only connect one output to one input. If you right click on a wire, though, you can add a node which will allow you to make another connection to that node. You can also pick the splitter component from the extras folder.

If you click on an object, there some help text that shows up on the right (often missing) and a property inspector on the left. Some of these require a little detective work on your part. For example, in the timer component, the high-level property sets the time in output is high and low-level sets the time the output is low. Both times appear to be in milliseconds.

Back End

What was interesting to me was the number of backends available as I/O devices. You can talk to an Arduino using Firmata but several others are also available. You can talk to a Raspberry Pi, Modbus, Processing, several commercial I/O interfaces, and the RS232 port. I wished there was a backend for Sigrok or USBTMC.

Then again, this is open source, so I guess I should add it instead of complaining. The project is hosted on SourceForge. Don’t get confused by the code you’ll get using the download button there (that’s an old version). If you look on the “code” tab you’ll find the subversion details to check out the most recent code:

svn checkout https://svn.code.sf.net/p/myopenlab3/code/ myopenlab3-code

Work Arounds

Getting things to work was a little challenging. Many Java programs don’t pick up my big screen correctly — I probably need to update my JVM. After I got tired of squinting, I ran Xephyr and passed it a fake DPI:

Xephyr -dpi 100 :3 -screen 1800x1200 -dpi 100  ; DISPLAY=:3 twm ; DISPLAY=:3 ./start_
linux &

Xephyr is like Xnest. It creates a virtual X Windows display in a window on your desktop. That made the mouse cursor a little funny which didn’t help with the wiring, but it was workable. Sure would be nice if the interface could zoom in and out, but as far as I could tell it doesn’t.

However, I had an even bigger problem. The program depends on the RXTX library to talk to the serial port. At first, it could not find my installation. I knew it should work because the Arduino IDE uses the same library and that was fine.

-Djava.library.path="/usr/lib/jni/"

But that wasn’t the end of the problem. The Arduino enumerates as /dev/ttyACM0 or perhaps some other number depending on what else is connected. The program would find ports that show up as /dev/ttyUSB* and /dev/ttyS* but didn’t want to show any ports with ACM in them. In a Kobayashi Maru maneuver, I issued the following command:

ln -s /dev/ttyACM0 /dev/ttyUSB99

Then MyOpenLab found /dev/ttyUSB99 and I was in business. I don’t like to lose.

More Resources

There’s a lot more to explore with this tool. There are dozens of components ranging from simple gates to PID controllers. However, this should get you started. If you speak Spanish, you are set. If you don’t, don’t forget that your browser probably has a translate button or you can use an online translator — you may have to hunt to translate the whole manual (or borrow my copy). Of course, the translations leave something to be desired. There is a forum that has a good bit of English. There’s also a YouTube channel, that has some English and was updated recently.

One thing to note about the YouTube videos. At least some of them have some English subtitles. For example, check out the introduction video below and turn on closed captioning in the YouTube viewer. Unfortunately, the translation stops when you get to the good stuff, but you can still follow what’s happening pretty well.

 

Hackaday brought you a first look the Arduino MKR Vidor 4000 when it announced. Arduino sent over one of the first boards so now we finally have our hands on one! It’s early and the documentation is still a bit sparse, but we did get it up and running to take the board through some hello world exercises. This article will go over what we’ve been able to figure out about the FPGA system so far to help get you up and running with the new hardware.

Just to refresh your memory, here’s what is on the Vidor board:

  • 8 MB SRAM
  • A 2 MB QSPI Flash chip — 1 MB allocated for user applications
  • A Micro HDMI connector
  • An MIPI camera connector
  • Wi-Fi and BLE powered by a U-BLOX NINA W10 Series device
  • MKR interface on which all pins are driven both by SAMD21 (32-bit ARM CPU) and FPGA
  • Mini PCI Express connector with up to 25 user programmable pins
  • The FPGA (an Intel/Altera Cyclone 10CL016) contains 16K Logic Elements, 504 KB of embedded RAM, and 56 18×18 bit HW multipliers

Sounds good. You can get more gory technical details over at Arduino and there’s even a schematic (.zip).

Documentation

Documentation is — so far — very hard to come by but the team is working to change that by the day. Here are the resources we’ve used so far (in addition to the schematic):

In addition, Arduino just released an example FPGA project for Quartus. I’ll explain what that means in a bit.

Get Up and Running with the Arduino Desktop IDE

Despite the getting started guide, it doesn’t appear the libraries are usable from the cloud-based IDE, so we followed the instructions to load the beta board support for the MKR 4000 into our desktop IDE. Be aware that the instructions show the “normal” SAMD board package, but you actually want the beta which says it is for the MKR 4000. If you search for SAMD in the Boards Manager dialog, you’ll find it (see the second entry in the image below).

 

The libraries we grabbed as ZIP files from GitHub and used the install library from ZIP file option with no problems.

What’s the Code Look Like?

The most interesting part of this board is of course the inclusion of the FPGA which left us wondering what the code for the device would look like. Browsing the code, we were a bit dismayed at the lack of comments in all but the JTAG code. We decided to focus first on the VidorPeripherals repository and dug into the header file for some clues on how everything works.

Looking at VidorPeripherals.h, you can see that there’s a few interesting I/O devices include SPI, I2C, UART, reading a quadrature encoder, and NeoPixel. There’s also a few headers that don’t exist (and presumably won’t get the define to turn them on) so don’t get too excited by some of the header file names until you make sure they are really there.

Then we decided to try the example test code. The library provides a global FPGA object that you need to set up:

// Let's start by initializing the FPGA
if (!FPGA.begin()) {
    Serial.println("Initialization failed!");
    while (1) {}
}

// Let's discover which version we are running
int version = FPGA.version();
Serial.print("Vidor bitstream version: ");
Serial.println(version, HEX);

// Let's also ask which IPs are included in this bitstream
FPGA.printConfig();

The output of this bit of code looks like this:

Vidor bitstream version: 1020107
number of devices 9
1 01000000 MB_DEV_SF
1 02000000 MB_DEV_GPIO
4 04000000 MB_DEV_I2C
6 05000000 MB_DEV_SPI
8 06000000 MB_DEV_UART
1 08000000 MB_DEV_SDRAM
4 09000000 MB_DEV_NP
11 0A000000 MB_DEV_ENC
0 0B000000 MB_DEV_REG

In many cases, the devices provided by the FPGA are pretty transparent. For example, here’s another snip from the example code:

// Ok, so we know now that the FPGA contains the extended GPIO IP
// The GPIO pins controlled by the FPGA start from 100
// Please refer to the online documentation for the actual pin assignment
// Let's configure pin A0 to be an output, controlled by the FPGA
FPGA.pinMode(33, OUTPUT);
FPGA.digitalWrite(33, HIGH);

// The same pin can be read by the SAMD processor :)
pinMode(A0, INPUT);
Serial.print("Pin A0 is ");
Serial.println(digitalRead(A0) == LOW ? "LOW" : "HIGH");

FPGA.digitalWrite(33, LOW);
Serial.print("Pin A0 is ");
Serial.println(digitalRead(A0) == LOW ? "LOW" : "HIGH");

That’s easy enough and it is nice that the pins are usable from the CPU and FPGA. We couldn’t find the documentation mapping the pins, but we assume it is coming.

Using, say, an extra serial interface is easy, too:

SerialFPGA1.begin(115200);
while (!SerialFPGA1);
SerialFPGA1.println("test");

Bitstream

So where’s the FPGA code? As far as you can tell, this is just a new Arduino with a lot of extra devices that connect through this mysterious FPGA object. The trick is that the FPGA code is in the library. To see how it works, let’s talk a little about how an FPGA operates.

When you write a program in C, that’s not really what the computer looks at, right? The compiler converts it into a bunch of numbers that tell the CPU to do things. An FPGA is both the same and different from that. You write your program — usually in a hardware design language like Verilog or VHDL. You compile it to numbers, but those numbers don’t get executed like a CPU does.

The best analogy I’ve been able to think of is that an FPGA is like one of those old Radio Shack 100-in-1 electronic kits. There are a bunch of parts on a board and some way to connect them with wires. Put the wires one way and you have a radio. Put them another way and you have a burglar alarm. Rewire it again and you have a metal detector. The numbers correspond to wires. They make connections and configure options in the FPGA’s circuitry. Unless you’ve built a CPU, there’s nothing in there examining and acting on the numbers like there would be with a CPU.

The numbers that come out of an FPGA tool is usually called a bitstream. Someone has to send that bitstream to an FPGA like the Cyclone onboard the Arduino every time it powers up. That someone is usually a memory device on the board, although the CPU can do it, too.

So that leads to two questions: Where is the bitstream? How does it get to the FPGA?

The answer to the first question is easy. If you look on Github, you’ll see in the library there is a file called VidorBase.cpp. It has the following lines:

__attribute__ ((used, section(".fpga_bitstream")))
const unsigned char bitstream[] = {
    #include "app.ttf"
};

What this means if there is an array called bitstream that the linker will put it in a specially marked section of memory. That array gets initialized with app.ttf which is just an ASCII file full of numbers. Despite the name, it is not a TrueType font. What do the numbers mean? Hard to say, although, in theory, you could reverse engineer it just like you can disassemble binary code for a CPU. However, it is the configuration required to make all the library calls we just talked about work.

The second question about how it gets to the FPGA configuration is a bit of a mystery. As far as we can tell, the bootloader understands that data in that section should get copied over to the FPGA configuration memory and does the copying for you. It isn’t clear if there’s a copy in the main flash and a copy in the configuration flash but it seems to work transparently in any event.

There’s a checksum defined in the code but we changed it and everything still worked. Presumably, at some point, the IDE or the bootloader will complain if you have the wrong checksum, but that doesn’t appear to be the case now.

By the way, according to the Arduino forum, there are actually two bitstreams. One that loads on power-up that you would rarely (if ever) change. Then there is another that is the one included with the library. You can double-click the reset button to enter bootloader mode and we suspect that leaves the FPGA initialized with the first bitstream, but we don’t know that for sure. In bootloader mode, though, the red LED onboard has a breathing effect so you can tell the double click works.

What about my FPGA Code?

This isn’t great news if you were hoping for an easy Arduino-like way to do your own FPGA development in Verilog or VHDL. Intel will give you a copy of Quartus Prime which will generate bitstreams all day for you. We think — but we aren’t sure — that the ASCII format is just a raw conversion from binary of the bitstream files.

Very recently, Arduino provided a Quartus project that would create a bitstream. This provides a few key pieces of the puzzle, like the constraint file that lets the FPGA compiler find the different parts on the board.

However, even with that project, you still have some reverse engineering to do if you want to get started. Why? Here’s what Arduino says about loading your own FPGA code (we added the emphasis):

Quartus will produce a set of files under the output_files directory in the project folder. In order to incorporate the FPGA in the Arduino code you need to create a library and preprocess the ttf file generated by Quartus so that it contains the appropriate headers required by the software infrastructure. Details of this process will be disclosed as soon as the flow is stable.

Programming the FPGA is possible in various ways:

  • Flashing the image along with Arduino code creating a library which incorporates the ttf file
  • Programming the image in RAM through USB Blaster (this requires mounting the FPGA JTAG header). this can be done safely only when SAM D21 is in bootloader mode as in other conditions it may access JTAG and cause a contention
  • Programming the image in RAM through the emulated USB Blaster via SAM D21 (this component is pending release)

In addition, the repository itself says that some key pieces are missing until they can work out licensing or clean up the code. So this gets us closer, but you’d still need to reverse engineer the header from the examples and/or figure out how to force the processor off the JTAG bus. The good news is it sounds like this information is coming, it just isn’t here yet.

Of course, you are going to need to understand a lot more to do anything significant. We know the FPGA is set in the AS configuration mode. We also asked Arduino about the clock architecture of the board and they told us:

[The CPU] has its own clock which is used to generate a 48 MHz reference clock that is fed to the FPGA (and that can be removed at any time to “freeze” fpga). In addition to this reference clock, [the] FPGA has an internal RC oscillator which can’t be used as [a] precise timing reference for tolerance issues but can be used in case you don’t want [the CPU] to produce the reference clock.

Of course, the FPGA has a number of PLLs onboard that can take any valid clock and produce other frequencies. For example, in the vision application, Arduino demonstrated, the 48 MHz clock is converted into 24 MHz, 60 MHz, 100 MHz, and 120 MHz clocks by PLLs.

Mix and Match?

One thing that is disappointing is that — at least for now — you won’t be able to mix and match different FPGA libraries. There is exactly one bitstream and you can’t just jam them together.  Although FPGAs can often be partially configured, that’s a difficult technique. But we were a little surprised that the IDE didn’t understand how to take libraries with, for example, EDIF design files for IP that would all get compiled together. That way I could pick the Arduino UART and mix it with the Hackaday PWM output module along with my own Verilog or VHDL.

The way things are structured now you will have one bitstream that is precompiled by another tool (probably Quartus for the foreseeable future). It will match up with a particular C++ library. And that’s it. Doesn’t matter how much of the FPGA is left over or how much of it you really use, you will use it all for the one library.

Of course, you can load another library but it is going to replace the first one. So you only get one set of functions at a time and someone else gets to decide what’s in that set. If you roll your own, you are going to have to roll your own all the way.

What’s Next?

It is still early for the Arduino Vidor. We are hopeful we’ll get the tools and procedures necessary to drop our own FPGA configurations in. It would be great, too, if the stock libraries were available in source format including the Verilog HDL. The recent GitHub release shows quite a bit, although it isn’t all of the examples, it is probably enough if we get the rest of the information.

As for a more intuitive interface, we don’t know if that’s in the cards or not. We don’t see much evidence of it, although posts on the Arduino forum indicate they will eventually supply an “IP Assembler” that will let you compose different modules into one bitstream. We don’t know if that will only work with “official” modules or not. However, we know the Arduino community is very resourceful so if we don’t get a good ecosystem it will not surprise us if someone else makes it happen. Eventually.

For now, we will continue to play with the existing bitstreams that become available. There are some neat new features on the CPU, too. For example, you can map two of the unused serial modules.  There’s a hardware-based cooperative multitasking capability. As more details on the FPGA emerge, we’ll keep you posted and if you learn something, be sure to leave word in the comments so everyone can benefit.

What do you do, when you need a random number in your programming? The chances are that you reach for your environment’s function to do the job, usually something like rand() or similar. This returns the required number, and you go happily on your way.

A shift register configured as a pseudo-random number generator.
A shift register configured as a pseudo-random
number generator. [by KCAuXy4p CC0 1.0]
Except of course the reality isn’t quite that simple, and as many of you will know it all comes down to the level of randomness that you require. The simplest way to generate a random number in software is through a pseudo-random number generator, or PRNG. If you prefer to think in hardware terms, the most elementary PRNG is a shift register with a feedback loop from two of its cells through an XOR gate. While it provides a steady stream of bits it suffers from the fatal flaw that the stream is an endlessly repeating sequence rather than truly random. A PRNG is random enough to provide a level of chance in a computer game, but that predictability would make it entirely unsuitable to be used in cryptographic security for a financial transaction.

There is a handy way to deal with the PRNG predictability problem, and it lies in ensuring that its random number generation starts at a random point. Imagine the  shift register in the previous paragraph being initialised with a random number rather than a string of zeros. This random point is referred to as the seed, and if a PRNG algorithm can be started with a seed derived from a truly unpredictable source, then its output becomes no longer predictable.

Selecting Unpredictable Seeds

Computer systems that use a PRNG will therefore often have some form of seed() function alongside their rand() function. Sometimes this will take a number as an argument allowing the user to provide their own random number, at other times they will take a random number from some source of their own. The Sinclair 8-bit home computers for example took their seed from a count of the number of TV frames since switch-on.

The not-very-random result of a thousand analogRead() calls.
The not-very-random result of a thousand analogRead() calls.

The Arduino Uno has a random() function that returns a random number from a PRNG, and as you might expect it also has a randomSeed() function to ensure that the PRNG is seeded with something that will underpin its randomness. All well and good, you might think, but sadly the Atmel processor on which it depends has no hardware entropy source from which to derive that seed. The user is left to search for a random number of their own, and sadly as we were alerted by a Twitter conversation between @scanlime and @cybergibbons, this is the point at which matters start to go awry. The documentation for randomSeed() suggests reading the random noise on an unused pin via analogRead(), and using that figure does not return anything like the required level of entropy. A very quick test using the Arduino Graph example yields a stream of readings from a pin, and aggregating several thousand of them into a spreadsheet shows an extremely narrow distribution. Clearly a better source is called for.

Noisy Hardware or a Jittery Clock

As a slightly old-school electronic engineer, my thoughts turn straight to a piece of hardware. Source a nice and noisy germanium diode, give it a couple of op-amps to amplify and filter the noise before feeding it to that Arduino pin. Maybe you were thinking about radioactive decay and Geiger counters at that point, or even bouncing balls. Unfortunately though, even if they scratch the urge to make an interesting piece of engineering, these pieces of hardware run the risk of becoming overcomplex and perhaps a bit messy.

The significantly more random result of a thousand Arduino Entropy Library calls.
The significantly more random result of a thousand Arduino Entropy Library calls.

The best of the suggestions in the Twitter thread brings us to the Arduino Entropy Library, which uses jitter in the microcontroller clock to generate truly random numbers that can be used as seeds. Lifting code from the library’s random number example gave us a continuous stream of numbers, and taking a thousand of them for the same spreadsheet treatment shows a much more even distribution. The library performs as it should, though it should be noted that it’s not a particularly fast way to generate a random number.

So should you ever need a truly random number in your Arduino sketch rather than one that appears random enough for some purposes, you now know that you can safely disregard the documentation for a random seed and use the entropy library instead. Of course this comes at the expense of adding an extra library to the overhead of your sketch, but if space is at a premium you still have the option of some form of hardware noise generator. Meanwhile perhaps it is time for the Arduino folks to re-appraise their documentation.

The subject of entropy and generating random numbers is one that has appeared on these pages many times. [Voja Antonic] made a in-depth study using uninitialized RAM as an entropy source for microcontrollers. If you have an insatiable appetite for understanding Linux entropy, we point you at [Elliot Williams]’ comprehensive examination of the subject.

[Arduino image: DustyDingo Public domain]


Filed under: Arduino Hacks, Hackaday Columns, Microcontrollers, Skills

In the mid-1970s, if you had your own computer, you probably built it. If you had a lot of money and considerable building skill, you could make an Altair 8800 for about $395 — better than the $650 to have it built. However, cheaper alternatives were not far behind.

In 1976, Popular Electronics published plans for a computer called the COSMAC Elf which you could build for under $100, and much less if you had a good junk box. The design was simple enough that you could build it on a piece of perf board or using wire wrap. We featured the online archive of the entire Popular Electronics collection, but hit up page 33 of this PDF if you want to jump right to the article that started it all. The COSMAC Elf is a great little machine built around a 40-pin RCA 1802 processor, and for many was the first computer they owned. I lost my original 1802 computer in a storm and my recent rebuild in another completely different kind of storm. But there is a way to reclaim those glory days without starting from scratch.  I’m going to repurpose another retro-computing recreation; the KIM-1.

I’ll admit it, Rewiring a real KIM-1 to take an 1802 CPU would be difficult and unnecessary and that’s not what this article is about. However, I did have a KIM UNO — [Oscar’s] respin of the classic computer using an Arduino mini pro. Looking at the keyboard, it occurred to me that the Arduino could just as easily simulate an 1802 as it could a 6502. Heck, that’s only two digits different, right?

The result is pretty pleasing. A “real” Elf had 8 toggle switches, but there were several variations that did have keypads, so it isn’t that far off. Most Elf computers had 256 bytes of memory (without an upgrade) but the 1802 UNO (as I’m calling it) has 1K. There’s also a host of other features, including a ROM and a monitor for loading and debugging programs that doesn’t require any space in the emulated 1802.

Repurpose

The KIM UNO has 24 switches. There are 16 for the hex digits, of course. The top two rows mimic functions from the original KIM-1. A real Elf had a way to input a byte (usually 8 toggle switches), a load switch, a run switch, a memory protect switch, and a push button wired to a CPU pin. That means the hardware has more than enough switches.

On the display side, a normal Elf had a single-byte hex display although some clones had more. There was also the Q LED that a program could light or extinguish. The KIM UNO hardware has many 7-segment displays so it is possible to put those digits to use like an Elf clone. There isn’t an LED, however, except for the Arduino’s built in LED which is not normally visible in operation. However, the digital displays have decimal points and they are connected to the Arduino. So if you don’t mind using those, you have plenty of LEDs, too.

The hardware is open source and easy to duplicate. [Oscar] sometimes has kits as well and they are very inexpensive (about $20).

The KIM UNO software is open source, so I started there. I first stripped all the code out of the main file other than the parts that drove the display and the keyboard, then built up everything need to suppot 1802 emulation. You can find all the code in my 1802UNO GitHub repository.

Inside the 1802

The 1802 instruction set is very regular and quite simple. Most instructions use the top 4 bits as an op code and the bottom 4 bits to select one of sixteen 16-bit registers. So 0x12 increments register 2 and 0x15 increments register 5. There are only a handful of op codes that don’t follow this pattern. There’s also an 8-bit accumulator called “D” (not to be confused with register D).

One unique feature in the 1802 architecture is the program counter. There isn’t one. Well, more precisely, there are up to 16. Any of the registers can be the program counter and a subroutine call can be as simple as switching the program counter. Unfortunately, that isn’t very reentrant (or good for recursion). If you want a proper subroutine call, you had to code it yourself. RCA provided the “standard call and return technique” that had the unfortunate downside of destroying the accumulator.

With so few instructions, the emulator turns out to be a few switch statements and some pretty simple code. Although it is made to run with the KIM UNO hardware, like the KIM UNO, you should be able to use it with just about any Arduino via the serial port. It isn’t quite as fun as having the real hardware, but it is simpler.

Unreal

The emulator is reasonably accurate except it doesn’t simulate interrupts (since there is no source of them). However, it doesn’t faithfully reproduce the 1802’s load mode which used DMA. Instead, load mode is just completely custom code that enters data into memory. It does not simulate the cycle and register manipulations that go on in a real 1802 using DMA in load mode.

In addition to loading a program with the ersatz load mode, you can also move RAM back and forth to EEPROM or a PC via the serial port.

Serial and Push Buttons

The serial port is just the usual Arduino serial port set for 9600 baud. By default, the serial input will mimic the hardware keys. However, you can use the pipe character (‘|’) to shift the serial port into terminal mode. Then the 1802 code can read data from the serial port. You lose the front panel functions and there’s no way to go back until you cycle the power unless you make the 1802 code release the port.

A few of the push buttons have special functions if you hold them down for more than one second. For example, the AD button writes the EEPROM data into RAM. This is useful for storing a self-contained demo, for example.

You can find a summary of the keyboard and serial commands on the GitHub site. The serial port can do things you can’t do from the front panel, like set a trace mode, dump the CPU registers, and more.

Building

The hardware doesn’t require any changes to the stock KIM UNO kit. There’s a lot to solder and once you solder the displays on, it would be hard to get the Arduino back off the board.

You could probably build the software using the Arduino IDE, but I used Platform IO. That lets me use the editor of my choice, but you ought to be able to get the code to work in the IDE, as well. There is enough memory to make the RAM slightly bigger, but I didn’t do it. Since one way to save and load the RAM is to EEPROM, I didn’t want the RAM to be larger than the EEPROM. In addition, the RAM “maps” like a real Elf (that is, RAM at location 0x0 also appears at 0x4000, 0x8000, etc). This would be more difficult if you added a little bit more than 1K of RAM.

There are a few other options at the top of 1802config.h. You can select how often the screen and keyboard refresh. Higher values are slower to refresh but faster to execute code. You can change the I/O ports associated with the keyboard, displays, and serial port. You can also change the serial escape character.

Examples

There are some examples provided that blink the LEDs and manipulate the serial port. If you look around, there’s a lot of 1802 code on the web. However, be aware that most 1802s don’t have a hardware UART. They emulate serial ports using the Q output and one of the EF inputs. That’s fine for a real device even though it takes lots of code, but for this virtual device, it isn’t practical. You’ll need to rip out any code that does serial I/O and replace it with single I/O instructions.

If you have a binary file (or a format you can convert to binary) I have a converter written in C included on GitHub. You can compile it on nearly any platform and use it to convert. It always assumes address. If that’s not right, you can always open the output in a text editor and adjust.

In addition, there are three ROMs included that you can try. By default, there is a simple high-low game. There are also two monitors, one for use with the built-in keyboard and another for use with a serial port. To select a ROM, edit 1802rom.h and change the comments so the ROM you want is not commented and the others are.

Practical?

Emulators are fun, but as the song goes, there’s nothing like the real thing. If that’s not authentic enough for you, it is possible to build a very authentic looking Elf, even today. The reason real 1802s are still around is they had several desirable characteristics, namely low power consumption and resistance to radiation.

The Arduino simulation has neither of those features. However, it is a fun retrocomputing toy, inexpensive, and a great learning tool. The CPU is simple enough to program directly in machine code and the portability is better than most other old school computers.

If you want to learn more about the 1802 there are several sites dedicated to it and a very helpful Yahoo group. One site has a very prolific software author, but most of the code won’t fit in the 1802 UNO’s 1K RAM. Maybe a version with more memory is in the future.


Filed under: Arduino Hacks, classic hacks, computer hacks, Hackaday Columns

Join us this Friday at noon PDT for a Hack Chat with Tenaya Hurst of Arduino. If you’ve been one of the big Maker Faires over the last few years (or innumerable other live events) and stopped by the Arduino area you’ve probably met Tenaya. She is the Education Accounts Manager for Arduino and loves working with wearable electronics.

Come and discuss maker education and the role Arduino is playing in getting our students excited about electronics, and STEAM education in general. Tenaya will also be discussing a new wearable tech kit she’s been working on. We hope to see the gear in person at Bay Area Maker Faire next week.

Here’s How To Take Part:

join-hack-chatOur Hack Chats are live community events on the Hackaday.io Hack Chat group messaging.

Log into Hackaday.io, visit that page, and look for the ‘Join this Project’ Button. Once you’re part of the project, the button will change to ‘Team Messaging’, which takes you directly to the Hack Chat.

You don’t have to wait until Friday; join whenever you want and you can see what the community is talking about.


Filed under: Arduino Hacks, Hackaday Columns, wearable hacks

I am a crappy software coder when it comes down to it. I didn’t pay attention when everything went object oriented and my roots were always assembly language and Real Time Operating Systems (RTOS) anyways.

So it only natural that I would reach for a true In-Circuit-Emulator (ICE) to finish of my little OBDII bus to speed pulse generator widget. ICE is a hardware device used to debug embedded systems. It communicates with the microcontroller on your board, allowing you to view what is going on by pausing execution and inspecting or changing values in the hardware registers. If you want to be great at embedded development you need to be great at using in-circuit emulation.

Not only do I get to watch my mistakes in near real time, I get to make a video about it also.

Getting Data Out of a Vehicle

I’ve been working on a small board which will plug into my car and give direct access to speed reported on the Controller Area Network (CAN bus).

To back up a bit, my last video post was about my inane desire to make a small assembly that could plug into the OBDII port on my truck and create a series of pulses representing the speed of the vehicle for my GPS to function much more accurately. While there was a wire buried deep in the multiple bundles of wires connected to the vehicle’s Engine Control Module, I have decided for numerous reasons to create my own signal source.

At the heart of my project is the need to convert the OBDII port and the underlying CAN protocol to a simple variable representing the speed, and to then covert that value to a pulse stream where the frequency varied based on speed. The OBDII/CAN Protocol is handled by the STN1110 chip and converted to ASCII, and I am using an ATmega328 like found on a multitude of Arduino’ish boards for the ASCII to pulse conversion. I’m using hardware interrupts to control the signal output for rock-solid, jitter-free timing.

Walk through the process of using an In-Circuit Emulator in the video below, and join me after the break for a few more details on the process.

The Hardware

I revised the board since the last video and removed the support for the various protocols other than CAN, which is the non-obsolete protocol of the bunch. By removing a bunch of parts I was able to change the package style to through-hole which is easier for many home hobbyists, so you can leave the solder-paste in the ‘fridge.

The “Other Connector” on your Arduino

Unlike the Arduino which is ready to talk to your USB port when you take it out of the box, the ATmega chips arrive without any knowledge of how to go and download code, in other words it doesn’t have a boot loader. Consequently I have the In-Circuit-Serial-Programming (ICSP) pins routed to a pin header on my board so that I can program the part directly.

On this connector you’ll find the Reset line, which means with this header I can use a true ICE utilizing the debugWIRE protocol. Since the vast majority of designs that use an AVR chip do not repurpose the reset pin for GPIO, it is a perfect pin to use for ICE. All of the communications during the debug process will take place on the reset pin.

Enter the ICE

When designing a computer from scratch there is always the stage where nothing yet works. Simply put, a microprocessor circuit cannot work until almost every part of the design works; RAM, ROM, and the underlying buses all need to (mostly) work before simple things can be done. As a hardware engineer by trade I would always reach for an ICE to kick off the implementation; only after the Beta release would the ICE start to gather dust in the corner.

In the case of the ATmega, the debugging capabilities are built into the microcontroller itself. This is a much more straightforward implementation than the early days when we had to have a second isolated processor running off-board with its own local RAM/ROM.

One note mentioned in the video is that a standard Arduino’ish board needs to have the filter capacitors removed from the RESET line to allow the high speed data on the line for its debugWIRE usage.

The ICE I am using here is the one made by Atmel, and is compatible with Atmel Studio, there are also other models available such as the AVR Dragon.

ICEyness

The ICE allows us to download and single step our code while being able to observe and overwrite RAM and I/O Registers from the keyboard. We are able to watch the program step by step or look underneath at the actual assembly code generated by the compiler. We can watch variables and locations directly in RAM or watch the C language counterparts. It’s also possible to jump over a sub-routine call in the instance of just wanting to see the result without all of the processing.

It’s worth your time to see even a glimpse of the capabilities of an ICE in action. I recommend that you watch the video where the debugging begin.

Final Words

This video was really about finishing the OBDII circuit so I didn’t really have the time to go over everything an ICE can do, maybe I will do a post dedicated to just the ICE and development environment next time.


Filed under: Arduino Hacks, Hackaday Columns, Microcontrollers, Skills

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.


Filed under: Arduino Hacks, ARM, Hackaday Columns, reviews, Skills


  • Newsletter

    Sign up for the PlanetArduino Newsletter, which delivers the most popular articles via e-mail to your inbox every week. Just fill in the information below and submit.

  • Like Us on Facebook