Intel IOT development kit content

In February, I wrote about building Yocto for Galileo gen1 , which makes development for Galileo somewhat easier. Almost a year has passed since then, and Galileo has got followers - Galileo gen2 , Edison . About Edison (already two months on sale ) it is necessary to write separately, the same post about the Intel IOT Development Kit.



From 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 was progressing, what has already happened, and what is planned.

Why do we all start this? Native (from platform creators) The Yocto build for Galileo should fit into 8 MB, and therefore uses uClibc. Even if you boot from 8GB SD-card. It is also sharpened, mainly for programming only through the Arduino IDE. However, Galileo is not only an Arduino Uno compatible motherboard, but also a computer comparable to the performance staff that was fifteen years old, but with the support of modern peripherals. Therefore, it is very logical to maximally facilitate its programming as a Linux computer with a PC and Arduino peripherals.
')
Therefore, we began by creating a Yocto 1.6 assembly , which includes the development tools, libraries, and drivers for popular peripherals. "Out of the box" can be written in C / C ++, Python, Node.JS, shell. The disk image weighs only 200 MB, but there is still a multi -gigabyte repository for opkg, from which you can install several thousand more necessary packages (If you have a sufficiently large SD-Card for the / root file system). Compared with 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 uclibc and eglibc. Unfortunately, therefore, it is impossible to reach out to any useful libraries from sketches, and I have to use IPC .

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

libmraa provides an interface to Galileo / Edison pins that can be used as GPIO, ADC, PWM, I2C, SPI, RS232. This is not a driver, everything happens in usermode (goodbye, realtime!). Like the Arduino sketches, on Galileo gen1, gen2, Edison, it works on / sys / class / * devices. That is, it would be a simple wrapper if the binding of these devices to the 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 . Support for Minnow max and Baytrail NUC will be available soon.

UPM runs on top of libmraa and implements the logic of sensors / actuators. Thus, there is no logic in the code of the sensors / actuators associated with the platform on which they operate. (Compare with Arduino, where eyes are dazzled by #ifdef UNO / DUO / TRE.) While UPM supports only forty devices, but our team with the help of the community, I hope, will write a couple of 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 normal 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 are worthy of a separate article.

Also included in the assembly is a node.js daemon and API that simplifies working with the Intel IoT analytics cloud. In general, 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 a few, and the data from the sensors connected to Galileo or Edison are easily sent to cloud for further processing. Of course, Intel IOT Analytics is now the easiest to use - it is already embedded in the IOT devkit, there are examples.

Above, I mentioned our Galileo disk image many times - part of IOT devkit. Some readers might have two questions: what other parts are there in devkit, and what about Edison?

In addition to the disk image, the opkg package repository, the cloud services IoT Analytics and Wyliodrin, we have included two things that make it easy to develop on the host (after all, it may not be entirely comfortable to develop large things directly on Galileo or even on Edison). 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, having participated in the hackathon (for example, one will be held in Moscow soon), some academic programs, or simply buy the Galileo gen1 kit or the 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 compiled a good disk image for Edison based on Yocto 1.6.1. They included libmraa and UPM in their builds and ensured compatibility with all the buns I listed above - XDK, IOT devkit, Eclipse build, IoT analytics, Wyliodrin, and Arduino IDE, compatible with all libraries on target.

During the autumn Intel Developer Forum, we opened the devkit website and forum . But Galileo and Edison already have their own website and forums , so there was some confusion. Some of the information is only on this site makers, some - only on ours, 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 could not fully understand this confusion. I hope the readers of this article will understand better than the editor of the oldest magazine for programmers.

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

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