Meet'up "Linux et Android dans les systèmes embarqués et les objets connectés"

État de l'art Android, Linux, et Tizen dans les systèmes embarqués et objets

connectés

NANTES 7/03/2017

2

WHO AM I

3

CHAINE DE VALEUR IoT

Hardware NETWORK ApplicationCloud / Service

End Device (sensor, …) Gateway

Network connectivit

y

Middleware &

platform Applicatio

n

DIGITAL / E-BUSINESSBUSINESS INFORMATION SYSTEM

INFRASTRUCTUREEMBEDDED &CONNECTED SYSTEMS

4

THINGS

embedded Linux

6

HISTORIQUE

• 1980 : RTOS (Real Time OS) génériques• 2000 : OS libres, grand public• Domaines historiques/industriels

● Militaire, spatial (RTOS/360, VRTX sur Hubble)● Contrôle de processus industriel● Transport : AUTOSAR/OSEK, ARINC 653 ● Internet/Telecom : routeurs, PABX

• 2010 « Nouveaux » domaines orientés IoT● Smart Home● Smart Cities● Industrie 4.0● E-Santé

7

OPEN SOURCE

Le logiciel libre est important dans le SI dans les année 2000

• Le logiciel libre a pris un part importante dans les systèmes embarqués /mobiles● OS (Linux, Android)● Outils de base (compilateur, éditeur, débogueur, ...)● « build systems » (Buildroot, Yocto/OE)● IDE (Eclipse)

• La plupart des éditeurs ont au catalogue des composants basés sur du logiciel libre (Wind River, Adacore, LynuxWorks, ...)

• Les plateforme IoT Open Source arrivent

8

LINUX COMME OS EMBARQUE / IoT

Réservé aux systèmes complexes● 32 bits minimum● Gestion complexe de la mémoire● Empreinte mémoire importante:● Consommation mémoire vive et d’énergie

• Temps réel ● Problème de migration de anciens RTOS car Linux n’est pas TR● Incompatible avec les systèmes critiques/certifiés● Souvent utilisé pour les outils, les simulateurs et architectures « mixtes » (banc de

test)• IoT

● N’est pas adapté pour des capteurs ● De plus en plus utilisé pour les objets intelligents / SmartHome● Gateway entre les capteurs et la plate-forme IoT● Prototypage

9

OS OPEN SOURCE POUR L’IoT

Système d’exploitation léger et flexible pour capteurs miniatures en réseau

Consommation énergétique et une empreinte mémoire minimales Support IPv6 et 6LoWPAN

Portabilité

Léger

Contraintes de mémoire

Appareils à faible consommation électrique pour l'Internet des objets

10

OS OPEN SOURCE POUR L’IoT

Système d'exploitation temps réel (RTOS) faible empreinte, portable, préemptif et Open source pour microcontrôleur

Porté sur 33 architectures Créé en 2003

Parmi les plus utilisés dans le marché des systèmes d'exploitation temps réel.

Hébergé par Linux Foundation

RTOS évolutif et optimisé optimisé pour les périphériques à ressources limitées,

Sonde Philae et Rosetta

11

OUTILS

• Yocto/OpenEmbedded● Moteur écrit en Python● Très puissant mais lourd● Basé sur des fichiers de configuration

• Buildroot● Basé sur la commande « make »● Au départ un démonstrateur pour uClibc● Désormais un véritable outil, bien maintenu !● Approche statique (pas de paquets)

13

ANDROID

Android = un système d'exploitation basé sur un noyau Linux

• Un « framework » fournissant des applications et permettant d'en ajouter facilement

• Basé sur Dalvik (puis ART), une machine virtuelle Java optimisée pour le mobile

• Navigateur web basé sur Webkit puis Chrome• Graphique optimisé en 2D ou 3D basé sur OpenGL/ES• Nouvel environnement de développement « Android Studio »

compatible avec Android « wear » et « things » • Partiellement open source mais pas réellement du logiciel

libre...

14

AVANTAGES POUR l’EMBARQUE

• Android a une interface utilisateur intuitive• IHM plus facile à développer qu’avec QT ou EFL• Possède un écosystème applicatif important et une forte

communauté• Il est nativement mobile. Android a été conçu à partir de zéro• Beaucoup de développeurs connaissent Android et Java• Les APIs facilitent le développement des applications • Les développeurs n'ont pas besoin de connaître l'architecture

