Chapter 7. Conclusions
It’s closing time; you don’t have to go home, but you can’t stay here.
This book is meant to be an introduction to the wide world of possibilities using Intel Edison: Linux, programming, sensors, Bluetooth, WiFi, and especially combinations of them. When all of these ideas can be fused together in one system, that’s when interesting new concepts and ideas can become reality. Intel Edison is the first true maker device that provides this possibility right out of the box.
This book is not, by any means, a comprehensive overview of every aspect of Intel Edison. The WiFi and Bluetooth alone would probably fill the book, and more text books have been written about image and audio processing than I care to count. But if you’re looking to build a cool end-to-end system incorporating all of these elements (and avoid picking up a degree in electrical engineering), this book will definitely get you started.
However, there are a few topics about which I should definitely say a few more words.
Linux Flavors
The official Intel Edison operating system, as supported by Intel, is Yocto Linux. While Yocto is a powerful operating system for embedded devices, some people find it easier to work with a fuller and more widely used Linux distribution. For this reason, the Intel Edison community worked hard to bring up Debian (aka Ubilinux) on Edison. Sparkfun has written a quite comprehensive tutorial on installing Ubilinux on Intel Edison. Note that what the tutorial says is absolutely true: you can definitely brick your Edison if you don’t follow the instructions properly. So, be warned and be diligent if you plan on installing Debian.
There are two real advantages of Debian aside from the fuller feature set of the OS itself: the much wider user community and the different package manager. A quick Google search will show you that Debian has many more users than Yocto, meaning problems will be easier to track down and debug when you run into them. But, in my opinion, the real reason to switch from Yocto to Ubilinux is the package manager.
In its most common use, Yocto Linux is built from scratch with the minimal set of dependencies necessary for a given project. This lightweight build is then flashed onto the device for use. While this keeps the distribution extremely lightweight and configurable, it necessitates a rebuild of the operating system every time a new package must be added. The rebuilds and reflashes reset your configuration changes back to the Yocto defaults, just like reflashing your Edison does. While this model works for production—you use one test system to figure out exactly what you need and then use that as the base image for all devices—it’s not exactly ideal in the maker space. As makers, we want more options and definitely less time-consuming ones.
That’s not it for Yocto, though. As you’ve seen in this book, Yocto does have the option of using opkg to manage packages instead of performing builds and rebuilds. Simply edit your configuration files to tell opkg where to find the necessary libraries and then you can pull and install them as needed. But did you ever stop to wonder where all those libraries came from? The answer is simple: they come from a single Intel employee (and a god among men), Alex T. Alex recognized that makers aren’t going to want to build and rebuild the system from scratch every time they need a new package. Instead, he built a huge set of Yocto Linux packages for Intel Edison and made them freely available online. The links you added to your base-feeds.conf file are links to his prebuilt packages. He’s the reason we were so easily able to perform all the software tasks we have in this book. Thanks Alex! I tip my hat to you.
But this does beg the question, what if Alex T. hadn’t come along? How would we have installed packages then? Do all distributions work this way, with one person holding the reigns? Obviously, the answer is no. Linux can’t work that way; it would just be too difficult. Most Linux distributions have an officially released package manager that comes prelinked to a very full and well-maintained library specific to that OS. Debian uses Ubuntu’s Advanced Packaging Tool (APT) to manage package installs and the apt-get utility for command-line calls. To say that this utility is well supported is an extreme undersell. Currently, Debian has over 43,000 supported packages. And by installing Ubilinux on your Edison, you have immediate access to all of them, for free, forever. It might be worth switching to Ubilinux if you begin a project on Yocto that requires packages that you’re not able to or are incredibly difficult to install on Yocto.
Programming Languages
Obviously, this book is quite Python-heavy for all the reasons mentioned in Chapter 4 (see “Introduction”) and also because of my own personal preference for Python. But there are other options worth exploring on Edison.
Node.js
Node is a more recent Java-based language that has accumulated a huge following in a very short period of time. According to the Node.js website, “Node.js is a platform built on Chrome’s JavaScript runtime for easily building fast, scalable network applications. Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices.”
In my opinion, Node.js is a little bit more difficult to wrap your head around than Python. The syntax of Node.js is different than a lot of other coding languages (especially Python), and the nonblocking element definitely takes a bit of getting used to. Whereas Python (and most other programming languages) moves linearly through your code, waiting until one command set is complete before executing the next (i.e., blocking), Node runs asynchronously and can execute tasks in a nonlinear fashion (i.e., nonblocking). Although this is a bit odd to think about, it’s an extremely useful architecture when dealing with distributed systems across many devices. While you’re waiting for interdevice communication, it’s very useful if the waiting doesn’t block all the other processes in the code. A great example of these sorts of distrbuted systems are web servers and real-time web applications.
If you’re planning to use your Edison to host a web service, it’s definitely worth looking into Node.js to see if it meets your needs. While there are also Python packages that can do the job, such as Flask and Tornado (which is actually asynchronous and very similar to Node.js), Node is preinstalled on Edison and might naturally be the best fit for the job. If you’d like to learn Node.js, the best way is to use Node to install a tutorial library and actively work though the examples.
The Node.js package comes with a preinstalled package manager (like Python’s pip), npm. To install the tutorial library on your Edison, simply run:
# npm install -g learnyounode
And then run the exercises in the tutorial with:
# learnyounode
The preceding example is the “Hello, World!” of Node tutorials, but many more can be found at the NodeSchool website. They cover everything from JavaScript to asyncronous I/O to using git.
C and C++
Through your Arduino programming in Chapter 3, you experienced a little bit of what C is all about. While you can program C++ code into the Arduino IDE, you can also write standalone C++ code in Linux, compile it, and then run it all natively as well. This is one of the reasons that Intel Edison is such an amazing learning tool for programming.
Some Intel-Edison-specific hardware is already supported in this fashion. For example, the SparkFun OLED block for Edison has only a standalone C++ library and no Arduino-style libraries to speak of. And although we’ve been accessing Intel’s mraa library in Python, it’s actually natively written in C, and we’re just calling it through Python bindings.
C is the required programming language for most embedded devices, and Intel Edison presents a great opportunity to learn how to use C on an embedded processor without being constrained by the memory or power of the usual embedded systems. When you get into C, you’ll notice that it’s super fast. Compiled languages just tend to be that way, making them advantageous if you’re looking for computational speed or timed actions.
While writing an introduction to C is definitely beyond the scope of a single section of a single chapter of this book, I can leave you with examples of HelloWorld in both C and C++, along with some compilation help. You’ll see immediately why I love Python so much.
For C, create a file named HelloWorld.c. Paste in the following contents:
/* Hello World program */#include<stdio.h>main(){printf("Hello World");}
Every program in C must contain a main function that is executed when the program is run. Before running, however, this code must be compiled. On Edison, you can compile C code with the following command:
# gcc InputFile.c -o OutputFileName
In this example, to compile your HelloWorld.c code into an executable program called HelloWorld, you would issue the following:
# gcc HelloWorld.c -o HelloWorld
Then, run the compiled program:
# ./HelloWorld Hello World
The C++ code follows the same general format. It must also contain a main function, except the main function must return an integer and be declared as such. The standard stdio.h library used in the C example will still work in this code, but C++ has a slightly nicer input/output library that should be used instead.
// 'Hello World!' program#include <iostream>intmain(){std::cout<<"Hello World!"<<std::endl;return0;}
Compile this code and run it. You’ll notice that the compilation call is almost exactly the same, except the compiler itself is now g++ instead of gcc:
# g++ HelloWorld.cpp -o HelloWorldCPP # ./HelloWorldCPP Hello World!
If that was fun for you, the following tutorials can take you a whole lot further:
The Intel XDK IoT Edition
Intel has developed an XDK for Galileo and Edison that wasn’t really discussed in this book. If you’re interested in playing with it, you can download and install it from the Intel website.
The main idea behind the XDK is that instead of coding directly, you can use a graphical user interface to select sensors and basic system functionality and the XDK will generate the code for you. The main reason I don’t discuss the XDK in this book is because of my own belief that learning should take you deeper into how things work. Getting into Linux, Python, circuits, and Arduino helps to do that. The XDK, on the other hand, limits you to a more shallow layer. It hides the code and the inner workings of the device behind a GUI. It makes it hard to learn.
That said, it doesn’t make it hard to prototype. Don’t be put off from playing with the XDK because it’s simple. Simple can be good. Simple can be very fast.
Shutdown Now
As you can see, there is so much more to Edison than meets the eye. It’s not an Arduino or a Galileo or a Raspberry Pi—this little module is something entirely new. So let your Edison take on its own personality and inspire your new and creative projects. Happy making!