Pour être précis, c’est la lecture des articles de Christophe Blaess (article1, ressources) dans Gnu Linux France Magazine qui m’a titillé ! Aussi j’ai suivi son article sur la cross-compilation d’une chaîne de développement avec BuildRoot (version 2013.02) ainsi que la compilation d’un noyau avec cette même chaîne. L’installation, la compilation de la chaîne de cross-compilation puis la compilation d’un noyau se sont fait assez rapidement (une seule erreur au moment de la compilation de la uClibC : changer la locale de la ligne UCLIBC_BUILD_MINIMAL_LOCALES=”fr_FR” du fichier buildroot-2013.02/output/toolchain/uClibc-0.9.33.2/.config) et j’ai obtenu le fameux “Kernel panic…” signe que ca roule ;-). En faisant le tour de la configuration du noyau (make menuconfig), j’ai fouillé du coté de l’I2C et des pilotes pour RTC. Comme je dispose de deux platines RTC maison je me suis intéressé à leur intégration directement dans le noyau.

Les platines sont équipées de :

• un DS1307 avec son quartz 32KHz et une pile bouton 3V : il faut alimenter ce circuit en 5V par l’intermédiaire de la broche du raspberry. Les lignes SDA et SCL sont toujours en 3,3V car ce sont des sorties à drain ouvert et les résistances de rappel des lignes SDA et SCL sont câblées sur le raspberry.
• un DS3232 avec une pile bouton 3V : ce circuit dispose de son oscillateur interne compensé en température ce qui lui procure une grande précision et donc une dérive faible (de l’ordre de la minute sur un an). Cette platine est aussi équipé d’un capteur de température DS1621.

Ces trois circuits disposent de pilotes natifs dans le noyau Linux (drivers/rtc/rtc-ds1307.c et rtc-ds3232.c, drivers/hwmon/ds1621.c). Comme je veux les utiliser très tôt dans le processus de démarrage du noyau il faut que les pilotes soient inclus dans le noyau et pas sous forme de modules. Comme ces circuits sont tous utilisés sur le bus I2C, il faut donc aussi que celui-ci soit compilé dans le noyau. Enfin la gestion de la RTC par le noyau se fait en cochant l’option  “Device driver -> Real Time Clock -> Set system time from RTC on startup and resume”. Cependant il reste un problème : comment indiquer au pilote l’adresse de la RTC sur le bus I2C (ici 0×68) ainsi que le bus I2C actif (il y a deux bus i2c sur un raspberry qui n’ont pas la même numérotation suivant la version)…

Il faut lire la documentation du noyau sur “l’instantiation” de périphérique disponible sur https://www.kernel.org/doc/Documentation/i2c/instantiating-devices. La méthode 4 décrite dans ce document est celle utilisée par quasiment tout le monde :  on instantie un périphérique en passant son type et son adresse au bus i2c concerné géré par le noyau (Ex: echo ds1307 0×68 > /sys/class/i2c-adapter/i2c-1/new_device). A partir de ce moment vous pouvez utiliser la commande hwclock. Dans notre cas c’est un peu plus compliqué ! Il va falloir appliquer la méthode 1.

Le raspberryPi utilise un SoC Broadcom bcm2708. Il va donc falloir modifier le fichier d’initialisation de cette puce pour déclarer la RTC. Ce fichier est “arch/arm/mach-bcm2708/bcm2708.c”. Dans un premier temps il faut rajouter une structure :

// Ajout O. Dartois pour test RTC DS3232
static struct i2c_board_info __initdata bcm2708_i2c_devices[] = {
{
I2C_BOARD_INFO(”rtc-ds1307″, 0×68),
.type = “ds1307″,
},
};

J’ai rajouté cette structure juste avant la fonction bcm2708_init(void). Puis toujours dans la fonction bcm2708_init(void), j’ai rajouté les lignes suivantes après l’enregistrement des busi2c :

bcm_register_device(&bcm2708_spi_device);
bcm_register_device(&bcm2708_bsc0_device);
bcm_register_device(&bcm2708_bsc1_device);
// Ajout O. Dartois
printk("Declaration RTC ...n");
i2c_register_board_info(1, bcm2708_i2c_devices, ARRAY_SIZE(bcm2708_i2c_devices));

On lance alors la compilation du noyau puis on copie le noyau zImage obtenu en kernel.img sur la carte SD du raspberryPi. On démarre la carte et on vérifie les messages du noyau (j’utilise le logiciel GrabSerial pour avoir une idée du temps de boot, c’est pour cette raison que vous avez des temps entre crochets au début de chaque ligne) :

[...]
[1.129414 0.000850] [ 0.077531] DMA: preallocated 4096 KiB pool for atomic coherent allocations
[1.148473 0.019059] [ 0.078721] bcm2708.uart_clock = 0
[1.149129 0.000656] [ 0.079882] Declaration RTC …
[1.149740 0.000611] [ 0.080256] mailbox: Broadcom VideoCore Mailbox driver
[1.150716 0.000976] [ 0.080369] bcm2708_vcio: mailbox at f200b880
[...]
[2.072602 0.005752] [ 1.813068] i2c /dev entries driver
[2.086104 0.013502] [ 1.819306] bcm2708_i2c bcm2708_i2c.0: BSC0 Controller at 0×20205000 (irq 79) (baudrate 100k)
[2.097600 0.011496] [ 1.835187] rtc-ds1307 1-0068: rtc core: registered ds1307 as rtc0
[2.104376 0.006776] [ 1.843777] rtc-ds1307 1-0068: 56 bytes nvram
[2.117500 0.013124] [ 1.850403] bcm2708_i2c bcm2708_i2c.1: BSC1 Controller at 0×20804000 (irq 79) (baudrate 100k)
[...]
[2.413443 0.015522] [ 2.146339] rtc-ds1307 1-0068: setting system clock to 2013-05-06 06:25:21 UTC (1367821521)
[...]
pi@raspberrypi:~$ date
lundi 6 mai 2013, 08:30:00 (UTC+0200)
pi@raspberrypi:~$

Je vérifie la date à la fin du boot. La distribution utilisé ici est la Raspian, l’horloge RTC est en UTC, le système utilise le fuseau horaire de europe/paris. On est à l’heure d’été donc l’heure est bien cohérente (UTC+2).

Petite remarque supplémentaire : comme le bus i2c est intégré au noyau vous ne pouvez plus changer la vitesse du bus au moment du “insmod”. Pour changer dynamiquement la vitesse du bus i2c, il faut modifier la valeur de : /sys/module/i2c_bcm2708/parameters/baudrate

Ressources internet

Une fois n’est pas coutume, je commence par les ressources Internet :

• L’article Wikipédia sur l’I2C : article wikipédia
• Le site de LadyADA : Adafruit Learning System
• Le site eLinux (partie sur l’I2C) : eLinux
• les pages de manuel de l’I2C : i2cdetect, i2cset, i2cget

Brochage du connecteur

Vous trouverez sur Internet de nombreux exemples du brochage du connecteur du RaspberryPI. J’en ai choisi deux parmi d’autres:

Les broches qui nous intéressent ici (pour la V2 revB) :

• GPIO0 (SDA) : broche 3 du connecteur,
• GPIO1 (SCL) : broche 5 du connecteur,
• la masse (GROUND) : broche 6 du connecteur,
• l’alimentation (on prendra des esclaves I2C qui fonctionnent en 3,3V) : broche 1 du connecteur

Utilisation de l’I2C sur le RaspberryPI

Activation de l’I2C

