Monday, May 28, 2018

Of FPGAs and Arduino: The MKR Vidor 4000 Leads Me to Big Questions

There will be a point-form 'tl;dr' summary at the bottom.

Arduino & Gumstix

I recently invested a substantial amount of time working on board support for Arduino-compatible devices. Geppetto now has several microcontrollers that can be found on Arduino-compatible boards, and I extended Geppetto's AutoBSP service to include ArduinoIDE integration. Once you've got a board design and click on the BSP button, you not only get the hardware abstraction layer (HAL) source files, but a link you can add to your IDE that adds your design's BSP to the Boards Manager under "Contributed."

Quite clever if you ask me.

It's time to point out that Geppetto is an electronic hardware design-to-order tool. In one end goes your modular, drag-and-dropped device design and an engineering fee, and your fabricated, tested, ready to rock development board comes out the other. the engineering fee makes Geppetto unideal for one-of maker boards, but for prototypes, proof of concept, and low volume boards, it's a short road to production.

Exciting Arduino News

The Arduino community just announced some new development boards. One of these boards includes a field-programmable gate array (FPGA), which gets my blood pumping.

I worked a lot with FPGAs when I was in university and my Master's thesis involved the development of an interactive logic design training tool. It was in the form of an embedded system incorporating an Altera (Intel) Cyclone V SoC, and targeted pre-university to undergraduate students, helping them learn hardware description languages, such as VHDL and verilog, as well as software languages, like C and Java.

Hardware description languages (HDLs) are used to define the behaviour of the look-up tables and registers to form digital design based on logic gates (AND, OR, eXclusiveOR, NOT, etc…), memory blocks and digital signal processors that make up FPGAs.

Working with FPGAs is an oddly rewarding experience. At first blush writing hardware description language seems insurmountable. But once you've written your first half-adder and seen those 7-segment LEDs spit out the correct answer, you're hooked. Or at least I was.

The potential for FPGAs in the modern computing era is widespread. From fine-grained parallelism to high speed signal processing to software-defined radios. My favorite area of development is adding ASIPs (Application Specific Instruction Processors) to existing SoC architectures.

I wanted to share that feeling with others and worked hard to find ways of presenting the learning material in an interactive, progressive and causal learning environment. An Arduino FPGA board might be a step in that direction. But it depends on how it’s presented and, most importantly, how it’s used.

So what do these FPGAs really have to offer the Arduinosphere?

"Getting Started..."

The announcement of the Arduino MKR Vidor 4000 has been met with much fanfare, including my own, but to validate the board's existence, we have to start by going back to the original purpose of Arduino.

Bare wire programming is hard. Real-time operating system RTOS programming is hard. Let's face it: starting out with MCUs is not easy. Back when Arduino started releasing hardware, it was to put these incredibly useful and traditionally complicated marvels in the hands of artists and enthusiasts who would otherwise not have the technological know-how or courage to attempt embedded software development.

The endless jungle of examples, snippets, libraries and forums serve up a steady stream of cut-and-pasteable functions into an IDE designed for simplicity. It is plausible that a user could go a long time without even adding a semicolon and still be able to produce the results they’re looking for.

So the service that Arduino provides access to programming Hardware without actually having to know how to program instead of coaching these creative individuals in the fundamentals of developing embedded systems. It's easy to stop there, using the simplified programming environment, embedded example applications, one-button compilation and uploading, and large and supportive community to design and maintain interactive art, fun robots, and endless maker projects, without digging into embedded software development. These creative individuals have a gateway into field which normally requires a skill set and knowledge base that is completely alien to them.

Asking an artist or a carpenter to learn the core skills involved in writing bare-wire microcontroller code, or even RTOS procedures, is much like asking a first-time skydiver, long-time airline passenger, to jump out of a plane. Fear and anxiety are not uncommon reactions. “I’m perfectly comfortable being in the air as long as there’s a cabin around me and wings on either side,” they say. Because the Arduino community fosters this copy-and-paste “non-programming” environment, you find a lot of passengers in its midst.

It’s a trade-off. You get more people doing amazing things with MCUs but don’t explain what it is they’re really doing.

Industry and Arduino

Part of my responsibility as gadget guru at Gumstix is to keep an eye on what people do with embedded devices, IoT, development boards, and technology. I also consider myself a bit of a developer advocate, despite my extended periods of silence. This is partly to do with my involvement in backend Geppetto development and a few marketing responsibilities. I've got my hands full, to say the least. Regardless, I've noticed that Arduino is popping up in some strange places in industry.

So what role does Arduino play in industrial applications? Let's start with your bill of materials. The popularity of a given part will drive its availability. The more ATMEGAs get purchased, the more of them Microchip will make. That means adding a chip found on a popular Arduino board to your BOM means it probably won't cause many problems in your supply chain.

Now that you've got a well-documented MCU on your board, you need to start developing your application. You start collecting TRMs and white papers and quickly realize that you've done an awful lot of reading and very little programming. So why not make things easy and write some proof-of-concept code in Arduino, show the boss that the board works and press on.

