Présentation générale

Description

Le but de ce projet est d’effectuer le portage du système d’exploitation RIOT-OS pour le microcontrôleur CC430 dans l’optique IoT. L’IoT, ou en français « Internet des Objets », est en quelque sorte l’extension d’Internet aux objets du quotidien et aux personne. Avec l’IoT, il ne s’agit plus de connecté via Internet seulement des serveurs et des ordinateurs, mais aussi des montres, des caméra, des feux de signalisation ou des capteurs en tout genre. RIOT-OS est un système d’exploitation destiné aux objets connectés, avec comme préoccupation principale une consommation minimale en mémoire et en puissance. C’est un OS OpenSource communautaire dont le site est le suivant : https://riot-os.org/. RIOT-OS a une organisation en module, avec des modules indépendants du hardware utilisé se reposant sur des modules dépendant du hardware utilisé, c’est-à-dire qu’il n’est pas nécessaire de réécrire tout l’OS pour l’adapter au microcontrôleur voulu, seulement les modules dépendant du hardware. Il est possible d’émuler le fonctionnement d’une application utilisant RIOT-OS sur un ordinateur, permettant de tester l’application développer sans les inconvénients du hardware. Le principal intérêt de cette fonctionnalité est de vérifier la viabilité d’une application avant de commencer le portage sur la cible voulue.

Le CC430 est une famille de microcontrôleur de la marque Texas Instrument, intégrant un microprocesseur MSP430 et un module radio CC1101. La famille MSP430 est une famille de microcontrôleur très utilisé dans le domaine professionnel. Le module radio CC1101 est un module radio conçu pour des applications embarquées à basse consommation, aussi de la marque Texas Instrument.

Objectifs

Les objectifs de ce projets sont :

Rendre compatible RIOT-OS avec le CC430
Permettre la communication par radio entre deux CC430 ayant RIOT-OS d'installé

Analyse du projet

Positionnement par rapport à l'existant

Il existe de nombreux OS pour l’embarqué et les systèmes connectés (Contiki, FreeRTOS, Linux, Windows For IOT…). Chaque Système d’Exploitation possède ses intérêts et ses défauts. Notre objectif est l’IoT, donc les objets connectés et les réseaux de capteurs. De plus, RIOT-OS est open source, nous allons donc comparer notre projet face à d’autres OS open source visant les objets connectés qui supportent les MSP430, donc proche du CC430.

Analyse du premier concurrent : FreeRTOS

FreeRTOS est l’un des OS les plus populaire du monde de l’embarqué. Très simple à prendre en main avec très peu de fichiers .C, il est disponible pour de très nombreuses plateforme. Les sources de cet OS sont disponible sur leur site https://www.freertos.org/. La plus grande force de FreeRTOS est sa simplicité d’utilisation, en effet, il n’y a qu’un seul fichier source à modifier pour rendre l’OS compatible avec n’importe quelle plateforme supportée. En revanche, FreeRTOS occupe « beaucoup » d’espace en mémoire, avec en moyenne 4kB d’utilisation de RAM et 9kB d’utilisation de ROM, comparé à respectivement 1.5kB de Ram et 5kB de ROM pour RIOT. De plus, dans une optique IoT, FreeRTOS ne supporte que les protocoles TCP, UDP et Ethernet pour la communication par Internet, tandis que RIOT, bien que ne supportant pas Ethernet, supporte TCP, UDP et surtout CoAP, un protocole de transmission d’information via Web optimisé pour les réseaux contraints sans fil. Enfin, il n’est possible que de développer en C sur FreeRTOS, alors que RIOT laisse le choix entre C et C++, permettant l’utilisation de plus bibliothèques.

Analyse du second concurrent : Contiki

Contiki est un OS ayant pour cible des petits microcontrôleurs à faibles cout et faible consommation pour l’IoT. Le site de Contiki est le suivant : http://www.contiki-os.org/. Contiki a été pensé pour les réseaux de capteurs et implémente plusieurs standards et protocoles de communications sans fils et Internet, tel que IPv4 et IPv6, 6loWPAN, RPL ou encore CoAP. Les principales forces de Contiki sont l’importance de la gestion de l’énergie des microcontrôleurs sur lequel il est porté et son émulateur Cooja permettant de simuler des réseaux Contiki et vérifier le bon fonctionnement de l’application développée. En revanche, tout comme FreeRTOS, Contiki est gourmand en mémoire RAM et ROM, nécessitant environ 2kB de RAM et 30kB de ROM. De plus, contrairement à RIOT-OS, les capacités temps réel de Contiki sont limitées, son scheduler est basé sur un algorithme coopératif et non préemptif comme c’est le cas pour RIOT-OS.

Scénario d'usage du produit ou du concept envisagé

