Friday, November 16, 2018

Eating My Own Dog Food: My Success Via Geppetto

So I have been at Gumstix for about 2 and 1/2 years now, and I have spent a lot of time telling anyone who will listen how awesome, unique and helpful Geppetto is as a service.  Well, I have finally had the opportunity to turn one of my own ideas into a reality by drag-n-drop designing, ordering and developing my own prototype through Geppetto's design-to-order magic.  This is my opportunity to eat my own dog food.

Some of you might be saying "Stop talking about dog food! what does that have to do with electronics engineering?"  I learned the expression from our CEO when he talks about how we design all of our own hardware with our own design tool.  Basically, would you trust your dog's health to a dog food company whose employees won't even feed their product to their own dogs?  If we won't use our own service, why should you.

Geppetto frequent flyers may already know that any of the development boards you find in the Gumstix storefront that have been released in the past 4 years can be cloned from the "Designed by Gumstix" tab in Geppetto.  That's because we designed the Aerocore 2 for NVIDIA Jetson, the Chatterbox and the RoomSense boards, to name a few, in Geppetto the same way you would design your boards.  You can clone the design and modify it to suit your project's particular needs.

So anyone who's been following me has seen me work with the hardware that's already in our store.  4 different Aerocores, GPS dongles, LoRaWAN gateways and nodes...  I have yet to design and have manufactured my own custom board...  Until now!

The Engineering Challenge

As lead developer on the AutoBSP service, it's my job to make sure it effectively generates quality device trees and DT overlays for as many of our supported platforms as possible.  So far, it's doing a great job.  However, as the number of supported devices, peripherals and SoCs continues to expand, the challenge has switched from board-by-board development and testing to integration and QA testing.

When it comes to the stability of the service's software, this can be done using a traditional unit test method, which includes a batch test of all valid designs in Geppetto's database.  No problem, right?

However, the only way to make certain that the BSP correctly supports a customer's design, is to actually test it on the board.  This is already done on a per-board basis at the end of the production pipeline, but it's important that, whenever a user returns to download their BSP from Geppetto, that they get the same or better quality of device tree as they downloaded on day one.

So the task is to gather up all of the Geppetto boards that require DTBs and one-by-one program them and test them.  We've tried doing swarm tests, where all of our engineers grab a stack of boards and distribute the work, but this eats up valuable time and resources.  We wanted to automate the process as much as possible to free our hands for more urgent tasks, such as getting your custom board into your hands and adding more modules to our library.

In a Nutshell

How do we automate such a tactile task?  How do we, for each board, flash its SD card or MMC memory with the latest Linux disk image, upload a freshly generated device tree binary, power up the board, and monitor and control the device's debug terminal?

Initial Solution

Hmm, not terrible...
Ugh!
I managed to ad-hoc solve this problem  with some hardware I found around the office.  Using a variable power supply that can be controlled over a serial connection connected to an Ethernet-controlled smart relay board, an Ethernet switch and a USB hub, I managed to develop an application that can download the latest Gumstix-built disk image and AutoBSP DTB, flash them to an SD card or onboard memory, switch on the power for the board, and run the test script our technicians run at the fab, returning a pass/fail result and storing a log of all tests.  It will do this for multiple boards connected to the system.

Can you spot the problem?

That's right.  The rat's nest of wires and cables, multiple bulky devices, the overkill of using 120V AC relays, and so-on makes for a real mess.  It seemed a good opportunity to use our online design-to-order app to streamline the process.

Refinement by Design

The largest design flaw culprit in the test rig I described above is the relay board.  Having it connected to the local network is perfect.  formulating the software to submit HTTP get requests was a snap.  Being able to choose between 5V and 12V using a 3-output VPS was vital. But the hardware! what a clunky, cumbersome mess!  That and a USB connection to the board's debug port are also the only two commonalities for all boards.  Many don't have Ethernet, some don't have USB, not all have video output.

So I decided to refine my relay and couple it with a USB hub.

Designed in Geppetto