Most professional embedded software developers and engineers will agree that Arduino should not be running on any product. At some point, the prototype's firmware should be rewritten in code that can be properly validated, tested and verified. Static analysis tools, unit tests, stress tests, and hardware-level debugging, among others, should be used before any embedded system leaves the lab to go to production and distribution.

To me this is an acceptable workflow. Use an Arduino sketch for proof of concept, then take the time to develop in a less abstracted language that can undergo formal verification and quality assurance. As long as end-user products arrive with stable, verified and secure code, the initial development cycle is trivial.

So the purpose of Arduino software and hardware in industry is as a breadboard to get your initial design rolling fast, to be abandoned early in the development cycle.


As I alluded to earlier, Arduino acts as an abstraction layer between the user and the hardware's abstraction layer (WARNING, this is an abstraction of an abstraction: BAD NEWS). It simplifies the depth of interaction required to get some thing to do something. It obfuscates the complexity of the system, shrouding it in simplified libraries, well-commented 20-line examples, and hidden build processes. It encourages "printf debugging" and trial-by-fire programming, which is fine. At first.

At some point, Arduino will become more hindrance than help. It's horrible at power consumption optimization, is wasteful with memory, and has little to no consideration for security or stability. Those looking to carry on will need to invest the time to understand the minutiae of MCU firmware, RTOS platforms and engineering problem solving strategies.

Here we meet that intimidation barrier. Some might say "Hey, I can do what I want to do without learning C or assembly code, reviewing reference manuals, or penetrating the hardware abstraction layer. I'll just stay here, where I'm comfortable and hope for the best." This is the airline passenger strapped in tight, gripping his bag of peanuts and complimentary orange juice.

And now on to the main event:

Arduino and FPGAs

The Vidor looks fantastic, and I hope to get my hands on one soon. But what is it really, in the end?
  • It's a SAMD21 microcontroller board following the MKR board design
  • It includes a U-BLOX WiFi/BLE module
  • It has some pretty advanced features
    • MIPI camera interface: Looks like it's for a Raspberry Pi camera
    • HDMI connector
    • PCIe edge connector
  • and last but not least, an Altera Cyclone 10 FPGA (YAY!)
There's more, but those are the highlights.

I love it! I want one!

Here's what I know about working with Altera Cyclone FPGAs. The bitstream and toolchain are closed-source. You have to use Altera's Quartus II IDE or CLI to properly flash it. It has many application-specific custom logic elements, as do Xilinx's chips, so even program modules are rarely portable between manufacturers. Also, if you thought MCU development was hard, wait till you try FPGAs!

So how is Arduino presenting this new hardware to its primarily "beginner-to-amateur" audience? Apparently, not as an FPGA. You use pre-compiled IP (Intellectual Property) blocks from within the “Arduino Create” online IDE, which are then incorporated into your compiled sketch and flashed to the FPGA by the SAMD21 MCU. It Compliments what you could currently do with an Arduino board by providing ready-to-use functionalities from the FPGA. For example, HDMI video output. You could display a sequence of images rendered by your Arduino sketch on a TV screen or projector to showcase your creation, which would be awesome. So Arduino is adding an FPGA to boost the capabilities of the main chip on the board, without providing any understanding of its capabilities or even its purpose. The FPGA’s function is out of context. It’s a pass-through device and a magic black box. You stick functions on it the same way I used to stick ROM cartridges into my NES as a kid (if this phrase means nothing to you, see this YouTube video).

This is great for an introduction, but the choice in hardware, if you ask me, is questionable. Don't get me wrong. As I said earlier, I like me some Cyclone, but using an Altera chip, a decidedly closed-source device, with apparently no direct access, closes the door to potential digital logic designers. If they had used a Lattice chip, for which an open toolchain has been developed (thank you, Clifford Wolf), and provided a direct channel to the programming interface, this would have been a far more robust development board.

Add on top of that the user’s temptation of forfeiting the core knowledge required to deploy stable firmware, let alone soft chip architectures on an FPGA, because it "just works," and we introduce the embedded industry to a potential world of hurt.

The Takeaway

As always, there needs to be a moral to this story. Here it is:

We need to treat Arduino as a door into a much larger world. We need to provide better ways of easing makers, developers, non-firmware-engineers and inventors into the core knowledge and skills required to carry their interests beyond the Arduinosphere without sending them off to university.

Now that FPGA IPs are a part of the Arduino ecosystem, this task has been made more difficult. We need to be able to peel back the abstract. Instead of adding more pre-compiled logic blocks for the users of Arduino, we should start showing them the inner workings. Slowly. Gently. And somehow as a natural progression.

The FPGA world has been on the rise. FPGAs recently started to popping up in Modern CPUs, from Intel Xeon and AMD EPYC to the Xilinx Zinq and Altera Cyclone V SoC FPGAs. More and more maker feeds on Twitter, and articles on hardware hacker blogs are talking about FPGAs in a meaningful and excited way. The future of development, processing and making is now intertwined with flexible hardware and custom logic.

