We're Giving Away 10 Intel®Edison Kits for Arduino - Review

Table of contents

RoadTest: We're Giving Away 10 Intel®Edison Kits for Arduino

Author: lcard

Creation date: 9 Jul 2016

Evaluation Type: Evaluation Boards

Did you receive all parts the manufacturer stated would be included in the package?: True

What other parts do you consider comparable to this product?: RPi, Beaglebone, Odroid, Arduino.

What were the biggest problems encountered?: Early versions of the update tools did not perform. They have since been corrected and improved. The platform specifications are not entirely overwhelming given the price, but Edison still has many great features.

Detailed Review:

I confess: My low-powered SCADA remote project is incomplete. I decided it was more important to write the RoadTest review than fully deliver the software and project I envisioned. I have managed to work with Edison enough to have a good feel for what the platform delivers and that's ultimately what I think our community members want to hear about. The incomplete state of my project is entirely of my own doing and not due to any shortcomings of the Edison platform.

To summarize my experience thus far working with Edison: This is a solid Unix host in a package the size of a book of matches. You can SSH to it and quickly feel right at home. gcc is there. make (and cmake) is there. The mraa library gives easy access to hardware interfaces. All the source examples that I tried compiled and ran without incident. Missing software packages can be added with a minimum of effort. Intel has clearly gone to lengths to make this a development platform that supports a broad set of development models. They are actively developing support and documentation material for Edison. I have not (yet) taken full advantage of the tools an development environments available for the platform. This link shows four different development modes directly supported by the platform out of the box. I chose a fifth and am managing perfectly fine.

I was really just looking for a system hosting a C99 compiler and a basic development environment. My development mode is to edit compile run using nano, gcc, make, git over an ssh connection. I had to download compile and install gnu screen, which took a 'wget', 'configure' and 'make install'. (Whew.)

I am working to develop a low-powered SCADA remote for this project. As I mentioned, this effort is not yet feature complete. I have connected a pair of Analog Devices TMP36 temperature sensors to two analog inputs. I connected at solid-state relay to a PWM output pin. The relay switches a 40w light bulb which acts as a heater to control the temperature measured by one of the temperature sensors. If I put the inverted pail (shown in the top of the image) on top of the setup I can create a temperature-controlled environment where the heat from the lightbulb can be monitored by one of the TMP36 sensors and controlled with the PWM output. I can hear you now - "Good job. You have used to Edison to perform a task that has been reliably filled for decades by a thermostat's a bi-metallic strip." This is true, but the project has broader scope and goals. 