Obviously, this is not my first rodeo.  I have been toying, tinkering, playing and working with Geppetto for a couple years now, and I jumped right into it.  First came the microcontroller.  As part of my requirements, WiFi access was required.  The obvious choice then is the ATSAMW25, the same chip-down module used on the Arduino MKR1000 and the only MCU with built-in WiFi.

Oooh, beveled corners!
Next come the relays.  Ten of them.  These were arranged easily enough around the edge of the board.  Each solid-state relay module includes a 2-point screw terminal.  Using the 'dimensions' tool, I was able to distribute them evenly and lock their placement with respect to each other.

In addition to WiFi access, I wanted to be able to manually toggle the relays, so each relay got a right-angle tactile switch.  And an indicator LED, of course.  Next, I made all of the connections, adding voltage regulators as needed.  The indicator LEDs are connected directly to their relays' 'Enable' signals so they are always on when the circuit is closed and always off when the circuit is open.

I also added a bonus programmable LED right next to the MCU that I'll use to indicate a connection to a WiFi access point, and a reset button.  Finally, I added a debug port for the MCU.  This will allow me to program it using Arduino as I prototype my design.

Next came the USB hub.  This part was easy.  A 7-port hub, a 3-port hub and a USB bridge quickly combined with a USB micro-B connector to create a 9-port USB hub.

A Bit of Custom Work

So I have this design now.  It only took about 1.5 hours to put together.  And hey, it only took that long because I wanted to play around with rounded edges and custom silkscreen logos - two new and cool features.  However, the board wasn't going to behave exactly as I wanted as-is.

However, I happen to know that our electrical engineers are quite skilled and are willing to go the extra mile for our Geppetto designs.  When I saved my design, I added a note in the description.  It went something like this:

"I would like to have the relays set up to provide either 5V or 12V from on-board power.  Please add a jumper or DIP switch to select voltage."

Now that my design was saved, I clicked the 'Validate' button and checked out my new storefront page.  This is where my experience briefly deviates from your own.  This is the point where you pay the board cost and engineering fee to order your design.  Since I'm developing this for a Gumstix application, it's a company expense.

After a brief chat with one of our engineers (he also happens to be my supervisor) to clarify exactly what I meant with my voltage comment, the schematic and layout that Geppetto's back-end generates are modified to include the jumpers as I'd requested, and the gerbers are off to the fabs.

RELAY COMMANDER!

"Relay Commander" Board In-Hand