As tech professionals, we owe it to the myriad Arduino users out there to encourage them to move beyond the comfort of the figurative airliner. To put a crash mat under them and guide them to the edge of a 6 foot platform, then to a higher platform and so on, until the skydiving that embedded development appears to be is just one more jump. We in the industry are in a position to foster the interest these enthusiast creators have in using embedded and FPGA devices into a desire to learn more and to take the initiative to remove that first layer of abstraction. To progress toward an in-depth understanding of their projects’ inner workings.

Maybe will take up the call as well, expose more of the Altera FPGA’s capabilities in their online IDE and provide educational resources for digital logic and bare-wire programming.

In the end, we are all part of the same tech community, making things happen in the real world with code.


As promised.

  • Arduino is cool and enables awesome maker projects and quick proof-of-concept prototypes.
  • Abstraction layers are great for bypassing complex concepts, but should be the building blocks of core knowledge.
  • We have to be careful in the tech industry to use more stable verifiable platforms than Arduino in our end-user and B2B products' firmware.
  • MKR Vidor 4000 brings an Altera FPGA to the Arduino ecosystem
  • Uh oh, its toolchain is closed-source.
  • More abstraction here to compensate.
  • Arduino should be as much an education tool as it is a creation tool.
  • But adding more complexity and obscuring it with even more abstraction cripples it from eventually becoming a software and (now) logic design education tool.
  • How do we encourage Arduino users to move beyond their comfort zone into the big leagues of logic design and firmware development?

Co-authored by: Dimitar Tomov, DesignFirst OU

Friday, March 16, 2018

Aerocore 2CD for Dragonboard 410C Camera and Display Demo

Today was the 96Boards Open Hours demo for the next Aerocore 2 MAV board.  I set up a test rig, hooked up 2 OV5640 CSI-2 cameras and a DSI OLED display and showed the 96Boards community what the Aerocore 2CD for Dragonboard 410C can do.

If you tuned in, thanks for watching.  If not, I'll add a link to the YouTube video as soon as it's up.  Either way, I promised to make all of the resources I used to get this demo up and running so that you can do it too.

I first demonstrated the Aerocore 2 for Dragonboard 410C on a quadrocopter drone last year, and wrote a how-to post about setting it up. This time, there was no drone, but instead there were 2 5.0MP cameras and a 5.5" OLED display.

So this is how I got my Dragonboard 410C to do all kinds of cool video tricks:

Getting Ready

Before I dive into the setup procedure, let's just talk about what we're really doing.  The Dragonboard 410C is really an exceptional SBC with lots of neat features, including high-speed and low-speed mezzanine connectors.  The inclusion of the high-speed header on the Dragonboard, and incidentally as part of the 96Boards CE spec, means that hardware developers can create expansion boards that have high speed features like SATA, PCI-express, or USB3.0.

The new Aerocore 2CD takes advantage of this high-speed connector to provide 3 high-speed LVDS interfaces: 2x 2-lane CSI-2 camera connectors and 1x DSI display connector.  In order to demonstrate these new features, I am going to connect 2 KLT-OV5640 camera modules, and an OSD055A AMOLED display to the Dragonboard, and using only GStreamer commands in some simple BASH scripts, I will stream camera 1, camera 2, or both cameras concurrently, over UDP to my desktop PC.

Then I will stream the same camera output to the XFCE interface on the connected OLED display.


the bits


It's not a bad idea to make some mounting brackets for the cameras and display to make it a more manageable rig.  For my demo I designed something in FreeCAD and printed it off on my personal 3D printer.  Also there are simple brackets you can make that will hold the cameras' connectors in place.


In addition to the hardware above I used the following files:

On my desktop I'm running Ubuntu 16.4.

Assembly and Setup

Bracket1 and Bracket2 have spaces in which the cameras sit.  The forward camera fits sung, but the rear bracket's camera mount was a little too thin on one side so it doesn't hold it still on its own.  That's okay though because I was already planning on taping them down for the demo.  At this point I also attached the display's ribbon cable to the Aerocore (pads up).

The standoffs connect to the topside of the Areocore board with 2.2mm screws but, due to some scaling issues with my 3D printer, the diameter of the screw holes was just a bit too big so I found two risers with slightly wider threads, which worked nicely.

Almost done...
Next, I attached these brackets to the display panel's frame.  I'd tried mounting the panel inside the frame but they're very delicate and I broke my first one.  That's going to take a redesign.

I connected the DSI ribbon (pads down) to the back of the display and taped the display down inside the frame's bevel.  Carefully.  Finally, I attached the Dragonboard to the underside of the Aerocore.

Down-facing camera peeks out past SD card
I copied the SD card image to a 16GB SD with dd card and expaneded the root filesystem's partition with gparted (the disk image's rootfs partition is only 2GB to reduce download and dd time). With the card in the Dragonboard's SD card reader, it was time to fire it up.