My concept is to have a service present a MODBUS address space over Edison's WiFi interface that maps back to an sqlite3 database table. I'm part way through this portion. libmodbus compiles and all its test applications run fine. I've managed to mangle one of libmodbus's example programs to read and write data for a MODBUS address map from an sqlite3 table. (There's still of couple of quirks I need to iron out before sharing this.) One interesting thing I found - Intel's Edison distribution includes sqlite3 libraries by default, but not the command-line sqlite3 monitor program. Not a big deal - the pre-compiled sqlite3 tools for linux/x86 run directly on Edison. You don't even need to compile. A convenient aspect of working on x86.

The other part of this project was to have an sqlite3 database configuration define a setup for discrete and analog input and outputs mapped back to the same sqlite3 table which is in turn mapped out  and shared by the MODBUS service. I'm working to have the database model define PID loops with their status and configuration are also mapped to the MODBUS service interface. I have a test program that holds temperature using (my interpretation of) a PID loop. My PID process can hold the temperature in my pail within a fraction of a degree. This pid controller program will read configuration from an sqlite configuration table, and write its status to the modbus mapping table. If I get his right, it will be able map more than one PID control to Edison's inputs and outputs, and give each PID loop separate process threads limited only by the number inputs and outputs on the Edison. This is all a matter of me finding enough time to develop and debug my project. Edison is helping me along the way.

A third leg of this project will be to add PID setpoint schedules to the sqlite database. (Such sophistication starts to differentiate us from that bi-metallic strip.) At some point I would like to develop an interface for model configuration using libmicrohttpd. This would enable the configuration database to be set up using a browser rather than ssh and sqlite3 to edit tables.

One early speed bump I encountered, working with Edison board on OSX was the update and configuration tool simply didn't work. The tool is supposed to automagically download the latest Yocto image from Intel and flash the Edison device connected over USB. When I first tried the tool it downloaded the Yocto distribution image, but then the tool froze. Further digging led me to an Intel "Phone Flash Tool Lite" download. This tool also failed to update my Edison. (References to the Phone Flash Tool Lite have now been removed from the Edison documentation.) Eventually I found the 'flashall.sh' script in the Yocto distribution archive. Unfortunately it's written assuming if you're using OSX that you also use Homebrew. (MacPorts FTW.) With my humble experience in Bourne shell scripting I was able to mangle the script to work without OSX Homebrew tools. These earlier tools were a mild frustration to me and it did give me some pause about the platform for less experienced tinkerers. I have since noticed Intel is actively working to maintain and develop Edison support tools and documentation. I have since re-tried their comprehensive update tool and found it to work with Edison from OSX without issue. I'm glad for this progress.

The Linux kernel version included in the latest Edison Yocto image is 3.10.17. The 3.10 kernel was released June 2013. The latest stable linux Kernel is 4.6.4 and there are six other newer kernels designated for long term support. I admit I don't closely track the features and functionality added to to the kernel. I don't know what's gone in since 3.10.17, and there's no functionality missing from the Yocto image that I'm looking for. Its just a number but 3.10 is a bit stale and I would feel better about Edison if the kernel was more recent. (My Beaglebones, for example, are running kernel 4.6.3.)

In final summary - I like the Intel Edison. This is an easy platform to develop for. Their development tools let you progress from writing Arduino sketches to rolling eventually your own Yocto distribution with several development modes in between. There is good sensor library support. Intel is actively supporting this platform. The cost of a dev board is a bit higher than some kits, but not unreasonable considering what you get.

Update July 28, 2016:

A couple of weeks ago I felt bad to submit a RoadTest Review without working code. At the time of writing I had half-working but misbehaving software which used a sqlite database file for a data store. As it turns out I was including header files from one version of libmodbus and linking to libs from another. (As you might guess that doesn't work very well.) Anyway during my development I re-examined my concept to rethink what I really needed and wanted. Sqlite configurable mapping of IO to modbus addresses is a nice idea but maybe overkill for what I'm trying to accomplish. The included PID controls were fun but I "streamlined" them too.

My current concept is just to bring out and expose all the Edison GPIO, PWM, and AIO directly out to a modbus network interface. It's now compile-time configurable (only), which is good enough for me, for now. This is simpler and now that I have my linking issue resolved actually works too. I'm a bit lazy here and put everything in one source file. Carrying this project forward it could/should be broken out into multiple source an header files. For now I'll claim I left it this way to make it simpler and less intimidating for others to compile. I put together a simple makefile because 'make' and 'make clean' are easy to type. (Wisdom of the ages.) My modbus_service source is hosted on Github.

I am perhaps vain to imagine anyone else might want to compile and run this. In case you do, you may also be interested in a modbus command line tool I wrote for testing. Be warned: I also tried to validate my modbus service using some pymodbus scriptage but it didn't work. (I may have some reading to do to better understand twisted python.)

I haven't decided where to take this next. I think I'd like to take a current measurements with my multi-meter to get an idea of just how low-powered Edison is running this simple software. I noticed the Intel Yocto images seem to be running a lot of stuff. There 's probably a fair amount of software that does not need to be part of the image for my needs. I've started reading about bitbake and am wondering about trying to customize software images for Edison. My initial review of the bitbake documentation suggests it is non-trivial. Wish me luck here.

Thanks again to element14Dave for supporting this little project.

-Loren