12 Comments

IMHO the biggest misstep from Intel was to give up on Edison. It was not just a SOC and not just a tinkerboard like RPI or Arduino. It was was a SOM with ROM/RAM/BT/Wifi and might have become a new standardized form factor. As such the use of the Hirose connector did not have to be a showstopper.

After giving up, they potentially missed the phone/tablet market, the IIoT market. And now, potentially may loose the datacenter as well.

It's true that initially Edison was announced as a Quark based SOM. The final version with Silvermont core and Quark MCU would have been perfect for IIoT, Linux connection to the world and RTOS on the Quark for measurement and control.

It may have been that the time was not ripe. Yocto was buggy. The kernel support was not yet upstreamed, Viper OS had no existing market.

How different it is today, PREEMPT_RT just landed for Linux, Viper has turned into Zephyr.

And the Edison support has mostly landed in the kernel, including ACPI (which is a great improvement over all the platform support needed to get Arm based boards running).

Today the support for Edison (by the community) is in quite good state building recent Yocto images with the latest linux kernels. See https://edison-fw.github.io/meta-intel-edison/.

The Edison was a brilliant thing. Today, 10 years later it would still fill a hole in the market (arguably, at a lower price point than the $50 at the time).

Expand full comment

There are some inaccuracies in the article. First of all, it's hard to compare an MCU to full-featured 64-bit microcomputer, which Intel Edison is. The resources it provides may not be beaten by poorly performant MCUs, while not consuming so much power. So, there was (still is?) a niche for it for sure. Second, is that Arduino board more likely for DIY prototyping, it definitely not meant for something real. The SparkFun baseboard is what the article missed to show. Last, but not least, Edison is supported by mainline U-Boot and Linux kernel (and Yocto) which was let's say 6 years ago not the case for the majority of the ARM-based boards (all of them require vendor specific heavily patched code).

Expand full comment

I'm not sure what comparison to an MCU you're referring to; I think it lost to other Linux SBCs, such as Raspberry Pi or Beagleboard.

The RPI and Beagleboard out-of-box experience was great. The Edison experience was bad, the out-of-the-box Yocto Linux image was fairly badly broken (I recount some of the ways at https://lcamtuf.coredump.cx/edison_fuzz/), the documentation was lacking and hard to find. Sparkfun did make a 1.8V breakout board - I still have some - but it clearly wasn't enough to save it.

Expand full comment

“…especially since it coincided with Espressif releasing a series of wi-fi microcontrollers…” these are not comparable. What I meant is that hardware was excellent, the (software) support was done in a bad way.

Expand full comment

Ah. But that's not really a comparison. It's just that Espressif cannibalized the IoT market that Intel was angling for here. It was good enough and cost 1/20th the price.

Expand full comment

Good enough for what? Again, please do not compare them. Yes, I agree that Espressif was taking quite a piece of the IoT pie, but the niche of it is different to what Intel provided.

Expand full comment

I don't want to sound impolite, but I'm not sure what you're getting at...

The niche that Intel imagined for themselves was different from Espressif, but evidently didn't really exist, at least not on the scale they hoped. Instead, every "smart" litterbox, coffee maker, and other piece of home automation started using Espressif chips that were good enough for what most of these IoT devices needed - which is simple sensor automation + wifi, not multi-core 64-bit compute.

The handful of devices that had more complex needs usually needed to drive high-resolution displays, do realtime speech processing, or similar tasks that Edison also wasn't particularly well-suited for, and where Arm cores cheaply licensed to a billion vendors and paired with all kinds of specialized peripherals proved to offer more versatility.

Expand full comment

Exactly like you put word _smart_ into double quotes they are not smart. That's what was considered as a niche for Intel, to have a device that need that power. With all that little power consumption and CPU powerfulness, it's still possible marked for chips like Intel Tangier (that's an SoC behind Edison), for example, drones where you want to have a good crunch of numbers and camera support. And as to realtime speach processing, Edison might be not suitable due to limited CPU frequency (500MHz), which you can find not limited on the motherboards with the same CPU designed for tablets (there aare 1.33GHz or 1.67GHz models).

Expand full comment

I’m speculating that Intel, remembering the IA-64 fiasco, went even harder on all its organizational pathologies with Edison. “Our mistake with IA-64 was insufficient bureaucracy; let’s have more oversight with Edison”. It’s an age-and-size sclerosis that is very common and is extremely difficult to defeat.

Expand full comment

Dig the article! Not that it's exactly related, but the dude over at The Chip Letter has a piece about how Intel's x86 moat became a prison - https://open.substack.com/pub/thechipletter/p/the-paradox-of-x86. It's apropos of very little, but it touches on some of Intel's missteps trying to compete outside the server/desktop space.

Expand full comment

> With it, died the small dream of having an expressive assembly language on embedded CPUs

I guess died for a while. I'm sure you've worked with them, but I recently started playing with the ESP32-C3, and it's fantastic, and is RISC-V. The Seeed Studio XIAO ESP32C3 form factor is great for hacking around easily.

Expand full comment

Well, CISC x86 assembly is still far more expressive than RISC-V - although to be fair, it's not necessarily more readable by the time you get to some of the wackier mnemonics like VGF2P8AFFINEINVQB. Not that it matters a whole lot either way.

Plus, ESP32-C3 still isn't beefy enough for Linux, right? It seems to be an enduring gap. There were some smaller SBCs in the later years, but I don't recall seeing anything this tiny.

Expand full comment