Présentation du Spark Core

| 16 minutes read

On ne perd pas les bonnes habitudes, il est temps de parler à nouveau hardware. Aujourd’hui, je vais aborder à nouveau le monde des objets connectés via un Arduino-like : le Spark Core. Qu’est-il ? Que propose-t-il de neuf ? Les réponses sont un peu plus bas.

Un rappel sur les objets connectés

L’objet connecté, associé à son terme compagnon d’Internet des Objets (ou IoT – Internet of Things) est un concept en vogue en ce moment. Pour rappel, il s’agit d’équiper de capteurs des objets du quotidien, et de leur donner ensuite une connexion à Internet afin de remonter les informations et de les analyser. Les usages venant à l’esprit sont principalement liés au domaine de la domotique, par exemple avec des capteurs de luminosité, température, humidité, afin de piloter le chauffage et les volets roulants de la maison, ou bien des capteurs de présence sur des places de parking associés à une application mobile capable d’indiquer quelles sont les places de stationnement libres les plus proches. Plusieurs technologies sont en lice sur ce domaine :

  • Le protocole Bluetooth Low Energy, qui est une extension du protocole Bluetooth « standard ». Ce protocole permet d’obtenir une transmission sans fil de courte portée (une dizaine de mètres), de relativement faible débit, avec une très faible consommation électrique. Il ne permet pas de se connecter en tant que tel à Internet, mais peut équiper des capteurs sans fil économes en énergie, et centraliser les informations relevées vers un outil qui sera connecté à Internet.
  • Certains protocoles spécifiques comme celui fourni par le réseau Sigfox. On a dans ce cas de figure des débits très faibles, mais une très grande portée (plusieurs kilomètres dans de bonnes conditions) et là aussi une faible consommation énergétique. Le cas d’utilisation de ce protocole est celui de données ne nécessitant pas une mise à jour trop fréquente, par exemple celui des places de stationnement (voir par exemple cet article de l’Usine digitale). Tout comme le protocole BLE, il n’y a pas de connexion directe à Internet, mais une centralisation des informations relevées sur un serveur lui-même accessible depuis Internet.
  • Enfin, le protocole WIFI qui a lui aussi ses avantages et inconvénients. Il est caractérisé par des débits importants par rapport aux protocoles mentionnés précédemment, une portée moyenne (50 à 100 mètres dans les cas typiques d’utilisation, plusieurs kilomètres avec des antennes adaptées), mais une consommation largement supérieure pendant les phases de transmission. Autre avantage, le WIFI permet une connexion à Internet bi-directionnelle (le périphérique connecté peut se comporter à la fois comme un client ou un serveur Internet).

Par la suite, je vais évoquer le cas des objets connectés via le protocole WIFI.

Dans un précédent article concernant l’Arduino Yún, j’avais évoqué le cas des shields Ethernet (ou WIFI) qui ont le défaut de faire reposer la majorité du travail réseau sur le micro-contrôleur. L’Arduino Yún a l’avantage de déporter ce travail sur un Linux embarqué et ayant nettement plus de puissance de traitement. En revanche, il existe des cas où ce type de solution peut être sur-dimensionné par rapport aux besoins. Une solution à la Arduino + Shield WIFI peut largement suffire, mais l’empreinte physique de cette solution peut être trop importante pour équiper de petits objets (surface à peu près équivalente à celle d’une carte bancaire). Et c’est là qu’arrive la solution dont je vais vous parler par la suite.

Le Spark Core

Le Spark Core a commencé comme un projet Kickstarter avec un succès très important (10 000 $ demandés, 568 000 $ obtenus). L’idée principale est de fournir un micro-contrôleur programmable associé à un contrôleur WIFI, le tout avec une empreinte physique minimale (un Spark Core est environ 6 fois plus petit qu’un Arduino).

Au final, un Spark Core propose :

  • Un micro-contrôleur STM32 F1 (cœur ARM Cortex-M3), fonctionnant à 72 MHz (Arduino : 16 MHz) et équipé de 128 ko de Flash (Arduino : 32 ko) et 20 ko de RAM (Arduino : 2 ko).
  • Un contrôleur WIFI Texas Instruments CC3000, compatible avec les réseaux 802.11 b/g. Ce contrôleur WIFI est celui à la mode en ce moment : bon marché, performant, on commence à le trouver un peu partout.
  • Une puce fournissant 2 Mo de Flash externe (Arduino : 1 ko d’EEPROM)
  • 18 entrées / sorties numériques (Arduino : 20) dont 8 capables de PWM (Arduino : 6)
  • 8 entrées analogiques 12 bits, 3,3V max (Arduino : 6 en 10 bit, 5V max)
  • Support des protocoles UART, I2C et SPI

