June 13, 2016 - Phil Coval and Mats Wichmann

How to Run IoTivity on ARTIK with Yocto

Samsung ARTIK is described by its developers as an end-to-end, integrated IoT platform that transforms the process of building, launching, and managing IoT products. I first saw one a year ago at the Samsung VIPEvent 2015 in Paris, but now there is an ARTIK10 on my desk and I would like to share some of my experiences of it with you.

In this post, I will show how to build a whole GNU/Linux system using Yocto, a project that provides great flexibility in mixing and matching components and customizing an environment to support new hardware or interesting software like IoTivity. If you’re looking for Tizen support, it’s already here (check at bottom of this article), but this post will focus on a generic Linux build.

Many of the board’s features I will be covering in this article are briefly introduced in the following video:

There are 3 ARTIK models on the market: ARTIK 1 is MIPS based system with 1MB of RAM while ARTIK 5 and 10 are powerful ARM systems based on Exynos System on Module. This article covers the ARTIK 10 and it can easily be adapted to the ARTIK 5, but not the ARTIK 1.

According to the specifications, the ARTIK 10 has an 8 Core CPU (4 Cortex-A7 and 4 Cortex-A15), 2GB of RAM, and a GPU (Mali T628) for multimedia needs. Since the ARTIK family is targeted for Internet of Things use cases, there are also a lot of connectivity controllers (Wired Ethernet, Wi-Fi : IEEE802.11a/b/g/n/ac, Bluetooth 4.1 + LE, Zigbee/Thread) as well as security elements (ARM TrustZone, TEE) which are mandatory for a safe IoT.

Unboxing and Booting the ARTIK 10

In the box you’ll find 4 antennas, a micro USB cable, and power supply (5V*5A with center positive plug). Warning: some devices like Intel NUC use the same 5.5 x 2.1mm power supply barrel, but at 12V. It’s a good idea to label power supply connectors if you have a bunch lying around because plugging in 12V+ will probably brick your ARTIK.

Setup the Debug Port

Once you plug the USB cable into the ARTIK, 2 blue lights will turn on and on your host side a serial port device will appear (even if device is powered off):

As you can see the device is owned by root and belongs to the dialout group, so check if your user is in this group too (groups | grep dialout), then you can use your favorite serial terminal (minicom, picocom) or GNUscreen.

That’s it!. If you’re on Windows, enjoy this Cybercode twins’ video to learn a bit about how to get setup.

Ready For Your First Boot

Turn off the device by pressing on the left side of the “POWER SW” 2 states button. Then, connect the power supply, wait about 10 seconds, and hold the SW3 POWER switch for a couple of seconds. After this, U-Boot’s log should be printed in the terminal.

Mine came loaded with the reference system based on Fedora 22. To use this, you can login as root:root and you’ll have at least 13G free (of 16G) to work. Here is a reference file from the flashed OS on the eMMC:

Since we’ll be setting up a different operating system, I prefer to avoid touching this supported system and I’ll leave it to use as a reference to compare hardware support. The plan is to work on a removable microSD card and not change the eMMC at all.

Boot From an SD Card

Like many other SoC’s like the ODROID devices, booting from a microSD card is supported, but it requires a bit of manual intervention. You first need to configure it using micro switches “SW2” on the left, located between the debug and USB3 ports.

The switch block may be covered with tiny piece of plastic tape, remove it carefully with a toothpick and move both switches from the left (OFF) position to the right where “ON” is printed.

To try my experimental, compressed image, download demo-image-artik10-20160606081039.rootfs.artik-sdimg.qcow2 (md5:12c64d6631482f90d45a0d015bea5980) from our file server and copy to your microSD card using qemu-utils:

As you did earlier, power the device off, connect the USB cable, insert the microSD card, switch it on, wait for a few seconds, and finally hold the micro switch for a couple of seconds. U-Boot should run through its configuration and some verbose output should be printed on the serial console:

And in the end you’ll get a login prompt for root without password:

Now you are ready for the section on building your own image, but if you really want to make sure everything is working, Canonical supports ARTIK so you can use an Ubuntu snappy image. For reference, I tested artik10-snappy-20160317.img.tar.xz and it reported the following for its Kernel:

Build Your Own Image with meta-artik

First we start with Poky: the Yocto reference distro, because it’s the quickest way to reach today’s goal. As with all Yocto targets, you first need to identify a Board Support Package (BSP) layer that collects all the special software needed for this family of hardware. As far as I know there is no official Yocto layer for ARTIK.

I’ve known about meta-exynos but I also noticed the meta-artik community layer from ResinIo; they spoke about ARTIK BSP at the latest Samsung Developer Conference (SDC2016):