I plugged it in, lights began to flash, bootlog messages came up on the console, and then... nothing...  The OLED display stayed dark.  Why?

Well the Dragonboard's HDMI interface has a little secret:  It's really HDMI over DSI!  The video output to the HDMI device is muxed with the DSI lines on the HS header.  You select one or the other with one of the S6 dipswitches on the Dragonboard's backside.  So once I toggled that to off and powered up my board again, up came my XFCE desktop!  Cool!

XFCE up and running!
I installed the GStreamer plugins on both my desktop PC and on the Dragonboard 410C.  Gumstix's Yocto images use the Smart package tool:

# smart update
# smart install gstreamer1.0 gstreamer1.0-plugins-good  \

I copied to the dragonboard and tested out the video feed to the DSI display.  The script is set up so that you can do that, or stream it over TCP/UDP for any or all cameras.

To stream it to your PC, type this at the Dragonboard's command prompt:

# -i <host-ip-address> -c N

where <host-ip-address> is your PC's address and N is '1' for the downward-facing camera, '2' for the front camera, and '3' for both together.

To stream it to the display, just omit  ' -i <host-ip-address>'.

Okay, Next!

That's it.  That's all I had to do. I hope I get the chance to put this stuff on a drone or robot and do some OpenCV work.

Meanwhile, I think I'll write up a quickstart guide for the storefront, a little more formally.  I'm still trying to get my LoRa gateway outside and I've got some bugs in the backlog, but I'm sure I'll get back to Aerocore, MAVs or robotics-type projects soon.

Hey, if you have any ideas for new projects, let me know! Follow me on Twitter @gstixguru or drop me an email at

Friday, February 2, 2018

Protocase: Full Coverage Chapter 1

Chapter 1: Designing and Ordering an Enclosure


Gumstix is a leader in embedded and IoT hardware, having delivered the first Linux-powered computer on module (COM) over 10 years ago. The company has come a long way since then and has come to introduce Geppetto to the world of embedded hardware development. Using this online tool, customers can quickly design prototype expansion boards or SBCs and have them delivered in weeks, instead of months, with no experience in electrical or electronics engineering.

As far as hardware is concerned, the circuit board design and fabrication is more than half the battle, but if you’re looking to deploy your prototype in the field, you’ll likely want to protect the delicate components and wiring that make your product great. You’re going to need an enclosure.

Picking an Enclosure

VIA Mini-ITX Form Factor Comparison
Some common ATX form factors

When it comes to housing or mounting your hardware, you have some options. The first one is to design your hardware to conform to some kind of standardized form factor, like micro-ITX, for example. This approach guarantees that there is a commercial product out there that will accommodate your device. The problem with this is you are limited to the manufacturer’s design choices. The port holes or standoffs may be in the wrong place. You might require additional cooling or weatherproofing. Or it might just be the wrong colour.

Another popular option is desktop additive manufacturing. 3D printers. I happen to be assembling my own Kossel-style delta printer at home and will likely print more than one device housing with it. This is a cheap and easy option. Design a 3D model that accommodates your device, slice it, hit “Print”, and wait. You get what you pay for, though (Filament costs pennies per print). Flimsy plastic construction, inconsistent results, and questionable resistance to the elements make most 3D-printed cases a poor option for industrial prototypes.

Until recently, my weapon of choice has been an ad-hoc approach. I wander around the office looking for cardboard and plastic boxes, leftover standoffs and screws, electrical tape, duct tape, and anything else lying around that I can smash together to give me something workable. I sometimes like to glorify it by calling it “In Situ Resource Utilization (ISRU)” but I’m not fooling anyone.
My Ad-Hoc "air cooled" rig (Derelict LCD display keeps it from tipping)

When I decided I was going to deploy an Overo Conduit gateway outside, I was given another option. A company that, given a brief description of my needs, a simple 3D representation of my device components, and a fistfull of cash, sent me exactly what I needed - a beautifully realized, black-on-black silkscreened, folded and welded metal case, complete with standoffs, accurately placed and cleanly cut port holes, and enclosure screws. That company is Protocase.

My Protocase Experience

From website to delivery, working with Protocase has been easy, fun, and rewarding. This is what it was like for me:

Welcome to Protocase:


The Website

The Protocase website is clean and easy to navigate. I immediately found my way to product and service descriptions, browsing through the wide variety of case configurations. I investigated the consolet and machined enclosure tabs, marveled at the selection of finishes, and ogled at the 2-3 day turnaround and lack of a minimum order requirement. Now that I was properly introduced to Protocase, it was time to consider my design options.

Enclosure Design

Protocase Designer

The first and fastest method of designing a case is to submit your own CAD drawing. For most engineering firms, this is probably the best scenario. They review your design and send you a quote. Done.

Second, there’s Protocase Designer. Start from their case templates, place cutouts, standoffs and screw holes based on real parts, visualize it in 3D, and get instant quote from a cross-platform desktop application. I gave this one a spin but quickly realized that, with the gateway module attached, the Overo Conduit was a real challenge to design for this way.