Il est possible d’étendre les possibilités du Spark Core à l’aide de shields spécifiques.

Les shields officiels sont :

  • Le Shield Shield (20$) : il permet d’utiliser avec le Spark Core des shields standards Arduino.
  • Le Relay Shield (20$) : il permet de piloter jusqu’à quatre relais (si jamais vous souhaitez allumer ou éteindre des appareils électriques à distance).
  • Le Programmer Shield (20$) : il permet de reprogrammer le Spark Core directement (accès direct au micro-contrôleur).
  • Le Battery Shield (20$) : il permet non seulement d’alimenter le Spark Core à l’aide d’une batterie LiPo 3,7V, mais aussi de recharger cette dernière. De plus, il est fourni avec une petite batterie LiPo (3,7V, 450 mAh).

Vous trouverez ci-dessous quelques photos du Spark Core, avec certains de ces shields. Sur la face supérieure se trouve le contrôleur WIFI, et sur la face inférieure le micro-contrôleur (la grosse puce noire au centre).

Le Spark Core est disponible en ligne pour 39 $.

Spark Core et consommation électrique

Un point intéressant du Spark Core est de pouvoir se mettre en veille pour une durée déterminée, au contraire des solutions Arduino standards qui ont besoin d’un évènement extérieur pour sortir de veille. Ce type de fonctionnement peut être utile dans le cadre d’un capteur distant, par exemple alimenté par un couple batterie + panneau solaire.

Il existe deux types de mise en veille pour le Spark Core :

  • Une mise en veille standard : dans ce cas, le contrôleur WIFI est coupé, et le micro-contrôleur programmable mis en pause. À la sortie de la mise en veille, le programme reprend là où il a été interrompu. En veille standard, la consommation annoncée est de 15mA à 30mA.
  • Une mise en veille profonde : dans ce cas, le contrôleur WIFI est coupé, et le micro-contrôleur programmable éteint. À la sortie de la mise en veille, le programme repart de zéro. En veille profonde, la consommation annoncée est de 3,2 µA.

Il faut savoir que les consommations annoncées sont théoriques. Dans la réalité, les consommations réelles seront plus élevées, du fait de l’électronique autour du Spark Core, qui consomme quand même un minimum de courant.

J’ai voulu faire une simulation de capteur distant fonctionnant sur batterie, en utilisant le Spark Core, son Battery Shield et la batterie fournie avec (3,7V, 450 mAh). Le code exécuté était le suivant :

  1. Connexion au Spark Cloud (voir le paragraphe suivant pour plus de détails).
  2. Lecture d’une entrée analogique.
  3. Connexion à un serveur distant pour lui communiquer le résultat de la lecture.
  4. Passage en veille profonde pour une minute (donc à la sortie de veille, reprise au point 1).

La batterie a tenu pendant vingt et une heures, ce qui donne une consommation moyenne de courant de (450 mAh / 21h) = 21,4 mA. La majeure partie de la consommation a lieu pendant la connexion au Spark Cloud et la connexion au serveur distant, les contrôleurs WIFI étant gourmands en électricité (maximum 300 mA). Ensuite, il faut savoir que le branchement électrique était le suivant :

Batterie — (3,7V) –> convertisseur de tension — (5V) –> / Fin du Battery Shield | Début du Spark Core / — (5V) –> régulateur de tension — (3,3V) –> Spark Core

Il faut savoir que les convertisseurs et régulateurs de tension n’ont pas une efficacité de 100%, mais soit subissent des pertes (comprendre : consomment plus de courant que strictement nécessaire) dans le cas des convertisseurs, soit consomment autant de courant qu’ils en distribuent (et le surplus d’énergie est dissipé en chaleur) dans le cas des régulateurs (pour ne pas alourdir ce chapitre, j’ai rajouté des détails sur le fonctionnement convertisseur / régulateur en bas de page).

Bref, en optimisant l’électronique (par exemple en éliminant le premier convertisseur) et en rajoutant une plus grosse batterie, il peut être possible de tenir plusieurs semaines. Rajoutez un panneau solaire pour charger la batterie, et votre Spark Core sera autonome.

 

Le Spark Cloud

Une des spécificités du Spark Core, en plus de fournir les classiques bibliothèques lui permettant de se comporter comme un client ou serveur TCP, est la présence d’une API REST. Tout Spark Core est disponible à l’adresse « https://api.spark.io/v1/devices/<device_id>/ » et est pilotable par une API REST.

