Important Disclaimer: I am an Intel employee in a business unit not directly involved with Edison, whereby I had personally applied and and was granted early access to Edison resources and hardware and from which my opinions expressed below are not indicative nor representative of Intel Corporation.

The Edison, first announced by Intel CEO Brian Krzanich during his CES Keynote in January 2014, is a small form factor single-board-computer. Intended to engage prototypers and product designers in the Internet of Things and wearables markets, Edison has been evolving internally and is now available to the public as announced at Intel's Developer Forum (IDF) event in San Francisco.

The MSRP of $50.00 is in the neighborhood of the Raspberry Pi compute module, and links on Mouser show the average markup will be around $12-13.00 USD. Sparkfun is selling the module at the Intel MSRP, presumably due to the number of companion boards they announced.

With the amount of hardware built into the platform, it's no surprise that the base board ended up in a footprint slightly larger than an SD card, 35.5mm by 25.0mm. Many assumed the Edison would be another board based on the Quark architecture like its bigger sibling, Galileo. In truth, it's a combination of Intel silicon: a dual-core 500Mhz Silvermont Atom running Linux (a SoC originally for smartphones, the Atom Z34XX), and a low power, low-speed variant of the Quark designed to drive I/O via an RTOS.

For a quick overview of the tech specs, see the product brief over at the Intel Maker Portal.

Several months before IDF, a collaborator from Intel Labs and I submitted a joint proposal to prototype using Edison as part of an internal validation effort. The information & opinions contained in this post are assembled from two months of hands-on prototyping with Edison and its companion boards. The Quark/RTOS subsystem wasn't operational during the validation period, so that functionality isn't reviewed here.

Footprint, Breakouts, Launch Ecosystem

Size matters, and Edison is tiny. It's ~10% larger in area over an SD card, though 25% thicker. One important thing note is that Edison is a brain, conceptually similar to the Raspberry Pi compute module. The main difference is that the RPi compute breaks out pins using a common RAM module pinout, where Edison uses a much smaller 70 pin connector (of which 40 of which are available to users).

This 70 pin connector is not prototyping-friendly, explaining why two breakout boards designed by Intel are available at launch: the direct breakout, and the Arduino breakout.

The smaller of the two, the direct breakout (pictured above), contains the bare essentials: USB serial, USB OTG, and a proto area with the remaining pins. At ~$75.00 USD for the direct breakout + module, I would theorize that Intel is operating on razor-thin margins in order to encourage early platform adoption. It's a lot of hardware for the money.

The Arduino breakout (pictured below) has some useful prototyping functionality like a JTAG header, micro-SD slot, and Uno-compatible shield layout — but, it's 25% larger in area over Galileo.

One possible reason for the enormity of the Arduino breakout is the quantity of level-shifting circuitry, supporting user-configurable 3.3v and 5v. Indeed, most of the Edison runs at 1.8v — great for battery-conscious wearable projects — though designers will find it problematic for sketching in hardware. Most breakouts on Adafruit and Sparkfun are 3.3v or 5v. Indeed, it's rare to see 1.8v components at all. The direct breakout has one or two voltage regulators dedicated to powering the SoC via USB; all of the user-configurable pins are 1.8v. My point? Stock up on your level shifters!

As part of the validation efforts we observed several teams designing custom breakout boards using the 70 pin Hirose connector, a part with general availability at distributors like Digikey. This connector is not designed for high-frequency insertion, a strong hint that the intent was to remain statically attached within a larger product. While designing a PCB with a large number of SMT components is an increasingly accessible proposition, the platform isn't quite bench-friendly without some useful design references to build new boards with...

Thankfully, Sparkfun came to the rescue! Shortly after the Edison announcement, Sparkfun revealed their involvement with Edison in the form of Blocks. While it isn't clear that the Blocks are open hardware (though they presumably are...), the modularity of stackable PCBs based on the connector will solve the prototyping problem for many users of Edison. Interestingly, PCB stacking has been explored before, notably by the Microduino Kickstarter. At first glance, it's apparent that Sparkfun took care to minimize the Z-height of each block, a recurring issue with previous stackable implementations.