An early model of my case

So I took my project to their design team.  one of their designers would take my hardware specs and ideas and create a CAD model for me at an hourly rate.  

I put together a rudimentary 3D model of my board combined with the RHF0M301 concentrator
module with OpenSCAD and sent them an e-mail describing what I was looking for. In no time at all, I was looking at an early eDrawing of my case. One short email, with a few answers to questions, and a half-day’s wait and I had the final draft in my inbox. I approved the design and it was off to the shop.

Now, with the case designed and off to manufacture, it was time to deal with aesthetics. Lucky for me, I already knew what I wanted: Matte black with glossy black silkscreen. If I hadn’t already decided, it would have been a real challenge, seeing as how there are over 30 powdercoat colors, 7 anodizing options, 3 bare-metal finish options, and chem film coating to choose from. There’s also 30 silkscreen colors, a digital printing option, and custom machined cut-outs for logos and branding.

I emailed a vector graphic to the team and (im)patiently waited for my enclosure.


Yes, I am not a patient person - especially when it comes to getting a new gadget. That’s okay though, because the folks at Protocase were very much so with me. My repeated email requests for status updates were met with swift and enthusiastic responses, letting me know how things were coming along. 

The Takeaway

 So what do I have to say about my designing and ordering experience with Protocase?  Great things!  Here's my gist:
  1. They have a wide variety of materials, methods, and finishes
  2. They have an equally impressive list of finishes, coats, and graphic design options
  3. You can design your case however you choose, including their own desktop application, or you can conscript their competent designers as I did.
  4. The staff are fantastic!


Stay tuned for my next post when I will build, connect and deploy my LoRa gateway out my bedroom window in a rainy Vancouver winter!

Thursday, December 7, 2017

AutoBSP Gets Your Geppetto Board Booted

What is AutoBSP

AutoBSP is a new service offered to Geppetto designers that accelerates board bring-up by customizing a boot configuration file -- a device tree -- for every design.

Quick, What Is a Device Tree?

Device trees are logical maps of the hardware connected to a processor. Linux bootloaders can make use of them to help multiplex GPIO pins, assign addresses to external devices, deliver device settings to kernel modules, and control the SoC’s power-up sequence.

Device tree source (DTS) code is compiled into binaries -- or device tree blobs (DTBs) -- and added to the boot partition of a device’s disk image. The bootloader then reads this DTB and configures the SoC and the operating system with help from its contents.

The SoC, its application-specific processors, programmable power systems, and connected devices are broken down into a tree of nodes. Each node contains vital information about its configuration, voltage levels, GPIO assignments and interrupt vectors. These are used by the kernel and drivers to bring up, operate and expose them to the userspace.

Why Should You Care?

One SoC, many devices: Just a few NXP i.MX 6 boards

In an ecosystem where, for any given SoC, there may be tens of SBCs, compute modules, or expansion boards, board bring-up can be an incredibly difficult challenge. The inclusion of device tree support in the Linux kernel facilitates the process by adding a flexible abstraction layer between the firmware and the hardware, removing the hardware description from the kernel.

Device drivers can be written to glean variables, parameters, and logical addresses for the various hardware components and chip features it needs to operate from the device tree; Regulators can be programmed and sequenced; Chip features can be activated and disabled.

Your Geppetto Board is Unique to You

Let’s say you’ve just designed and ordered a custom board using the Geppetto interface. You have included a Linux-ready COM and a particular collection of sensors, ports and devices that suit your application. That board will be in your hands in a few weeks, tested and ready to go. Gumstix will offer our own flavour of Yocto Linux through our storefront, as well as developer documentation, spec sheets, and other helpful resources.

With almost 200 modules available in the Geppetto library and more added regularly, there are endless possible arrangements that your design might take and it’s possible that you’ll want it running some flavour of Linux. It’s our goal to offer you as much support and information as possible to help get your platform up and running as fast as we can get it in your hands.

AutoBSP is Unique to Your Geppetto Board

Normally, someone would have to manually create a device tree to bring up the components on your board, meticulously adding, tweaking and debugging each node until all of the devices work as expected. AutoBSP delivers a working, compiled device tree specific to your design on demand.

This means that, as soon as the product is in your hands it will be ready to run, saving hours of development and testing. AutoBSP is one more way that Gumstix is accelerating your time to market by getting your prototype designs ready for development as fast as we can deliver the hardware.

SoC and Compute Module Support

Most Linux-ready COM connector and Processor modules are supported by AutoBSP, and the rest are on their way. Here’s some detail:

What AutoBSP Can Do:

AutoBSP will currently build DTBs for boards designed for the majority of platforms available in Geppetto. The following COMs and SoCs are currently supported:

  • Gumstix Overo and Overo STORM COMs
  • Gumstix DuoVero COMs
  • Toradex Colibri iMX6 COMs
  • Toradex Colibri iMX7 COMs
  • TechNexion PICO iMX6 COMs
  • Raspberry Pi 2/3 and Raspberry Pi CM/CM3
  • AM335x (Pepper) SBCs
  • AM437x (Poblano) SBCs
  • SCM-iMX6 (Cobalt) SBCs

What AutoBSP Will Do:

Just like Geppetto, AutoBSP is constantly expanding to accommodate the needs of its users. Expect support to grow as new SoC modules are added to Geppetto. Some additions are already underway.

  • BeagleBone Black
  • Arduino-supported MCUs
  • 96Boards CE (Dragonboard 410C)

Wait, Did You Say Raspberry Pi?

That’s right. When you design a Raspberry Pi HAT, or an RPCM expansion board, AutoBSP will deliver a DTB overlay specific to your board. That’s one file to configure I2C devices, assign GPIOs, and activate SoC features. If you’ve gone and purchased a Gumstix Pi HAT and you’re looking to get started quickly on your next maker project, the AutoBSP-generated dt-overlay will help you skip much of the trial-and-error setup procedure you deal with for other HATs and get you coding as fast as possible.

Copy AutoBSP’s DTBO file to your Raspberry Pi boot partition’s ‘overlays’ directory and change the ‘dtoverlay=’ string in ‘config.txt’ to match and the Linux kernel will ‘see’ your board and its devices when it starts up.


At Gumstix, we are constantly looking for ways to make our lives easier. The benefit is that we pass these helper services, or their benefits, along to our clients. It started with the COM. Gumstix pioneered the idea in 2003 with the Verdex and Verdex Pro - a Linux-ready compute device the size of a stick of gum. This enabled hardware developers to test, prototype and deploy their designs more easily, encapsulating the compute power in a single, replaceable module.

We carried the idea forward ten years later when Geppetto was born. We further modularized the concept of the computer by introducing hardware as feature modules on a virtual board. Start with a COM connector, drop in USB, Ethernet, and any of the ~150 modules in the Geppetto library to build your own development board, prototype or production device. Click 'Complete Design' and Geppetto generates the CAD files for you and sends them to our engineers for review.

Geppetto now takes advantage of all of the back-end data that Geppetto uses to render your board as well, providing extra resources for engineers and developers. Through the 3D preview feature, users can export the 3D rendering of their device to an STL file.

AutoDoc delivers valuable signal and connection data on the fly before your design is even ordered. It includes links to reference manuals, feature outlines, signal descriptions and their associations, and much more.

Now, AutoBSP goes a step further and gives you the files you need to get Linux up and running. With a featured Yocto image from Gumstix and an AutoBSP DTB, you will have your board running in minutes instead of days.

You can expect to see more of these types of services to crop up from time to time as we discover new ways of making your life easier.

Just One More Reason

AutoBSP is just one more reason why Geppetto is THE design-to-order tool for IoT, embedded, and robotics hardware. Test-drive Geppetto today at and create your next innovation.

Monday, October 16, 2017

Say Hello to The Cobalt MC

Introducing the Cobalt MC

Now that Gumstix has added the SCM-i.MX 6Quad and 6Dual SoCs to Geppetto and released a development board along with it, it’s time to put it to use. The Cobalt MC is packed with PC-like features, such as HDMI, Gigabit Ethernet, audio jacks and USB. It also has WiFi, BT4.0/BLE, CSI-2 and SPI, CAN, I2C and UART headers. These combined with a handy cluster of GPIO pins, including PWMs make this a good board for IoT and homebrew gadgets.

It’s powered by the NXP SCM-i.MX 6Quad single-chip module. This SoC packs 4 Arm Cortex-A9 cores, a myriad of embedded systems, a power regulator, 100+ passives and a gig of RAM into a single tiny package. That’s pretty cool.

So what can we do with the Cobalt MC?

Here, let me give you some examples.


Of course. This is the first option that pops into my mind. Load it up with an XFCE flavour of Yocto, install some ARM-ready productivity apps and web browsers, and you’re off to the races. It’s not going to run ‘Overwatch’ or anything, but it’ll fit just about anywhere you could want to put a PC.

IoT Hub

Deploying smart-home gadgets? Need a command and control station to tie them all together? Develop your device management software with this single board computer, and get your connected sensors, actuators, vacuum cleaners, and interfaces talking to each other in no time.

Video Conference Device

Combine the Cobalt MC with a USB far-field mic array, HDMI LCD panel, and an HD camera to broadcast your live feed at blazing Gigabit speeds. Develop an Android or IOS remote control app and take advantage of its Bluetooth functionality.

Smart ROV

Yes, let’s bring up the subject of robots, because robots are awesome. Why not hook the board’s UART bus to an ROV’s microcontroller and have it make all of the pathfinding, obstacle avoidance and target-tracking decisions?

Endless Possibilities

These are only the ideas I could come up with on the fly. You’ve probably been sitting there for weeks/months/years scheming and plotting. Where do you need a tiny quad-core Linux SBC? 

