Buzzword technology has two possible fates: they fail and disappear or they succeed and disappear. Remember at one time “multimedia” and “networking” were buzzwords. They succeeded and now they’ve vanished into ubiquity. Of course, there are plenty of failed buzzwords (like telecosm) that you probably don’t even remember. They just vanished into obscurity.
Unless you’ve been living under the CNC mill in your local hackerspace, you’ve probably heard or read about the “Internet of Things” (IoT). Companies big and small have realized that getting in early on The Next Big Thing is good for share prices and, right now, IoT is where everyone is trying to make a play.
There’s two things I’d observe, though: First, IoT is far from new. Connecting embedded systems to the Internet is old hat (I even wrote a book called Embedded Internet Design way back in 2003). Second, the way it is going, IoT–in its current incarnation–is doomed.
With the summer’s big security conferences over, now is a good time to take a look back on automotive security. With talks about attacks on Chrysler, GM and Tesla, and a whole new Car Hacking village at DEF CON, it’s becoming clear that autosec is a theme that isn’t going away.
Up until this year, the main theme of autosec has been the in-vehicle network. This is the connection between the controllers that run your engine, pulse your anti-lock brakes, fire your airbags, and play your tunes. In most vehicles, they communicate over a protocol called Controller Area Network (CAN).
An early paper on this research [PDF] was published back in 2010 by The Center for Automotive Embedded Systems Security,a joint research effort between University of California San Diego and the University of Washington. They showed a number of vulnerabilities that could be exploited with physical access to a vehicle’s networks.
A number of talks were given on in-vehicle network security, which revealed a common theme: access to the internal network gives control of the vehicle. We even had a series about it here on Hackaday.
The response from the automotive industry was a collective “yeah, we already knew that.” These networks were never designed to be secure, but focused on providing reliable, real-time data transfer between controllers. With data transfer as the main design goal, it was inevitable there would be a few interesting exploits.
For many hardware enthusiasts, it’s hard to stop imagining the possibilities of an almighty fablab in our garage — a glorious suite of machines that can make the widgets of our dreams. Over the years, many of us start to build just that, assembling marvelous workbenches for the rest of us to drool over. The question is: “how do we get there?”
Ok, let’s say we’ve got a blank garage. We might be able to pick up a couple of tools and just “roll with it,” teaching ourselves the basics as we go and learning from our mistakes. With enough endurance, we’ll wake up ten years later and realize that, among the CNC mill, lathe, o-scope, logic analyzer, and the graveyard of projects on the shelves–we’ve made it!
Image Credit: [Rupunzell] on EEVBlog
“Just rolling with it,” though, can squeeze the last bits of change out of our wallets–not to mention ten years being a long journey while flying solo the whole time. Hardware costs money. Aimless experimentation, without understanding the space of “what expectations are realistic,” can cost lots of money when things break.
These days, the internet might do a great job of bringing people together with the same interest. But how does it fare in exchanging the technical know-how that’s tied directly to tools of the trade? Can we get the same experience from a chatroom as we might from a few minutes with the local ‘CNC Whisperer’ who can tell us the ins-and-outs about tuning the machine’s PID controllers?
I’d say that we just can’t. “Getting started” in any subject often seems daunting, but we’re at a compounded disadvantage in that the gurus on the forum have some shared implicit knowledge and jargon on the subject that we wont have if we truly are taking our first steps. (Not to fear, though; none of us were born with this stuff!)
Ruling out forums for taking our first baby steps, where can we find the “seasoned gurus” to give us that founding knowledge? It’s unlikely that any coffee shop would house the local hardware guru sippin’ a joe and taking questions. Fear not, though; there are places for hackers to get their sustenance.
For years we have been graced by cheap consumer electronics that are able to be upgraded through unofficial means. Your Nintendo DS is able to run unsigned code, your old XBox was a capable server for its time, your Android smartphone can be made better with CyanogenMod, and your wireless router could be expanded far beyond what it was originally designed to do thanks to the efforts of open source firmware creators. Now, this may change. In a proposed rule from the US Federal Communications Commission, devices with radios may be required to prevent modifications to firmware.
The proposed rule only affects devices operating in the U-NII bands; the portion of the spectrum used for 5GHz WiFi, and the proposed rule only affects the radios inside these devices. Like all government regulations, the law of unintended consequences rears its ugly head, and the proposed rules effectively ban Open Source router firmware.
The rules require all relevant devices to implement software security to ensure the radios of devices operating in this band cannot be modified. Because of the economics of cheap routers, nearly every router is designed around a System on Chip – a CPU and radio in a single package. Banning the modification of one inevitably bans the modification of the other, and eliminates the possibility of installing proven Open Source firmware on any device.
Microcontrollers existed before the Arduino, and a device that anyone could program and blink an LED existed before the first Maker Faire. This might come as a surprise to some, but for others PICs and 68HC11s will remain as the first popular microcontrollers, found in everything from toys to microwave ovens.
Arduino can’t even claim its prominence as the first user-friendly microcontroller development board. This title goes to the humble Basic Stamp, a four-component board that was introduced in the early 1990s. I recently managed to get my hands on an original Basic Stamp kit. This is the teardown and introduction to the first user friendly microcontroller development boards. Consider it a walk down memory lane, showing us how far the hobbyist electronics market has come in the past twenty year, and also an insight in how far we have left to go.
Getting into FPGA design isn’t a monolithic experience. You have to figure out a toolchain, learn how to think in hardware during the design, and translate that into working Verliog. The end goal is getting your work onto an actual piece of hardware, and that’s what this post is all about.
In the previous pair of installments in this series, you built a simple Verilog demonstration consisting of an adder and a few flip flop-based circuits. The simulations work, so now it is time to put the design into a real FPGA and see if it works in the real world. The FPGA board we’ll use is the Lattice iCEstick, an inexpensive ($22) board that fits into a USB socket.
Like most vendors, Lattice lets you download free tools that will work with the iCEstick. I had planned to use them. I didn’t. If you don’t want to hear me rant about the tools, feel free to skip down to the next heading.
Although it isn’t official, Ubuntu Core–the tiny Internet of Things version of Ubuntu–now runs on the Raspberry Pi 2. There are prebuilt binaries as well as instructions for how to roll your own, if you prefer. You can even access GPIO
Ubuntu Core abandons the old-style Debian packages, in favor of Snap, a new version of the Ubuntu phone’s Click package manager. Snap offers transactional updates. The idea is that all of these “things” on the IoT need to be updated to patch security holes or fix other issues.
![Image Credit: [Rupunzell] on EEVBlog](https://hackaday.com/wp-content/uploads/2015/08/eevblogrupunzel.jpg)