Carrie F. est développeuse de systèmes embarqués et doit mettre en place réseau de capteurs afin de mesurer la pollution d’une zone sensible, une usine, une ville, une zone contaminée tel que Tchernobyl, dont les données doivent être transmises à un serveur de manière sécurisé. Elle n'a pas beaucoup de temps et doit choisir un produit lui permettant de réaliser son projet dans le temps qui lui est attribué. Elle fait le choix du CC430 qui est un microcontrôleur possédant nativement des capacités de communications sans fil. Afin de mettre en place rapidement son réseau de capteur, elle a besoin d'un OS pret à l'emploi. La combinaison RIOT-OS-CC430 permettrait de répondre à toutes les problématiques. En effet, à la fois le MSP430 intégré dans le CC430 et RIOT-OS offrent des solutions afin de sécuriser à la fois les transmissions ET le capteur, permettent une communication sans fils via Internet, et RIOT-OS étant axé sur l’économie d’énergie, permet de faire fonctionner plus longtemps les capteurs sur batterie, permettant de soit palier à un défaut d’alimentation, voir de ne dépendre que du soleil afin de s’alimenter.

Réponse à la question difficile

La question difficile était : "Sur quel microcontrôleur de la famille des MSP430 le port doit-il être fait?". Après discussion, il s'est avéré que le sujet réel était "Portage de RIOT-OS sur CC430 pour IOT" et non "Portage de RIOT-OS sur MSP430 pour IOT" , et donc le sujet du projet répondait à cette question : le port doit être effectué sur le CC430, un microcontrôleur de la famille des MSP430 ayant un CC1101. La réponse à la question difficile est donc triviale : le microcontrôleur doit être le CC430.

Préparation du projet

Cahier des charges

Choix techniques : matériel et logiciel