The SCM’s in Geppetto D2O

Okay so you’ve read through my examples and have said “Hey that sounds like exactly what I need!” Then you’ve ordered one and developed a prototype around it. Great! I’m glad we could help! But now you’re saying “With all these extra connectors, gadgets and doohickeys, I’m not really taking advantage of the SCM’s svelte size.” Or “This is great but it’s missing something.” Bottom line: “I’d love to crowdfund this or take it to market, but first I’d like to make some changes.”

That’s something that Geppetto’s really good at. If you go to and click on the “Designed By Gumstix” tab, you’ll find the Cobalt MC design, which you can export to your workspace and tweak to your heart’s content. You might want to swap the barrel connector for a battery terminal, or get rid of the GPIOs and add a connection for a GPS module. Power over Ethernet, dual-stacked USB ports, accelerometer or barometers. With about 150 modules in the Geppetto library, there’s lots of options.

Tuesday, September 5, 2017

Updates: Intel Joule, LoRa, Arduino and Protocase

Blog Break

It has been a while since I posted a blog entry.  I have been knee-deep in a challenging internal project and haven't had much time to come up for air.  Today, I've got a chance to reflect on some of the things that have been happening here at Gumstix and share my perspective with you.

First, there's the EOL announcement from Intel that blindsided the x86-focused IoT community:
 the Joule, Edison, and Curie modules are soon to be no more than a footnote in the history of embedded computing.

Also, Just recently, hardware support for LoRaWAN was added to the Geppetto module library and 3 LoRa boards were released.  I got to play with that quite a bit.  It also brought with it an ATmega32U4 Geppetto module, supplanting the Curie module as our primary Arduino-compatible MCU.

Finally, I've been talking a lot with Protocase.  These guys are cool.  They provide design and production services for custom small-run enclosures, rackmounts, brackets, and consolets. I'm very excited to see what they're making for me.

Intel EOL Announcements and Me

I'll admit it, I took the Intel Joule news harder than maybe I should have.  I spent a lot of time working with it and it's carrier boards.  I was looking forward to putting the GadgetDrone in the air with the AeroCore 2 for Joule, the Caspa HD and one of the RealSense point cloud cameras we have at the office.  I liked the idea of setting up my Workstation board in a 3D-printed enclosure as a Yocto build slave.  Oh and I still hope to test the Caspa 4K's "tone-mapping (Er, I mean HDR) Video" mode.

I was also sad to see the Curie go.  Working with our Radium 96Boards IE board is a lot of fun.  It had been a while since I'd worked at the MCU level.  Bare-wire programming on an 8051 and using a dual-Arduino Uno plus ZigBee robot controller were highlights of my academic career, but I haven't done anything of the sort since.  The Radium's nice and small, IE compliant and has all the cool features of the Curie, like Bluetooth, 6-axis IMU and Neuron pattern recognition nodes.

For whatever reason, Intel decided to terminate their IoT-targeted endeavors.  Maybe it was the slow - and sometimes negative - response from the community.  It's also possible that the challenges in providing software support for their hardware were more monolithic than anticipated.  Either way, the Joule, Curie and Edison are gone.

For all of you who jumped on board with Intel's IoT hardware just over a year ago, I empathize with your plight.


If you're into IoT, you may have heard of LoRa, LoRaWAN and the LoRa Alliance.  It's a communication protocol for sub-GHz long range LPWANs, and it's sweeping Europe and North America's IIoT industry.  It works like this:  

You set up a Gateway. This is the equivalent of a WiFi router in your home, but the difference is these things can have a range of up to 15 km, depending on the quality of your antenna.

You deploy nodes.  These are your data acquisition points - temperature, presence detection, air quality, etc.  Whatever you need to know.  Put them where they need to be and hook them up to a battery, solar panel or hamster wheel (No hamsters were harmed in the writing of this blog post).  The idea is that they require very little power to run and can last anywhere from a week to several months on a single charge, or indefinitely with solar.  These tend to have a range of 2-5 km.

You monitor the data and use it as you see fit.

Gumstix released a gateway/concentrator and a transciever module in Geppetto, as well as a gateway dev board for both the Overo and the Raspberry Pi Compute Modules (Overo Conduit and Gumstix Pi Conduit boards), and a weather station sensor board (Strata Node).  They're in the store and available in both North American and European frequency bands.

Once I had my Gumstix Overo Conduit gateway and an RHF0M301 gateway/concentrator module in hand, I was impressed with how quick and easy it was to set up on  The Strata node I recieved was pre-release and hadn't had the bootloader flashed yet (they come pre-flashed now), so it took a little longer, but writing a sketch and setting up a project on TTN and went super-smoothly.  It just so happens that I made a bit of a quick-start video:

Arduino Stuff

Arduino is a great thing.  For artists, makers, inventors, amateur developers, and teachers, it's a great way to avoid the challenges of bare-wire programming and get physical objects doing what you want them to do.  For professionals, it's a good prototyping tool, delivering your proof of concept to the project manager in hours or days instead of weeks (or worse).