sous-jacente Android, juste les API

15

INCONVENIENTS POUR l’EMBARQUE

• Google a le contrôle total sur Android• La nature monolithique d’Android rend difficile de réduire les

fonctionnalités sans casser les dépendances• Demande beaucoup de ressource mémoire• Il est plus difficile d'ajouter le support matériel• Pas réellement un projet libre ni communautaire• Inapproprié pour les périphériques avec des exigences en

temps réel• Système de « build » statique assez rudimentaire par rapport à

ceux de Linux (Buildroot, OE)

16

CONCLUSION

• Certains diront qu’Android devient une alternative viable à Linux pour l’embarqué non TR parce qu'il normalise le développement de logiciels pour de tels périphérique

• Utiliser Android quand :● Le projet nécessite une IHM● Le projet ne nécessite pas de TR dur (pour l’instant)● L’utilisation de Java est un avantage

• Attention à la dépendance / Google • Android ne peut remplacer GNU/Linux embarqué

● Développement communautaire● Support matériel● Système de construction bien plus avancé (Yocto)

17

ANDROID THINGS

Pour créer des périphériques connectés pour une grande variété d'applications grand public et industrielles.

• Android SDK et Android Studio• Google Play Services & Google Cloud• Flashable image + SDK (Developer Preview) Android Things

18

CHANGEMENTS VIS A VIS D’ANDROID

• Android Things ne nécessite pas d’écran• Prend en charge les interfaces utilisateur graphiques en utilisant

le même Toolkit qu’Android• N'inclut pas la barre d'état système ou les boutons de

navigation• Les paquets de base manquants (ContactsContract

MediaStore, Paramètres etc.)• Sous-ensemble des services Google Play disponibles• Pas d'autorisations d'exécution• Pas de notifications Changements de comportement• Pas de systeme de deploiement

19

BOARD

• Processeur Intel, ARM Cortex A7• 32 et 64 bits• MMU donc pas de microcontrôleur

Tools

21

STRATEGY DE SAMSUNG

22

TIZEN PROJECT

Tizen es un système d’exploitation

• Principalement pour le SmartHome ● Toute la gamme Samsung d’ici 2018● Arrive sur l’IoT

• Projet Open Source • Samsung principal contributeur• Basé sur GNU/Linux• Hébergé par la Linux Foundation

23

HISTORIQUE

24

CASSER LES SILOTS AVEC IoTivity

• IoTivity est un framework● communication entre objets● C/C++ library (FLOSS : Apache 2.0)

• Implémentation des standards● Open Connectivity Foundation (OCF)

• Supporté dans Tizen:3.0, Yocto, ...• Cross Platform, multi profiles & protocol agnostic

● IP, Ethernet, WiFi, Bluetooth, BLE, Zigbee, LTE...

25

MODULES POUR l’IoT ET LE CLOUD

• Cortex A Exynos5 CPU(s) et Cortex M MIPS• Ethernet, WIFI, Bluetooth, BLE, Zigbee, SigFox...

MERCI

1Extension API Android

Support matériel et extension de l'API Android

Pierre Ficheux ([email protected])

Mars 2017


Agenda

● Rappels démarrage Android● Zygote, « System Server » et les « services »● Support matériel GNU/Linux● Support matériel Android● Solution simplifiée● Solution complète (Service + HAL + SDK)● Test et exemple d'application● Démonstrations


Démarrage d'Android

● Le démarrage d'Android proche de celui d'un système GNU/Linux

– Chargement du noyau statique par le bootloader

– Détection/initialisation du matériel par le noyau

– Exécution du programme init (PID = 1)

● La suite est spécifique à Android et contenue dans system.img → /system

– Démarrage de la partie espace utilisateur par les scripts init*.rc

– Démarrage Zygote, system_server puis la JVM (Dalvik / ART)


Architecture générale


Zygote & Co

● Zygote est fils d'init# ps | grep init

root 1 0 348 216 c017be04 0000e91c S /init

# ps | grep zygote

root 93 1 458472 35880 ffffffff 4006b0e4 S zygote

● Le system_server est démarré par Zygote (startSystemServer() dans ZygoteInit.java)system 490 93 541620 33972 ffffffff 4006afc0 S system_server