One of my primary complaints building the IDF demo was related to GPIO and control, especially PWM. Born from a smartphone SoC, Edison has a limited number of PWM pins. While looking at programming and hardware control below, it's worth noting my excitement about one particular Block: the "Arduino." This Block contains an ATmega328pP designed to communicate with the brain via UART and with all the 5v level-shifting convenience.

While the WIP Quark chip will better handle integrated low-level hardware I/O, I personally appreciate the simplicity of a solid 8mHz microcontroller running bare-metal C next to my Linux chip. Moreover, I'm a pin-junky, and I owe a beer to the first person to design a similar breakout using an ATmega 32u4 or similar.

Wireless Connectivity

The Edison module hosts a Broadcom BCM43340 chip, supporting Bluetooth Low Energy along with B/G/N and WiFi direct. An on-PCB antenna provides OK connectivity for a smartphone or a router in a small radius, though it's range-limited for multi-room connectivity. The use of the module's on board standard antenna connector is highly recommended. Mouser is presently stocking a few different Edison SKUs, some with the additional connector and some without.

As with most BT/WiFi combined chipsets, the controller multiplexes both signals over the same antenna, so high-bandwidth connections on both BT and Wifi might be problematic. Although I didn't test the multiplexing limits in practice, I did see reasonable performance streaming a sustained 10FPS 640x480 webcam to a web browser. One other cool feature? The Broadcom chip supports access point mode.

The Intel-supplied Yocto binary contains BlueZ 5.0, supporting all major bluetooth profiles including BLE/4.0.

Programming & Arduino Compatibility

Similar to the Galileo, Edison contains an Arduino implementation as a userland Linux program. The Intel-reengineered Arduino IDE is a collection of cross-compiler tools to upload an application to the module. This design decision to emulate Arduino is a longstanding frustration — and in my personal opinion — the most poorly designed aspect of the product. Problems stemming back to Galileo — including library compatibility, shield support, and GPIO speed weren't 'fixed' in Edison — a fact that is not surprising given the emulated implementation. Want to drive a string of WS2811 LEDs? No such luck.

As embedded Linux developers know, hardware-level programming in Linux is usually a function of writing and reading data from file descriptors known to the kernel. Any programming language capable of reading and writing to a file is capable of controlling GPIO pins along with a host of other protocols like I2C and SPI. The underlying Arduino library shipping with the IDE is a great reference for this method of programming, illustrating the support logic necessary to configure pins prior to use.

Another aspect of the platform (at launch) is programming library availability. The Yocto binary comes pre-installed with recent versions of NodeJS and Python, but there are no convenience libraries to unravel the tangle of descriptors and hardware capabilities. On the bright side, this is likely to evolve quickly given the drive of the open-source community to create accessible and easy-to-consume libraries.

Over the course of validation, my preferred prototyping experience involved performing high-level messaging and compute in Linux. What do I mean by this? The Edison excels at applications involving networking/messaging (BLE/HTTP/Websockets) and peripherals like USB cameras, audio interfaces, and MIDI controllers. In particular, NodeJS shines for this functionality on Edison. However, for hardware I/O, it's much simpler to pair Edison with an ATmega chip via UART rather than mess with the on-board I/O capabilities. Prototyping using a combination of NodeJS on Edison along with at ATmega is a solid experience. I'll buy yet another beer for the first person to port Node-Red to Edison.

Linux, Yocto, and Package Management

Yocto, which I discuss at length in a previous post about Galileo, is the Intel-funded project that helps developers build custom Linux distributions specific to their embedded devices. Using a downloadable Board Support Package (BSP), developers can customize a distro tailored to their specific application.

At its core, Yocto is targeted at experienced embedded developers. Because it's an on-demand build system and not necessarily a "distribution," package management suffers. Yocto uses okpg, a capable package manager, however Intel made the decision not to bundle a source to download pre-built binaries. Solid apt-get support for ARM is one of the critical aspects of the Raspberry Pi ecosystem: Intel just needs to be pushed in the right direction.