Adding the ATmega32U4 to the Geppetto library means I'll get a lot more time to play with Arduino hardware, projects, board support, and the IDE.  It also means that there will likely be more Arduino boards coming to the store and hardware modules coming to the Geppetto library.

I'm also going to have to find a quick and easy way to set up my 'arduino_pins.h' file.

Discovering Protocase

If you've seen my previous posts, chances are you've seen my low-tech enclosures, mounting brackets and test environments.  My indoor quadcopter test flight had a paracord tether tied to the rafters so that I didn't give my co-workers a hair cut.  I like to think of it as ISRU (In Situ Resource Utilization).  However, in some cases, a solid, well-made case is more than just a good idea.  When I went shopping for enclosures for my Overo Conduit board so that I could deploy it outside, my boss pointed me to  I think he just wanted me to stop asking for a 3D printer for the office.

These guys are awesome.  They're working on something for me and I can't wait to show it off.  They have a huge variety of custom products: L-shape, U-shape 5-sided, milled aluminum, and more!  They'll build from your CAD drawings and have free templates to help get started.  They even have their own design software for you to use.  If all else fails, they will work with you and design a fully customized enclosure for your device.

If you've got a prototype, an invention or a first-run for a kickstarter campaign, Protocase might be for you.  Just check out their page and see for yourself.

To Summarize:

I've been busy.  From grinding away at that internal project to working on LoRa and Arduino board support to designing enclosures to recovering from the Intel IoT fallout, I've hardly had enough time to catch my breath.  Now that things are settling down a bit, I am looking forward to spending more time telling you all about the cool stuff I'm working on.

Friday, July 14, 2017

AutoDoc: We Automated Product Documentation

Geppetto's AutoDoc

Gumstix has announced this week that Geppetto users can now download documentation for their designs that is generated from the current state of their project.  The addition of the AutoDoc button marks the public release of a tool we've been using internally for some time.  As one of the content curators of this application, I'm excited to share it with everyone because it's a bigger deal than it sounds.

Hardware Documentation

I'm one of those people who find it satisfying to produce usable technical documentation - to describe the operation and setup of a platform in a legible, accurate and eloquent way.  I have always felt that written tech materials either skimp on details or skimp on readability, and I strive to find a balance of both.

For hardware, one of the documents engineers find most helpful is the schematic - a block diagram of the ICs and passive elements that are interconnected in a design.  Firmware programmers, on the other hand, are less reliant on these drawings.  Instead, they need to know the bus names, addresses, GPIO indexes, and features  of the devices connected to the SoC they are programming.
Both need access to technical reference manuals, a layout overview, and connection maps.

AutoDoc cover page for one of my designs
Geppetto's purpose is to provide an avenue for board development that does not require in-house electrical engineers, providing a piece of hardware that could pass directly into a developer's hands.  In my opinion, this is the epitome of the startup use-case.

Why AutoDoc?

Because Geppetto completes the layout, BOM, and fabrication steps for your design, you can have a board in your hands really fast.  That doesn't leave a lot of time for someone like me to sit down and write out a detailed description of your design and its components, so we developed a method of generating written design specs solely from the data later used to generate your board.  We have been able to provide this kind of documentation for some time and it has helped many clients get their applications up and running fast.

With the data in these files, developers can configure drivers, write interface software, and begin testing code before the board has even shipped.  By exposing access to this resource to you before you complete your design, you don't even need to order your boards before you get started. Clicking on the AutoDoc button gives you the pin-outs and signals as they are currently saved.  I feel like it's empowering you with ownership of your design at the earliest possible time.

...And I don't have to sit there and write it all out.

Board layout diagram and a module description

Why it Works

If you don't know what LaTeX is, you should.  It is essentially a programming language for documents.  Look at this way:  When you write a document in MS Word or Google Docs, you have to struggle with the complexity of its "What You See is What You Get" (WYSIWYG) interface.  This is nice for letters, memos, and most resumees, but when it comes to technical documentation, it becomes a fight.  Also, it's not particularly portable.  When you create a document in Google and download it as a .docx file, it definitely doesn't look the same.  Margins change, images move or disappear entirely, fonts are lost or mutilated...  A mess.

Tables, captions, title pages, pagination and indenting:  All these things can be hard-coded into a document with LaTeX.  It will look right every time you compile it.  It will look right when someone else compiles it.

So if we treat documentation as source, then we can script it.  We can apply templates to it. We can make the result deterministic and incrementally improve its quality and content.  And this is what we did with AutoDoc.  There is now no temporal or financial expense in creating a useful reference manual for custom designed Geppetto boards  Enjoy.

What's Next?

I like how Geppetto automates things.  Seeing what it delivers always makes me smile.  So what else can we automate.  Lots!  What else do you need, as firmware developers?  As project managers?  As startup companies?  You can look forward to more of it from Geppetto.