● Les applications (processus) sont filles de Zygote, chacune utilisant une instance de JVMradio 620 93 474592 22684 ffffffff 4006bebc S com.android.phone

u0_a16 638 93 484500 31860 ffffffff 4006bebc S com.android.launcher

u0_a10 964 93 466912 17492 ffffffff 4006bebc S com.android.musicfx

root 986 2 0 0 c019043c 00000000 S flush-179:0

root 1025 101 820 480 c004f6cc 400a694c S /system/bin/sh


Service et « System server »

● Service = composant exécuté en tâche de fond (no GUI)● System server démarre les services Android → audio,

power, activity, window, …● Utilisation de la commande service

$ service list Found 69 services:

0 phone: [com.android.internal.telephony.ITelephony]

1 iphonesubinfo: [com.android.internal.telephony.IPhoneSubInfo] 2 simphonebook: [com.android.internal.telephony.IIccPhoneBook] 3 isms: [com.android.internal.telephony.Isms]

...

31 statusbar: [com.android.internal.statusbar.IstatusBarService]

...

● Affichage/masquage de la barre d'état en utilisant les méthodes exposées par Binder (et les codes 1 et 2) $ service call statusbar 1

Result: Parcel(00000000 '....')

$ service call statusbar 2


Architecture Android

/frameworks/base/services/java

/frameworks/base/services/jni

/hardware/libhardware/

/device/[MANUF.]/[DEVICE]

/sdk/emulator/

Noyau ou module

/frameworks/base/core/

AOSP-providedASL

Manuf.-providedManuf. license

Manuf.-providedGPL-license

Schéma K. Yaghmour

Répertoires AOSP

1

2

3

4

56


HAL


Support matériel GNU/Linux :-)

● Sous GNU/Linux le support matériel concerne uniquement le noyau

● La plupart des périphériques récents sont supportés– PCI

– USB

– I2C

– SPI

– Ethernet

– ...

● Certains bus sont accessibles par des API « user space » (USB, I2C, SPI) → simplicité

● On peut aisément ajouter un pilote externe (.ko)● Accès par un « démon » (= service), NTP + /dev/rtc