What really matters in this set is the u-boot-artik and linux-exynos recipes to fetch sources. So we’re going to make use of my small contribution to produce standalone bootable sdcard images in meta-artik’s master branch.
The patch adds a new class for SD card output; the black magic is that U-Boot params should be dumped to different places (0x00080e00 (1031*512) for ARTIK5 and 0x00099e00 (1231*512) for ARTIK10), if not done I’ll try to adapt this for Tizen too.

Let’s clone Poky, add the layer to your conf file, and build a regular image.

With the recipe in place, you need to tell the environment to look for it. For this, edit the bblayers.conf file from the base setup (this file will be in build/conf/ underneath your top level directory) and add a line to the BBLAYERS stanza (there’s no need to add to BBLAYERS_NON_REMOVABLE, that doesn’t apply to this build). Using the format of the base post, the line would look like this:

Then, build the image:

When this finishes, write the image to the SD card:

Adding IoTivity

IoTivity is an open source framework that enables effective device-to-device connectivity for the Internet of Things. It implements the emerging standards from the Open Connectivity Foundation (OCF was formerly known as OIC, and the specified protocols still use the oic name, as does the layer described below).

The layered approach of Yocto makes it easy to add components, as long as descriptions exist for them. Otherwise you need to write your own descriptions, which is not too hard. To add IoTivity, add the meta-oic layer:

Next, add it to previous file (./build/conf/bblayers.conf)

We also want to add some of the IoTivity packages into the built image; edit build/conf/local.conf to add these:

Finally, build it :

Like before, copy this image to the SD card and boot it up the normal way.

Trying out IoTivity

Once you have installed the example packages, you can find apps to try things out. This is probably more interesting with two machines running IoTivity, so you can have a distinct client and server device, but it is possible to run both on the same machine.

In /opt/iotivity/examples/resource/cpp/ you will see these files, which make up client/server pairs – the names are descriptive:

Start the simple server, which will emulate an OCF/OIC device, and in this case, a light:

Now start the simple client in the another shell session:

The OIC specifications describe a RESTful model of communications, where everything is modeled as resources and web-style commands are used to operate on representations of these resources, such as GET, POST, PUT, etc. The communication model is called CRUDN (Create, Retrieve, Update, Delete, Notify). In this example, the IoTivity server sets up resources to describe the (emulated) OIC device. Once the client starts, it tries to discover if there are interesting resources on the network using a multicast GET; the server responds to this with the resources it is hosting. In our example, there is a light resource and a brightlight resource (meaning the light that can have brightness controlled). At this point, the two can speak to each other with the client driving the conversation.

We can see the client getting a representation of the state of the emulated light:

It then creates a state on the server that has a power value of 15.

Next the client tries to update the light state to a value of 55:

After this, the client sets up an observe on the server so it will be notified of state changes.

The light power is updated in steps of 10, with the client reporting to via prints every time it receives a notification. A typical event looks like:

Meanwhile, we can watch the server report the requests it receives and the actions it takes. Once the light power reaches a certain level and the client sees that the last change has been observed, the connection is shut down.

This is just a basic sample of IoTivity in operation, have fun experimenting with this brand new technology for the Internet of Things! There is more to be done from this state, specifically on the connectivity domain such as adding Bluetooth, BTLE, or LPWAN, since these are what matter the most for IoTivity.

What’s Next?

We can expect that Tizen support will improve soon as it’s becoming one of the reference board.

Development Boards for Tizen IoT from Samsung Open Source Group

IoT applications have an incredibly wide range of uses; here is an example of work we’ve done within the automotive context:

Toward "OCF Automotive" profile from Samsung Open Source Group

Feedback is also welcome if you’d like us to explain anything with more depth, such as Tizen support, Tizen OBS/GBS images, or Tizen Yocto, feel free to keep in touch.

Phil Coval

About Phil Coval

Philippe has been involved with the Tizen project since 2012 when he became the co-maintainer on some of the distributions domain’s in the Common profile. He now works for the Samsung Open Source Group where he actively supports community contributions by helping others who have an interest in free software and open hardware. In particular, he is actively involved in the Tizen and IoTivity communities.

Mats Wichmann

About Mats Wichmann

Mats has been working in and around the open source world since the 1980’s. He has worked as a system developer, architect, trainer, author, consultant and engineering manager at various times. For the past 15 years he has been involved in several software-compatibility standards such as the Linux Standard Base and POSIX. These days he is working on compliance (software compatibility) programs for the Tizen mobile operating system and the Open Interconnect Consortium (Internet of Things space).

ARTIK is a registered trademark of Samsung.

Embedded Technology / Internet of Things / IoTivity / Linux ARTIK / Embedded Devices / IoT / IoTivity / SoC / Tizen / Tutorial / Yocto /

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

Comments Protected by WP-SpamShield Anti-Spam