Il faut tout d’abord être “root” pour réaliser les commandes suivantes : sudo su. Il faut éditer le fichier “/etc/modprobe.d/raspi-blacklist.conf” avec l’éditeur nano puis commenter (mettre le caractère #) la ligne “blacklist i2c-bcm2708″.
Puis rajouter la ligne “i2c-dev” dans le fichier “/etc/modules”. Redémarrez le RaspberryPI avec la commande “reboot”.
Pour vérifier que le pilote de l’I2C est bien chargé, tapez ces deux commandes:

• dmesg | grep i2c : permet de visualiser les messages du noyau se rapportant au bus i2c,
• ls /dev/i2c* : cette commande permet de savoir si le bus i2c est bien accessible depuis “l’espace utilisateur” donc depuis vos programmes.

Voici le résultat de ces deux commandes :

1
2
3
4
5
6

root@raspberrypi:/home/pi# dmesg|grep i2c
[   32.803506] bcm2708_i2c bcm2708_i2c.0: BSC0 Controller at 0x20205000 (irq 79) (baudrate 100k)
[   32.832122] bcm2708_i2c bcm2708_i2c.1: BSC1 Controller at 0x20804000 (irq 79) (baudrate 100k)
[   38.616811] i2c /dev entries driver
root@raspberrypi:/home/pi# ls /dev/i2c-
i2c-0  i2c-1

On remarque qu’il y a deux bus i2c reconnus sur la carte. La vitesse de ces bus est ici de 100kHz (mode basse vitesse du bus i2c). Ces deux bus sont accessibles par i2c-0 et i2c-1. En fait un seul bus est disponible sur le connecteur.

Installation des outils I2C

Pour tester si le bus I2C est fonctionnel on connecte une platine avec deux circuits :

• un capteur de température DS1631,
• une horloge temps réel DS3231.

Schéma électrique de la platine  et typon (échelle 2) :

Il faut ensuite installer les outils nécessaires pour dialoguer sur le bus i2c sans programmer. En tant qu’utilisateur root, tapez la commande suivante:

1
2
3
4
5
6
7
8
9
10
11
12

root@raspberrypi:/home/pi# aptitude install i2c-tools
Les NOUVEAUX paquets suivants vont être installés :
  i2c-tools
0 paquets mis à jour, 1 nouvellement installés, 0 à enlever et 0 non mis à jour.
Il est nécessaire de télécharger 59,5 ko d'archives. Après dépaquetage, 223 ko seront utilisés.
Prendre :  1 http://mirrordirector.raspbian.org/raspbian/ wheezy/main i2c-tools armhf 3.1.0-2 [59,5 kB]
 59,5 ko téléchargés en 1s (56,8 ko/s)
Sélection du paquet i2c-tools précédemment désélectionné.
(Lecture de la base de données... 60077 fichiers et répertoires déjà installés.)
Dépaquetage de i2c-tools (à partir de .../i2c-tools_3.1.0-2_armhf.deb) ...
Traitement des actions différées (« triggers ») pour « man-db »...
Paramétrage de i2c-tools (3.1.0-2) ...

L’utilitaire i2cdetect permet de parcourir le bus i2c pour détecter des esclaves reliés à ce bus. Les commandes suivantes permettent de parcourir le bus i2c-0 : raspberry V2revA ou le bus i2c-1 : raspberry V2revB.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

root@raspberrypi:/home/pi# i2cdetect -y 0
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
root@raspberrypi:/home/pi# i2cdetect -y 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- 48 -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- 68 -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

On remarque que sur le bus i2c-1 il y a deux esclaves i2c :

• adresse 0×48 : capteur DS1631 dont les lignes d’adresses A2, A1 et A0 sont reliées à la masse. L’adresse de ce composant est donné dans la documentation : 0b1001A2A1A0 donc 0b1001000 donc en hexadécimal 0×48.
• adresse 0×68 : horloge RTC. Dans la documentation on trouve l’adresse suivante : 0b1101000 soit 0×68.

Le résultat du parcours du bus est donc concluant.

Utilitaires d’interrogation du bus i2c

Nous allons commencer à interroger le capteur de température de l’horloge temps réel. Le résultat de la conversion de température est accessible à l’adresse 0×11 sur deux octets (voir extrait de la documentation ci-dessous ) :

Vous disposez de deux utilitaires pour cela : i2cset et i2cget. Ci-dessous vous trouverez ce que renvoie ces commandes lorsqu’on les lance sans paramètres :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

root@raspberrypi:/home/pi# i2cset
Usage: i2cset [-f] [-y] [-m MASK] I2CBUS CHIP-ADDRESS DATA-ADDRESS [VALUE] ... [MODE]
  I2CBUS is an integer or an I2C bus name
  ADDRESS is an integer (0x03 - 0x77)
  MODE is one of:
    c (byte, no value)
    b (byte data, default)
    w (word data)
    i (I2C block data)
    s (SMBus block data)
    Append p for SMBus PEC
root@raspberrypi:/home/pi# i2cget
Usage: i2cget [-f] [-y] I2CBUS CHIP-ADDRESS [DATA-ADDRESS [MODE]]
  I2CBUS is an integer or an I2C bus name
  ADDRESS is an integer (0x03 - 0x77)
  MODE is one of:
    b (read byte data, default)
    w (read word data)
    c (write byte/read byte)
    Append p for SMBus PEC

En gros on remarque qu’il faut spécifier :

• le numéro du bus i2c,
• l’adresse de l’esclave,
• la ou les registres à écrire/lire.

Dans l’exemple qui suit, on lit la température fourni par l’horloge temps réél : adresse 0×68, registres 0×11 et lecture d’un mot (2 octets) :

1
2
3
4
5
6
7
8

root@raspberrypi:/home/pi# i2cget 1 0x68 0x11 w
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will read from device file /dev/i2c-1, chip address 0x68, data address
0x11, using read word data.
Continue? [Y/n] y
0x4013
root@raspberrypi:/home/pi# i2cget -y 1 0x68 0x11 w
0x4013

On obtient la valeur hexadécimal 0×4013. La valeur 0×13 correspond au contenu du registre 0×11 (partie entière de la température). La valeur 0×40 correspond à la valeur du registre 0×12 (partie fractionnaire de la température) dont seul les bits B7 B6 nous intéresse. On obtient donc la température suivante : 0×13 = 19 et 0×40 => B7=0 et B6=1. B7 représente 2^-1=0,5°C et B6 représente 2^-2=0,25°C. La température finale est donc de 19,25°C.

Pour initialiser correctement la RTC, il faut écrire la valeur 0×04 dans le registre 0×0E (registre de “control”) et 0×08 dans le registre 0×0F (registre de “status”). Pour la signification de ces valeurs reportez-vous à la documentation officielle. Cela se traduit par les commandes suivantes :

1
2
3
4
5
6

root@raspberrypi:/home/pi# i2cset -y 1 0x68 0x0E 0x04 b
root@raspberrypi:/home/pi# i2cget -y 1 0x68 0x0F b
0x88
root@raspberrypi:/home/pi# i2cset -y 1 0x68 0x0F 0x08 b
root@raspberrypi:/home/pi# i2cget -y 1 0x68 0x0F b
0x08

Vous pouvez maintenant lire les secondes, minutes, heures, jour du mois, mois et année. Exemple avec la lecture des secondes et de l’année :

1
2
3
4

root@raspberrypi:/home/pi# i2cget -y 1 0x68 0x00 b
0x41
root@raspberrypi:/home/pi# i2cget -y 1 0x68 0x06 b
0x00

On obtient donc pour les secondes : 0×41 => 4 x 10s + 1 x 1s = 41s. Pour les années 0 ! La RTC n’est donc pas réglé. Je vous invite à chercher par vous même les commandes pour mettre à l’heure votre horloge RTC.

Bonus : installer une RTC sur le Raspberry

Par défaut, le raspberryPi n’a pas d’horloge RTC. Il récupère la date et l’heure au démarrage à condition d’avoir une connexion Internet. Pour pallier ce défaut on peut connecter au bus i2c une horloge.
Vous trouverez ci-dessous les pilotes gérés par le noyau Linux de la raspberry:

1
2
3
4
5
6

root@raspberrypi:/home/pi# ls /lib/modules/3.6.11-rpi-aufs/kernel/drivers/rtc/
rtc-bq32k.ko   rtc-ds1672.ko  rtc-isl12022.ko  rtc-max6900.ko  rtc-r9701.ko	rtc-rx8581.ko
rtc-ds1305.ko  rtc-ds3232.ko  rtc-isl1208.ko   rtc-max6902.ko  rtc-rs5c348.ko	rtc-s35390a.ko
rtc-ds1307.ko  rtc-ds3234.ko  rtc-m41t80.ko    rtc-pcf2123.ko  rtc-rs5c372.ko	rtc-x1205.ko
rtc-ds1374.ko  rtc-em3027.ko  rtc-m41t93.ko    rtc-pcf8563.ko  rtc-rv3029c2.ko
rtc-ds1390.ko  rtc-fm3130.ko  rtc-m41t94.ko    rtc-pcf8583.ko  rtc-rx8025.ko

Une des plus répandues de ces horloges est certainement la DS1307. Cependant la DS3231 est compatible au niveau des registres de date et d”heure d’une DS1307, elle est plus chère mais aussi beaucoup plus précise. Les commandes suivantes permettent de régler la RTC à partir de l’heure récupérer sur Internet.

1
2
3
4
5
6
7
8

root@raspberrypi:/home/pi# echo ds1307 0x68 > /sys/class/i2c-adapter/i2c-1/new_device
root@raspberrypi:/home/pi# hwclock -r
sam. 29 mars 2011 15:02:36 CET  -0.302646 seconds
root@raspberrypi:/home/pi# date
samedi 9 février 2013, 16:27:34 (UTC+0100)
root@raspberrypi:/home/pi# hwclock -w
root@raspberrypi:/home/pi# hwclock -r
sam. 09 févr. 2013 16:28:11 CET  -0.763037 seconds

Si l’on détaille les lignes précédentes:

1. déclaration d’un nouvel esclave sur le bus i2c : son type (ds1307) et son adresse (0×68),
2. lecture de la date dans la RTC : ici la RTC n’est pas à l’heure,
3. vérification de l’heure système avec la commande date,
4. transfert de l’heure système dans la RTC : paramètre -w de la commande hwclock,
5. vérification de l’heure de la RTC.

Pour que l’heure de la RTC soit appliquée au système au démarrage, il faut rajouter les lignes suivantes à la fin du fichier “/etc/rc.local” avant la ligne “exit 0″ :

1. “echo ds1307 0×68 > /sys/class/i2c-adapter/i2c-1/new_device”,
2. “sudo hwclock -s”.

Qu’est-ce que la cross-compilation ?

Je reprend ici la définition de developpez.com :

Il peut arriver, souvent ou rarement selon votre domaine, que vous ayez besoin de compiler un programme pour une plateforme différente de celle qui est utilisée pour le développement. Par exemple, pour créer une application pour un téléphone portable, vous n’allez certainement pas programmer avec votre téléphone. Vous développerez plutôt votre application toujours sur ordinateur mais la compilerez pour le téléphone et non pour votre système. C’est la cross-compilation.

Dans notre cas la machine de développement est un PC sous GNU/Linux Debian 6 ou 7 et la cible est un système embarqué à base de SoC ARM (RaspberryPi ou Olinuxino).

Installer la chaîne de cross-compilation sur votre Debian

Lancez un interpréteur de commandes avec les droits “root” sur votre Debian (généralement “Terminal administrateur”). Il faut tout d’abord rajouter la clé public GnuPG du dépôt emdebian (cela permet de vérifier la signature des paquets que vous téléchargez). Puis éditer le fichier des sources de paquetages pour ajouter le dépôt de la emdebian enfin il faut installer le cross-compilateur à proprement parler. Vous pouvez donc taper les commandes suivantes :

1
2

root@portable-od:~# apt-get install emdebian-archive-keyring
root@portable-od:~# nano /etc/apt/sources.list

Rajoutez alors la première ligne pour une debian 7 Wheezy OU la deuxième ligne pour une debian 6 Squeeze:

1
2

deb http://www.emdebian.org/debian/ sid main
deb http://www.emdebian.org/debian/ squeeze main

Mettez à jour la liste des paquetages disponibles :

1

root@portable-od:~# aptitude update

On cherche maintenant les différentes versions du cross-compilateur gcc pour arm:

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

root@portable-od:~# aptitude search gnueabi
root@debian7:~# aptitude search gnueabi
p   binutils-arm-linux-gnueabi      - GNU binary utilities, for arm-linux-gnueab
p   binutils-arm-linux-gnueabihf    - GNU binary utilities, for arm-linux-gnueab
v   c++-compiler-arm-linux-gnueabi  -
v   c++-compiler-arm-linux-gnueabih -
v   c-compiler-arm-linux-gnueabi    -
v   c-compiler-arm-linux-gnueabihf  -
p   cpp-4.3-arm-linux-gnueabi       - The GNU C preprocessor
p   cpp-4.4-arm-linux-gnueabi       - GNU C preprocessor
p   cpp-4.4-arm-linux-gnueabihf     - The GNU C preprocessor
p   cpp-4.5-arm-linux-gnueabi       - The GNU C preprocessor
p   cpp-4.5-arm-linux-gnueabihf     - The GNU C preprocessor
p   cpp-4.6-arm-linux-gnueabi       - GNU C preprocessor
p   cpp-4.6-arm-linux-gnueabihf     - GNU C preprocessor
p   cpp-4.7-arm-linux-gnueabi       - GNU C preprocessor
p   cpp-4.7-arm-linux-gnueabihf     - GNU C preprocessor
p   g++-4.3-arm-linux-gnueabi       - The GNU C++ compiler
p   g++-4.4-arm-linux-gnueabi       - GNU C++ compiler
p   g++-4.4-arm-linux-gnueabihf     - The GNU C++ compiler
p   g++-4.5-arm-linux-gnueabi       - The GNU C++ compiler
p   g++-4.5-arm-linux-gnueabihf     - The GNU C++ compiler
p   g++-4.6-arm-linux-gnueabi       - GNU C++ compiler
p   g++-4.6-arm-linux-gnueabihf     - GNU C++ compiler
p   g++-4.7-arm-linux-gnueabi       - GNU C++ compiler
p   g++-4.7-arm-linux-gnueabihf     - GNU C++ compiler
p   gcc-4.3-arm-linux-gnueabi       - The GNU C compiler
p   gcc-4.3-arm-linux-gnueabi-base  - The GNU Compiler Collection (base package)
p   gcc-4.4-arm-linux-gnueabi       - GNU C compiler
p   gcc-4.4-arm-linux-gnueabi-base  - GCC, the GNU Compiler Collection (base pac
p   gcc-4.4-arm-linux-gnueabihf     - The GNU C compiler
p   gcc-4.4-arm-linux-gnueabihf-bas - The GNU Compiler Collection (base package)
p   gcc-4.5-arm-linux-gnueabi       - The GNU C compiler
p   gcc-4.5-arm-linux-gnueabi-base  - The GNU Compiler Collection (base package)
p   gcc-4.5-arm-linux-gnueabihf     - The GNU C compiler
p   gcc-4.5-arm-linux-gnueabihf-bas - The GNU Compiler Collection (base package)
p   gcc-4.5-plugin-dev-arm-linux-gn - Files for GNU GCC plugin development.
p   gcc-4.5-plugin-dev-arm-linux-gn - Files for GNU GCC plugin development.
p   gcc-4.6-arm-linux-gnueabi       - GNU C compiler
p   gcc-4.6-arm-linux-gnueabi-base  - GCC, the GNU Compiler Collection (base pac
p   gcc-4.6-arm-linux-gnueabihf     - GNU C compiler
p   gcc-4.6-arm-linux-gnueabihf-bas - GCC, the GNU Compiler Collection (base pac
p   gcc-4.6-plugin-dev-arm-linux-gn - Files for GNU GCC plugin development.
p   gcc-4.6-plugin-dev-arm-linux-gn - Files for GNU GCC plugin development.
p   gcc-4.7-arm-linux-gnueabi       - GNU C compiler
p   gcc-4.7-arm-linux-gnueabi-base  - GCC, the GNU Compiler Collection (base pac
p   gcc-4.7-arm-linux-gnueabihf     - GNU C compiler
p   gcc-4.7-arm-linux-gnueabihf-bas - GCC, the GNU Compiler Collection (base pac
p   gcc-4.7-plugin-dev-arm-linux-gn - Files for GNU GCC plugin development.
p   gcc-4.7-plugin-dev-arm-linux-gn - Files for GNU GCC plugin development.
p   gccgo-4.7-arm-linux-gnueabi     - GNU Go compiler
p   gccgo-4.7-arm-linux-gnueabihf   - GNU Go compiler
p   gdb-arm-linux-gnueabi           - The GNU Debugger

Si vous désirez installer la chaîne de cross-compilation “classique” (sans support pour l’unité de calculs flottants) tapez par exemple :

1

root@portable-od:~# aptitude install g++-4.7-arm-linux-gnueabi

Si vous désirez une chaîne qui supporte “l’unité de calculs flottants” (hf : hard float en anglais, actuellement seulement si vous êtes sous debian 7 Wheezy), tapez:

1

root@portable-od:~# aptitude install g++-4.7-arm-linux-gnueabihf

Vérifiez votre installation en tapant le début du compilateur puis la touche TAB deux fois (exemple ci-dessous pour le compilateur g++ classique) :

1
2
3
4
5
6
7
8
9
10
11
12
13

root@portable-od:~# arm-linux-
arm-linux-gnueabi-addr2line       arm-linux-gnueabi-gprof
arm-linux-gnueabi-ar              arm-linux-gnueabi-ld
arm-linux-gnueabi-as              arm-linux-gnueabi-ld.bfd
arm-linux-gnueabi-c++filt         arm-linux-gnueabi-ld.gold
arm-linux-gnueabi-cpp-4.7         arm-linux-gnueabi-nm
arm-linux-gnueabi-elfedit         arm-linux-gnueabi-objcopy
arm-linux-gnueabi-g++-4.7         arm-linux-gnueabi-objdump
arm-linux-gnueabi-gcc-4.7         arm-linux-gnueabi-ranlib
arm-linux-gnueabi-gcc-ar-4.7      arm-linux-gnueabi-readelf
arm-linux-gnueabi-gcc-nm-4.7      arm-linux-gnueabi-size
arm-linux-gnueabi-gcc-ranlib-4.7  arm-linux-gnueabi-strings
arm-linux-gnueabi-gcov-4.7        arm-linux-gnueabi-strip

Il faut ensuite établir les liens symboliques vers le nom du cross-compilateur (ci dessous pour la version classique, pour la version avec support des calculs flottants rajouter ‘hf’ coller à ‘gnueabi’ => ‘gnueabihf’) :

1
2

root@portable-od:~# ln -s /usr/bin/arm-linux-gnueabi-gcc-4.7 /usr/bin/arm-linux-gnueabi-gcc
root@portable-od:~# ln -s /usr/bin/arm-linux-gnueabi-g++-4.7 /usr/bin/arm-linux-gnueabi-g++

Premier test de la chaîne de cross-compilation

Vous allez compiler le programme suivant:

1
2
3
4
5
6
7
8

#include <iostream>
using namespace std;
 
int main()
{
   cout << "Cross compilation ARM OK" << endl;
   return 0;
}

Vous taperez donc les commandes suivantes:

1
2
3
4

root@portable-od:~# nano arm-hello.cpp
root@portable-od:~# arm-linux-gnueabi-g++ arm-hello.cpp -o arm-hello
root@portable-od:~# ./arm-hello
-bash: ./arm-hello : fichier binaire impossible à lancer

La dernière commande est intéressante. On a essayé de lancer le binaire “arm-hello” sur une architecture i386 alors que l’on a compilé pour une architecture de type ARM : résultat le binaire ne peut être exécuté !
Pour savoir pour quel architecture un binaire est compilé, vous utilisez la commande ‘file’ (qu’il faut installer si elle n’est pas disponible) :

1
2
3
4

root@portable-od:~# aptitude install file
root@portable-od:~# file arm-hello
arm-hello: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), 
for GNU/Linux 2.6.26, BuildID[sha1]=0x72fa9b146a359e4f866133ed06be736488ea71fa, not stripped

Il y a deux choses intéressantes à signaler :

• le binaire “arm-hello” est bien compilé pour une architecture ARM,
• le binaire est “not stripped”, ce qui signifie qu’il a encore les symboles dans son code pour le débogage. Or si l’on ne désire pas déboger cet exécutable, il faut retirer ce qui n’est pas utile. Le binaire final sera alors plus “léger”.

Ci-dessous, on regarde la taille du binaire avant et après avoir retiré les informations de debogage avec la commande ’strip’ :

1
2
3
4
5

root@portable-od:~# ls -l arm-hello
-rwxr-xr-x 1 root root 7377 janv. 30 16:55 arm-hello
root@portable-od:~# arm-linux-gnueabi-strip arm-hello
root@portable-od:~# ls -l arm-hello
-rwxr-xr-x 1 root root 4244 janv. 30 17:07 arm-hello

On passe de 7377 octets à 4244 octets !

Transférer et exécuter le binaire sur la plateforme ARM

Une fois que vous disposez du binaire, il faut le tester sur la plateforme concernée : RaspberryPi ou Olinuxino. Dans les deux cas, il faut connecter la carte à un réseau ethernet : soit en filaire, soit en Wifi. Il est conseillé pour cette partie d’utiliser une des bornes wifi disponible dans la section et de la configurer pour qu’elle distribue des adresses ip par le serveur dhcp intégré. Votre station de développement sera configuré en dhcp, la carte ARM sera configuré en dhcp soit en filaire, soit en wifi : ainsi les deux machines seront sur le même réseau.
Vérifiez la config réseau sur chacune des machines avec la commande ‘ifconfig’. Testez la commande ping entre les deux machines. Enfin pour envoyer un fichier vers la carte ARM depuis votre station de développement:

1

root@portable_od:~# scp arm-hello root@adresse_ip_machine_arm

Dans un autre terminal vous pouvez vous connecter sur la carte ARM par ssh:

1

root@portable_od:~# ssh root@adresse_ip_machine_arm

Sur la machine ARM, vous pouvez alors lancer l’exécutable :

1
2

root@olinuxino:~# ./arm-hello
Cross compilation ARM OK

• le NI9201 : Module d’entrée analogique 8 voies, ± 10 V, 500 kéch./s, 12 bits
• le NI 9263 : Module de sortie analogique 4 voies, 16 bits, 100 kéch./s, ±10 V
• le NI 9401 : Module d’E/S numériques bidirectionnelles haute vitesse 8 voies, TTL 5 V
• Documentation au format PDF de ces trois modules : docs_modules_9201_9263_9401

Nous allons donc réaliser la mise en œuvre de cet appareil dans les pages suivantes.

Le châssis NI cRIO-9074

Commencez par lire les spécifications techniques de la page d’accueil de ce châssis et la page généraliste sur les compactRIO.

Pour la partie logiciel, il faut installer :

• LabVIEW 2011 ou plus récent et les drivers NI-DAQmx (version 9.6.1 à la date de rédaction de l’article),
• Le driver RIO et les extensions RT (Real-Time) et FPGA (lire ces pages),
• Le driver NI-488 et le driver NI-VISA

Ces trois étapes sont très importantes sinon le logiciel MAX, le gestionnaire de systèmes distribués puis ensuite LabVIEW ne fonctionneront pas avec le compactRIO !

Pour la partie matériel, il vous faut :

• une alimentation 24V/50W continue : livré avec le matériel
• un câble ethernet droit si vous prévoyez de connecter le compactRIO sur le réseau de l’établissement ou un câble croisé si vous voulez relier le compactRIO à votre ordinateur

Sur le coté gauche du compactRIO vous trouvez un ensemble de mini-interrupteurs. Par défaut tous ces interrupteurs sont en position ‘OFF’ :

• SAFE MODE : cet interrupteur permet de lancer le système temps réel du compactRIO en mode normal (OFF) ou en position dégradé (ON). Le passage en mode dégradé est nécessaire si le logiciel embarqué est défectueux. Le logiciel embarqué est mis à jour depuis l’utilitaire MAX.
• CONSOLE OUT : En utilisant un logiciel de terminal (hyperterminal sous Windows ou minicom sous GNU/Linux) vous pouvez visualiser les messages de démarrage du système compactRIO. Pour cela mettre l’interrupteur en position ON et connecter le DB9 du compactRIO à l’aide d’un cable croisé à la voie série du PC (utilisation possible de convertisseur USB-Série). La transmission de données s’effectue en mode 8N1 9600 bits/s. Vous pouvez alors visualiser la configuration IP et la version du logiciel embarqué entre autre. Dans le cadre normal, cet interrupteur est en position OFF.
• IP RESET : Pour réinitialiser la configuration IP du compactRIO, positionner cet interrupteur en position ON puis démarrer l’appareil. Vous pouvez aussi activer cet interrupteur pour “débloquer” un châssis qui a été bloqué par le logiciel MAX. La position normale est donc OFF.
• NO APP : Mettre cet interrupteur en position ON permet de ne PAS exécuter le VI téléchargé dans le chassis.
• USER1 : la position de cet interrupteur peut être lu dans une application d’un utilisateur (VI RT Read Switch).
• NO FPGA : Mettre cet interrupteur en position ON empêche une application FPGA de ce lancer au démarrage de l’appareil. Après le démarrage du compactRIO, vous pourrez téléchargé une nouvelle application FPGA depuis LabVIEW indépendamment de la position de ce bouton.

L’ensemble de DELs sur le coté gauche du compactRIO vous renseigne sur le fonctionnement de celui-ci :

• DEL Power : une alimentation adéquate est connectée au chassis (alimentation continue 19 à 30V - 20W)
• DEL FPGA : cette DEL peut être utilisée dans vos programmes.
• DEL STATUS : cette DEL est éteinte en fonctionnement normal. Cet DEL s’allumera pour signaler des erreurs en clignotant un certain nombre de fois :
  • 1 fois : le châssis n’est pas configuré. Utilisez MAX pour le configurer.
  • 2 fois : le châssis a détecté une erreur dans son logiciel (par exemple aprés une mise à jour interrompue). Reprogrammez le logiciel embarqué depuis MAX.
  • 3 fois : le châssis est en mode dégradé (safe mode) (interrupteur safe mode en position ON ou pas de logiciel installé sur le châssis).
  • 4 fois : Le logiciel a “planté” deux fois ou plus. Cela peut arrivé si le châssis n’a plus assez de mémoire. Modifiez le VI implanté dans le compactRIO pour qu’il consomme moins de mémoire.
  • clignotement continu : le châssis a détecté une erreur irrécupérable. Contactez NI.
  • clignotement continu ou allumage constant : le châssis est configuré en mode DHCP et n’a pu récupérer une adresse IP. Vérifiez le câblage ethernet et que le serveur DHCP est actif.

  DEL USER1 : DEL disponible pour vos applications en utilisant le VI “RT LED”.

Le châssis est équipé de deux ports ethernet : le premier sert à la connexion à votre réseau, le second à chainer plusieurs compactRIO. Dans les huit emplacements disponibles vous pouvez connecter les modules d’entrées/sorties de la série C.

Premier démarrage du compactRIO, configuration IP de l’appareil et installation de logiciels

Câblez l’alimentation au module, suivant le cas connectez le châssis à l’aide d’un câble ethernet au réseau de l’établissement (câble droit) ou à votre PC (câble croisée). La configuration IP de votre établissement ou de votre portable est censé vous être connu. Si votre établissement est équipé d’un serveur DHCP ou si vous utilisé le châssis à la maison pour des tests (boxADSL), le châssis récupérera tout seul une adresse IP.

Nous allons maintenant configurer le châssis en fixant son adresse IP (adresse IP fixe : adapté au fonctionnement en établissement). Si vous avez un adaptateur série-usb et un câble série croisé sous la main, n’hésitez pas à regarder les messages de démarrage du compactRIO dans Hyperterminal (pensez à mettre l’interrupteur CONSOLE sur ON).

Avant toute chose : désactivez le parefeu de Microsoft Windows et éventuellement l’antivirus surtout s’il est lui aussi équipé d’un parefeu !

Lancez le logiciel MAX puis cliquez sur le ‘+’ de “Systèmes déportés” pour qu’une recherche sur le réseau s’effectue pour trouver les appareils compactRIO. Dans la capture ci-dessous, un appareil a été trouvé à l’adresse 192.168.1.67. Si l’appareil n’a pas pu récupérer une adresse ip sur un serveur DHCP, son adresse sera 0.0.0.0 = non configuré.

Dans le même temps, vous pouvez observer la voie série du compactRIO :

                            cRIO-9074 Boot

Copyright 2007-2010 National Instruments Corp.

Bootrom version: 3.1.2f0
Creation date: Jan 25 2011, 13:41:02

Press any key to stop auto-boot...
 0
auto-booting...

boot device          : tffs=0,0
unit number          : 0
processor number     : 0
host name            : lvrt
file name            : /c/ni-rt/system/vxWorks
flags (f)            : 0x8

Selecting PIO mode 6
Attaching to ATA disk device... Using SST NANDrive
Reliance File System Driver
Datalight Reliance v3.2.2 Build 1376BV
VxWorks Edition for ppc603
Copyright (c) 2003-2008 Datalight, Inc.  All Rights Reserved Worldwide.
done.
Loading /c/ni-rt/system/vxWorks...3597136
Starting at 0x10000...

Selecting PIO mode 6
Using SST NANDrive
Reliance File System Driver
Datalight Reliance v3.2.2 Build 1376BV
VxWorks Edition for ppc603
Copyright (c) 2003-2008 Datalight, Inc.  All Rights Reserved Worldwide.

Adding 8519 symbols for standalone.
Mounting onboard storage...
Configuring primary storage device...

-> * Loading vxfpsup.out: vxfpsup
lvusEngine: PPC603 CPU detected...
CPU tick frequency: 33.000259 MHz [Using: 1000 MHz]

VxWorks kernel image
Build time: Dec  2 2011, 16:46:53

LabVIEW Real-Time Executive
Build Time: Dec  4 2011 15:56:37
(C) Copyright 2002-2011 National Instruments Corporation

MAX system identification name: RIO
Initializing network...
Device 1 - MAC addr: 00:80:2F:14:4A:A2 - 192.168.1.67 /24 (primary - static)
Device 2 - MAC addr: 00:80:2F:14:4A:A3 - 0.0.0.0 /32 (static)
* Loading nimdnsResponder.out: nimdnsResponder
Starting mDNSResponder task tMDNS.
* Loading nirtdm.out: nirtdm

Loading LVRT...
* Loading nimdnsResponder.out: nimdnsResponder
* Loading nirtdm.out: nirtdm
* Loading vxfpsup.out: vxfpsup
* Loading tsengine.out: tsengine
Time sync source: rtc now active
* Loading nisvcloc.out: nisvcloc
* Loading nisysrpc.out: nisysrpc
* Loading NiRioRpc.out: NiRioRpc
* Loading NiViSrvr.out: NiViSrvr
* Loading niserial.out: niserial

Welcome to LabVIEW Real-Time 11.0.1

NI-VISA Server 5.1 started successfully.
NI-RIO Server 4.1 started successfully.

On remarque que l’adresse est “statique” donc qu’elle a été fixée par l’utilisateur. Les serveurs VISA et RIO sont fonctionnels.

Pour changer ou fixer l’adresse ip de l’appareil, cliquez sur l’onglet “Paramètres réseau” en bas de la fenêtre de MAX. Vous obtenez alors la page suivante :

Ici on remarque que l’adresse est en mode “statique”. Si vous souhaitez passer votre compactRIO en mode DHCP ou si vous reliez le compactRIO à votre ordinateur à l’aide d’un cable croisé, cliquez sur le bouton à coté de “Configurer l’adresse IPv4″ et choisissez l’option “DHCP ou Link-local”.

Ici on restera en “statique” : il faudra adapter les paramètres IP à votre établissement.

Laissez la deuxième carte ethernet “eth1″ désactivée.

Sauvegardez vos changements par l’icone “Enregistrer” et faites redémarrer l’appareil par l’icone “Redémarrer”. Suivez le “boot” par voie série pour vérifier que les changements IP ont été pris en compte.

Laissez du temps à MAX pour retrouver l’appareil.

Remarque : si le compactRIO n’est pas visible dans les “systèmes déportés” il peut y avoir deux raisons essentielles à cela :

• Les pilotes de matériel sont incomplets, manquants ou non installés : reprendre la procédure d’installation avec les DVD de LabVIEW,
• votre PC et le compactRIO ne sont pas sur le même réseau IP et/ou dans le même adressage IP. Vérifiez vos paramètres IP et faites un “ping” entre votre PC et le compactRIO.

Nous allons maintenant rajouter quelques fonctionnalités à notre compactRIO. Pour cela toujours dans MAX cliquez sur l’item “Logiciels” de votre RIO. Puis en haut de la fenêtre cliquez sur “Ajouter/supprimer des logiciels”. Une nouvelle fenêtre s’ouvre comme dans la capture ci-dessous:

Vous pouvez par exemple rajouter les fonctionnalités “webserver”. Ce qui permettra d’accéder au compactRIO et à ces réglages par l’intermédiaire d’un navigateur. Une fois cette fonctionnalité installée, pointez votre navigateur vers l’adresse ip du compactRIO pour observer le résultat. Rajoutez aussi la fonctionnalité “NI Scan engine” que nous allons utiliser par la suite.

Vérification du fonctionnement des modules de la série C du compactRIO

Le compactRIO est livré avec les trois modules décrit en début d’article. Pour pouvoir les tester à distance, il faut installer l’extension ou le logiciel “NI Scan engine” dans votre compactRIO (voir ci-dessus). Ensuite lancez l’application “Gestionnaire de systèmes distribués” dans le menu “Démarrer”, “National Instrument”.

Le Gestionnaire de systèmes distribués centralise la gestion et la surveillance des systèmes NI sur votre réseau. C’est un outil très utile pour la mise au point et la visualisation rapide des valeurs de vos E/S ainsi que de l’utilisation des ressources systèmes.

Vous devez obtenir l’écran suivant (l’adresse IP peut être différente ainsi que le nombre de compactRIO détecté) :

Vous remarquez que l’on retrouve les trois modules installés sur le châssis. Ici les noms sont “Mod1″, “Mod2″ et “Mod3″. Cliquez sur les différents items afin d’observer ce qu’ils contiennent.

Vérifiez que l’item “Affichage automatique” est coché dans le menu “Affichage” pour avoir des graphes déroulants et des renseignements complémentaires sur l’état des modules.

Vous pouvez connecter un capteur de température analogique LM35 ou un potentiomètre sur une des entrées analogiques pour vérifier qu’elle fonctionne correctement. Ou encore relier AO0 (Analogue Out 0) à AI0 (Analog In 0) à l’aide d’un simple fil…

Premier VI implanté sur le compactRIO

Lancez LabVIEW. Au démarrage si l’installation des logiciels c’est passé correctement, vous devez avoir le “SplashScreen” ci-dessous (notez l’horloge) et un choix supplémentaire en bas de la page d’accueil : Cibles => Projet Temps Réel.

Lors de la création d’un projet, vous pouvez sélectionner le mode de programmation de votre application :

• le mode “Scan interface” qui vous permet d’utiliser vos modules de la série C directement depuis LabVIEW. Les entrées/sorties de chaque module sont accésibles comme de simples variables que vous glissez-déposez sur le diagramme.
• le mode “FPGA interface” qui vous permet de piloter vos modules par le FPGA embarqué. Cette solution nécessite d’avoir installé l’extension FPGA de LabVIEW. C’est la solution pour avoir le maximum de rapidité (temps réel)  au prix d’une mise en oeuvre plus complexe. C’est aussi par ce biais que vous pouvez réaliser les bus I2C, SPI, Série matériel…

Dans notre cas, nous allons utiliser le mode “Scan Interface” (ou alors rajoutez 1H de téléchargement et une heure d’installation pour la solution FPGA).

Créez un “projet vide”, puis dans la fenêtre de projet qui s’est ouverte faites un clic droit sur l’item “Projet”. Choisissez “Nouveau”, “Cibles et périphériques”. Choisissez alors dans la fenêtre qui s’ouvre votre compactRIO (Item Real-Time CompactRIO). La fenêtre de l’explorateur de projet peut se présenter de la manière suivante (à l’adresse ip prés) :

On retrouve votre compactRIO (ici nommé RIO) avec l’adresse IP qui lui est affecté.

Vous retrouvez aussi les trois modules de la série C installés sur le châssis. Dans l’exercice qui suit on se propose de relier AO0 à AI0 à l’aide d’un fil, positionner DIO3 en sortie et DIO7 en entrée puis les relier par un fil et de vérifier que l’ensemble fonctionne correctement.

Ici le module1 (NI9201 : Entrées Analogiques) est déroulé et vous avez accès aux différentes voies (notées AI0 à AI7).

Pour accéder à ces entrées, il suffit de les glisser/déposer sur un diagramme.

Pour créer un VI qui sera implanté dans le compactRIO, il faut faire un clic droit  sur le nom de votre châssis (ici RIO) puis “Nouveau” puis “VI”. Vous retrouvez alors les fenêtres classiques de LabVIEW (face avant et diagramme). Renommez-le si vous le souhaitez puis glissez/déposez AI0 et AO0 sur le diagramme.

Il faut alors mettre en place une boucle de scrutation des entrées/sorties. En environnement temps réel, c’est la boucle “boucle cadencée” qui est utilisée.

Pour utiliser les E/S TOR TTL, il faut tout d’abord les configurer. Le module NI9401 permet de déterminer le sens des E/S par groupe de 4 (D7:D4 et D3:D0). Vous ne pouvez pas gérer individuellement chaque broche. Ce réglage est accessible en faisant un clic droit sur l’item “Mod3″ (NI9401) puis en choisissant “Propriétés”. Dans la fenêtre qui apparaît, choisissez le sens des E/S :Vous pouvez alors glisser/déposer les E/S numériques dans le diagramme.

Vous réalisez donc la face avant suivante et le diagramme associé :

Un mot sur la boucle cadencé : il faudra régler ces paramètres en double-cliquant sur son bloc de gauche. Les deux paramètres à régler sont :

• la source de cadencement de la boucle : mettre “Synchroniser avec le moteur de balayage”,
• Dans les attributs de cadencement de la boucle : régler la période (1: envoi des données à travers le réseau à chaque synchronisation de boucle, XX: envoi toutes les XX synchronisation de boucle). Dans le cas de phénomènes qui évoluent lentement il est donc inutile d’envoyer le résultat du capteur à chaque tour de boucle pour ne pas engorger le réseau ethernet. Le réglage du temps de balayage se fait en cliquant avec le bouton droit sur le nom de votre appareil dans l’arbre de projet (ici RIO) puis choisir “Propriétés”. Dans la fenêtre qui s’ouvre choisir l’item “Moteur de balayage” : vous pouvez alors modifier la période de balayage sur la partie droite de la fenêtre.

Vous pouvez observez l’effet du “dt” en le modifiant dans la boucle cadencée et en regardant à quel allure évolue l’indicateur “Nb d’itérations”.

Fonctionnalités étendues du module NI9401

Ce module permet de configurer ces 8 E/S suivant différentes configurations visibles ci dessous (clic droit sur le module NI9401 dans l’arbre de projet puis “Propriétés”. Dans la fenêtre qui vient de ’s’ouvrir sélectionnez “Specialty Digital Configuration”):

Vous avez donc le choix entre :

• des compteurs rapides (jusqu’à 1MHz),
• des sorties MLI,
• la gestion d’encodeur en quadrature.

Mais vous ne pouvez pas “mixer” ces configurations. De plus toutes les E/S sont concernées : c’est à dire que vous avez 8 compteurs ou 8 MLI ou 2 gestion d’encodeur.

Réalisez le VI ci-dessous. Il permet juste de générer un signal MLI (à l’origine je voulais piloter un petit servo moteur et faire l’alimentation avec une des sorties MLI en la mettant à 100% !) :

Vous prendrez pour la PWM1 une période de 50Hz. Le réglage de la MLI se fait avec une valeur comprise entre 0 et 100. Vérifiez à l’oscilloscope l’allure de la courbe et appréciez la justesse des temps ! (même en augmentant la fréquence de la MLI !

Lectures pour approfondir vos connaissances…

Je n’ai fait qu’effleurer les possibilités du compactRIO. Il faut explorer plus avant et en particulier avec le FPGA. Je vous conseille de lire les PDFs joints à la formation : “Getting started with CompactRIO and LabVIEW” et le guide du développeur du compactRIO (en anglais également)

Il faut tout d’abord vérifier que les options de compilation du noyau concernant la gestion des GPIO à travers le système de fichier “sysfs” sont activées.

Après démarrage de la carte TQ6410, nous pouvons vérifier que nous avons accès aux GPIOs en tapant:

root@TQ6410-Iris:~# ls /sys/class/gpio/
export       gpiochip137  gpiochip178  gpiochip38  gpiochip9
gpiochip0    gpiochip144  gpiochip194  gpiochip55  gpiochip91
gpiochip104  gpiochip161  gpiochip26   gpiochip63  unexport
gpiochip121  gpiochip17   gpiochip32   gpiochip74

On ne trouve pas directement d’accès aux broches (répertoire gpioXXX) mais des répertoires gpiochipXXX. Pour comprendre le fonctionnement des GPIOs il faut lire la documentation fournie dans les sources du noyau ou sur le site kernel.org : http://www.kernel.org/doc/Documentation/gpio.txt

Ci-dessous un extrait qui correspond à nos attentes:

Paths in Sysfs
--------------
There are three kinds of entry in /sys/class/gpio:

   -	Control interfaces used to get userspace control over GPIOs;

   -	GPIOs themselves; and

   -	GPIO controllers ("gpio_chip" instances).

That's in addition to standard files including the "device" symlink.

The control interfaces are write-only:

    /sys/class/gpio/

    	"export" ... Userspace may ask the kernel to export control of
		a GPIO to userspace by writing its number to this file.

		Example:  "echo 19 > export" will create a "gpio19" node
		for GPIO #19, if that's not requested by kernel code.

    	"unexport" ... Reverses the effect of exporting to userspace.

		Example:  "echo 19 > unexport" will remove a "gpio19"
		node exported using the "export" file.

GPIO signals have paths like /sys/class/gpio/gpio42/ (for GPIO #42)
and have the following read/write attributes:

    /sys/class/gpio/gpioN/

	"direction" ... reads as either "in" or "out".  This value may
		normally be written.  Writing as "out" defaults to
		initializing the value as low.  To ensure glitch free
		operation, values "low" and "high" may be written to
		configure the GPIO as an output with that initial value.

		Note that this attribute *will not exist* if the kernel
		doesn't support changing the direction of a GPIO, or
		it was exported by kernel code that didn't explicitly
		allow userspace to reconfigure this GPIO's direction.

	"value" ... reads as either 0 (low) or 1 (high).  If the GPIO
		is configured as an output, this value may be written;
		any nonzero value is treated as high.

		If the pin can be configured as interrupt-generating interrupt
		and if it has been configured to generate interrupts (see the
		description of "edge"), you can poll(2) on that file and
		poll(2) will return whenever the interrupt was triggered. If
		you use poll(2), set the events POLLPRI and POLLERR. If you
		use select(2), set the file descriptor in exceptfds. After
		poll(2) returns, either lseek(2) to the beginning of the sysfs
		file and read the new value or close the file and re-open it
		to read the value.

	"edge" ... reads as either "none", "rising", "falling", or
		"both". Write these strings to select the signal edge(s)
		that will make poll(2) on the "value" file return.

		This file exists only if the pin can be configured as an
		interrupt generating input pin.

	"active_low" ... reads as either 0 (false) or 1 (true).  Write
		any nonzero value to invert the value attribute both
		for reading and writing.  Existing and subsequent
		poll(2) support configuration via the edge attribute
		for "rising" and "falling" edges will follow this
		setting.

GPIO controllers have paths like /sys/class/gpio/gpiochip42/ (for the
controller implementing GPIOs starting at #42) and have the following
read-only attributes:

    /sys/class/gpio/gpiochipN/

    	"base" ... same as N, the first GPIO managed by this chip

    	"label" ... provided for diagnostics (not always unique)

    	"ngpio" ... how many GPIOs this manges (N to N + ngpio - 1)

Regardons ce que l’on obtient avec les commandes suivantes sur le contrôleur GPIO 137 :

root@TQ6410-Iris:~# cat /sys/class/gpio/gpiochip137/
base       label      ngpio      subsystem/ uevent
root@TQ6410-Iris:~# cat /sys/class/gpio/gpiochip137/label
GPM
root@TQ6410-Iris:~# cat /sys/class/gpio/gpiochip137/base
137
root@TQ6410-Iris:~# cat /sys/class/gpio/gpiochip137/ngpio
6

Le label contient GPM : c’est le nom du port de sortie du S3C6410 donc le port M. Si je regarde sur le schéma électrique de la carte (disponible au format PDF en fin d’article), je trouve que le port M est constitué de 6 broches (GPM0 à GPM5) et que les lignes GPM0 à GPM3 sont aussi identifiées par nLED1 à nLED4 (ce sont des DELs disponibles sur la carte pilotées au travers d’un transistor). L’adresse de base de ce port commence à 137. Donc la première broche de ce port (GPM0) aura comme numéro 137. “ngpio” contient le nombre d’E/S de ce port : ici 6 ce qui correspond bien au schéma électrique. La broche GPM5 aura donc comme numéro 142.

Il faut maintenant créer l’accès à une broche. Par exemple la GPM0 donc la numéro 137 (ainsi on pourra visualiser le fonctionnement sur une DEL). Il faut donc “créer” cette broche puis regarder ce que le noyau met à notre disposition:

root@TQ6410-Iris:~# echo 137 > /sys/class/gpio/export               

root@TQ6410-Iris:~# ls /sys/class/gpio/

export       gpiochip121  gpiochip17   gpiochip32  gpiochip74

gpio137      gpiochip137  gpiochip178  gpiochip38  gpiochip9

gpiochip0    gpiochip144  gpiochip194  gpiochip55  gpiochip91

gpiochip104  gpiochip161  gpiochip26   gpiochip63  unexport

root@TQ6410-Iris:~# ls /sys/class/gpio/gpio137/

direction  subsystem  uevent  value

Si la création de la broche s’est dérouler correctement un nouveau répertoire est créé avec le nom de la broche (ici gpio137). Le répertoire contient alors tout ce qu’il faut pour piloter cette broche. “direction” permet de mettre cette broche en entrée ou en sortie (en écrivant “in” ou “out”). “value” permet de positionner (en écrivant ‘0′ ou ‘1′) ou de lire la valeur de la broche. Les commandes suivantes permettent de positionner la broche 137 en sortie puis d’écrire un ‘0′ ou un ‘1′ sur celle-ci :

root@TQ6410-Iris:~# echo "out" > /sys/class/gpio/gpio137/direction

root@TQ6410-Iris:~# echo "1" > /sys/class/gpio/gpio137/value

root@TQ6410-Iris:~# echo "0" > /sys/class/gpio/gpio137/value

Les dernières commandes allument/éteignent la del LED1 sur la carte. Il suffit maintenant de faire des opérations de lecture/écriture sur fichier pour commander une sortie ou lire une entrée. Notez qu’après un redémarrage les “gpio” ne sont pas conservés.

Pour compléter l’article, il faut lire Howto use GPIO signals et en particulier le code C de gestion des GPIOs .

• le coût d’une carte Arduino est faible (20€), une documentation abondante existe sur Internet
• il n’y a pas de programmation à faire coté Arduino : le “firmware” est fourni par NI puis programmé dans la mémoire flash du microcontroleur de l’arduino
• le coût d’un “shield” maison reste raisonnable et permet d’avoir exactement ce que l’on souhaite comme capteurs, E/S…
• La programmation de cette carte avec LabVIEW suit les “grands classiques” : ouverture d’un bus de communication, configuration des entrées/sorties, lecture des entrées, traitement numérique,  pilotage des sorties, fermeture du bus de communication
• Chaque étudiant travaille sur “sa” carte à son rythme !  Éventuellement il peut acheter le matériel nécessaire pour faire le TP chez lui (bon là je rêve un peu

Un document au format OpenOffice Writer est à télécharger et à compléter en fin d’article. Abordons maintenant la description de la carte arduino UNO et du shield “TP LIFA”…

La carte Arduino UNO R3

Il suffit de se rendre sur le site officiel : http://www.arduino.cc/ et éventuellement sur les pages françaises mais celles-ci ne sont pas forcement à jour : http://www.arduino.cc/fr/.  La carte est décrite sur http://arduino.cc/en/Main/ArduinoBoardUno. En résumé et pour notre cas d’utilisation :

• Broches d’alimentation : 5V, 3,3V, GND
• 6 broches d’entrées analogiques numérotées A0 à A5 : ces broches permettront de numériser un signal analogique compris entre 0V et 5V issu d’un capteur par exemple.
• 13 broches d’entrées/sorties “tout ou rien” (TOR) numérotées de 0 à 13. Les broches qui sont précédés du caractère ‘~’ (3, 5, 6, 9, 10 et 11) peuvent être configurés en mode MLI (Modulation de Largeur d’Impulsion) ou PWM en anglais (Pulse Width Modulation). Ce mode est décrit sur Wikipédia. Il permet par exemple de faire varier la vitesse d’un moteur à courant continu ou encore sur notre “shield” l’intensité lumineuse d’une DEL. Les broches 0 et 1 permettent de réaliser une liaison série avec un PC par exemple, elles sont utilisées ici pour dialoguer avec LabVIEW. Les bus I2C ou SPI ne seront pas utilisés ici.

Complétez le document OpenOffice Writer - partie “Généralités”

La carte d’extension (shield) TP LIFA

Cette carte embarque les éléments suivants:

• 3 interrupteurs pour réaliser des entrées logiques TOR
• 3 DELs pour réaliser des sorties TOR (une rouge, une orange, une verte)
• une DEL RGB pour réaliser des sorties pilotables en mode MLI ou TOR. Cela permet d’obtenir n’importe quelle couleur.
• un capteur de température analogique de type LM35 (documentation)
• un potentiomètre qui permet de fixer une tension par exemple pour réaliser une consigne
• une photorésistance montée dans un pont résistif qui permet donc de capter l’éclairement
• une sortie MLI envoyée dans un filtre passe-bas : cela permet d’obtenir une sortie analogique 0V-5V. On pourra donc créer toute forme de signaux analogiques. Cette sortie peut être rebouclée par l’intermédiaire d’un cavalier sur une entrée analogique pour vérifier la forme d’onde générée

Photographie de la carte:

Schéma électrique:

Implantation:

Complétez le document partie “Carte d’extension”

Exercice 1 : Prise en main - E/S TOR

A l’aide de l’article sur LIFA et de la documentation papier sur LabVIEW, réalisez la face avant suivante qui permet de piloter en tout ou rien les DELs rouge, orange et verte ainsi que le diagramme associé:

L’indicateur permet de choisir la voie série sur laquelle la carte arduino est reliée. Le bouton “Stop” permet d’arrêter la boucle “while” du diagramme. Les boutons de la face avant sont du type “Commutation jusqu’au relâchement”.

Rajoutez ensuite sur la même face avant des voyants qui permettent de lire l’état des boutons poussoirs :

Exercice 2 - Lecture d’une entrée analogique - Capteur de température

Complétez la face avant précédente ainsi que le diagramme associé pour lire le capteur de température :

Veuillez noter que l’axe des Y est gradué en °C.

Pour lisser le graphique de température (élimination des parasites), vous afficherez la moyenne des cinq dernières mesures.

Modifiez le diagramme pour que la del verte s’allume si la température est comprise entre 18°C et 21°C, la del orange entre 21°C et 24°C, la del rouge au dessus de 24°C (utilisez le sous-vi “Dans la gamme”).

Exercice 3 - Signaux MLI ou PWM - DEL RGB

Réalisez la face avant suivante qui permet de commander l’intensité lumineuse de chacune des dels de la DEL RGB :

Vérifiez le bon fonctionnement de votre montage en actionnant les curseurs de chacune des dels. Vous constatez que lorsqu’on est à 0 la del à l’éclairement maximal et à 255 qu’elle est éteinte. Modifiez votre diagramme afin que la valeur 0 éteigne la del et que la valeur 255 réalise l’éclairement maximal.

Exercice 3.1

Réalisez une face avant afin de visualiser sur un graphe déroulant la tension issu de la photorésistance (lecture d’une entrée analogique). Vérifiez le bon fonctionnement de ce graphe en cachant à l’aide de votre doigt la photorésistance. Vous souhaitez réaliser un éclairage automatique à l’aide de la DEL RGB en fonction de la luminosité. En pleine obscurité, on souhaite avoir l’intensité blanche maximale (255 sur les dels RGB). En plein soleil, la del RGB sera éteinte. Entre les deux l’intensité de la del RGB varie linéairement afin de produire une lumière blanche (même valeur sur les dels RGB).

Exercice 3.2

Réalisez un VI qui en fonction de la température pilote la del RGB avec les contraintes suivantes :

• en dessous de 10°C : la del bleue est à son maximum d’intensité, les autres dels sont éteintes,
• à 20°C : la del verte est à son maximum, les autres dels sont éteintes,
• à 30°C et au dessus : la del rouge est à son maximum, les autres dels sont éteintes,
• entre 10°C et 20°C : vous ferez un mélange des couleurs bleu et verte proportionnellement à la température,
• entre 20°C et 30°C:  vous ferez un mélange des couleurs verte et rouge proportionnellement à la température.

Exercice 4 - Génération de signaux - DEL RGB

Afin de réaliser un mélange harmonieux des couleurs, il faut piloter chacune des dels RGB en sinusoidale ! De plus chacun des signaux sera déphasé de 120° (3 x 120° = 360°). Vous devez donc générer les signaux suivants :

En fonction de ce que vous avez déjà étudié, mémorisez dans un tableau les valeurs des trois sinusoïdes puis envoyez-les vers les dels RGB. Pensez à ralentir la boucle d’envoi avec un VI “Attendre”. Dans un second temps, faites varier la vitesse de changement des couleurs soit avec le potentiomètre disponible sur la carte, soit avec la luminosité.

Exercice 5 - Datalogger - Traitements des chaînes et des fichiers

Vous allez réaliser un “datalogger” de température. Un datalogger mémorise la donnée d’un capteur avec la date et l’heure courante, le tout est généralement visualisé à l’écran et sauvegardé dans un fichier. Pour découvrir les VIs de chaine et de fichiers, il faut lire le document de présentation de LabVIEW. On se propose de réaliser la face avant suivante:

Vous respecterez EXACTEMENT le format de sortie de la zone de texte. Une fois que ce système est fonctionnel, sauvegardez les mêmes données dans un fichier (le nom du fichier sera saisi par l’utilisateur sur la face avant.

Compilation d’un noyau avec support USB (clavier, souris, convertisseurs USB/Série)

Le problème est que j’avais optimisé le noyau linux de la carte en taille et en fonctionnalité. Le support USB n’était donc pas activé dans le noyau. La première des choses à faire est donc de modifier la configuration du noyau et relancer une compilation. Les options à activer sont les suivantes (que j’ai déterminé après moultes essais/erreurs) :

• Device Drivers
  • USB support
    • Support for Host-side USB
      • USB annouce new devices (pour voir les messages du sous-système USB dans les messages noyau)
      • OHCI HCD support (support matériel pour le bus USB1.1)
  • HID Devices
    • Generic HID support
    • USB Human Interface Device (full HID) support
    • Special HID drivers (je n’ai pas testé sans cette option, peut-être est-ce inutile)
      • Load all HID drivers on hid core load + tous les drivers (en particulier Samsung)
  • Input device support
    • Mouse interface (accés à la souris par /dev/input/mice)
    • Keyboards
      • AT keyboard
    • Mice
      • PS/2 mouse + les options des différents constructeurs

Pour disposer de la configuration de compilation du noyau on peut l’inclure dans celui-ci. Je vais aussi avoir besoin d’utiliser des convertisseurs USB/Série. J’ai donc aussi activé:

• General Setup -> Kernel .config support
  • Enable access to .config through /proc/config.gz
• Device driver -> USB support
  • USB Serial Converter support
    • USB CP2101 UART bridge controller
    • USB FTDI Single Port Serial Driver
    • USB Prolific 2303 Single Port Serial Driver

On lance alors la compilation puis l’implantation du nouveau nouyau comme décrit dans les articles précédents. Au niveau des messages du noyau j’obtiens donc quelques lignes supplémentaires:

[21474536.995000] ohci_hcd: USB 1.1 ‘Open’ Host Controller (OHCI) Driver
[21474536.995000] s3c2410-ohci s3c2410-ohci: S3C24XX OHCI
[21474537.000000] s3c2410-ohci s3c2410-ohci: new USB bus registered, assigned bus number 1
[21474537.005000] s3c2410-ohci s3c2410-ohci: irq 79, io mem 0×74300000
[21474537.065000] usb usb1: configuration #1 chosen from 1 choice
[21474537.070000] hub 1-0:1.0: USB hub found
[21474537.070000] hub 1-0:1.0: 2 ports detected
[21474537.080000] usb usb1: New USB device found, idVendor=1d6b, idProduct=0001
[21474537.085000] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[21474537.090000] usb usb1: Product: S3C24XX OHCI
[21474537.095000] usb usb1: Manufacturer: Linux 2.6.28.6-IRIS-Turgot-O.Dartois ohci_hcd
[21474537.100000] usb usb1: SerialNumber: s3c24xx
[21474537.105000] usbcore: registered new interface driver usbserial
[21474537.110000] usbserial: USB Serial Driver core
[21474537.115000] USB Serial support registered for cp2101
[21474537.120000] usbcore: registered new interface driver cp2101
[21474537.125000] cp2101: v0.07:Silicon Labs CP2101/CP2102 RS232 serial adaptor driver
[21474537.130000] USB Serial support registered for FTDI USB Serial Device
[21474537.135000] usbcore: registered new interface driver ftdi_sio
[21474537.140000] ftdi_sio: v1.4.3:USB FTDI Serial Converters Driver
[21474537.145000] USB Serial support registered for pl2303
[21474537.155000] usbcore: registered new interface driver pl2303
[21474537.160000] pl2303: Prolific PL2303 USB to serial adaptor driver
[21474537.165000] mice: PS/2 mouse device common for all mice
[...]
[21474537.625000] usb 1-1: configuration #1 chosen from 1 choice
[21474537.625000] hub 1-1:1.0: USB hub found
[21474537.630000] hub 1-1:1.0: 4 ports detected
[21474537.645000] usb 1-1: New USB device found, idVendor=05e3, idProduct=0606
[21474537.645000] usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[21474537.650000] usb 1-1: Product: USB2.0 Hub
INIT: version 2.88 booting
[21474537.930000] usb 1-1.3: new low speed USB device using s3c2410-ohci and address 3
Using makefile-style concurrent boot in runlevel S.
[21474538.025000] usb 1-1.3: no configurations
[21474538.025000] usb 1-1.3: can’t read configurations, error -22
[21474538.100000] usb 1-1.3: new low speed USB device using s3c2410-ohci and address 4
[21474538.220000] usb 1-1.3: configuration #1 chosen from 1 choice
[21474538.235000] input: Logitech USB-PS/2 Optical Mouse as /devices/platform/s3c2410-ohci/usb1/1-1/1-1.3/1-1.3:1.0/input/input1
[21474538.280000] generic-usb 0003:046D:C03E.0001: input: USB HID v1.10 Mouse [Logitech USB-PS/2 Optical Mouse] on usb-s3c24xx-1.3/input0
[21474538.285000] usb 1-1.3: New USB device found, idVendor=046d, idProduct=c03e
[21474538.295000] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[21474538.300000] usb 1-1.3: Product: USB-PS/2 Optical Mouse
[21474538.310000] usb 1-1.3: Manufacturer: Logitech
[21474538.395000] usb 1-1.4: new low speed USB device using s3c2410-ohci and address 5
[21474538.520000] usb 1-1.4: configuration #1 chosen from 1 choice
[21474538.530000] input: LITEON Technology USB Multimedia Keyboard as /devices/platform/s3c2410-ohci/usb1/1-1/1-1.4/1-1.4:1.0/input/input2
[21474538.580000] generic-usb 0003:046D:C312.0002: input: USB HID v1.10 Keyboard [LITEON Technology USB Multimedia Keyboard] on usb-s3c24xx-1.4/input0
[21474538.590000] usb 1-1.4: New USB device found, idVendor=046d, idProduct=c312
[21474538.590000] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[21474538.595000] usb 1-1.4: Product: USB Multimedia Keyboard
[21474538.600000] usb 1-1.4: Manufacturer: LITEON Technology

Au moment du test j’avais un hub usb2 défaillant mais j’ai quand même pu y brancher un clavier LiteON et une souris Logitech USB. Bon visiblement le matériel est reconnu. Voyons si tout se passe correctement dans l’espace utilisateur…

Support d’une souris USB, d’un clavier AZERTY USB dans l’espace utilisateur pour Qt Embedded

Sur l’écran de la TQ6410, j’ai le programme login qui attend une connexion. Je commence à taper et des caractères apparaissent à l’écran ! Le clavier est reconnu mais en mode QWERTY. Il va donc falloir installer tout ce qu’il faut pour passer en mode “francais”:

root@TQ6410-Iris:~# aptitude install keyboard-configuration
root@TQ6410-Iris:~# aptitude install console-setup
root@TQ6410-Iris:~# aptitude install console-data

Lors de la configuration des différents paquets précédents j’ai choisi à chaque fois les options ayant rapport avec le clavier français (fr-latin9). Après redémarrage, je dispose d’un clavier AZERTY. Pour ce qui est de la souris, je voulais vérifier que j’obtenais bien des données sans lancer un programme graphique. Une solution peut être la commande suivante qui affiche en héxadécimal les données reçues :

root@TQ6410-Iris:~# cat /dev/input/mice | hexdump

Si vous recevez des données lorsque vous bougez la souris, il y a de fortes chances que ca fonctionne .

Bon maintenant il faut lancer un programme Qt qui active le framebuffer et qui à besoin de la souris et du clavier. J’ai donc recompilé mon programme de test de la carte ES ModBUS pour Qt embedded. Cependant avant de lancer le programme il faut lire la documentation de Qt sur les problèmes de clavier et de souris pour le monde embarqué :

• http://doc-snapshot.qt-project.org/4.8/qt-embedded-pointer.html pour la gestion de la souris
• http://doc-snapshot.qt-project.org/4.8/qt-embedded-charinput.html pour la gestion du clavier

Tout cela nous conduit à fixer les variables d’environnement suivantes:

export QWS_KEYBOARD=”TTY:/dev/tty0:keymap=fr.qmap”
export QWS_MOUSE_PROTO=”IntelliMouse:/dev/input/mice”

On lance l’application graphique. La souris réagit correctement mais le clavier est un QWERTY ! En sortant de l’application j’ai un message d’erreur qui me dit que le “fr.qmap” n’a pas été trouvé, c’est pour cette raison qu’il a basculé sur un clavier QWERTY. Recherche sur internet et il faut lire la page suivante : http://doc-snapshot.qt-project.org/4.8/qt-embedded-kmap2qmap.html

Donc sur ma station de développement dans le répertoire de Qt-everywhere je dois avoir un répertoire “tools” qui contient un utilitaire qui se nomme “kmap2map” : c’est bien le cas dans le répertoire éponyme. Je croos-compile donc cet utilitaire pour la TQ6410. L’exécutable, une fois compilé, se trouve dans “bin”. Je transfert le programme par scp et l’exécute sans paramètre pour visualiser l’aide. En gros il faut faire “./kmap2qmap clavier.kmap clavier.qmap“. Pour ma part les claviers sont disponibles dans “/usr/share/keymaps/i386/azerty” (debian squeeze 6.0.4). Je tape donc les commandes suivantes:

root@TQ6410-Iris:~# cp /usr/share/keymaps/i386/azerty/fr-latin9.kmap.gz .
root@TQ6410-Iris:~# gunzip fr-latin9.kmap.gz
root@TQ6410-Iris:~# ./kmap2qmap fr-latin9.kmap fr.qmap

La génération du fichier “fr.qmap” vous donnera sûrement des erreurs ne pas en tenir compte. Relancez votre application, cette fois-ci le clavier doit être en français (du moins c’est le cas pour moi !)

Conclusion

On peut donc maintenant interagir avec les applications graphiques Qt et ceci sans dalle tactile. Cependant il ne faut pas perdre de vue que c’est la dalle tactile qui doit être utilisée in-fine !!!

LIFA et manette Nunchuck

La manette nunchuck est une des deux manettes utilisées avec la console de jeu Wii de Nintendo. Cette manette se présente de la manière suivante (les informations proviennent essentiellement d’une documentation nommée ZX-Nunchuck que j’ai corrigé) :

Cette manette est équipée de deux boutons tout ou rien (bouton C et Z), un joystick analogique deux axes et un accéléromètre trois axes. Les trois axes sont orientés de la manière suivante:

Vous remarquez sur le connecteur que l’on retrouve des noms de signaux connus (SCL et SDA). En effet cette manette peut s’interroger par l’intermédiaire d’un bus I2C. Bien que l’alimentation nominale soit 3,3V, les lignes SCL et SDA sont tolérantes au +5V. Ne coupez pas le connecteur en bout de manette, des fils rigides suffisent pour réaliser la connexion avec l’arduino. Comme tout périphérique sur le bus I2C, cette manette a une adresse fixe qui est définie ci-dessous :

Soit en binaire 0b1010010 ou 0×52 en hexadécimal ou 82 en décimal. Il faut ensuite initialiser la communication avec la manette. Vous trouverez sur Internet plusieurs solutions ( http://www.windmeadow.com/node/42 par ex. )mais une est plus simple que les autres ( http://arduino.cc/playground/Main/WiiChuckClass ) car les données retournées ne sont pas codées. La séquence d’initialisation est donc la suivante :

1. Écrire à l’adresse 0×52 les valeurs 0xF0, 0×55
2. pause de 1 ms
3. Écrire à l’adresse 0×52 les valeurs 0xFB, 0×00

Pour obtenir les données de la nunchuck :

1. Écrire à l’adresse 0×52 la valeur 0×00
2. Lire à l’adresse 0×52 les 6 octets de résultat

Les 6 octets représentent les données suivantes:

• Octet 1 : Joystick - Axe X : un octet donc de 0 à 255
• Octet 2 : Joystick - Axe Y : un octet donc de 0 à 255
• Octet 3 : Accéléromètre - Axe X : un octet représentant les 8 bits de poids fort sur les 10 bits possibles, si on utilise que cet octet on aura des valeurs de 0 à 255
• Octet 4 : Accéléromètre - Axe Y : 8 bits de poids fort sur les 10 bits possibles : de 0 à 255
• Octet 5 : Accéléromètre - Axe Z : 8 bits de poids fort sur les 10 bits possibles : de 0 à 255
• Octet 6 : du MSB au LSB : 2 bits pour l’axe Z de l’accéléromètre, concaténé avec les 8 bits précédents vous pouvez obtenir 10 bits de résolution soit des valeurs de 0 à 1023. 2 bits pour l’axe Y de l’accéléromètre, 2 bits pour l’axe X de l’accéléromètre. 1 bit qui représente l’état du bouton C : 0:enfoncé, 1:relâché.  1 bit qui représente l’état du bouton Z : 0:enfoncé, 1:relâché.

Nous avons tout ce qu’il faut pour travailler avec cette manette. On commence donc par le câblage :

J’ai testé directement avec le nunchuck sans mettre de résistance de rappel sur le bus i2c. Cela semble fonctionner normalement. On peut alors réaliser la face avant suivante sous LabVIEW pour tester toutes les fonctionnalités de la manette :

L’adresse du capteur doit être modifiée à 0×52 (82). Le potentiomètre permet de réaliser une mesure toutes les 50ms à 500ms. Le tableau “Données I2C” permet d’afficher les données brutes reçues du bus i2c. Deux dels permettent d’afficher l’état des boutons C et Z ( ce sont des booléens). Enfin deux graphiques déroulants permettent d’afficher l’évolution des données du joystick et de l’accéléromètre. Avant de regarder le diagramme ci-dessous, essayez de le réaliser par vous même…Ok le digramme peut se présenter de la manière suivante :

1. Initialisation de la communication avec l’arduino
2. Initialisation du bus i2c en mode maitre
3. Initialisation du Nunchuck avec l’écriture des valeurs définies dans la séquence vu  ci-dessus
4. Boucle infinie avec une temporisation gérée par le potentiomètre en face avant
5. Demande d’une lecture du nunchuck (écriture de la valeur 0)
6. Lecture des 6 octets attendus et affichage des données brutes dans le tableau. Ces valeurs sont dans un tableau 1D d’octets non signés
7. On extrait de ce tableau les coordonnées X et Y du joystick (indice 0 et 1 du tableau). On assemble ensuite ces valeurs pour le graph déroulant
8. De la même manière on extrait les valeurs X,Y et Z de l’accéléromètre (indice 2,3 et 4). On travaille donc ici avec les bits de poids fort issu de l’accéléromètre.
9. Enfin on récupère l’octet 5 qui contient l’état des boutons. On fait un ET logique entre cette valeur et la valeur 1 (0b0000 0001). Le résultat sera égale à 1 si le bouton Z n’est pas appuyé, 0 sinon. On traite de la même manière le bouton C avec un masque fixé à 2 (0b0000 0010).
10. On sort de la boucle infinie avec le bouton STOP.
11. On ferme la connexion avec l’arduino ou on affiche les éventuelles erreurs.

Une vidéo pour vous rendre compte de ce que ça donne (video réalisé avec le logiciel wink : http://www.debugmode.com/wink/ ): Video Face avant LabVIEW pour Nunchuck

Commande d’une del rgb avec une manette nunchuck

Nous nous fixons comme but la commande d’une del RGB en fonction des valeurs des axes X,Y et Z de l’accéléromètre du nunchuck. Pour faire varier la luminosité de chaque del nous utiliserons la technique de la modulation MLI (ou PWM). Vous avez normalement tous les éléments pour mener à bien ce projet. La del RGB a comme référence chez Farnell 1168585. Le brochage de cette del est le suivant :

Le câblage peut se présenter de la manière suivante…des photos car tous les composants ne sont pas disponibles dans fritzing. On utilise les canaux PWM 3,5 et 6 de la carte arduino pour commander individuellement les dels R,V et B. Cliquez sur les photos pour les avoir en plein écran et observer de manière plus fine les détails :

La face avant peut-être celle que l’on a vu précédemment en simplifié :

Par contre le diagramme doit être modifié :

Les sous-VI nouveaux sont ceux fournis directement par la palette arduino ( sous VI : RGB Led configure et RGB Led write) et la conversion des trois valeurs RGB issues de la nunchuck en couleur (sous VI RGB en couleur). Cela fonctionne mais je suis relativement déçu de l’effet obtenu. En effet même avec une del “diffusée” le mélange des couleurs n’est pas correct, on voit encore trop les points lumineux de chaque del. D’autres part les variations sont trop faibles et surtout le point de repos de chaque axe de l’accéléromètre est trop élevé. Il faudrait ramener autour de 0 pour avoir de plus grande variation de l’intensité lumineuse. Si vous réalisez le montage vous verrez mieux de quoi je parle.

Pour tester de manière plus convaincante ce montage, remplacez les valeurs de l’accéléromètre par celle du joystick analogique…Le mieux est encore de faire un montage pour piloter deux moteurs en sens et en vitesse avec le joystick !

LIFA et le bus SPI : anneau de dels

Parmi les VI que propose LIFA, nous n’avons pas encore testé le SPI (Serial Peripheral Interface). Ça tombe bien, j’avais réalisé un montage honteusement copié sur http://mayhewlabs.com/products/rotary-encoder-led-ring mais je ne l’avais jamais testé. En gros et sans s’occuper de l’encodeur il s’agit de piloter 16 dels avec le circuit spécialisé TLC5925 de chez TI. On peut réaliser de beaux effet lumineux mais aussi montrer graphiquement l’évolution d’un encodeur (reportez-vous aux différentes vidéos du site officiel). Il s’agit juste d’envoyer les bonnes valeurs dans un registres à décalage 16 bits puis de valider le tout au bon moment ! Un chronogramme pour fixer les idées :

Alors il nous faut une horloge (signal CLK ou SCK), une entrée de donnée coté TLC (SDI) donc sortie de données coté carte arduino (signal MOSI), un signal pour valider le verrou à l’instant opportun (signal LE actif à l’état haut, une sortie numérique sur la carte arduino). Le signal OE actif à l’état bas peut être directement câblé à la masse si vous souhaitez un éclairage maximal des dels ou à une sortie MLI de l’arduino pour régler l’intensité lumineuse. Donc il ne nous faut que 3 ou 4 fils pour piloter ce module.

Ce module ce présente de la manière suivante (schéma électrique, implantation, photographie) :

Pour ceux qui sont attentifs il y a une petite différence entre les photos et le typon…j’ai fait disparaitre le petit régulateur de tension !

Sur ce module J1 est le connecteur principal. Les broches qui nous intéressent dans ce projet sont :

• la broche 1 : la masse qu’il faut relier à une masse de l’arduino
  
• la broche 2 : l’alimentation en 5V qu’il faut relier au +5V de l’arduino
• la broche 6 : Latch Enable (LE) qu’il faut reliée à une sortie numérique de l’arduino : la broche 2 par exemple
  
• la broche 7 : l’horloge (SCK) qu’il faut reliée à la borne 13 de l’arduino
  
• la broche 8 : l’entrée de données (SDI) qu’il faut reliée à la sortie de données coté arduino broche 11
• la broche 9 : Output Enable peut être reliée soit à une sortie numérique de l’arduino pour allumer/éteindre les dels ou une sortie MLI de l’arduino (broche 3 par ex.) pour piloter l’intensité des dels ou relier plus simplement à la masse.

Premier test : animation de deux dels

On se propose de réaliser un effet graphique avec cette platine : 2 dels opposées qui tournent dans un sens ou dans l’autre à une vitesse réglable par une glissière sur la face avant LabVIEW. On rajoutera aussi un potentiomètre sur la face avant pour régler l’intensité lumineuse des dels. Compte tenu de ce mini cahier des charges, on obtient le câblage suivant :

La face avant peut se présenter ainsi :

Les deux tableaux contiennent des données non signées sur 8 bits (U8). Ce sont ces données qui seront envoyés sur le bus SPI. On doit piloter 16 sorties donc il nous faut assembler deux données 8 bits pour former une données 16 bits.

Le diagramme LabVIEW peut se présenter de la manière suivante (on verra sur un autre diagramme une méthode différente de traitement des données basée sur des entiers non signés codées sur 16 bits (U16).

Quelques explications sur ce diagramme :

• On initialise la communication avec l’arduino
• la broche 2 de l’arduino est mise en sortie numérique. Cette broche est reliée à la broche LE (Latch Enable) du TLC. Une impulsion positive sur cette sortie valide le latch.
• on initialise le bus SPI et on choisit l’ordre d’envoi des bits (ici les bits de poids fort en premier)
• on lit la valeur du potentiomètre “luminosité des dels”. Cette valeur (moins 255) sert pour générer un signal MLI (par défaut sur la broche 3 de l’arduino) qui est relié à la broche OE (Output Enable) du TLC. On peut ainsi piloter l’intensité lumineuse des dels.
• La glissière “Sens et vitesse de défilement” permet de choisir quel tableau va fournir les valeurs à envoyer. Si c’est positif le tableau “sens trigo” est utilisé sinon c’est le tableau “sens horaire”. La valeur fournie par la glissière sert aussi à la temporisation de la boucle infinie donc à la vitesse de “défilement” des dels.
• Le sous VI “SPI Send Receive” reçoit en entrée un tableau 1D de U8. Nous construisons donc un tableau 1D qui contiendra deux valeurs de 8 bits et qui dépend du nombre de boucle modulo 8 (on doit envoyer 8 x 2 octets pour réaliser l’effet). Le mieux pour se rendre compte de comment fonctionne l’envoie des données, c’est de modifier les valeurs du tableau.
• On verrouille les données dans le “latch” en créant une impulsion positive sur le broche 2 de l’arduino.
• Une fois sorti de la boucle par le bouton STOP, on arrête le bus SPI, on ferme la communication avec l’arduino et on affiche les éventuelles erreurs.

Voici le résultat :

Deuxième test : Vu-mètre ou visualisation de la position d’un potentiomètre virtuel

Dans cet exemple, on va utiliser une platine qui dispose de 8 dels vertes, 4 dels orange et 3 dels rouge soit un total de 15 dels qui forment l’anneau. La del 16 sera une del bleue qui peut servir de témoin d’appui par exemple. Le but de cet exercice est de visualiser sur les dels la position d’un potentiomètre virtuel sur une face avant d’un VI LabVIEW.

Le schéma de câblage est identique au précédent. Seule la platine a été changé. La face avant est très simple et peut se présenter de la manière suivante :

et le diagramme associé :

On retrouve l’initialisation de l’arduino et de la communication SPI. Sinon l’intérieur de la boucle infinie peut être expliqué comme suit :

• un tableau d’entiers non signés sur 16 bits (U16) est initialisé en dehors de la boucle. Il contient les 16 valeurs que l’on va “afficher” sur l’anneau de dels.
• Le bouton rotatif renvoie un entier U8 compris entre 0 et 15. On affiche cette valeur sur le vu mètre de la face avant mais on s’en sert aussi d’indice pour extraire UNE  donnée (d’où la constante 1) d’un tableau (sous VI “Sous ensemble d’un tableau”).
• Cette données est alors séparée en 8 bits de poids fort (ET logique avec 65280 et décalage de 8 bits vers la droite) et 8 bits de poids faible (ET logique avec 255)
• le tout est ré-assemblé dans un tableau pour être écrit par le sous VI d’écriture sur le bus SPI.

Voici ce que ça donne :

Dialogue par ethernet avec un arduino et son ethershield

Il n’est plus question ici de travailler avec LIFA mais directement avec l’arduino et son shield ethernet. On se propose de réaliser une face avant qui va permettre de piloter une DEL et récupérer la température le tout par une liaison ethernet (voire même à travers Internet).

On utilisera un capteur de température LM35 connecté sur l’entrée A0 et une del sur la sortie 3. Comme le lm35 a une pente de 10mV/°C et 0V à 0°C, la variation de température dans une pièce entrainera une variation de quelques dizaines de mV. On va donc augmenter la précision de la mesure analogique en activant la référence de tension interne de 1,1V de l’arduino. Le convertisseur analogique-numérique est sur 10 bits, on obtiendra donc un quantum de 1,1V / 1024 = 1mV (1,0742mV précisément). On pourra donc mesurer des température de 0°C à +110°C ce qui est amplement suffisant. Le câblage se présente de la manière suivante :

Le code arduino est présenté ci-dessous. Il se base totalement sur l’exemple “Web Serveur” qu’il suffit alors de simplifier. Le code est commenté donc à lire attentivement !

/*
  Serveur TCP
  O. DARTOIS, le 23/05/12
  Source directement basée sur l'exemple Web Server
 */

#include <SPI.h>
#include <Ethernet.h>

// Adresses MAC et IP à changer suivant vos besoins
byte mac[] = { 0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0xED };
IPAddress ip(192,168,1, 177);

// Initialisation de la librairie ethernet
// et création d'un objet "Server" qui va accepter
// les connexions extérieures à l'adresse IP defini plus
// haut et sur le port indiqué (ici 8000)
EthernetServer server(8000);

void setup()
{
  Ethernet.begin(mac, ip);      // Initialisation de la pile TCP/IP
  server.begin();               // Démarrage du serveur
  pinMode(3,OUTPUT);            // Broche 2 en sortie (DEL)
  digitalWrite(3,LOW);          // Broche 2 à 0 => DEL eteinte
  analogReference(INTERNAL);    // Référence du CAN à 1,1V
}

void loop()
{
  // Attente des connexions et création d'un objet client s'il y a lieu
  EthernetClient client = server.available();
  if (client) {                                // Un client existe
    while (client.connected()) {               // il est connecté
      if (client.available()) {                // et il a envoyé des caractères
        char c = client.read();                // on lit le caractère reçu
        if (c == 'A') digitalWrite(3,HIGH);    // si c'est 'A' on allume la DEL
        if (c == 'a') digitalWrite(3,LOW);     // si c'est 'a' on éteint la DEL
      }
      // on renvoie au client une chaine de caractère qui représente le résultat de
      // la conversion AN (par ex: '236') suivi des caractères CR+LF
      server.println(analogRead(0));
      delay(100);                              // On ralenti un peu le flot de données
    }
    client.stop();                             // Fermeture de la connexion
  }
}

Une fois ce code compilé et implanté dans l’arduino avec son ethershield, nous allons réaliser une face avant sous LabVIEW pour piloter ce montage.

Le diagramme LabVIEW se présente de la manière suivante :

Comme vous le remarquez, le diagramme est très simple…c’est grâce aux sous VI spécialisés de LabVIEW que l’on arrive à un tel niveau de simplicité. Un peu d’explication tout de même : le serveur du coté arduino implémente une pile TCP/IP simplifiée mais suffisante pour dialoguer sur un réseau de type ethernet. Du fait que l’on utilise IP et des adresses IP en version 4 vous pouvez réaliser du routage, ce qui veut dire que vous pouvez mettre un tel montage derrière votre box à la maison et y accéder depuis n’importe où sur Internet. Le protocole de transport utilisé ici est TCP, c’est un protocole de transport de données en mode connecté et fiable. Ce qui veut dire que normalement vos données arriveront toujours à bon port ! Les pertes de paquets seront gérés par TCP et pas par vos soins. Comme on le voit, on utilise TCP comme protocole de transport et pour faire de l’échange de données on travaille avec des “sockets” réseaux. Tout cela sera masqué grâce aux VI disponibles dans la palette “Communications de données” puis “Protocoles” puis “TCP”. Pour dialoguer avec l’arduino, il faut suivre la démarche suivante:

1. Mettre un VI “TCP Ouvrir une connexion” puis le configurer. Dans notre cas, l’adresse IP de l’arduino est 192.168.1.177 et son port d’écoute est le 8000. Il faudra donc que votre PC soit dans le même réseau que votre arduino. Par exemple ici, l’adresse ip de votre portable pourrai être 192.168.1.15.
2. Une fois la connexion ouverte, vous pouvez envoyer des données avec le VI “TCP écrire”. Il prend en entrée des caractères ou chaines de caractères. Ici suivant l’état du bouton “Commande DEL”, on va envoyer le caractère ‘A’ (pour allumer la DEL, voir le code arduino) ou le caractère ‘a’.
3. Pour réceptionner des données, vous utiliserez le VI “TCP Lire” : celui-ci réclame un “buffer” d’octets pour stocker les données reçues (ici j’ai mis 10 même si l’on va recevoir moins de caractères). Par contre ce qui est important c’est le “mode” de fonctionnement de ce VI. Ici il est en mode “CRLF” : c’est à dire qu’il attend soit que le buffer soit plein pour mettre sur sa sortie les caractères reçues, soit lorsqu’il reçoit “CRLF”, il met sur sa sortie les caractères reçues SANS CRLF. Vous comprenez peut-être mieux pourquoi c’est la méthode “println” et pas “print” qui a été employée (println rajoute automatiquement CRLF après les caractères qu’on lui a passé). La chaine de caractère reçue est affichée de manière “brute” dans l’indicateur “données reçues”. On veut afficher la température sur un vumètre mais il faut transformer le résultat de la conversion AN de l’arduino que l’on a reçu en un nombre. C’est le rôle du sous VI “Chaine décimale en nombre” et de la multiplication par le coefficient pour retrouver la température ( quantum = 1,074.10-3 et sensibilité du capteur de 10mV/°C). Enfin on affiche la température en °C sur le vumètre.
4. Lorsqu’on arrête la boucle infinie avec le bouton stop, il faut fermer proprement la connexion TCP avec le VI “TCP Fermer la connexion”. On affiche alors les éventuelles erreurs.

Testez l’ensemble et vous verrez que c’est fonctionnel. Modifiez le diagramme et le code arduino pour piloter la DEL en MLI par exemple…

Conclusion

Les deux articles sur LIFA et LabVIEW ne présentent pas de projets complets mais ils fournissent toutes les base pour débuter ceux-ci. Ces articles ont surtout comme but de vous initier à LIFA et de vous faire gagner du temps. Bon courage pour vos futures réalisations.

Matériels et logiciels nécessaire

Matériels :

• un ordinateur de type compatible PC avec Microsoft Windows7 ou WindowsXP (je n’ai pas testé sous GNU/Linux mais ça doit être fonctionnel)
• une carte compatible Arduino : dans notre cas une carte arduino UNO
• un shield de prototypage ou une plaquette d’essai sans soudure (http://www.lextronic.fr/P4130-kit-arduino-protoshield.html à 15€ par exemple)
• divers shields en fonction des utilisations avancées : ethershield, Xbee Shield, etc… (facultatif)
• quelques composants de bases (résistance, dels, …) et des capteurs (température, humidité aussi bien en I2C qu’en analogique)

Logiciels :

• L’environnement de développement d’arduino ( http://arduino.cc/en/Main/Software )
• NI LabVIEW (version d’évaluation disponible sur http://www.ni.com/trylabview/) avec les pilotes VISA qui gèrent la voie série ( http://joule.ni.com/nidu/cds/view/p/id/2251/lang/en )
• VI Packet Manager : logiciel qui gère l’installation des extensions de LabVIEW disponible sur le site d’un partenaire de National Instrument ( http://jki.net/vipm/download )
  
• Le paquet LIFA décrit sur https://decibel.ni.com/content/groups/labview-interface-for-arduino et son installation sur https://decibel.ni.com/content/docs/DOC-15971
• Le logiciel Fritzing pour dessiner les schémas de câblage ( http://fritzing.org/welcome/ )

Téléchargez le tout puis installez dans l’ordre ci-dessus. La plupart du temps ça se résume à “suivant”, “suivant”,…”terminer”. La version de LIFA utilisée ici est 2.XX.

Installation du firmware LIFA sur la carte Arduino

Le firmware LIFA est disponible après installation dans le répertoire “C:\Program Files\National Instruments\LabVIEW 2011\vi.lib\LabVIEW Interface for Arduino\Firmware\LVIFA_Base” (du moins sur mon installation). Vous trouverez alors plusieurs fichiers dont les trois principaux sont :

• le sketch “LVIFA_Base.ino” : c’est ce sketch que vous compilerez et transfèrerez dans la platine Arduino
• le sketch “LabVIEWInterface.ino” : il contient l’implémentation de toutes les fonctions utilisées par LabVIEW pour dialoguer avec la carte Arduino
• le fichier d’inclusion “LabVIEWInterface.h” : ce fichier d’en-tête est particulièrement intéressant puisque c’est lui qui contient les “define” que vous pouvez modifier pour adapter LIFA. Trois “define” en particulier seront à modifier suivant vos projets :
  • DEFAULTBAUDRATE : la vitesse de transmission de la voie série. En effet LabVIEW communique avec la carte Arduino par une voie série, par défaut la vitesse est de 115200 bauds/s mais si vous utilisez une liaison série sans fil (XBee ou Bluetooth), il faudra sans doute baisser la vitesse de transmission pour fiabiliser le dialogue
  • COMMANDLENGHT : le nombre d’octets transmis en une seule fois par une commande LabVIEW. Par défaut cette valeur est à 15. Si c’est insuffisant pour votre projet il faut le changer ici et sur le diagramme LabVIEW
  • STEPPER_SUPPORT : permet ou non d’intégrer le support des moteurs pas à pas dans le firmware, cela permet de diminuer la taille du fichier hex
• Les autres fichiers sont pour la gestion des moteurs pas à pas.

Chargez donc “LVIFA_Base.ino” dans l’environnement Arduino, compilez-le puis programmez votre carte Arduino.

Vous disposez normalement maintenant d’une Arduino prête à fonctionner avec LabVIEW.

Remarque : L’extension “ino” est la nouvelle extension pour les “sketches” arduino depuis la version 1.00, avant l’extension était “pde”.

Premier exemple : Allumer une diode depuis LabVIEW et lire l’état d’une entrée

On commence toujours par une del donc on échappe pas à la tradition ! Le câblage sur la plaquette d’essai peut se présenter de la manière suivante (le dessin est réalisé avec le logiciel Fritzing) :

Lancez LabVIEW, puis réalisez la face avant suivante:

Lorsque vous passez sur le diagramme, une nouvel palette dédié à Arduino doit apparaitre :

Réalisons le diagramme suivant:

Les applications LabVIEW utilisant LIFA sont toutes construites sur le même modèle:

1. Établir la connexion avec la platine Arduino à l’aide du sous VI “INIT”. Celui-ci dispose de nombreuses entrées pour le configurer. Je vous conseille de créer des constantes pour ces entrées afin d’observer les différents choix possibles. La création d’une constante se fait en cliquant avec le bouton droit sur une des entrées puis choisir “Créer”, “Constante”. Si vous souhaitez modifier ces paramètres sur la face avant créez des indicateurs. Tout d’abord choisir le port COM qui a été créé lors de la première connexion de l’arduino (ici COM19). Choisir la vitesse, elle doit correspondre avec celle défini dans “LabVIEWInterface.h” (ici 115200 qui est la valeur par défaut), ensuite le choix de la carte Arduino (par défaut UNO). Les deux derniers paramètres sont laissés tels quels. En sortie vous obtenez la “ressource” initialisée (trait épais rose) qui sera utilisée par tous les sous VI arduino et de quoi gérer les erreurs (trait épais jaune).
2. Initialiser les E/S. Si vous utilisez des E/S numériques, utilisez le sous VI “Set Digital Pin Mode”. Il faut préciser alors la broche concernée ( ici 8 ) et son sens ( ici output : on pilote une del ).
3. Boucle infinie de gestion des évènements. Comme sur micro-controlleur vous avez une boucle infinie qui gère les évènements (on ne considère pas ici les interruptions). Cette boucle infinie est ici représentée par une boucle “while” (flèche épaisse grise qui reboucle sur elle-même). Pour arrêter cette boucle, créez un indicateur sur le terminal de répétition de la boucle (ici point rouge). On doit allumer la DEL en fonction de l’état de l’interrupteur à levier de la face avant (Commande DEL). On transforme tout d’abord l’information booléenne (true, false) en nombre (0,1) puis on envoie cette information à l’entrée du sous VI “Digital Write Pin”. La broche de sortie est bien sur toujours la 8. Si vous regardez bien le diagramme, un petit point rouge à l’entrée du VI “Digital Write Pin” est présent. Ce qui indique que les formats utilisés ne sont pas totalement compatibles (ici la conversion booléenne se fait vers un entier signé codée sur 16 bits, or le VI attend une valeur non signé sur 8 bits).
4. Fermeture de la connexion avec la carte Arduino à l’aide du sous VI “CLOSE”. On libère ainsi proprement la mémoire et le port COM. Éventuellement câblez un gestionnaire d’erreurs simple.

Testez votre programme, lors de la manipulation de l’interrupteur de la face avant la diode doit réagir en conséquence. Vous savez donc piloter en tout ou rien des sorties. A titre d’exercice, modifiez le câblage, la face avant et le diagramme pour lire et afficher l’état d’un interrupteur…..

La correction est donnée ci-dessous :

Le câblage :La face avant dans LabVIEW:Le diagramme :

Remarque: Le microcontrolleur Atmel présent sur la carte Arduino possède des résistance de pull-up interne activable individuellement. Vous pouvez donc vous passez de la résistance de 10K sur le schéma de câblage à condition de modifier le “sketch” de LIFA dans la fonction setup. Lire cet article : http://arduino.cc/fr/Main/ApprendreBrochesEntreeSortie

Remarque: Si vous avez plusieurs broches à initialiser en entrée ou en sortie, le faire dans une boucle sous LabVIEW.

Deuxième exemple : Lire une tension analogique

Nous allons lire la tension issu d’un capteur de température analogique (LM35 : datasheet ici) et l’afficher sous LabVIEW. Ce capteur donne 0V à 0°C et à une pente de +10mV/°C. Ce qui fait par exemple à 25°C : 250mV. La variation de tension n’est pas importante et nous choisissons de ne pas amplifier cette tension pour garder un schéma de câblage simple. Le convertisseur analogique numérique de l’Atmel est un 10bits. La plage de numérisation est de base entre 0V et +Vcc = 5V. Le quantum fait donc 5/2^10 = 4,88mV. On réalise le câblage suivant:

La face avant sous LabVIEW peut se présenter de la manière suivante:

Le diagramme se présente de la manière suivante :

Remarque : la sortie du sous VI “Analog Read Pin” donne une tension et pas un nombre compris entre 0 et 1023 !

Troisième exemple : Moteur CC commandé en sens et en vitesse

Nous allons utiliser un circuit intégré qui permet de piloter deux moteurs CC : le L293D (datasheet ici). Ce circuit est relativement facile à mettre en œuvre et comme nous allons piloter qu’un seul moteur cela simplifie encore l’ensemble. Notez qu’il existe des shields pour piloter des moteurs CC (par ex : http://www.lextronic.fr/P5073-platine-de-commande-de-moteurs-dc.html). La broche 1 (EN1) permet d’activer le premier pont en H, si l’on connecte cette broche à une broche de l’arduino qui fourni un signal MLI alors on pourra faire varier la vitesse du moteur. Les broches 2 (IN1) et 7 (IN2) permettent de fixer le sens de rotation du moteur ou encore de le freiner. Les broches 3 (OUT1) et 6 (OUT2) sont les broches de sorties de puissance vers le moteur. La broche 16 (VSS) reçoit une alimentation 5V issu de la carte arduino. La broche 8 (VS) est connecté au +9V d’une pile pour assurer l’alimentation en puissance du moteur. Enfin les broches 4,5,12, 13 sont reliées aux masses (GND de l’arduino et pôle négatif de la pile). On obtient donc le schéma de câblage suivant :

Les broches 7 et 8 de l’arduino devront donc être en mode “digital” pour piloter le sens du moteur, la broche 11 en mode MLI (remarque: seul les broches avec une tilde peuvent être mises en mode MLI matériel : 6 broches en tout sur une arduino UNO). Le sens de rotation du moteur suit le tableau suivant:

Enable 1 (EN1)	Input 1 (IN1)	Input 2 (IN 2)	Fonction
High	Low	High	Tourne dans le sens horaire
High	High	Low	tourne dans le sens trigonométrique
High	Low	Low	Stop
High	High	High	Stop
Low	Non applicable	Non applicable	Stop

La face avant de cette exemple sera très simple (un potentiomètre unique qui évolue de -100% à +100%, le signe permet de fixer le sens de rotation) :

Le programme LabVIEW peut se présenter de la manière suivante (la seule partie qui varie d’une capture à l’autre, c’est l’intérieur de la boite de test : Vrai et Faux :

Câblez et testez : le moteur doit varier en vitesse et en sens. A l’oscilloscope la fréquence de la MLI est de 400Hz. Cette fréquence n’est pas réglable par l’intermédiaire d’un VI.

Quatrième exemple : Capteur de température DS1621 sur bus I2C

Le DS1621 est un capteur de température relativement répandu (datasheet ici). Je ne vais pas détailler ici la documentation, on va juste préciser les commandes à envoyer au DS1621 pour l’initialiser et faire une lecture simple de température. La broche 1 est SDA, la 2 est SCL : signaux du bus I2C. La broche 3 (Tout) ne sera pas utilisée dans notre application. Les broches 7 (A0), 6 (A1) et 5 (A0) sont reliés à la masse pour fixer l’adresse I2C de ce capteur. La broche 4 est la masse et la broche 8 +Vcc (ici 5V).

La séquence d’initialisation est la suivante (broches A0, A1 et A2 reliées à la masse) :

1. Condition de départ (start)
2. Écrire 0×90 : on sélectionne le boitier à l’adresse A2A1A0 = 000 en écriture
3. Écrire 0xAC : on écrit dans le registre de configuration
4. Écrire 0×00 : conversion de température en continu
5. Condition d’arrêt (stop)
6. Attendre 20ms : écriture en eeprom de la configuration précédente
7. Condition de départ (start)
8. Écrire 0×90 : on sélectionne le boitier à l’adresse A2A1A0 = 000 en écriture
9. Écrire 0xEE : lancement de la conversion en continu de la température
10. Condition d’arrêt (stop)

La séquence suivante permet la lecture de la température :

1. Condition de départ (start)
2. Ecrire 0×90 : on sélectionne le boitier à l’adresse A2A1A0 = 000 en écriture
3. Ecrire 0xAA : demande de lecture de la dernière température échantillonnée
4. Condition de départ (restart)
5. Ecrire 0×91 : on sélectionne le boitier à l’adresse A2A1A0 = 000 en lecture
6. Lire les 8 bits de poids fort de la température
7. Lire les 8 bits de poids faible de la température et faire un NACK !!
8. Condition d’arrêt (stop)

Vous remarquez que ce n’est pas très simple mais on va essayer d’implémenter le tout en LabVIEW avec les fonctions Arduino. Suivant la version de la carte arduino UNO que vous possédez les broches SCL et SDA ne sont pas au même endroit (UNO Rev2 : A4=SDA, A5=SCL; UNO Rev3: deux broches dédiées sur un connecteur SCL et SDA). Au moment de rédiger ce tutoriel  je dispose d’une carte arduino UNO rev2, le schéma de câblage ci-dessous est donc adapté pour cette plate-forme :

La face avant sous LabVIEW se présente de la manière suivante :

Remarque : un indicateur permet de choisir l’adresse du capteur DS1621 sur le bus I2C. Sous l’intitulé “Données I2C” c’est en fait un indicateur sous forme de tableau, il permet de visualiser les données brutes lues sur le bus I2C.

Le diagramme peut se présenter de la manière suivante :

Cela mérite quelques explications !!! Tout d’abord j’ai triché…pour comprendre comment fonctionne les sous VI I2C j’ai regardé les signaux I2C issu de l’arduino sur un oscilloscope et je dois dire que ça m’a bien aidé ! Lecture du diagramme de gauche à droite:

1. Initialisation du bus I2C (TWI dans la terminologie arduino)
2. Initialisation du DS1621. Tout d’abord l’adresse du composant. L’adresse est sur 7 bits (bit de poids fort en premier), les 4 premiers sont fixes (1001 voir documentation), les 3 derniers sont fixés avec les broches A2A1A0. Dans notre cas A2A1A0=000 donc l’adresse du composant est 0b1001000 en binaire ou 0×48 en hexadécimal ou 72 en décimal. Vous avez donc l’explication de la valeur 72 sur la face avant. Ensuite il faut écrire les valeurs 0xAC (172) et 0×00 (0) : c’est le rôle du premier sous VI  “I2C Write”.
3. Suite de l’initialisation. Normalement il faut attendre une dizaine de ms mais comme la transmission des 15 octets de LabVIEW vers l’arduino prend du temps, on peut considérer que la temporisation est réalisée. On écrit alors la valeur 0xEE (238). A ce point le DS1621 est correctement initialisé.
4. On rentre alors dans une boucle infinie. La température sera demandée toutes les 500ms. Pour faire la demande de la dernière température, il faut écrire la valeur 0xAA (170).
5. On lit alors le résultat : ici le DS1621 doit nous renvoyer 2 octets d’où la valeur 2 sur le sous VI “I2C Read”. Ce sous VI se charge aussi de faire le NACK final (vérifié à l’oscilloscope). On obtient alors un tableau 1D à deux cases contenant des entiers non signés codés sur 8 bits. Ces données sont affichées de manière brute dans un l’indicateur de la face avant “Données I2C”.
6. Il faut traiter les deux valeurs fourni par le DS1621. On commence par extraire les données du tableau avec le sous VI “Indexer un tableau”. L’indice  ‘0′ : 8 bit de poids fort du résultat de la température en entier signé et l’indice ‘1′ : 8 bit de poids faible de la conversion : dans notre cas cet octet prendra deux valeurs : soit 128 pour indiquer qu’il faut rajouter 0,5°C, soit 0.
7. On reconstruit alors la température réelle et on l’affiche sur le thermomètre.

Cela fonctionne, notez cependant que l’on ne gère pas les températures négatives…c’est à faire en guise d’exercice

Cinquième exemple : Afficheur LCD alphanumérique

Pour ce test il existe un shield (par exemple http://www.zartronic.fr/shield-lcd-pour-arduino-p-125.html) ou on peut le fabriquer à partir des fichiers Isis et Ares disponible sur http://www.ac-limoges.fr/sti_ge/spip.php?article38. L’afficheur LCD sera utilisé en mode 4 bits et la ligne RW sera reliée à la masse pour diminuer le nombre de fils. On peut avoir le câblage suivant qui n’est PAS DU TOUT le câblage par défaut proposé sous LabVIEW :

Pour être plus explicite on a le câblage suivant (j’exclue les alimentations et le réglage de contraste avec le potentiomètre).

• broche 4 de l’arduino vers broche 4 (RS) de l’afficheur
• broche 5 (RW) de l’afficheur reliée à la masse : l’afficheur est toujours en mode écriture
• broche 6 de l’arduino vers broche 6 (E) de l’afficheur
• broches 10,11,12,13 de l’arduino respectivement sur 11,12,13,14 (DB4,DB5,DB6,DB7) les 4 bits de poids fort du bus de données de l’afficheur

Remarque : suivant votre afficheur, vous pouvez tenter de mettre la broche 3 (Vcontrast) directement à la masse. Si les caractères sont encore visibles cela simplifie encore le câblage.

On va afficher la date et l’heure courante du PC sur l’afficheur LCD. On vérifiera que la longueur de la chaine à afficher est compatible avec le nombre de colonne de l’afficheur sinon on affichera le mot “Erreur !!” et on positionnera un témoin lumineux à rouge. La face avant peut être celle-ci :

Compte tenu du cahier des charges précédent, on peut obtenir le diagramme LabVIEW suivant :

Quelques commentaires sur ce diagramme:

• le sous VI “LCD configure 4-bit” permet d’affecter les broches de l’afficheur LCD aux broches de l’arduino. Le nom des broches est rappelé sur le diagramme. La valeur 255 pour la ligne R/W indique que cette ligne n’est pas cablé du coté de l’arduino. La broche “LCD” précise quel ligne sur l’arduino sera utilisée pour piloter le rétroéclairage de l’afficheur s’il en possède un. Ne connectez pas directement la broche de l’arduino à la broche d’alimentation du rétro-éclairage (vu sur les exemples de chez NI) mais utilisez plutôt un petit transistor MOS type BS170 (datasheet ici) pour piloter l’alimentation du rétro-éclairage.
• Le sous VI “LCD Init” permet de préciser le nombre de colonnes (ici 16) et le nombre de ligne (ici 2) de l’afficheur LCD.
• Tout ce qui est dans la partie supérieure de la boucle while concerne la récupération de la date et de l’heure du PC (avec un format précis) et du test pour savoir si la longueur de la chaine générée est compatible avec le nombre de colonnes de l’afficheur
• Le sous VI “LCD Set Cursor Position” permet de fixer la position de départ de la chaine à afficher. Notez bien que les coordonnées x,y de l’afficheur commence à 0,0 et pas 1,1 !
• Le sous VI “LCD print” permet d’afficher la chaine que l’on a généré auparavant

Remarque : le VI précédent a été testé sur un afficheur LCD 16×2 et un afficheur LCD 20×4 en changeant les paramètres d’initialisation et la position d’affichage. Tout a bien fonctionné

Conclusion…

Pour explorer plus avant les possibilités de LIFA, il suffit d’ouvrir les VI exemples fournis. Ceux-ci se trouvent dans “C:\Program Files\National Instruments\LabVIEW 2011\vi.lib\LabVIEW Interface for Arduino\Palette Examples”. J’espère aussi que les quelques exemples précédents vous ont ouvert l’appétit ! Je trouve le “mariage” open-source, open-harware de l’arduino et le très propriétaire NI LabVIEW assez intéressant car il permet de développer rapidement de petites applications ou projets. De ce point de vue LIFA correspond bien à une philosophie d’apprentissage par projet !

Je compte, si j’ai assez de temps faire un second article, sur une utilisation plus avancé de LIFA. Un des thèmes abordés pourrait être la manette nunchuck de la wii car elle embarque un accéléromètre 3 axes, un joystick analogique et deux boutons poussoirs, le tout interrogeable par un bus I2C pour un prix de 20€…

Vous trouverez ci-dessous une archive zip contenant les captures d’écrans, les fichiers pour fritzing, les VI des exemples (réalisés avec la version 2011 de LabVIEW). N’hésitez pas à commenter cet article et à apporter votre pierre à l’édifice de l’open source - open hardware.

• QTExtSerialPort : http://code.google.com/p/qextserialport/
• QTSerialDevice : http://gitorious.org/qserialdevice

Mon environnement de développement sera une debian Squeeze. QTCreator est installé depuis les paquets standards (en version 1.3.1 basé sur les librairies QT 4.6.3).

Test avec QExtSerialPort

Il faut se rendre àl’adresse indiquée plus haut. On va faire une copie du projet en utilisant Mercurial. Il faut d’abord installer celui-ci puis se déplacer dans un endroit adéquate puis enfin rapatrier le projet:

olivier@portable-od:~$ sudo aptitude install mercurial
olivier@portable-od:~$ cd Documents/BTS_IRIS/LangageC-C++/Qt
olivier@portable-od:~/Documents/BTS_IRIS/LangageC-C++/Qt$ hg clone https://code.google.com/p/qextserialport/
destination directory: qextserialport
requesting all changes
adding changesets
adding manifests
adding file changes
added 106 changesets with 726 changes to 124 files (+2 heads)
updating to branch default
95 files updated, 0 files merged, 0 files removed, 0 files unresolved
olivier@portable-od:~/Documents/BTS_IRIS/LangageC-C++/Qt$ ls
basiclayouts   imageviewer         qextserialport
collidingmice  localfortuneclient  Test_crosscompilateur

On rentre dans le répertoire “qextserialport”. On remarque un “qextserialport.pro” (un projet Qt4). On va donc essayer de compiler ce projet avec une simple commande “make”. En analysant les messages de compilation, on remarque que l’on a obtenu:

• une librairie partagée :  libqextserialport.so.1.2.0 dans le répertoire “src/build” et les liens symboliques
• des exemples : enumerator,  event (le projet QEPSTA nécessite une compilation dans QTCreator)

On teste donc les exemples fournis…le problème est que la librairie partagée n’est pas reconnue. Je copie donc celle-ci dans “/lib” et je fais les liens symboliques associés. Enfin on remet à jour la liste des librairies avec ldconfig:

olivier@portable-od:~/Documents/BTS_IRIS/LangageC-C++/Qt/qextserialport$ cd src/build/
olivier@portable-od:~/Documents/BTS_IRIS/LangageC-C++/Qt/qextserialport/src/build$ ls
libqextserialport.so  libqextserialport.so.1  libqextserialport.so.1.2  libqextserialport.so.1.2.0
olivier@portable-od:~/Documents/BTS_IRIS/LangageC-C++/Qt/qextserialport/src/build$ sudo cp libqextserialport.so.1.2.0 /lib
[sudo] password for olivier:
olivier@portable-od:~/Documents/BTS_IRIS/LangageC-C++/Qt/qextserialport/src/build$ cd /lib
olivier@portable-od:/lib$ sudo ln -s libqextserialport.so.1.2.0 libqextserialport.so.1.2
olivier@portable-od:/lib$ sudo ln -s libqextserialport.so.1.2.0 libqextserialport.so.1
olivier@portable-od:/lib$ sudo ln -s libqextserialport.so.1.2.0 libqextserialport.so
olivier@portable-od:/lib$ sudo ldconfig
olivier@portable-od:/lib$ cd /home/olivier/Documents/BTS_IRIS/LangageC-C++/Qt/qextserialport/examples/enumerator/
olivier@portable-od:~/Documents/BTS_IRIS/LangageC-C++/Qt/qextserialport/examples/enumerator$

• enumerator : on lance l’éxecution du programme “enumerator” et l’on obtient la liste des “ports séries” disponible sur la machine.

olivier@portable-od:~/Documents/BTS_IRIS/LangageC-C++/Qt/qextserialport/examples/enumerator$ ./enumerator
List of ports:
port name: "ttyS0"
friendly name: "Serial port 0"
physical name: "/dev/ttyS0"
enumerator name: "/dev"
vendor ID: "ffffffffa3e49cf8"
product ID: "7fff"
===================================
port name: "ttyS1"
friendly name: "Serial port 1"
physical name: "/dev/ttyS1"
enumerator name: "/dev"
vendor ID: "ffffffffa3e49cf8"
product ID: "7fff"
===================================
port name: "ttyS2"
friendly name: "Serial port 2"
physical name: "/dev/ttyS2"
enumerator name: "/dev"
vendor ID: "ffffffffa3e49cf8"
product ID: "7fff"
===================================
port name: "ttyS3"
friendly name: "Serial port 3"
physical name: "/dev/ttyS3"
enumerator name: "/dev"
vendor ID: "ffffffffa3e49cf8"
product ID: "7fff"
===================================
port name: "ttyUSB0"
friendly name: "USB-serial adapter 0"
physical name: "/dev/ttyUSB0"
enumerator name: "/dev"
vendor ID: "ffffffffa3e49cf8"
product ID: "7fff"
===================================

En fait le seul port série que j’ai sur ma machine est le “/dev/ttyUSB0″ : c’est un adaptateur USB-Serie basé sur le circuit FT232 de FTDI.

• event : si on exécute ce programme, le message d’erreur suivant apparaît :

olivier@portable-od:~/Documents/BTS_IRIS/LangageC-C++/Qt/qextserialport/examples/event$ ./event
hi there
trying to open file "COM1"
could not open file: Aucun fichier ou dossier de ce type
device failed to open: "The COM1 file doesn't exists"
^C

Visiblement le nom du port est codé “en dur”. Donc on modifie le fichier source (remplacement de COM0 par /dev/ttyUSB0) et on recompile (make dans le répertoire) puis on exécute :

olivier@portable-od:~/Documents/BTS_IRIS/LangageC-C++/Qt/qextserialport/examples/event$ nano main.cpp
olivier@portable-od:~/Documents/BTS_IRIS/LangageC-C++/Qt/qextserialport/examples/event$ ls
event  event.pro  main.cpp  Makefile  PortListener.cpp  PortListener.h  tmp
olivier@portable-od:~/Documents/BTS_IRIS/LangageC-C++/Qt/qextserialport/examples/event$ make
g++ -c -pipe -O2 -Wall -W -D_REENTRANT -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/share/qt4/mkspecs/linux-g++ -I. -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui -I/usr/include/qt4 -I../../src -Itmp -o tmp/main.o main.cpp
main.cpp: In function ‘int main(int, char**)’:
main.cpp:15: warning: unused variable ‘listener’
g++ -Wl,-O1 -o event tmp/main.o tmp/PortListener.o tmp/moc_PortListener.o    -L../../src/build -L/usr/lib -lqextserialport -lQtGui -lQtCore -lpthread
olivier@portable-od:~/Documents/BTS_IRIS/LangageC-C++/Qt/qextserialport/examples/event$ ./event
hi there
trying to open file "/dev/ttyUSB0"
file opened succesfully
warning: device is not turned on
listening for data on "/dev/ttyUSB0"
bytes read: 2
bytes: "f "
bytes read: 2
bytes: "f "
bytes read: 2
bytes: "x "

Visiblement le programme fonctionne et reçoit les données de la voie série. Nous avons donc deux codes sources à examiner.

J’ouvre enfin le programme QEPSTA dans QTCreator (ouvrir le projet QEPSTA.pro) et je lance la compilation et l’exécution. A la compilation une erreur apparaît, je modifie la ligne d’include concernée en #include “../../src/qextserialport.h”. Je relance la compilation est j’obtiens deux erreurs sur fprintf et stderr. Je choisis la solution radicale de commenter les lignes concernées. Il y a d’autres erreurs du mêmes types. Cependant à la fin le programme ne pouvait être lié avec la bibliothèque qextserialportd (voir le fichier qespta.pro, d pour debug). J’ai donc changé en qextserialport et c’est OK. Le programme graphique s’exécute.

J’ai depuis développé une petite application de test basé sur trois “scrool bar” R,G,B pour commander le microcontrolleur. Le tout est fonctionnel. Le code sera mis plus tard avec les classes associées.

Comme nous avons des doutes sur la compilation de cette librairie sous la dernière version de QT (4.8 à l’instant d’écriture de ces lignes) j’installe dans une machine virtuelle VirtualBox une ubuntu 11.10. QTCreator sera alors installé ensuite pour voir quel version est utilisé dans cette environnement. Suivant la version, j’installerai le dernier SDK directement depuis le site de QT.