Support matériel Android :-(

● Plus complexe que sous GNU/Linux (voir schéma)● L'accès au matériel passe par « toujours » par un service

Android● Il faut définir les points suivants :

– Module noyau (identique Linux)

– Bibliothèque HAL (Hardware Abstraction Layer)

– Service Java + interface JNI (vers la HAL)

– Exposer le nouveau service en langage AIDL

– Ajouter des classes de développement (SDK modifié)

● Très peu de documentation car développement « fermé »


Approche simplifiée● Une première approche pour un nouveau matériel consiste à :

– Écrire un pilote noyau (compatible Linux)

– Accéder au pilote depuis Java par JNI (pas de HAL)● Exemple concret du capteur USB

– La température est disponible par "cat /dev/temper0"

– L'application Java affiche la valeur convertie en °C

– Autres exemples (I²C) en bibliographie

1


Ajout de service « init »

● Un service correspond à une application ou un script exécutée au démarrage

● Le code est à place dans les fichiers /init*.rcservice temper /system/bin/init_temper.sh

class main

oneshot

● Dans le cas présent – détachement/attachement du device USB (HID)

– Chargement du pilote USB

● Trace de l'initialisation# logcat -d | grep temper

I/INIT_TEMPER( 107): init_temper

● Syntaxe du init.rc dans system/core/init/readme.txt

n'est pas redémarré


Bibliothèque JNI

#define FILE_PATH "/dev/temper0"

/* Java_<package name>_<class name>_<method name> */

jstring Java_com_example_temper_MainActivity_getTemp(JNIEnv* env, jobject thiz )

{

char buf[256];

// do something like "cat /dev/temper0"

FILE *fp = fopen (FILE_PATH, "r");

memset (buf, 0, sizeof(buf));

fread (buf, 1, sizeof(buf), fp);

fclose (fp);

return (*env)->NewStringUTF(env, buf);

}

nom de la fonction Java

2


Application Java

● La bibliothèque est chargée dans la classe MainActivitystatic {

System.loadLibrary("temper");

}

● La fonction update_temp() effectue la mise à jourpublic native String getTemp();

...

void update_temp()

{

tv = (TextView)this.findViewById(R.id.textView2);

Float f = Float.parseFloat(getTemp());

// Convert driver data to °C

f = (f * 125) / 32000;

String s = String.format("%.1f °C", f);

tv.setText(s);

}

6

appel de la fonction


Approche « complète »● HAL

device/ti/beagleboneblack/temperhw

|-- Android.mk

`-- temperhw_bbb.c

hardware/libhardware/include/hardware

`-- temperhw.h

● Service/JNIframeworks/base/services/jni

|-- com_android_server_TemperService.cpp

`-- onload.cpp (M)

● Service/Javaframeworks/base/services/java/com/android/server

|-- TemperService.java

`-- SystemServer.java (M)

● Manager + expositionframeworks/base/core/java/android/os

|-- ItemperService.aidl

`-- TemperManager.java

● SDKframeworks/base/core/java/android/content

|-- Context.java (M)

frameworks/base/core/java/android/app

|-- ContextImpl.java (M)


Bibliothèque HAL

● Ajout arborescence à device/*● Ajout de l'interface (.h) à hardware/libhardware/include● Nouvelle bibliothèque conforme à la HAL● Dans le cas de l'exemple la bibliothèque se limite aux actions

suivantes :– Ouverture du fichier /dev/temper0

– Lecture de la température (fonction read())

– Fermeture du fichier

● La bibliothèque exécute les mêmes opérations qu'une commande

$ cat /dev/temper0

2


Définition du module

● Le type temperhw_device_t définit l'interface avec les couches supérieuresstruct temperhw_device_t {

struct hw_device_t common;

// device functions

int (*read)(char* buffer, int length); // read temperature

...

};

● Pointeur initialisé à l'ouverturestatic int open_temperhw (const struct hw_module_t* module, char const *name, struct hw_device_t** device)

{

struct temperhw_device_t *dev = malloc(sizeof(struct temperhw_device_t));

...

dev->read = temperhw__read;

...

return 0;

}


Code de la fonction read()

int temperhw__read (char* buffer, int length)

{

int retval, fd;

// Just like "/dev/temper0"

fd = open("/dev/temper0", O_RDONLY);

if (fd < 0) {

ALOGI("Failed to open device!\n");

return -1;

}

retval = read (fd, buffer, length);

close(fd);

return retval;

}

traces « info » (I) dans logcat


Interface JNI

● L'ajout de service est dans frameworks/base● Défini dans service/jni/com_android_server_TemperService.cpp● La table ci-dessous définit les fonctions à enregistrer

static JNINativeMethod method_table[] = {

{ "init_native", "()I", (void*)init_native },

{ "finalize_native", "(I)V", (void*)finalize_native },

{ "read_native", "(I[B)I", (void*)read_native },

{ "test_native", "(II)I", (void*)test_native},

};

● Le 2ème paramètre code les types des paramètres de la fonction (rouge) et le type de retour (bleu)

● (I[B)I → paramètres entier + tableau d'octets, retour entier

3


Principales fonctions définies

● La fonction init_native() ouvre le module HAL (.so) par :hw_get_module(TEMPERHW_HARDWARE_MODULE_ID, (hw_module_t const**)&module);

● La fonction finalize_native() libère le pointeur alloué

● La fonction read_native() appelle la fonction read() de la HALstatic int read_native(JNIEnv *env, jobject clazz, int ptr, jbyteArray buffer) {

temperhw_device_t* dev = (temperhw_device_t*)ptr;

jbyte* real_byte_array;

int length;

real_byte_array = env->GetByteArrayElements(buffer, NULL);

...

length = dev->read((char*)real_byte_array, env->GetArrayLength(buffer));

env->ReleaseByteArrayElements(buffer, real_byte_array, 0);

return length ;

} fonction définie dans libtemper.so (dépend de la cible)


Enregistrement

● Définition de la fonction d'enregistrementint register_android_server_TemperService (JNIEnv * env) {

return jniRegisterNativeMethods (env, "com/android/server/TemperService", method_table, NELEM(method_table));

};

● L'appel à la fonction s'effectue dans JNI_OnLoad() du fichier onload.cpp


Code Java du service● Localisé sur service/java/com/android/server/TemperService.java● Le constructeur appelle init_native()

public class TemperService extends ITemperService.Stub {

...

public TemperService(Context context) {

super();

mContext = context;

mNativePointer = init_native();

}

};

● La fonction Java read() appelle read_native()public String read(int maxLength) {

int length; byte[] buffer = new byte[maxLength];

length = read_native(mNativePointer, buffer);

return new String(buffer, 0, length);

}

● Ajout du nouveau service à la fonction run() de SystemServer.java

4


Exposition des fonctions (AIDL)

● AIDL = Android Interface Description Language● Déclaration des fonctions du nouveau service pour

utilisation par Binder (IPC Android)● Ajout du nouveau service par os/ItemperService.aidl

interface ItemperService {

/**

* {@hide}

*/

String read (int maxLength);

}

● Le code est produit par l'utilitaire aidl


SDK

● Ajout des nouvelles classes au SDK● Utilise un « manager » pour accéder au service (Power

Manager, Activity Manager, etc.)– Interface dans content/Context.java

– Implémentation dans app/ContextImpl.java

● Accès par la fonction getSystemService()mTemperManager = (TemperManager) this.getSystemService (Context.TEMPER_SERVICE);

5


Compilation AOSP

● On doit compiler l'image cible et le SDK● Pour l'image, résultat dans out/target/product

$ cd work_43

$ source build/envsetup.sh

$ lunch 18

$ make update-api

$ make

● Pour le SDK, résultat dans out/host/linux-x86/sdk$ lunch sdk-eng

$ make

produit frameworks/base/api/current.txt


Test du nouveau service

● Vérification de la présence du service$ service list | grep temper

7 temper: [android.os.ITemperService]

● Création du fichier (simulation)# echo 8888 > /dev/temper0 ; chmod 666 /dev/temper0

● Test de dialogue Binder avec la commande service$ service call temper 1

Result: Parcel(00000000 00000000 00000000 '............')

● Traces « logcat »$ adb logcat | grep temper

I/temperhw_bbb( 275): Temper HW - read() for 0 bytes called

I/temperhw_bbb( 275): Temper HW - read() = 0


Application

● On déclare une variable de type TemperManagerimport android.os.TemperManager; // Added class

public class HelloTemperInternalActivity extends Activity {

...

TemperManager mTemperManager;

}

● Nouvelle fonction update_temp() void update_temp() {

Float f = 0.0f;

String s;

tv = (TextView)this.findViewById(R.id.textView2);

try {

f = Float.parseFloat (mTemperManager.read (20)); // Get temp from service

f = (f * 125) / 32000; // Convert to °C

s = String.format ("%.1f °C", f);

tv.setText(s); // update TextView

} catch (Exception e) { … }

}

6


Conclusions

● Méthode utilisable pour toute extension matérielle...et plus →

A-Industrial-OSP ?● Ajout d'un service « tâche périodique » pour un Android/RT

(noyau Xenomai)import android.os.SquareSignalManager;

m = (SquareSignalManager)this.getSystemService(Context.SQUARESIGNAL_SERVICE);

m.send(frequency);


Références● http://www.opersys.com/blog/extending-android-hal● http://www.vogella.com/tutorials/AndroidServices/article.html#service_overview● http://fr.slideshare.net/opersys/understanding-the-android-system-server● http://www.linuxembedded.fr/2014/12/investigation-android-temps-reel● https://source.android.com/devices/sensors/hal-interface.html● http://anatomyofandroid.com/?s=system+server● http://fr.slideshare.net/opersys/understanding-the-android-system-server● http://androidxref.com/4.3_r2.1/xref/frameworks/base/core/java/com/android/internal/os/ZygoteInit.java● http://developer.android.com/guide/components/aidl.html● http://elinux.org/Android_Binder● http://www.2net.co.uk/tutorial/android-4.3-beaglebone-fastboot● Article « Extension de l'API Android » dans OpenSilicium #14● Article « AOSP pour BeagleBone Black » dans OpenSilicium #14● http://www.possamai.it/android-i2c● http://boundarydevices.com/i2c-tools-under-android

http://www.opersys.com/blog/extending-android-hal

http://www.vogella.com/tutorials/AndroidServices/article.html#service_overview

http://elinux.org/Android_Binder

http://www.2net.co.uk/tutorial/android-4.3-beaglebone-fastboot

http://www.possamai.it/android-i2c

1Prototyping IoT with Yocto

Prototyping IoT with

Pierre Ficheux ([email protected])

03/2017


$ whoami

● French embedded Linux developer, writer and teacher● CTO @ Smile-ECS (Embedded & Connected Systems)


2 kinds of objects

● Basic one such as sensor– MCU/µC (no MMU)

– Software is « bare metal » or light OS such as Contiki or RIOT

● Advanced one (computer like)– CPU with MMU (32 bits or more)

– OS such as Linux / Tizen / Android

Parrot flower power (µC)

Eccelenza touch (Yocto)“Tesla car is a connected computer on wheels !”


Linux and IoT

● Not “the” universal OS for IoT but...● According to “IoT developer Survey 2016”

– 73 % Linux

– 23 % « bare metal » (no OS)

– 12 % FreeRTOS

– 6 % Contiki

● Don't forget there are and

– Distribution (Debian, Ubuntu, etc.)

– « Build system » (Yocto, Buildroot, etc.)

● Today most of objects are computers


Linux distribution

● Most of developers use Linux distribution● Well known, comfortable and portable environment but

– High footprint (Go)

– boot time (close to 1 mn)

– Development oriented → host but not a target

– No traceability (binaries)

– Limited target support (x86, ARM)

– Not for IoT at all !!

● Most distributions runs on ARM → easy to take a wrong way

● Alternate – and right - way is « build system » !


What is a « build system » ?

● Not a distribution, just a tool to build one from sources● Does not provide sources but “recipes” ● Provides binaries file to be installed on the target

– Bootloader

– Linux kernel and DT blobs

– Root-filesystem image + applications

● Provides additional information– Licensing

– Dependencies graphs

● Much better footprint, boot time, etc.● Android uses a dedicated – but open source - build

systems


Most famous build systems

● Yocto/OpenEmbedded– Based on “BitBake” (Python)

– Very powerful, not that easy to learn

– Text oriented

● Buildroot– Based on standard GNU Make

– Started as an internal tool for uClibc

– Static approach (no packages)

● OpenWrt– Modified Buildroot

– Packaging support

– Used for WeIO (IoT device)


Buildroot

● Formerly internal tool for uClibc● One version every 3 months since 2009.02● Kernel like graphical configurator● Fast and easy to use● Result is not a distribution but a “Linux firmware”


OpenEmbedded

● A “cross compilation framework”● Started Chris Larson, Michael Lauer et Holger Schuring

for “OpenZaurus” (2002)● Zaurus (SHARP) was the “first” Linux/Qt PDA


OE principles

● Recipe is a .bb (for BitBake) file for every component (from “Hello World” to whole distribution)

● OE uses classes (.bbclass), headers (.inc) and configuration files (.conf)

● You can inherit from class with inherit● “Deriving” a recipe is VERY useful → .bbappend● Files are organized as “layers” → meta-*● OE data flow is based on packages (RPM, IPK, DEB)● Package management on target is optional


Yocto / OE

● Yocto (symbol y) is a unit prefix in the metric system denoting a factor of 10-24

● Yocto project was started in 2010 by Linux foundation● Sub-projects integration (OE, BitBake, Poky, etc.)● Currently most of embedded companies and hardware

makers are members (Intel, Montavista, NXP, TI, etc.)● Richard Purdie (Linux Foundation fellow) is the

architect● Most of Linux BSP are provided as OE layers !


Yocto / OE workflow


Yocto / OE layers

IoT layer


Yocto/Poky « in a nutshell »

● Installing Poky and BSP$ git clone -b krogoth git://git.yoctoproject.org/poky

$ cd poky

$ git clone git://git.yoctoproject.org/meta-raspberrypi

● Creating working directory$ source oe-init-build-env rpi-build

● Adding BSP layer to conf/bblayers.conf$ bitbake-layers add-layer meta-raspberrypi

● Adding target name to conf/local.confMACHINE = "raspberrypi"

● Creating minimal image$ bitbake core-image-minimal

● Testing on SD card$ sudo dd if=<path>/core-image-minimal-raspberrypi.rpi-sdimg of=/dev/sdb


Use case 1 : IoT sensor

● Building a demo sensor for Smile– Raspberry Pi (zero)

– I²C temperature/pressure sensor (MPL115A2)

– Wi-Fi (USB)

– HTTP protocol


Demonstrator (global architecture)

sensor


Building distribution

● Starting from smaller distro « core-image-minimal »● Adding options and new recipes

– Package management

– Standard or “derivated” recipes

– New recipes (I²C sensor control)

● Put everything in a new layer → meta-iot$ yocto-layer create iot

● Updating local.conf (for test only)● Creating a new distro recipe → « rpi-iot-image »


Using .bbappend (derivation)

● One recipe (.bb) is defined in layer “A”● We update recipe in a .bbappend located in layer “B”● Currently

– Network configuration (Wi-Fi + HTTPd)

– I²C activation in config.txt

– Autoload of i2c-dev module


Wi-Fi + HTTPd

● Wi-Fi adapter is supported → wlan0● We need some additional packages (Wi-Fi management +

HTTP server=IMAGE_INSTALL_append += "iw wpa_supplicant lighttpd"

● Updating /etc/network/interfaces for wlan0 automatic configuration

● WPA authentication (manual procedure for test)# wpa_passphrase <ESSID> <password> > /etc/wpa_supplicant.conf

# ifdown wlan0

# ifup wlan0


Sensor + I²C

● Updating config.txtdtparam=i2c_arm=on

→ do_deploy_append() ● Adding packages to local.conf

IMAGE_INSTALL_append += "i2c-tools kernel-modules"

● Loading I²C supportKERNEL_MODULE_AUTOLOAD += "i2c-dev"

→ Kernel .bbappend● New recipe for MPL115A2 control

– Adapting original program (C, based on WiringPi)

– Starting a “service”, reading sensor every 20 secs → using update-rc.d class


NTP support

● No RTC on Raspberry Pi● NTP recipe provided by meta-openembedded layer

$ cd poky

$ git clone git://git.openembedded.org/meta-openembedded

$ git checkout <yocto-branch>

$ bitbake-layers add-layer ../meta-openembedded/meta-oe

$ bitbake-layers add-layer ../meta-openembedded/meta-python

$ bitbake-layers add-layer ../meta-openembedded/meta-networking

$ bitbake ntp tzdata

● Configuring timezone# rm -f /etc/localtime

# ln -s /usr/share/zoneinfo/Europe/Paris /etc/localtime

# cat /etc/default/ntpdate

...

NTPSERVERS="pool.ntp.org"


Updading target

● SMART included by package management● Creating packages index

$ bitbake package-index

● Creating HTTP channels on the target# smart channel --add <channel> baseurl=http://<pkg-dir>

# smart update

# smart install ntpdate tzdata


Use case 2 : Border router (N. Aguirre)

● More complex demonstration based on sensorTag (TI)● Raspberry Pi (Yocto 2.1 based) as “border router”


SensorTag

● Cortex M3 (48MHz, 128KB flash, 8KB RAM)● 512KB external flash for OTA and/or storage● Low-power (10 mA active, 100 uA sleeping)● Radio802.15.4 + Bluetooth Low Energy (BLE)● $ 30 from TI website


Raspberry Pi + 6LBR

● 6LBR est a board router software (between IoT/sensors world and Internet world)

● Get data from SensorTags (6LoWPAN)● Send data to the “cloud”● MQTT broker● Time Series (Influxdb) database● MQTT / database connector (Telegraf)● Web management and display (Grafana)


Grafana display


Références

● http://elinux.org/Build_Systems● https://www.yoctoproject.org/● http://buildroot.uclibc.org● http://iot.ieee.org/images/files/pdf/iot-developer-survey-2016-report-final.pdf● https://openwrt.org● http://eccellenzatouchvki.com● http://www.parrot.com/fr/produits/flower-power● https://www.yoctoproject.org/ecosystem/iot● http://we-io.net/hardware● https://github.com/nodesign/weioBoard● https://www.raspberrypi.org/documentation/hardware/raspberrypi/schematics/README.md● http://www.ti.com/ww/en/wireless_connectivity/sensortag2015

http://elinux.org/Build_Systems

https://www.yoctoproject.org/

http://buildroot.uclibc.org/

http://iot.ieee.org/images/files/pdf/iot-developer-survey-2016-report-final.pdf

https://openwrt.org/

http://eccellenzatouchvki.com/

http://www.parrot.com/fr/produits/flower-power

https://www.yoctoproject.org/ecosystem/iot

http://we-io.net/hardware

https://github.com/nodesign/weioBoard

https://www.raspberrypi.org/documentation/hardware/raspberrypi/schematics/README.md

http://www.ti.com/ww/en/wireless_connectivity/sensortag2015