Par exemple :

  • Une requête POST à l’URL « https://api.spark.io/v1/devices/<device_id>/led » avec les paramètres « access_token=<token> » et « params=toto » appellera la fonction « led » en lui passant un paramètre de valeur « toto ».
  • Une requête GET à l’URL « https://api.spark.io/v1/devices/<device_id>/temp »avec le paramètre « access_token=<token> » passé dans le corps de la requête HTTP (et non pas dans l’URL) retournera le contenu de la variable « temp » dans un bloc JSON.
$ curl -G https://api.spark.io/v1/devices/<device_id>/temp -d access_token=<token>
{
  "cmd": "VarReturn",
  "name": "temp",
  "result": 2106,
  "coreInfo": {
    "last_app": "",
    "last_heard": "2014-03-03T09:32:58.817Z",
    "connected": true,
    "deviceID": "<device_id>"
  }
}

Les fonctionnalités de l’API REST sont fournies par l’intermédiaire de ce qui est appelé le Spark Cloud. Il faut savoir que le Spark Core ne peut pas (du moins pour le moment) fonctionner sans connexion à Internet. Le fonctionnement est le suivant, à partir du moment où le Spark Core est branché à une alimentation :

  1. Le contrôleur WIFI est démarré, et tente de se connecter au réseau WIFI pour lequel il est configuré.
  2. Une fois la connexion WIFI établie, le Spark Core tente de se connecter au Spark Cloud (et de s’y authentifier).
  3. Une fois la connexion au Spark Cloud établie, le micro-contrôleur programmable est démarré.
  4. Par la suite, le Spark Core maintient une connexion TCP avec le Spark Cloud, qui lui enverra les requêtes qui lui sont destinées via des messages CoAP. Plus de détails sont disponibles ici : How does SparkCore maintain connection to cloud API?

Ce fonctionnement pose tout de même deux problèmes :

  1. Sans connexion Internet, le micro-contrôleur est complètement inactif et donc inutilisable. Il reste possible de se créer un firmware à partir des sources officielles pour désactiver la connexion au Spark Cloud, mais dans ce cas on perd la possibilité d’utilisation de l’API REST, ainsi que la possibilité de reprogrammer le Spark Core en ligne.
  2. Le Spark Cloud est pour le moment géré par Spark. On dépend donc d’un service que l’on ne contrôle pas pour la gestion de l’API REST. Il est prévu de fournir les sources du Spark Cloud pour une installation sur son propre serveur courant mars / avril 2014.

Hormis les fonctions spécifiques au Spark Core, le reste de l’API est identique à l’API standard Arduino.

Tout comme le Spark Cloud est connecté à Internet, l’environnement de développement officiel est « dans le cloud ». L’IDE est un éditeur en ligne, et permet d’écrire, compiler et flasher le Spark Core depuis l’interface web.

Spark Core Web IDE

Spark Core Web IDE

 

Divers

Il reste possible de manipuler le Spark Core en ligne de commande à l’aide de spark-cli, qui est basé sur Node.js. Par contre, spark-cli repose toujours sur le Spark Cloud.

De même, il est aussi possible de faire son propre firmware à l’aide d’outils de développements installés sur son ordinateur et des sources du firmware, et de flasher le Spark Core via USB.

Ensuite, il faut savoir que le projet Spark Core est encore jeune et rencontre quelques problèmes de stabilité pour la connexion au Spark Cloud et les bibliothèques TCPClient et TCPServer. La majeure partie de ces problèmes est due au contrôleur WIFI, et les équipes de Spark travaillent étroitement avec Texas Instruments afin de les résoudre.

Dans tous les cas, la communauté des utilisateurs est très active, et les équipes de développement travaillent par sprints de deux à trois semaines pour l’ajout de fonctionnalités.

Sinon, vous pouvez voir un exemple de leur hackathon interne ayant abouti à un proche cousin du thermostat connecté Nest, récemment racheté par Google : Building an open source Nest.

Un exemple : Statut de compilation par Jenkins

Le but de cet exemple est d’allumer une LED bleue quand la compilation par Jenkins d’un projet Maven se termine avec succès, et une LED rouge quand elle se termine par un échec. Après, rien de vous empêche de remplacer la LED bleue par des machines à bulles géantes et la LED rouge par un gyrophare et une corne de brume. Après tout, il faut savoir parfois motiver les troupes.

La configuration de Jenkins

Il faut d’abord installer le plugin « Hudson Post build task », puis configurer le projet comme ci-dessous (penser à remplacer « device_id » et « access_token » par les bonnes valeurs)