Furthermore, another issue is Kernel driver support. Many validation participants had issues adding components for common drivers and packages like UVC or ALSA. The most straightforward way of adding drivers, packages, and their dependencies is at Yocto build-time. Unfortunately, the lengthy and complex build process turns this situation into an relatively intractable problem for many. To encourage adoption, I strongly felt that a standard suit of drivers and packages should have been available in the quick-start OS binary. Since they are not, this will remain an open challenge for new developers on Edison.

And what about other Linux distros? Enterprising hackers have had success with Debian support on Intel Galileo. Because of the Atom core, this will likely be easier for Edison given Intel's historic support for Linux and Android on similar x86 configurations. I might predict that official support from Intel will be possible in the future, given the friendly disposition of the Debian ecosystem.

Performance & Power

The Atom Z34XX SoC used in Edison is a strong chip (running up to ~1.6Ghz), complete with 3D graphics acceleration and a USB 3.0 stack. It's not much of a surprise (given the form factor) that the SoC SKU used in the Edison is downclocked to 500Mhz with most of the smartphone features soft-disabled for power reasons. The SoC and dedicated PMIC nails power management: it doesn't heat up at all. This is a stark contrast to Galileo's 400Mhz Quark, a chip that was hot to the touch at idle.

The power specifications cited in the documentation are close to real-world performance. While these approximate numbers merit a more rigourous examination, the nominal power draw of the SoC under a moderate compute load is ~200mA (via a MiM USB monitor). When using the radio at full-bore, this figure more than than doubles to ~500mA.

And what about performance? The only benchmark I repeatedly tested was 7za b (version 9.20). Given 20 runs, the mean was a total 615 MIPS. This number can be compared against systems ranging from IoT devices to server-grade Xeons here. At a quick glance, it's roughly 2x the performance of the RPi Rev B. Based on empiric observations during the validation project, Edison provided enough cycles to accomplish audio-rate FFT along alongside low-FPS OpenCV object tracking. Strictly looking at compute, Intel is making strides in the low-power/good-performance space with Edison.

Other Interesting Features

One unique feature about Edison is an RNDIS device via the USB OTG port. A mechanical toggle controls the functionality of this connector on the Arduino breakout board: (1) as a DFU update path to flash the onboard memory with a new operating system, or (2) as a combination mass storage/RNDIS device tied to Yocto. If you are familiar with debugging applications on embedded systems, you know that FTDI/serial can be quirky at times. With an RNDIS device, a SSH connection over USB is a concrete alternative (albeit with some driver trickery on Windows and OSX).

Not to mention: it's a real x86! Galileo is frustrating because it uses an uncommon i586 instruction set. Pleasantly, software "just compiles" on Edison. No bizzare segfaults due to buggy instructions. But, does x86 really matter? Unabashedly, many charts and graphs show that Intel is playing catchup in the mobile performance-per-watt category. On the flip side, I know a guy who cuts algorithms like butter with some well-tuned SSE optimizations. Your milage might vary. At least in the Linux kernel arena, x86 development is leaps and bounds beyond the relative state of affairs in /arch/arm. The most tangible benefit is how applications and libraries compile cleanly with no additional GCC flags.

Final Thoughts

The Edison is a worthy successor to Galileo and tech-spec competitive with ARM platforms like Electric Imp and other IoT-focused chips like the CC3200. But who is the audience? Intel has been pushing hard into the maker/DIY culture. Is Edison a product for them?

Maybe. Edison feels like a product designed by engineers for engineers. The documentation is sparse and the technical guides read like integration manuals for OEMs. This is a little contrary to many of the emerging platforms in this arena whose documentation goes up on Github. While Edison is rough around the edges for Arduino hackers, Intel is, by definition, a company that builds hardware that can scale. For emerging markets that might identify with the "hardware is the new software" manta, scale is important.

Edison might hit a nice a target with volume Kickstarter projects, where Intel can provide a commitment of 1000+ units. It's certainly not a Raspberry Pi clone (nor RPi-killer), but the entire project is founded on the vision that the company is trying to help tech innovation in lower-volume markets.

To summarize my feelings working with Edison in a sentence? It might flounder a bit with makers in the UX/prototyping department (particularly re: Arduino compatibility), but the size, cost, and functionality of Edison is a clear win for serious hackers and product developers.