After a quick few weeks, the board arrived at the office.  I spent some obligatory time admiring my (and our engineers') handywork.  The terminal blocks, the right-angle pushbuttons, and the USB hub all look great together.  With the vanity attack out of the way, time to get down to business.

Arduino Sketch

Thanks to Geppetto's AutoDoc service, I had all of the design data in hand to write an early draft of my relay control sketch.  Additionally, thanks to AutoBSP, I was also able to test it out on a RoomSense, getting the initial WiFi and console interfaces tested.  Since I didn't have any breadboard-able pushbuttons on hand, testing that interface was a bit too involved to test.

So when the board arrived, I flashed our slightly modified ATSAMW25 bootloader, included with the AutoBSP package, and started testing in earnest.

I'm kind of proud of the fact that Arduino BSPs from Geppetto are designed to be installed in the same was as other "Contributed" packages.  When you download autobsp.zip from the Geppetto, it includes a file called contributor_url.txt.  it contains a URL that you can copy into your Arduino IDE's settings and the board will show up in the boards manager as would any other BSP.

After a few hours of debugging, I had a stable implementation of the device's minimum operation, including debounced pushbuttons, HTTP request/response interface and command line interfacing over USB. A couple things are currently irking me still.  Right now, when I power on the device, two of my relays cycle.  Also, I need to be able to fetch the state of all relays over the WiFi interface.

Disclaimer
If you've read this previous post, you know that I'm a little uncomfortable with Arduino in finished products.  It may seem hypocritical for me to turn around a couple months later and write my relay's firmware in Arduino.  I get it, and I'm slowly developing an embedded-C version of the firmware, but as I said in that article, Arduino IS great for prototyping quickly.  Getting my relay board up and working as soon as possible is a priority.  It is going to be an integral part of kernel, AutoBSP and firmware integration testing in the very near future and I don't have time to be messing around at the lower levels until the pressure's off.

Operating the Board

Now, with the firmware in the functional prototype stage, with WiFi, console and pushbuttons working, I can review the actual quality of the board.  The placement of everything is very nice.  The volatge selection jumpers are a little bit further back than I would have liked but they are still nicely aligned with respect to the relay IC.

The screw terminals feel well-secured to the PCB. The right-angle USB ports arranged in the center are a bit sticky but, thanks to the extra thru-holes I put in the middle of the board, the standoffs prevent the board from over-flexing.  All in all I am very pleased with the construction and custom work that went into my relay board.  And because I somewhat modeled the network API after that of the Ethernet relay controller, integrating it into my test suite proved easy enough.  With the kinks worked out and my test boards wired up, this baby's ready to go.

My Own Dog Food

So back to my original statement.  Am I willing to eat my own dog food?  Do I think Geppetto is worth the noise I make about it?  Absolutely.  As an embedded software engineer, I don't have the experience required to lay out a board, or source my BOM.  I don't have the contacts required to get in touch with reliable PCB manufacturers and fabs.  Having a service like Geppetto to take care of that major chunk of the development process means I don't have to go the ad hoc route.

Yes, I will gladly partake of my company's product.  I encourage you to do the same.  And if you are interested in your own Arduino-ready 10x relay controller with a built-in USB hub, get in touch with me on Twitter (@gsitxguru) or leave a comment below.  If there's enough interest, I think we might be able to get the board in the store.



Tuesday, July 31, 2018

Harnessing The NVIDIA® Jetson TX2 With the Gumstix Aerocore 2 Platform



An interview with FIRST Robotics Competition participant and summer Gumstix intern Kenny Akers 



Kenny Akers is a senior student at Woodside Priory High School in Portola Valley California and 3-year veteran of the FIRST Robotics Competition -- An international contest of wits to see which team of High School students can custom-build a robot to complete a complex task. Each team has six weeks to garner financial support, design, construct, program and test their bots before pitting them against the other teams’ creations. As a member of Team 751, dubbed “Barn2Robotics” for its rustic base of operations, he brings his unique talents to their software development department.

Having taught himself C, C++, Java, Python and basic circuitry on his own time, Kenny is clearly a self-starter. Last year he was given the opportunity to loan his considerable talent to the Gumstix team for the summer months. He’s come back this year to push the limits of our hardware yet again. I didn’t get to spend much time with him last year so I was excited to catch up with him and learn more about his work and his experience here at Gumstix.

There is a summary of this interview on the Gumstix Blog but I wanted to share the complete Q&A with you because it's really an interesting read.


 A Summer of FIRSTs

Aerocore 2 for NVIDIA Jetson


Before I get to our interview, I thought I’d share a little about what’s new at Gumstix and what it has to do with Kenny. As you may have heard, Gumstix just released the Aerocore 2 for NVIDIA Jetson. This is our first board using the Jetson -- the first compute module series featuring the 256 CUDA cores of the Tegra X1 and X2 SoCs. Kenny gets to be the first person to play with the Aerocore 2 for Jetson and has some big plans for it. You guessed it, he’s putting it into his robot for the FIRST Robotics Competition… but I’ll let him tell you about it.




 

Part 1: A Bit About Yourself

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.
 

Obfuscation

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 Arduino.cc 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.



TL;DR


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.


Materials

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.


Software

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  \
  gstreamer1.0-plugins-bad



I copied cam_demo_dev.sh 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:

# cam_demo_dev.sh -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 keiththegumstixguru@gumstix.com.

Friday, February 2, 2018

Protocase: Full Coverage Chapter 1



Chapter 1: Designing and Ordering an Enclosure



Introduction


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: www.protocase.com

 



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.




Waiting...


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!

Next...

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.

AutoStuff



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 geppetto.gumstix.com 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.

Micro-Workstation


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 geppetto.gumstix.com 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.