Intel IOT development kit content

In February, I wrote about the Yocto build for Galileo gen1 , which makes development a bit easier for Galileo. Almost a year has passed since then, and Galileo began to have followers - Galileo gen2 , Edison . About Edison (already two months on sale ), you need to write separately, the same post about Intel IOT Development Kit.



Of the glands on my desktop (sorry for the mess), it is compatible with Galileo gen1, gen2 and Edison.
From December 2013 to October 2014 I was the architect of this product, and now I will describe how the project progressed, what has already happened, and what is planned.

Why did we all start this? The native (from the creators of the platform) Yocto build for Galileo should fit in 8 MB, and therefore uses uClibc. Even if booting from an 8GB SD-card. Also, it is sharpened, mainly for programming only through the Arduino IDE. However, Galileo is not only an Arduino Uno compatible board, but also a computer, comparable to the staff of fifteen years ago in performance, but with support for modern peripherals. Therefore, it is very logical to maximally facilitate its programming as a Linux computer with PC and Arduino peripherals.

Therefore, we started by creating the Yocto 1.6 build , which includes development tools, libraries, and drivers from popular peripherals. Out of the box you can write in C / C ++, Python, Node.JS, shell. Disk imageit weighs only 200 MB, but there is still a multi -gigabyte repository for opkg from which you can install several thousand more packages you need (if you have a large enough SD-Card for the / root file system). Compared to the February alpha, the current build loads 3 times faster, despite a bunch of new services in the download. And just systemd instead of sysvinit.

In order to maintain compatibility with the Arduino IDE, the disk image includes both uclibc and eglibc. Unfortunately, therefore, it’s impossible to get any useful libraries out of sketches, and you have to use IPC .

If there are enough libraries for the periphery of the PC, then for most simple and cheap sensors / actuators there are only Arduino or mbed libraries. They would have to be ported, as there is a lot of platform-specific code in the drivers for advanced sensors. So we decided to invent a bicycle, and published on Github two completely open projects with a MIT license - libmraa and UPM . libmraa is written in C, and UPM in C ++ (native C ++ aka C with classes). They both generate libraries when building, which can be used when programming in Python and Node.JS.

libmraa provides an interface to Galileo / Edison pins, which can be used as GPIO, ADC, PWM, I2C, SPI, RS232. This is not a driver, everything happens in usermode (goodbye, realtime!). Like Arduino sketches, on Galileo gen1, gen2, Edison, it runs on top of / sys / class / * devices. That is, it would be a simple wrapper if the binding of these devices to Arduino pins was monotonous and trivial. Unfortunately, each of these platforms has its own characteristics and limitations in the field of input-output. For example, you can read more about Galileo gen2 here . Minnow max and Baytrail NUC support coming soon.

UPM runs on top of libmraa and implements sensor / actuator logic. Thus, in the sensor / actuator code, there is no logic related to the platform on which they operate. (Compare with Arduino, where #ifdef UNO / DUO / TRE is eyeballs.) UPM supports only forty devices so far, but our team with the help of the community, I hope, will write a couple hundred more in a year.

In addition to the usual programming tools, the IOT devkit disk image for Intel Galileo also contains one not quite ordinary one. Romanian startup Wyliodrin has developed a Blockly-based programming environment that facilitates graphical programming of sensors / actuators on Intel Galileo, Edison, and Raspberry Pi. The guys from Wyliodrin and their special offer for Intel Galileo owners deserve a separate article.

The assembly also includes a node.js daemon and an API that simplifies working with Intel IoT analytics cloud. In general, the cloud backend for IoT is now a terribly fashionable topic, and many well-known vendors have already announced (Azure Intelligent Systems Service) or released their own version. I tested several, and data from sensors connected to Galileo or Edison is easily sent to cloud for further processing. Of course, Intel IOT Analytics is now the easiest to use - it is already built into IOT devkit, there are examples.

I have mentioned our disk image for Galileo many times, part of the IOT devkit. Some readers might have two questions: what other parts does devkit have, and what about Edison?

In addition to the disk image, the opkg package repository, the IoT Analytics and Wyliodrin cloud services, we included two things that make it easier to develop on the host (still, developing large things directly on Galileo or even Edison may not be very comfortable). IOT devkit supports Intel XDK for development on Node.JS and a special Eclipse build for Linux, Windows and Mac OS, configured as a host for C / C ++ development.

In addition, IOT devkit can be obtained in tangible form by participating in a hackathon (for example, one will be held in Moscow soon ), some academic programs, or simply buying a Galileo gen1 kit or gen2 kit .

Regarding the second question, everything is simple: the team that created the Edison platform was not limited by the need to use uClibc, and put together a good disk image for Edison based on Yocto 1.6.1. They included libmraa and UPM in their assembly and provided compatibility with all the goodies that I listed above - XDK, IOT devkit build Eclipse, IoT analytics, Wyliodrin, and Arduino IDE, compatible with all libraries on the target.

During the autumn Intel Developer Forum, we opened the devkit site and forum . But Galileo and Edison already have their own site and forums , so there was some confusion. Some of the information is available only on this site of makers, some is only on our website, and some are duplicated. For example, recently they wrote about devkit in Dr Dobbs, but it seemed to me that the author of the article was not able to fully understand this confusion. I hope that readers of this article will understand better than the editor of the oldest magazine for programmers.

On the site, we posted a disk image and Eclipse IDE for download and called it all IOT devkit 1.1 beta. Beta because we only had one part time QA engineer in our team (but we all ate our dog food ourselves, so the obvious bugs were swept away). In a couple of months, we plan to get rid of the insulting word “beta” by correcting all the bugs along the way, adding support for new interesting sensors, adding a wizard to the Eclipse IDE to create new projects, and taking into account tons of wishes of the hackathon participants.

Themes for the flame in the comments, which the author will be especially pleased to support:
1. Who needs your Yocto, you had to port Ubuntu / Debian / Gentoo / Slackware!
2. Why there are so many options / programming languages ​​/ IDE, you had to leave one thing, but to do it well.
3. Why did you switch to systemd, on an embedded platform everything should be in easily editable shell scripts.
4. Why not right out of the box Java / Mono / Haskell / Brainf * & ck?
5. My DHT22 X sensor does not work , which needs to send microsecond pulses to exact time periods - and Arduino Uno can do this.
6. I made a pull request in UPM, adding support for my favorite soil moisture sensor in a flower pot, but the evil github user arfoll does not commit.
7. Well, and what is better than RasPi / BBB / etc / etc / etc? "
8.Carthago delenda est Why, even in Quark, they did not abandon the outdated set of x86 instructions, you give one more RISC microcontroller!