Configuration Hudson Post Build Task

Configuration Hudson Post Build Task

Le code côté Spark Core

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
/**
 * Exemple de code avec contrôle de LED via Internet. Il est possible d'allumer
 * ou d'éteindre une LED en fonction de paramètres reçus.
 * 
 * Dans cet exemple, on a une LED bleue, nommée OK, qui est allumée quand un build Hudson
 * s'est déroulé avec succés, et une LED rouge, nommée KO, qui est allumée quand le même
 * build Hudson échoue.
 * 
 * Exemple d'appel de l'API REST pour allumer la LED OK :
 * $ curl https://api.spark.io/v1/devices/<device_id>/led 
 *      -d access_token=<access_token> 
 *      -d params=OK
 * 
 * Exemple d'appel de l'API REST pour allumer la LED OK :
 * $ curl https://api.spark.io/v1/devices/<device_id>/led 
 *      -d access_token=<access_token> 
 *      -d params=KO
 * 
 */
 
// Définition des constantes pour les broches
//   auxquelles sont branchées les LED de statut 
const byte OK_LED = D4;
const byte KO_LED = D0;
 
// Fonction « setup », exécutée lors de l'initialisation
//   du micro-contrôleur
void setup() {
    // Passage des broches des LED de statut en mode OUTPUT
    //   a.k.a. source de courant
    pinMode(OK_LED, OUTPUT);
    pinMode(KO_LED, OUTPUT);
 
    // On éteint la LED OK (état LOW -> 0V)
    digitalWrite(OK_LED, LOW);
    // On allume la LED KO (état HIGH -> 3,3V)
    digitalWrite(KO_LED, HIGH);
 
    // On définit une fonction pour le contrôle des LED
    Spark.function("led", ledControl);
}
 
// Fonction « loop », exécutée en boucle tant que le 
//   micro-contrôleur est allumé
void loop() {
    // On ne fait rien dans ce cas
}
 
// Fonction de contrôle des LED. 
int ledControl(String command) {
    if (command == "OK") {
        // Si la valeur du paramètre reçu (paramètre « command ») est 
        //   égale à « OK », on allume la LED OK et on éteint la LED KO
        digitalWrite(OK_LED, HIGH);
        digitalWrite(KO_LED, LOW);
    } else {
        // Sinon, on allume la LED KO et on éteint la LED OK
        digitalWrite(OK_LED, LOW);
        digitalWrite(KO_LED, HIGH);
    }
}

Le résultat en vidéo

 

Note : le cas des convertisseurs et régulateurs

Les convertisseurs de tension et régulateurs de tension ont un fonctionnement différent : le premier est un circuit actif (qui a besoin d’autres composants autour), le second est un circuit passif; le premier est plus efficace que le second, le premier est plus cher que le second.

Prenons le cas d’un composant électronique demandant pour fonctionner 5V à 1A (soit 5W de puissance), qu’on veut alimenter à l’aide d’une pile de 9V.

  • Avec un régulateur de tension : le courant qui va entrer dans le régulateur va être le même que celui qui va être consommé par le composant électronique, soit 1A. Donc en entrée du régulateur, on va avoir une puissance consommée de 9W (9V * 1A), et en sortie une puissance distribuée de 5W (5V*1A). Les 4W de différence vont être dissipés par le régulateur sous forme de chaleur (et croyez-moi, 4W sur la surface d’un ongle, c’est chaud). Le rendement est de (5/9) = 56%
  • Avec un convertisseur de tension parfait (soit 100% d’efficacité), la puissance en entrée va être la même que celle en sortie, donc dans ce cas 5W. Ce qui donne une entrée à 9V et (5W / 9V) = 0,56A. La consommation électrique est nettement moindre dans ce cas (à peu près la moitié de celle d’un régulateur de tension).
  • Avec un convertisseur de tension réaliste (disons 90% d’efficacité), la puissance en entrée va être de (puissance sortie / 0,9), soit dans le cas qui nous intéresse, (5 / 0,90) = 5,56W. On a donc une consommation électrique de (5,56 W/9V) = 0,62A.

Arnaud Boudou Author: Arnaud Boudou

Développeur Java et mobile (iOS) ; enthousiaste des TIC ; photographe amateur (un jour, peut-être…).

Mes hashtags : #j2ee #objc #raspberrypi #inneedforgadgetry

@boudouarnaud sur Twitter

Like it?  Share  it!

Share Button
What do  You  think? Write a comment!

Leave a Reply

Required fields are marked *.


CommentLuv badge