La référence exacte du CC430 utilisé est : CC430F5137IRGZT (datasheet http://www.ti.com/lit/ds/symlink/cc430f5137.pdf , http://www.ti.com/lit/ug/slau259e/slau259e.pdf)

Les programmes seront écrit en C et compilés avec le compilateur GCC pour msp430 (http://www.ti.com/tool/msp430-gcc-opensource).

Le CC430 sera flashé grâce à un launchpad de la marque TI : le MSP-EXP430G2 (http://www.ti.com/tool/MSP-EXP430G2).

Afin de vérifier que les CC430 émettent correctement les messages radios, un autre microcontrôleur sera utilisé comme agent de contrôle : le MSP430-CCRF (https://www.olimex.com/Products/MSP430/Starter/MSP430-CCRF/)

Liste des tâches à effectuer

Afin de réaliser le projet, il faut :

Mettre en place la chaîne de compilation (ggc pour msp430, comprendre comment utiliser le flasheur..)
Analyser le fonctionnement de RIOT-OS
Charger la version de RIOT-OS pour MSP430 sur le CC430 et déterminer quelles parties doivent être faites/refaites

Calendrier prévisionnel

Réalisation du Projet

Feuille d'heures

Tâche	Prélude	Heures S1	Heures S2	Heures S3	Heures S4	Heures S5
Analyse du projet	0
Mise en place de la chaine de compilation		8	1
Analyse du fonctionnement de RIOT-OS			6	2
Portage du module radio				5	7	7

Prologue

Semaine 1

La première semaine du projet a été consacrée à la mise en placede la chaine de compilation nécessaire pour complier le code pour le CC430 et et le falsher sur la carte.

Le compilateur msp430-gcc a été installé et l'outil mspdebug a été installé pour pouvoir flasher les cartes.

Les connexions physiques entre la carte habritant le cc430 et le launchpad msp-exp430g2 ont été repérées.

Des câbles avec une extremité femelle ont été soudés à une carte afin de permettre une communication (et donc une programmation) facile entre cette carte et le launchpad.

Semaine 2

Beaucoup de lecture et de recherche sur le fonctionnement de RIOT-OS ont été effectuées

Semaine 3

J'ai récupéré des sources d'un ancien projet IMA5 (lien needed) dans lequel existait des codes fonctionnels et des bibliothèques fonctionnelles pour utiliser le module radio du CC430. Je compte utiliser ces sources comme bases à intégrer a RIOTOS Afin de porter intégralement RIOTOS sur le CC430, il faut ajouter aux source de RIOTOS les sources permettant d'utiliser les différents modules disponibles sur le CC430. Parmi les modules disponibles sur le cc430, il ne faut porter que les modules suivants : le module CRC16, le module radio (le cc1101) et le module de cryptage AES. Après discussion avec les encadrants de projets, il n'est nécessaire pour l'instant que de porter le module radio

RIOT-OS fonctionne grâce à une série de makefile en cascade et à une arborescence précise, chaque fichier et makefile devant se trouver au bon endroit et modifiés de manière cohérente par rapport a l'architecture de compilation de RIOTOS.

Les différents microcontrôleurs supportés par RIOTOS sont rangés dans le dossier */RIOT/cpu et les différentes board sont rangés dans le dossier */RIOT/boards. Afin de porter RIOT OS pour le cc430, il faut donc ajouter les sources du module radio au dossier des sources du CC430, soit dans le dossier */RIOT/cpu/cc430. Il faut aussi créer un répertoire propre à la carte électronique fourni par les encadrants, j'ai donc crée dans l'architecture de RIOT un répertoire */RIOT/boards/CC430BV. En me basant sur l'architecture de la board msb430, une board utilisant un msp430 donc très proche de celle dont je dispose, j'ai recréé l'architecture de répertoire et de makefile pour cette board.

J'ai ensuite ajouté dans les sources du cc430 les bibliothèques pour le module radio en suivant l'architecture des différents répertoires, c'est à dire :

j'ai ajouté dans le dossier /RIOT/cpu/cc430/include/ le fichier RF1A.h, correspondant au fichier header pour faire fonctionner le module radio
j'ai ajouté dans le dossier /RIOT/cpu/cc430/ le fichier RF1A.c, correspondant au fichier source pour faire fonctionner le module radio

J'ai de plus ajouté des fichiers utiles pour un projet que je compte réutilisé dans les sources du CC430BV, principalement des sources pour la PMM et la commande des LED de la board.

J'ai ensuite crée un dossier pour mes projets de test au sein de l'arborescence de RIOT afin que les makefile retrouvent facilement les chemins des sources de l'OS.

J'ai rencontré beaucoup de problème liés à la compilation, la plupart de mes nouvelles sources n'étant pas reconnues. Afin de résoudre le problème, j'ai commencé par tenter de compiler un des mini projet d'exemples, en l’occurrence un simple projet "hello world", trouvable dans le répertoire */RIOT/examples/hello-world, et je me suis rendu compte que ce projet, compilant pour d'autres board, ne compilait pas pour ma nouvelle board cc430BV. EN suivant les messages d'erreurs j'ai pu résoudre ce problème et l'exemple compile sans erreur. En revanche, je n'arrive toujours pas a compiler mon projet de test avec mes nouvelles sources.

Semaine 4

Cette semaine a été consacrée à résoudre les problème de compilation liés au portage du module radio. Le principale problème rencontré est que à la compilation, certains fichiers sources nouvellement ajoutés ne sont pas reconnus, et donc certaines fonctions et certaines variables n’existent pas. Ce problème peut être facilement résolu en faisant un #include "monfichier.h" et en l'ajoutant au répertoire courant du projet, mais cela ne présente pas un grand intérêt dans le cadre de l'utilisation de RIOTOS et va a l'encontre de l’intérêt du portage.

Le problème est que pour que le port soit bien fait, n'importe quel projet puisse utiliser les sources pour la communication radio, et ce pour n'importe board existante utilisant le cc430, le module radio étant inclut dans ce microcontrôleur. Les sources doivent donc être ajouté au dossier même du cc430, et je n'ai pas trouvé de solution afin que ces fichiers soient bien inclus lors de la compilation.

J'ai modifié les makefiles que j'avais crée car il se trouvait qu'il y avait des erreurs, résolvant certains problèmes, mais le plus gros persiste, mes nouvelles sources ne sont pas prises en compte.

Après une remarque de M. Vantroys, j'ai décidé de prendre exemple sur l'architecture des répertoires et des makefiles de la board chronos, board utilisant aussi un cc430. Malgré cela, j'ai toujours les meme problèmes de compilation. En observant le cheminement du makefile grace à l'option -n, je remarque bien pourtant que mes fichiers, principalement mes fichiers sources RF1A.h et RF1A.c sont bien pris en compte et normalement bien ajoutés à la compilation grâce à l'option -I de gcc, mais certains #define sont inaccessible.

Semaine 5

En fouillant dans les exemples fournis par RIOTOS et dans la documentation de l'OS, j'ai trouvé la bonne méthode à utiliser pour porter l'OS sur le cc30. Contrairement à ce que je pensais, il faut bien utiliser les #include "header.h" pour inclure les sources nécessaires, avec header.h dans RIOT/cpu/cc430/includes et sources.c dans RIOT/cpu/cc430. J'ai donc déplacer mes fichiers RF1A.c et RF1A.h dans les bons répertoires (RIOT/cpu/cc430 et RIOT/cpu/cc430/includes). Dans le dossier correspondant à la board doit être inclut tous les fichiers sources relevant des drivers nécessaires au fonctionnements des périphériques n'étant pas nativement sur le cpu. Les sources de la gestion de led doivent donc y être placés. L'architecture doit donc être la suivante (sans tenir compte des dossiers et des fichiers déjà existant et ne devant pas être déplacés) :

RIOT/
 cpu/
  cc430/
   RF1A.c
   includes/
    RF1A.h
 board/
  cc430BV/
   drivers/
    Makefile
    led_commands.c
    include/
     led_command.h

IMA4 2017/2018 P10

Sommaire