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.

Réalisation de la carte électronique

Cette carte électronique doit donc répondre au cahier des charges suivant:

• piloter en tout ou rien trois sorties 230V (voyant lumineux, alarme sonore, aspirateur à fumées)
• générer une tension continue variable comprise entre 0V et 10V pour la consigne de vitesse de l’altivar
• être compatible avec les régulateurs de températures qui fonctionnent sur bus RS485 avec le protocole ModBUS en mode RTU
• permettre de piloter la consigne de l’altivar de manière manuel (avec un potentiomètre multitours) ou automatique (par la tension générer sur la carte)
• fonctionner à partir d’une tension unique régulée de 5V

Ce qui m’a conduit à adopter les solutions suivantes pour un prototype en fonction de ce que j’avais comme composants disponibles :

• la réception de la trame ModBUS, son décodage et enfin le pilotage de l’ensemble sera réalisé par un microcontrolleur Microchip PIC18F2520
• pour piloter en tout ou rien du 230V, j’ai utilisé des relais classiques 12V/230V 1A
• le bus RS485 deux fils sera piloté avec un CI du type DS75176
• le 12V de commande des relais sera réalisé à partir du 5V à l’aide un convertisseur de type “boost” piloté par le PIC
• la consigne 0-10V sera réalisé par filtrage d’un signal MLI généré par le PIC puis amplifié (x2) par un montage à amplificateur opérationnel. Cet amplificateur utilisant le 12V comme tension d’alimentation
• l’aiguillage de la tension continue générée par le PIC (mode automatique) ou celle issu du potentiomètre (mode manuel) sera réalisé par un relai

Ce qui nous mène au schéma électrique suivant (le fichier original au format Proteus Isis 7.4 est disponible en fin d’article) :

Quelques explications sur ce schéma :

• la carte est alimentée par une alimentation extérieure industrielle régulée 5V. La diode D1 protège le montage contre les inversions de polarité. Cependant elle introduit un problème : en effet la chute de tension dans cette diode est proportionnelle au courant qui la traverse. Lorsque les relais sont alimentés, le “5V” varie ! Or le CAN du PIC utilise comme référence cette tension de 5V ainsi que la génération du signal 0-10V. Je pense donc qu’à terme il faudra soit supprimer cette diode, soit alimenter la carte en 24V continu et générer les tensions continues de 5V et 12V (ce qui supprimera le convertisseur boost). C3 et C4 sont des condensateurs de filtrage.
• la conversion du signal RS485 en signal RS232 TTL est assuré par un ci du type SN75176. Comme on utilise un bus RS485 sur 2 fils, cela sous entend que l’on fonctionne en mode half-duplex. Il faut donc gérer ce mode en pilotant les lignes DE et RE. En mode réception, il faut mettre un état bas sur les lignes 2 et 3. En mode émission il faut mettre un état haut. Cette gestion est assurée de manière automatique dans le code C du PIC. R6 et R7 protège les entrées du SN75176. R8 et J2 permettent de “fermer” le bus RS485 sur une impédance de 120 Ohms pour éviter les réflexions en bout de ligne. R9 et J3 permettent de réaliser un “pull-up” de la ligne A du bus RS485. R10 et J4 assurent le “pull-down” de la ligne B du bus RS485.
• Les composants autour des relais RL1, RL2 et RL3 permettent de piloter en tout ou rien ces relais. Les DELs permettent de visualiser que les relais sont en position “travail”. En effet si la carte ne fonctionne pas ou en absence d’alimentation les relais sont sur leur position repos (donc pas de voyant lumineux allumé, pas de sirène mais pas d’aspirateur à fumées non plus). Comme les contacts “travail” et “repos” sont sortis sur des borniers, c’est l’utilisateur qui choisira sa configuration.
• le convertisseur “boost” est réalisé autour des composants Q5, D7, BOB et C1. Le transistor mosfet utilisé ici est surdimensionné mais c’est celui que j’avais de disponible. Attention à prendre une diode rapide pour D7 (et pas une 1N4007 comme indiqué sur le schéma). R22 protège la grille du transistor et R23 bloque le transistor en l’absence de commande. Le pont diviseur R20/R21 permet de renvoyer vers le PIC une image de la tension de sortie. Le système fonctionne alors en boucle fermée et l’asservissement est réalisé par le PIC. En effet, en gros, il faut piloter le rapport cyclique du signal MLI PWM_12V pour obtenir un 12V continu quelque soit le courant demandé par les relais. Cette partie disparaitra si je choisi d’alimenter la carte en 24V. Cette partie était surtout là pour me faire plaisir et tester un montage que je n’avais pas encore utilisé mais du coup comme le système est pleinement fonctionnel je l’utiliserais dans d’autres montages.
• l’amplificateur U3 sera du type “rail to rail” (pas de tensions de déchets) pour gérer les tensions basses en particulier. Les tensions hautes prés du 10V posant moins de problèmes car l’amplificateur est alimenté en 12V. R14 et C6 filtrent le signal MLI issu du PIC pour obtenir une tension continue comprise entre 0V et 5V. U3, monté en amplificateur non inverseur, multiplie cette tension par deux (gain fixé par R11, R12) pour obtenir la gamme 0-10V. D5 protège l’entrée de l’altivar contre les tensions supérieures à 10V. R13 et C7 filtrent l’alimentation de U3.
• le relais RL4 permet de commuter entre la tension fournie par un potentiomètre extérieur (P1) et la tension issu de U3 pour réaliser la tension de consigne de l’altivar. Ce relai assure donc la commutation entre le mode automatique et le mode manuel.
• enfin le microcontroleur U1 assure la gestion de l’ensemble. J1 est le connecteur de programmation. J7 permet de choisir la vitesse du bus rs485 (9600 ou 19200). J5 et J6 permettent de choisir l’adresse de la carte sur le bus RS485 (adresse 16, 32, 64 ou 128). Un tableau récapitulatif de ces cavaliers sera présenté plus loin dans cet article.

On passe à la phase de routage sur une carte au format “europe”, on câble et on obtient la carte suivante:

Étude du protocole ModBUS sur liaison physique RS485 en mode RTU

Le protocole ModBUS est décrit sur différents sites : wikipédia, stielec
La liaison physique RS485 est décrite sur : wikipédia, technologuepro
Mais je me suis principalement appuyé sur le document officiel : Modbus Serial Line Protocol and Implementation Guide

La liaison physique RS485 permet des liaisons multipoints, on peut donc connecter plusieurs esclaves et un maitre sur le même bus. Dans notre cas, le maitre sera un système embarqué sous GNU/Linux avec un adaptateur RS232/RS485 et les esclaves seront les régulateurs de températures eurotherm et la carte d’E/S. Chaque esclave doit avoir une adresse unique sur le bus (1 à 247). L’adresse 0 étant une adresse de diffusion (ou broadcast), les adresses supérieures à 247  sont réservés.

Il existe deux mode de transmission du protocole ModBUS sur voie série : le mode ASCII et le mode RTU (Remote Terminal Unit). Les régulateurs de température fonctionnant en mode RTU, on choisit donc d’implémenter ce mode pour la carte E/S. Le format de transmission en mode RTU pour chaque octet est le suivant :

• un bit de start (front descendant)
• 8 bits de données : poids faible en premier
• 1 bit de parité (la norme recommande une parité paire mais nous n’utiliserons pas de parité car les régulateurs sont configurés de cette manière)
• 1 bit de stop s’il y a un bit de parité sinon 2 bits de stop (dans notre montage : pas de bit de parité et un bit de stop)

Le format d’une trame ModBUS RTU est le suivant:

• Adresse de l’esclave sur un octet compris entre 1 et 247.
• Le code fonction correspond à une opération demandée par le maitre auquel l’esclave doit répondre sauf dans le cas ou le maitre envoie une trame de broadcast (à l’adresse 0).
• Les données que ce soit pour une demande de la part du maitre ou une réponse de l’esclave sont groupés sous forme de mots (2 octets) dont le MSB est en premier.
• Le CRC est un code de vérification de la trame généré par le maitre ou l’esclave. Ce CRC suit la norme CRC16 : l’algorithme est décrit dans le document officiel de la norme. Une application en ligne pour calculer les CRC est disponible ici ou là.

Chaque trame ModBUS RTU doit être précédé et suivi d’un temps de repos de 3,5 fois la durée d’un caractère (d’un octet). Ce qui donne au niveau temps : à 9600 bauds/s : 4ms et à 19200 bauds/s : 2ms pour des trames 8E1. La détection de fin de trame sur le PIC se fera en détectant ce temps après la réception du dernier caractère.

Le ModBUS propose un ensemble de fonctions (Code Fonction). Toutes ces fonctions lisent ou écrivent dans une zone mémoire spéciale de l’esclave pour commander les différents organes de la carte. Dans notre cas le découpage mémoire des registres internes est le suivant:

1. Registre 0 sur 16 bits : pilote le relais 1. Écrire un ‘0′ dans ce registre met le relai en position repos, écrire un chiffre supérieur à 0 met le relai en position travail (dans notre exemple : alarme visuelle)
2. Registre 1 sur 16 bits : pilote le relais 2. Écrire un ‘0′ dans ce registre met le relai en position repos, écrire un chiffre supérieur à 0 met le relai en position travail (dans notre exemple : alarme sonore)
3. Registre 2 sur 16 bits : pilote le relais 3. Écrire un ‘0′ dans ce registre met le relai en position repos, écrire un chiffre supérieur à 0 met le relai en position travail (dans notre exemple : pilote l’aspirateur des fumées)
4. Registre 3 sur 16 bits : pilote le relais 4. Écrire un ‘0′ dans ce registre met le relai en position repos, écrire un chiffre supérieur à 0 met le relai en position travail (dans notre exemple : permet de basculer du mode manuel (position repos) au mode automatique (position travail))
5. Registre 4 sur 16 bits : génère une tension continue comprise entre 0V et 10V. Écrire un ‘0′ dans ce registre génère du 0V en sortie, écrire ‘1023′ génère du +10V (dans notre exemple, cette tension sert au pilotage du régulateur de vitesse Altivar)

Dans notre cas, la carte d’E/S ne répondra qu’à trois commandes:

• Code fonction 0×03 : Read Holding Registers : Lire les registres internes. Cette commande permet d’obtenir l’état des différents organes de la carte. Cette commande permet de lire n registres 16 bits à partir du registre x codé sur 16 bits.
  
  *: le nombre d’octets renvoyés est égale au Nb de registre à lire x 2
  Par exemple la trame ModBUS suivante sans CRC permet de lire l’état des trois premiers relais en une seule lecture (l’esclave est à l’adresse 16 ou 0×10) : 0×10 0×03 0×00 0×00 0×00 0×03. Si vous désirez obtenir la valeur de la tension actuelle qui pilote l’altivar : 0×10 0×03 0×00 0×04 0×00 0×01
• Code fonction 0×06 : Write Single Register : Ecrire dans un registre. Cette commande permet d’écrire une valeur codée sur 16bits dans le registre indiqué.
  Vous remarquez que si tout c’est passé correctement la réponse est identique à la requête. Par exemple la trame ModBUS sans CRC qui suit permet de passer le relais2 en mode travail : 0×10 0×06 0×00 0×01 0×00 0×01.
• Code fonction 0×08 : Diagnostics : Diagnostique. Seule la sous fonction 0×0000 est implémenté. Cette sous fonction est “echo”. La réponse est identique à la requête. Par exemple, si vous envoyez la trame suivante sans CRC : 0×10 0×08 0×00 0×00 0×12 0×34, vous devriez obtenir exactement la même chose en retour.

Code source en Langage C pour le PIC18F2520

Le code source suivant permet de réaliser le cahier des charges précédent. Il est commenté, cependant si quelque chose n’était pas assez clair, n’hésitez pas à me contacter…

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261

// Carte gestion des alarmes, de l'aspirateur de fumées, et de l'altivar
// avec le protocole MODBUS sur voie série (ModBUS RTU) RS485
// Projet Four - InnovDecor
// O. Dartois - le 19/02/2012
 
// Remarque: Je me suis basé pour implémenter le protocole ModBUS sur la doc
// des régulateurs 2208e de la société EuroTherm. Dans la présentation des trames
// il y a une erreur sur l'ordre des octets du CRC. Dans la documentation il est
// indiqué MSB puis LSB or aprés lecture du protocole officiel:
// http://www.modbus.org/docs/Modbus_over_serial_line_V1_02.pdf p44
// il s'avère que l'on doit transmettre dans l'ordre LSB puis MSB !!!
 
// Seulement 3 fonctions du protocole MODBUS sont implémentées dans ce code
// et pour les besoins du projet. Un mot = 16 bits
// Fonction 06 : Ecriture d'un mot
// Fonction 03 : Lecture de N mots
// Fonction 08 : Bouclage (ou loopback)
 
//#include <16F886.h>
#include <18F2520.h>
 
#device *=16
#device adc=10                   // CAN en mode 10bits
 
#FUSES NOWDT                     //No Watch Dog Timer
#FUSES INTRC_IO                  //Oscillateur interne si utilisé
//#FUSES HS                       //Utilisation d'un quartz externe >= à 4MHz
#FUSES PUT                       //Power Up Timer
#FUSES MCLR                      //Master Clear pin enabled
#FUSES NOPROTECT                 //Code not protected from reading
#FUSES NOCPD                     //No EE protection
#FUSES NOBROWNOUT                //No brownout reset
#FUSES NOIESO                    //Internal External Switch Over mode enabled
#FUSES NOFCMEN                   //Fail-safe clock monitor enabled
#FUSES NOLVP                     //No low voltage prgming, B3(PIC16) or B5(PIC18) used for I/O
#FUSES NODEBUG                   //No Debug mode for ICD
#FUSES NOWRT                     //Program memory not write protected
//#FUSES BORV21                  //Brownout reset at 2.1V
#FUSES CCP2B3                    // Sortie de la PWM2 sur la broche B3
 
// Horloge interne a 8MHz
//#use delay(internal=4M, clock=16M)
#use delay(internal=8M)
 
// Activation du SCI à 9600 bauds/s en 8N1, gestion du half duplex avec la broche C5
#use rs232(baud=9600,parity=N,xmit=PIN_C6,rcv=PIN_C7,bits=8,ENABLE=PIN_C5)
 
// Gestion par le programmeur des ports d'E/S
#use fast_io(A)
#use fast_io(B)
#use fast_io(C)
 
// Define pour faciliter la lecture du programme
#define AL1             PIN_A1
#define AL2             PIN_A2
#define AL3             PIN_A3
#define MAUTO           PIN_A4
#define GEST_HALF       PIN_C5
#define AL1_ON          output_high(AL1)
#define AL1_OFF         output_low(AL1)
#define AL2_ON          output_high(AL2)
#define AL2_OFF         output_low(AL2)
#define AL3_ON          output_high(AL3)
#define AL3_OFF         output_low(AL3)
#define MAUTO_ON        output_high(MAUTO)
#define MAUTO_OFF       output_low(MAUTO)
#define CHOIX_VITESSE   input(PIN_B2)
 
#define MODBUS_LECTURE  0x03
#define MODBUS_ECRITURE 0x06
#define MODBUS_BOUCLAGE 0x08
 
// Les deux lignes suivantes ne sont plus nécessaires car c'est gérer par le #use RS232
//#define EMISSION  output_high(GEST_HALF)
//#define RECEPTION output_low(GEST_HALF)
 
// Variables globales du programme
const float consigne=12.0;
int8 addr_carte = 16;
volatile int8 req_modbus[16], cpt_req_modbus=0;
volatile int1 recep_trame_modbus = false;
 
// Cette structure permet d'avoir l'état des differentes E/S de la carte
// toutes les variables sont en int16 pour être conforme avec le MODBus
struct registres_interne {
   int16 relai0;
   int16 relai1;
   int16 relai2;
   int16 relai_ma;
   int16 val_cons10V;
} registres_carte;
 
// Routines d'interruptions
// Interruption réception voie serie
#int_RDA
void RDA_isr(void)
{
   // On stocke le caractère recu dans le tableau d'octets req_modus puis
   // on incremente le compteur de réception
   req_modbus[cpt_req_modbus] = getchar();
   cpt_req_modbus++;
   // Le timer0 gère le timeout, à chaque réception de caractères on repart à 0
   // On met le compteur du timer0 à 0
   set_timer0(0);
   // On efface le drapeaux d'interruption car il a été fixé par ailleurs
   clear_interrupt(INT_TIMER0);
   // On active l'interruption
   enable_interrupts(INT_TIMER0);
}
 
// Si on recoit rien au bout de 1,5 fois la durée d'un octet on considère que
// la trame modbus est complète
#INT_TIMER0
void timer0_isr(void)
{
   disable_interrupts(INT_TIMER0);
   recep_trame_modbus = true;
}
 
// Fonction d'initialisation pour parametrer tous les modules du PIC
void initialisation(void)
{
   int8 choix_adresse;                       // Variable temporaire pour le choix de l'adresse de la carte
 
   setup_adc_ports(AN0|VSS_VDD);             // Activation de l'entree analogique AN0
   setup_adc(ADC_CLOCK_INTERNAL);            // Utilisation de l'horloge interne du CAN
   set_tris_a(0b11100001);                   // On fixe les E/S sur les ports
   set_tris_b(0b11110111);                   // 0 : Output = sortie
   set_tris_c(0b10011011);                   // 1 : Input = entree
   port_b_pullups(0b00000111);               // Activation des résistances de rappel individuellement
   setup_spi(SPI_SS_DISABLED);               // Desactivation du SPI
   setup_timer_0(T0_INTERNAL|T0_DIV_32|T0_8_BIT);  // Reglage du timer 0
   setup_timer_1(T1_DISABLED);               // Desactivation timer 1
   setup_ccp1(CCP_PWM);                      // Activation de la premiere PWM : generation 12V
   setup_ccp2(CCP_PWM);                      // Activation de la deuxieme PWM : generation 10V
   setup_timer_2(T2_DIV_BY_1,255,1);         // Activation des PWM avec le timer2
   setup_comparator(NC_NC_NC_NC);            // Desactivation des modules de comparaison
   set_adc_channel(0);                       // Choix du canal 0 pour le CAN
   output_a(0);                              // Sorties du port A a 0 : relais en position repos
   memset(&registres_carte,0,sizeof(registres_carte)); // Initialisation des registres de la carte à 0
   set_pwm1_duty(1);                         // MLI generation 12V arrêté
   set_pwm2_duty(registres_carte.val_cons10V); // MLI generation 10V arreté
   disable_interrupts(INT_TIMER0);           // Interruption tts les 1/(8MHz/4) * 32 * 256 = 4,096ms
   enable_interrupts(INT_RDA);               // Activation interruption voie serie
   enable_interrupts(GLOBAL);                // Activation des interruptions (globalement)
   if (!CHOIX_VITESSE) setup_uart(19200);    // Si un cavalier est présent sur J7 on change la vitesse
                                             // de l'USART à 19200 bauds/s au lieu de 9600 bauds/s
   choix_adresse = input_b()&0x03;           // On récupère l'état des cavaliers J5 et J6
                                             // Si un cavalier =>0, si pas de cavalier =>1 car résistances de rappel interne
   switch (choix_adresse) {
      case 3 : addr_carte = 0x10; break;     // Pas de cavalier : adresse de la carte : 0x10 ou 16
      case 2 : addr_carte = 0x20; break;     // Pas de cavalier sur J6, cavalier sur J5 : adresse de la carte : 0x20 ou 32
      case 1 : addr_carte = 0x40; break;     // Pas de cavalier sur J5, cavalier sur J6 : adresse de la carte : 0x40 ou 64
      case 0 : addr_carte = 0x80; break;     // Cavalier sur J5 et J6 : : adresse de la carte : 0x80 ou 128
   }
}
 
// Code trouvé sur un forum, une version optimisé existe chez CCS
int16 calc_crc16()
{
   int16 crc = 0xFFFF;
   int8 i, done = 0;
   int8 todo;
 
   do {
         todo = req_modbus[done];
         crc ^= todo;
         for (i = 0; i < 8; i++) {
            if (crc % 2 != 0) {
               crc = (crc >> 1) ^ 0xA001;
            } else {
               crc = crc >> 1;
            }
         }
         done++;
   } while (done < (cpt_req_modbus-2));
 
   return crc;
}
 
void main()
{
   float val_tension;
   int16 val_pwm=0;
   int16 CRC16, registre, donnee;
   int8 i,j;
 
   initialisation();
 
   while(true) {
 
      if (recep_trame_modbus) {
         // On vérifie que l'adresse de l'esclave est la notre et que l'on a recu
         // plus que 3 octets (taille minimum d'un requete MODBUS : 4 octets)
         // Ex: Addr Esclave + Fonction Bouclage + CRC (2 octets) = 4 octets
         if (req_modbus[0] != addr_carte || cpt_req_modbus<4) goto fin;
         // calcul du CRC16 et comparaison avec celui transmis dans la trame
         CRC16 = make16(req_modbus[cpt_req_modbus-1], req_modbus[cpt_req_modbus-2]);
         // on sort si le CRC n'est pas correct
         if (CRC16 != calc_crc16()) goto fin;
         // On teste si on gère la fonction demandée
         if ((req_modbus[1] != MODBUS_BOUCLAGE) &&
             (req_modbus[1] != MODBUS_ECRITURE) &&
             (req_modbus[1] != MODBUS_LECTURE)) goto fin;
         // on aiguille suivant la fonction choisie
         switch (req_modbus[1]) {
            case MODBUS_ECRITURE :
               // On analyse si le registre existe sinon on sort
               registre = make16(req_modbus[2], req_modbus[3]);
               if (registre > 4) goto fin;
               donnee = make16(req_modbus[4], req_modbus[5]);
               switch (registre) {
                  case 0 : (donnee)?AL1_ON:AL1_OFF; registres_carte.relai0=donnee; break;
                  case 1 : (donnee)?AL2_ON:AL2_OFF; registres_carte.relai1=donnee; break;
                  case 2 : (donnee)?AL3_ON:AL3_OFF; registres_carte.relai2=donnee; break;
                  case 3 : (donnee)?MAUTO_ON:MAUTO_OFF; registres_carte.relai_ma=donnee; break;
                  case 4 : if (donnee <= 1023) { set_pwm2_duty(donnee); registres_carte.val_cons10V=donnee; } break;
               }
               // Notez l'absence du break ici pour renvoyer la réponse
           case MODBUS_BOUCLAGE :
               for (i=0; i<cpt_req_modbus; i++) putc(req_modbus[i]);
               break;
           case MODBUS_LECTURE :
               registre = make16(req_modbus[2], req_modbus[3]);
               if (registre > 4) goto fin;
               donnee = make16(req_modbus[4], req_modbus[5]);
               if ((donnee == 0) || (donnee > 5)) goto fin;
               // on teste si on ne demande pas des registres en dehors de la plage autorisée
               // on a 5 registres accésibles à partir de 0
               if ((registre+donnee) > 5) goto fin;
               req_modbus[2] = donnee * 2;
               // Les deux boucles 'for' pour remplir le tableau de la requete modbus à partir de la structure
               // qui représente la mémoire de registre. Deux boucles pour gérer le passage LSB,MSB de la structure
               // vers le format modbus qui réclame MSB,LSB
               for (i=registre*2,j=0;j<donnee*2;i+=2,j+=2) req_modbus[4+j]=*((int8 *)&registres_carte + i);
               for (i=registre*2,j=0;j<donnee*2;i+=2,j+=2) req_modbus[3+j]=*((int8 *)&registres_carte + i + 1);
               cpt_req_modbus = 3 + donnee * 2 + 2;
               CRC16 = calc_crc16();
               req_modbus[cpt_req_modbus-1] = CRC16>>8;
               req_modbus[cpt_req_modbus-2] = CRC16&0x00FF;
               for (i=0; i<cpt_req_modbus; i++) putc(req_modbus[i]);
               break;
         }
 
         fin:
         recep_trame_modbus = false;
         cpt_req_modbus = 0;
      }
 
      // Boucle d'asservissement de la tension 12V
      // Pont diviseur : R20=68K, R21=33K donc VCAN_12V = (33K/(33K+68K)*(VCC/2^10)
      val_tension = read_adc() * 0.0145;
 
      if (abs(consigne-val_tension) > 0.05) {
         if (val_tension<consigne && val_pwm<1000) val_pwm++;
         if (val_tension>consigne && val_pwm>5) val_pwm--;
         set_pwm1_duty(val_pwm);
      }
      delay_us(500);
   }
}

Remarque : lorsqu’une trame n’est pas valide ou qu’elle contient une requête non conforme, le code se contente de l’ignorer. Donc si vous ne recevez rien en retour d’une requête c’est que très certainement celle-ci est incorrecte ou que votre liaison physique est défectueuse. Rappelez-vous aussi qu’en l’absence de cavalier sur J5,J6 et J7 la carte a comme adresse 0×10 ou 16 en décimal et qu’elle fonctionne en 8N1 à 9600 bauds/s !

Programmation de la carte en langage C++ et réalisation de classes

Cette carte sera pilotée sous au moins deux environnements : un avec du GNU/Linux (emDebian sur plateforme TQ6410 avec QT comme framework), l’autre avec un PC industriel sous Microsoft Windows. Pour faciliter le pilotage de cette carte et des régulateurs, il a été décidé de créer des classes C++. Ces classes C++ se baseront sur la librairie open source libmodbus disponible sur libmodbus.org. Je ne peux pour l’instant pas donner les codes sources de ces classes, ni les tests unitaires réalisés avec celles-ci tant que les étudiants n’ont pas fini leur projet. La seule chose que je peux affirmer pour l’instant, c’est que les classes fonctionnent dans le cadre que l’on s’est fixé. Les codes sources seront disponibles lorsque les étudiants auront finalisé le projet…

L’interface graphique de test suivante a été réalisé sous GNU/Linux Debian avec Qt4.7 et les classes développées pour la carte :

Conclusion temporaire

Je pense que la mise en place chez l’industriel concerné va amener des modifications au niveau de la carte d’E/S. Lorsque le projet sera totalement finalisé, je mettrais à disposition les sources et le nouveau typon. En attendant vous avez largement de quoi débuter avec cette carte…

Je travaille avec une debian Sqeeze Grip (6.0). Les “pseudos” systèmes de fichiers /proc et /sys sont bien montés au démarrage. Le framebuffer est bien géré par le noyau. Le “touchscreen” est détecté dans /devices/virtual/input/input0. Un petit tour dans /dev que udev a peuplé pour trouver “fb0″ et “input/event0″. La gestion du touchscreen sera assuré par la librairie tslib. Celle-ci a été installé avec les paquets standards de debian (voir les autres articles). La base semble correct…En fait lors des premières compilations de Qt j’ai eu des soucis avec la librairies tslib qu’il ne trouvait pas même en ayant installé les paquets de développement. J’ai donc choisi de recompiler complètement la librairie et les utilitaires qui l’accompagne. La procédure est décrite ci-dessous.

1
2
3
4
5
6
7

root@casimir:~/qt-everywhere/# git clone http://github.com/kergoth/tslib.git
root@casimir:~/qt-everywhere/# cd tslib/
root@casimir:~/qt-everywhere/tslib# aptitude install dh-autoreconf
root@casimir:~/qt-everywhere/tslib# ./autogen.sh
root@casimir:~/qt-everywhere/tslib# ./configure --host=arm-linux-gnueabi --prefix=/usr/local/tslib --enable-static --enable-shared
root@casimir:~/qt-everywhere/tslib# make -j2
root@casimir:~/qt-everywhere/tslib# make install

La librairie tslib nécessite autoconf, d’où l’installation de autoreconf. Ensuite on compile en dynamique et en statique et enfin on installe dans /usr/local/tslib. Ce répertoire est ensuite copié intégralement sur la SDCard qui contient le ‘rootfs’ pour la carte TQ6410. On monte la carte et on copie le tout :

1
2
3

root@casimir:~/qt-everywhere/tslib# mount -t auto /dev/sdd1 /mnt
root@casimir:~/qt-everywhere/tslib# copy -R /usr/local/tslib /mnt/usr/local
root@casimir:~/qt-everywhere/tslib# sync; umount /mnt

On passe maintenant à la compilation de Qt. Sur notre machine de développement, on créée un nouveau répertoire puis on télécharge à l’aide de wget la dernière archive en date (qt-4.7.3 : 204Mo) de qt-everywhere enfin on désarchive le tout:

1
2
3
4

root@casimir:~# mkdir qt-everywhere
root@casimir:~# cd qt-everywhere
root@casimir:~/qt-everywhere# wget http://get.qt.nokia.com/qt/source/qt-everywhere-opensource-src-4.7.3.tar.gz
root@casimir:~/qt-everywhere# tar xzvf qt-everywhere-opensource-src-4.7.3.tar.gz

On rentre dans le répertoire puis on modifie le mkspec pour un arm v6 (arm11 sur le S3C36410):

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

root@casimir:~/qt-everywhere# cd qt-everywhere-opensource-src-4.7.3
root@casimir:~/qt-everywhere/qt-everywhere-opensource-src-4.7.3# vi mkspecs/qws/linux-armv6-g++/qmake.conf 
 
## qmake configuration for building for ARMv6 devices with arm-linux-g++#
 
include(../../common/g++.conf)
include(../../common/linux.conf)
include(../../common/qws.conf)
 
# modifications to g++.conf
QMAKE_CC                = arm-linux-gnueabi-gcc
QMAKE_CXX               = arm-linux-gnueabi-g++
QMAKE_LINK              = arm-linux-gnueabi-g++
QMAKE_LINK_SHLIB        = arm-linux-gnueabi-g++
QMAKE_CFLAGS           += -march=armv6
QMAKE_CXXFLAGS         += -march=armv6
 
# modifications to linux.conf
QMAKE_AR                = arm-linux-gnueabi-ar cqs
QMAKE_OBJCOPY           = arm-linux-gnueabi-objcopy
QMAKE_STRIP             = arm-linux-gnueabi-strip
 
QMAKE_INCDIR += /usr/local/tslib/include/
QMAKE_LIBDIR += /usr/local/tslib/lib/
QMAKE_LFLAGS += -Wl,-rpath-link=/usr/local/tslib/lib
 
load(qt_config)

On adapte l’existant pour faire pointer vers notre chaine de cross-compilation (ici arm-linux-gnueabi-xxxx), on rajoute les lignes QMAKE_INCDIR, QMAKE_LIBDIR pour qu’il utilise les includes et librairies de la TSLIB. La ligne QMAKE_LFLAGS permet d’éviter une erreur à l’édition de lien (voir ce lien). On lance ensuite la création des ‘makefiles’ puis la compilation et l’installation avec les commandes suivantes:

1
2
3

root@casimir:~/qt-everywhere/qt-everywhere-opensource-src-4.7.3# ./configure -embedded arm -xplatform qws/linux-armv6-g++ -prefix /usr/local/Qt -qt-mouse-tslib -little-endian
root@casimir:~/qt-everywhere/qt-everywhere-opensource-src-4.7.3# make -j2
root@casimir:~/qt-everywhere/qt-everywhere-opensource-src-4.7.3# make install

Dans la ligne ‘configure’ on génère tous les exemples, démos, docs, librairies, etc…Je l’ai laissé pour être sur de tout avoir correctement cependant la durée de compilation sur ma machine est énorme (plus de 6H : attention c’est un athlon et un disque ide de 40Go). Si une erreur apparaît en disant qu’il ne trouve pas la tslib, passez l’argument ‘-v’ à la commande configure puis regarder les logs. Dans la plupart des cas c’est qu’il ne trouve pas le compilateur : mettre dans le qmake.conf le nom et le chemin complet du cross-compilateur. Le ‘make install’ n’est pas strictement nécessaire car il va copier dans /usr/local/Qt l’ensemble des fichiers. Ca fait un peu doublon mais ensuite je vais transférer ce répertoire directement sur la carte SD qui contient ma debian lenny Grip (procédure identique à la copie de la tslib, ici le répertoire source est /usr/local/Qt).

Du coté de la carte TQ6410, je désinstalle les paquets que j’avais installé auparavant et qui risque de gêner quand je vais installer Qt: nodm, matchbox et libts:

1
2
3

root@TQ6410-Iris:~# aptitude remove --purge matchbox
root@TQ6410-Iris:~# aptitude remove --purge nodm
root@TQ6410-Iris:~# aptitude remove --purge libts-0.0-0

On installe ensuite la tslib que l’on a compilé auparavant sur notre machine de développement et on informe que l’on a de nouvelles librairies en créant un fichier /etc/ld.so.conf/tslib.conf qui contient le chemin vers les nouvelles librairies. Dans mon cas ce sera: /usr/local/tslib/lib. On met à jour la configuration en lançant ldconfig. Ensuite éditez le fichier /usr/local/tslib/etc/ts.conf pour décommenter la ligne qui contient ‘module raw’. Faire ensuite tous les exports de la tslib en faisant bien attention aux chemins et en laissant TSLIB_CALIBFILE= vide.

1
2
3
4
5
6
7
8

export TSLIB_TSEVENTTYPE=INPUT
export TSLIB_CONSOLEDEVICE=none
export TSLIB_FBDEVICE=/dev/fb0
export TSLIB_TSDEVICE=/dev/input/event0
export TSLIB_CALIBFILE=
export TSLIB_CONFFILE=/usr/local/tslib/etc/ts.conf
export TSLIB_PLUGINDIR=/usr/local/tslib/lib/ts
export QWS_MOUSE_PROTO=tslib:/dev/input/event0

On lance ensuite la calibration de l’écran avec:

1

root@TQ6410-Iris:~#/usr/local/bin/ts_calibrate /usr/local/tslib/etc/ts.calib

Vous appuyez sur les croix qui apparaissent…vous obtenez alors un fichier de calibration de l’écran. Vous pouvez alors faire l’export de TSLIB_CALIBFILE correctement:

1

export TSLIB_CALIBFILE=/usr/local/tslib/etc/ts.calib

Pour tester lancez : /usr/local/tslib/bin/ts_test. Si c’est bon vous pouvez tester les applications Qt que vous avez compilé précédemment. Elles sont disponibles dans /usr/local/Qt/examples et demos. Quand vous lancez une application, il faut faire:

./nom_appli -qws pour la lancer en mode embarqué. Si les caractères sont illisibles à l’écran, il faut rajouter deux variables aux précédentes:

1
2

export QWS_SIZE=800x600
export QWS_DISPLAY="LinuxFb:mmWidth=160:mmHeight=100"

Ces variables correspondent bien sur à mon écran (ici un 7”). J’ai ensuite récupéré une démonstration de ‘widget’ pour l’embarqué pour les compiler. J’ai suivi la procédure de pobot mais j’ai désarchivé dans /usr/local/Qt. J’ai donc un nouveau répertoire du nom de ‘embedded-widgets-1.1.0′. Pour compiler ces nouveaux exemples, j’ai tapé ces lignes dans le répertoire précédemment cité:

1
2
3

export PATH=/usr/local/Qt/bin:$PATH
/usr/local/Qt/bin/qmake -spec qws/linux-armv6-g++
make

J’ai ensuite transféré ce répertoire sur ma carte SD et testé sur la carte TQ6410. Cela fonctionne très bien et les widgets sont réellement impressionnants.

Le démarrage de la carte à froid (cold boot) se déroule dans cet ordre :

1. Lancement du chargeur intégré à la puce SoC (chez TI : X-Loader, chez Samsung ?) qui charge U-Boot depuis la flash NAND
2. Démarrage de U-Boot qui s’occupe du chargement de l’image noyau depuis la flash NAND en RAM
3. Décompression du noyau et démarrage de celui-ci
4. Montage du système de fichiers racine puis passage à INIT
5. Fin de l’initialisation : “UserLand” : vos applications

Le chargeur de la puce ne m’est pas accessible donc pas d’optimisation la dessus ! Nous allons donc commencer par U-Boot. Mais pour optimiser le temps de chargement, il faut pouvoir mesurer le temps de chaque étape. J’ai choisi d’utiliser GrabSerial (présentation et installation ici) pour faire les mesures de temps car il n’apporte pas de surcharge du coté système embarqué. GrabSerial utilise Python et necessite un module python à installer avec la commande suivante:

1

root@casimir:~# aptitude install python-serial

Il faut ensuite télécharger le script python GrabSerial, le rendre exécutable (chmod +x) et enfin le lancer avec une commande du style:

1

root@casimir:~# ./grabserial.py -v -t -m "Starting kernel.*"

qui va permettre d’intercepter les caractères arrivant sur la voie série ttyS0 et qui remet à 0 le compteur de temps lorsque “Starting kernel” apparaitra… Vous avez un exemple d’une trace issu de GrabSerial en fin d’article sur la personnalisation de la carte TQ6410.

Optimisation de U-Boot

Nous allons commencer par les optimisations simples (sous entendu sans recompilation du code) :

1. Le ‘u-Boot’ fourni avec la carte attend pendant 3s que vous tapiez sur une touche pour arrêter le chargement. On peut réduire ce temps à ‘0s’ et ainsi gagner 3s mais vous n’aurez plus accès au menu de U-Boot. Il faudra alors reflasher le U-Boot d’origine depuis la flash NOR. Pour fixer ce temps à ‘0′, quitter le menu de U-Boot pour passer à l’interpréteur de commande : Quit to shell (lettre ‘q’) puis tapez ’set bootdelay 0′. Si vous souhaitez conserver cette option, tapez ’saveenv’.
2. Vérifiez que la vitesse de transmission du port série est à 115200. Toujours depuis le shell de U-Boot, tapez ‘printenv’ puis vérifiez que la variable ‘baudrate’ est à 115200 sinon la fixer avec ’set baudrate 115200′.
3. U-Boot effectue une somme de contrôle sur le noyau qu’il charge. On peut désactiver cette option en tapant ’set verify no’.
4. Toutes les sorties vers la voie série ralentissent énormément U-Boot. Pour désactiver les sorties il faut que le code soit compiler avec ‘#define CONFIG_SILENT_CONSOLE’ et mettre à 1 la variable silent: ’set silent 1′. J’ai essayé de recompiler le code fourni avec la carte avec l’option ci-dessus mais cela n’a rien changé sur le fait qu’il m’affiche les messages de lecture de la flash NAND lors du chargement du noyau. Il faut donc que je trouve dans le code ou est ce “printf” qui ralentit énormément la lecture en flash NAND…
5. Par défaut si on ne touche pas au menu de U-Boot, au bout de 3s, la commande ‘bootcmd’ est exécutée. Or cette commande lit  0×500000 octets soit 5 242 880 octets avec le U-Boot fourni par le vendeur de la carte. Ceci même si votre noyau fait 1,2Mo. Il faut donc modifier cette commande pour ne lire que ce qui est nécessaire en flash NAND pour démarrer le noyau. Par exemple, un des noyaux (uImage) que j’ai compilé pour cette plateforme fait 1 246 156 octets qu’il faut aligner sur la flash NAND (padder en anglais) sur des secteurs de 2 048 octets donc on fait 1 246 156/2 048 = 608,47. On prend 609+1=610 et on remultiplie par 2048, on obtient 1 249 280 octets soit 0×13 100 en hexadécimal. On tapera donc la commande suivante pour fixer ‘bootcmd’ : set bootcmd ‘nand read.i c0008000 80000 13100; bootm c0008000′. On charge en RAM (0xc000800) à partir de l’adresse 0×80000 de la flash NAND (adresse ou l’on télécharge  le noyau en flash avec la lettre ‘k’ du menu) 0×131000 octets. On gagne ainsi un temps précieux. Remarquez que si vous tapez la lettre ‘b’ du menu, c’est toujours 5Mo qui seront lu depuis la flash car la commande est codé en “dur” dans le code.

On obtient la trace suivante:

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

[    0.000003]
[    0.289005]
[    0.289216] U-Boot 1.1.6 (Aug  5 2011 - 11:50:17) for TQ6410
[    0.293653]
[    0.293860]
[    0.294013] CPU:     S3C6410@532MHz
[    0.296218]          Fclk = 532MHz, Hclk = 133MHz, Pclk = 66MHz, Serial = CLKUART (SYNC Mode)
[    0.303626] Board:   TQ6410
[    0.305115] DRAM:    128 MB
[    0.306488] Flash:   0 kB
[    0.307700] NAND:    256 MB
[    0.399982] In:      serial
[    0.401473] Out:     serial
[    0.402932] Err:     serial
[    0.483943] MAC: 08:90:90:90:90:90
[    0.486062] Hit any key to stop autoboot:  3  2  1  0
[    3.468708]
[    3.468897] NAND read: device 0 offset 0x80000, size 0x131000
[    3.473340]
[    3.473511] Reading data from 0x80000 --   0% complete.Reading data from 0x83000 --   1% complete.Reading data from 0x86000 --   2% complete.Reading data from 0x89000 --   3% complete.Reading data from 0x8c000 --   4% complete.Reading data from 0x8f000 --   5% complete.Reading data from 0x92000 --   6% complete.Reading data from 0x95000 --   7% complete.Reading data from 0x98000 --   8% complete.Reading data from 0x9b000 --   9% complete.Reading data from 0x9e000 --  10% complete.Reading data from 0xa1800 --  11% complete.Reading data from 0xa4800 --  12% complete.Reading data from 0xa7800 --  13% complete.Reading data from 0xaa800 --  14% complete.Reading data from 0xad800 --  15% complete.Reading data from 0xb0800 --  16% complete.Reading data from 0xb3800 --  17% complete.Reading data from 0xb6800 --  18% complete.Reading data from 0xb9800 --  19% complete.Reading data from 0xbc800 --  20% complete.Reading data from 0xc0000 --  21% complete.Reading data from 0xc3000 --  22% complete.Reading data from 0xc6000 --  23% complete.Reading data from 0xc9000 --  24% complete.Reading data from 0xcc000 --  25% complete.Reading data from 0xcf000 --  26% complete.Reading data from 0xd2000 --  27% complete.Reading data from 0xd5000 --  28% complete.Reading data from 0xd8000 --  29% complete.Reading data from 0xdb000 --  30% complete.Reading data from 0xde800 --  31% complete.Reading data from 0xe1800 --  32% complete.Reading data from 0xe4800 --  33% complete.Reading data from 0xe7800 --  34% complete.Reading data from 0xea800 --  35% complete.Reading data from 0xed800 --  36% complete.Reading data from 0xf0800 --  37% complete.Reading data from 0xf3800 --  38% complete.Reading data from 0xf6800 --  39% complete.Reading data from 0xf9800 --  40% complete.Reading data from 0xfd000 --  41% complete.Reading data from 0x100000 --  42% complete.Reading data from 0x103000 --  43% complete.Reading data from 0x106000 --  44% complete.Reading data from 0x109000 --  45% complete.Reading data from 0x10c000 --  46% complete.Reading data from 0x10f000 --  47% complete.Reading data from 0x112000 --  48% complete.Reading data from 0x115000 --  49% complete.Reading data from 0x118000 --  50% complete.Reading data from 0x11b800 --  51% complete.Reading data from 0x11e800 --  52% complete.Reading data from 0x121800 --  53% complete.Reading data from 0x124800 --  54% complete.Reading data from 0x127800 --  55% complete.Reading data from 0x12a800 --  56% complete.Reading data from 0x12d800 --  57% complete.Reading data from 0x130800 --  58% complete.Reading data from 0x133800 --  59% complete.Reading data from 0x136800 --  60% complete.Reading data from 0x13a000 --  61% complete.Reading data from 0x13d000 --  62% complete.Reading data from 0x140000 --  63% complete.Reading data from 0x143000 --  64% complete.Reading data from 0x146000 --  65% complete.Reading data from 0x149000 --  66% complete.Reading data from 0x14c000 --  67% complete.Reading data from 0x14f000 --  68% complete.Reading data from 0x152000 --  69% complete.Reading data from 0x155000 --  70% complete.Reading data from 0x158800 --  71% complete.Reading data from 0x15b800 --  72% complete.Reading data from 0x15e800 --  73% complete.Reading data from 0x161800 --  74% complete.Reading data from 0x164800 --  75% complete.Reading data from 0x167800 --  76% complete.Reading data from 0x16a800 --  77% complete.Reading data from 0x16d800 --  78% complete.Reading data from 0x170800 --  79% complete.Reading data from 0x173800 --  80% complete.Reading data from 0x177000 --  81% complete.Reading data from 0x17a000 --  82% complete.Reading data from 0x17d000 --  83% complete.Reading data from 0x180000 --  84% complete.Reading data from 0x183000 --  85% complete.Reading data from 0x186000 --  86% complete.Reading data from 0x189000 --  87% complete.Reading data from 0x18c000 --  88% complete.Reading data from 0x18f000 --  89% complete.Reading data from 0x192000 --  90% complete.Reading data from 0x195800 --  91% complete.Reading data from 0x198800 --  92% complete.Reading data from 0x19b800 --  93% complete.Reading data from 0x19e800 --  94% complete.Reading data from 0x1a1800 --  95% complete.Reading data from 0x1a4800 --  96% complete.Reading data from 0x1a7800 --  97% complete.Reading data from 0x1aa800 --  98% complete.Reading data from 0x1ad800 --  99% complete.Reading data from 0x1b0800 -- 100% complete.
[    4.672055]  1249280 bytes read: OK
[    4.678741] ## Booting image at c0008000 ...
[    4.679811]    Image Name:   Linux-2.6.28.6-IRIS-Turgot-O.Dar
[    4.684310]    Image Type:   ARM Linux Kernel Image (uncompressed)
[    4.686018]    Data Size:    1246092 Bytes =  1.2 MB
[    4.688032]    Load Address: 50008000
[    4.692227]    Entry Point:  50008000
[    4.999951] OK
[    5.000117]
[    5.000197] Starting kernel ...

J’ai laissé volontairement la ‘longuuuuue’ chaine qui indique la progression de la lecture en flash. Je pense que cette sortie vers la voie série ralentit énormément le boot. Je recherche donc dans les codes sources comment supprimer cette sortie… Je viens de trouver ! C’est dans le fichiers drivers/nand/nand_util.c…faire une recherche avec “Reading” et commenter la ligne : printf(”\rReading data from…percent);.  Je recompile le tout et je fais un test avec et sans cette sortie avec GrabSerial:

• avec la sortie “Reading…” : 1,204s pour charger le noyau (1,2Mo) depuis la flash NAND
• sans la sortie “Reading….” : 0,832s pour charger le noyau (1,2Mo) depuis la flash NAND

Conclusion : prêt de 30% de temps de gagner ! Dans la plupart des cas limiter les sorties vers l’écran ou la voie série permet de gagner du temps (voir plus loin pour le noyau avec le ‘printk’ et l’option ‘quiet’). J’obtiens un temps de 1,6s depuis le démarrage à froid jusqu’au message ‘Starting kernel’ et 14,4s jusqu’à l’affichage du login avec un rootfs en ext3 sur carte SD.

Optimisation du noyau Linux

J’ai modifié la configuration de base fourni par le vendeur pour qu’elle corresponde à nos besoins. En clair moins vous mettez de ‘choses’ dans votre noyau, plus celui-ci est petit et plus il charge vite. Actuellement j’ai gardé le nécessaire pour faire tourner la carte correctement, cependant comme je n’ai pas encore choisi le système de fichiers du ‘rootfs’ j’ai gardé le support du ext3, de yaffs, de jffs2 avec tous les systèmes de compression et ubifs. Une fois que j’aurais décidé lequel je garde j’éliminerai les autres et je gagnerai du temps au boot. De plus afin d’avoir des indication de temps par le noyau j’ai compilé celui-ci avec le support du “printk”, on pourra l’éliminer par la suite.

Pour l’instant on peut appliquer des modifications à la ligne de commande du noyau Linux. Comme précédemment, limiter les sorties vers l’écran ou la voie série permet de gagner du temps. Donc la première chose à changer et de rajouter le paramètre ‘quiet’. Un petit test avec GrabSerial et on obtient :

• messages du noyau affichés : de “Starting kernel” au lancement de INIT : 2,255s
• messages du noyau cachés :  de “Starting kernel” au lancement de INIT : 1,707s

Conclusion: on gagne 548ms rien qu’avec ce paramètre !

A chaque démarrage, on recalibre la durée d’une boucle appelée ‘loop_per_jiffy’ ou LPJ associée au BogoMips. Or le noyau nous donne la valeur de la calibration pendant le boot. Il suffit donc de passer ce paramètre au noyau pour éviter cette calibration. Dans mon cas, la ligne qui nous interesse est la suivante:

1

Calibrating delay loop... 353.89 BogoMIPS (lpj=884736)

A priori cette opération dure 110ms mais la sortie ‘printk’ du noyau n’est sans doute pas assez précise. Faisons un test avec GrabSerial. J’obtiens:

• avec boucle de calibrage: de “Starting kernel” au lancement de INIT : 1,707s
• sans boucle de calibrage: de “Starting kernel” au lancement de INIT : 1,599s

Conclusion: environ 110ms de gagner ! Dans les messages noyau on obtient:

1

Calibrating delay loop (skipped) preset value.. 353.89 BogoMIPS

On obtient actuellement un temps de 13,184s pour l’arrivée jusqu’au login mais surtout on met 3,228s jusqu’à INIT.

La décompression du noyau au départ prend 560ms, ce qui est loin d’être négligeable. J’ai testé avec un noyau non compressé mais c’est plus défavorable donc il faudrait que la décompression soit plus rapide. Dans la version de mon noyau (2.6.38), l’image est compressé avec ZLIB et je n’ai pas d’autres choix. Apparemment si vous pouvez choisir votre système de décompression, il faut prendre LZO !

Choix du système de fichiers racine parmi ext3, JFFS2, YAFFS2 et UBIFS

Pour continuer à optimiser le temps de boot, je me suis dit que l’on pouvait certainement gagner sur le temps de montage du rootfs. Pendant tous les tests précédents on monte le rootfs depuis une carte SD formatée en ext3. Le paramètre ‘rootwait’ du noyau permet d’attendre le système de fichiers. Cette attente est donnée dans les messages du noyau, ici elle vaut (du message ‘Waiting for root device /dev/mmcblk0p1…’ à ‘VFS: Mounted root (ext3 filesystem)’) 435ms.

Au boot 3 “pseudos” partitions sont créées aux adresses indiquées ci-dessous dans la flash NAND, on le voit avec les messages du noyau suivant:

1
2
3
4
5
6
7

S3C NAND Driver, (c) 2008 Samsung Electronics
S3C NAND Driver is using hardware ECC.
NAND device: Manufacturer ID: 0xec, Chip ID: 0xda (Samsung NAND 256MiB 3,3V 8-bit)
Creating 3 MTD partitions on "NAND 256MiB 3,3V 8-bit":
0x00000000-0x00080000 : "Bootloader"
0x00080000-0x00580000 : "Kernel"
0x00580000-0x10000000 : "File System"

On va donc s’interresser à la troisième partition “File System” qui va contenir le système de fichiers racine. Comme on démarre actuellement sur la carte SD, on peut effacer sans problème cette “partition”. Pour cela vous devez disposer des outils de manipulation des Flashs NOR et NAND. Ceux-ci s’installent avec la commande suivante depuis le système embarqué et nous allons tester quelques commandes :

1
2
3
4
5
6
7
8
9
10
11

root@TQ6410-Iris:~# aptitude install mtd-utils
root@TQ6410-Iris:~# mtdinfo /dev/mtd2
mtd2
Name:                           File System
Type:                           nand
Eraseblock size:                131072 bytes, 128.0 KiB
Amount of eraseblocks:          2004 (262668288 bytes, 250.5 MiB)
Minimum input/output unit size: 2048 bytes
Sub-page size:                  unknown
Bad blocks are allowed:         true
Device is writable:             true

On remarque bien que la flash NAND s’efface par blocs de 128Ko et que l’unité de base est de 2048octets.

Système de fichiers JFFS2 sur flash NAND

On va commencer par tester le système de fichiers JFFS2. Pour mémoire dans la configuration du noyau, j’ai activé toutes les méthodes de compression avec une préférence pour LZO (compression plus faible que ZLIB ou BZip2 mais vitesse de décompression trés rapide). On va donc initialiser cette partition pour qu’elle acceuille un système de fichiers JFFS2:

1
2
3
4
5
6
7
8

root@TQ6410-Iris:~# flash_eraseall -j /dev/mtd2
Erasing 128 Kibyte @ 62c0000 -- 39 % complete. Cleanmarker written at 62c0000.
Skipping bad block at 0x062e0000
Erasing 128 Kibyte @ 8e60000 -- 56 % complete. Cleanmarker written at 8e60000.
Skipping bad block at 0x08e80000
Erasing 128 Kibyte @ 95e0000 -- 59 % complete. Cleanmarker written at 95e0000.
Skipping bad block at 0x09600000
Erasing 128 Kibyte @ fa80000 -- 100 % complete.Cleanmarker written at fa60000.

On remarque que la flash NAND a des erreurs. Le système de fichiers en tiendra compte ! On monte notre “pseudo” partition dans /mnt:

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

root@TQ6410-Iris:~# mount -t jffs2 /dev/mtdblock2 /mnt
root@TQ6410-Iris:~# mount
tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
udev on /dev type tmpfs (rw,mode=0755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620)
rootfs on / type rootfs (rw)
/dev/mtdblock2 on /mnt type jffs2 (rw)
root@TQ6410-Iris:~# df -h
Filesystem            Size  Used Avail Use% Mounted on
rootfs                1.9G  477M  1.4G  26% /
/dev/mtdblock2        251M  5.9M  245M   3% /mnt

Nous disposons donc d’un espace conséquent pour le stockage de notre système de fichiers racine (prés de 245Mo avant compression). Pour installer le système de fichiers racine dans cette espace, j’ai créé auparavant une archive tar.bz2 de mon système qui tourne actuellement sur la carte SD. Comment faire ? Trés simple, sur votre système de développement montez cette carte SD avec une commande du style : mount -t auto /dev/sdd1 /mnt puis créez l’archive avec tar jcf rootfs-debian-squeeze-grip-for-TQ6410.tar.bz2 /mnt/*. Vous obtenez alors une archive de votre système de fichiers racine (chez moi cette archive fait 22Mo) que vous allez copier sur la carte SD avec cp rootfs-debian-squeeze-grip-for-TQ6410.tar.bz2 /mnt pour ensuite le désarchiver vers la NAND Flash. Démontez votre carte SD avec umount /mnt. On admet que l’on reprend la suite des commandes ci-dessus et que vous disposez de l’archive à la racine de la carte SD Au fait si vous n’arrivez pas à désarchivez l’archive c’est que vous n’avez probablement pas bzip2 d’installé…un petit aptitude install bzip2 réglera l’affaire !

On désarchive donc notre système de fichiers racine vers /mnt qui représente le mtd2 de la flash NAND (attention soyez patient) :

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

root@TQ6410-Iris:~# cd /mnt
root@TQ6410-Iris:/mnt# tar jxf /debian-squeeze-grip-OD.tar.bz2 .
root@TQ6410-Iris:/mnt# ls /mnt
bin   dev  home  lost+found  mnt  proc  sbin     srv  tmp  var
boot  etc  lib   media       opt  root  selinux  sys  usr
root@TQ6410-Iris:/mnt# df -h
Filesystem            Size  Used Avail Use% Mounted on
rootfs                1.9G  477M  1.4G  26% /
/dev/mtdblock2        251M   42M  210M  17% /mnt
root@TQ6410-Iris:/mnt# du -h --max-depth=1 /mnt
3.9M    /mnt/bin
512     /mnt/dev
361K    /mnt/etc
7.3M    /mnt/lib
0       /mnt/mnt
0       /mnt/opt
0       /mnt/srv
0       /mnt/tmp
0       /mnt/sys
8.3M    /mnt/var
40M     /mnt/usr
0       /mnt/boot
0       /mnt/home
0       /mnt/proc
3.3M    /mnt/sbin
14K     /mnt/root
0       /mnt/media
0       /mnt/selinux
0       /mnt/lost+found
63M     /mnt

On vérifie le contenu de la flash NAND avec un ‘ls’. On regarde combien on a mangé de place (ici 42Mo) et combien on occupe effectivement de place (ici 63Mo). On travaille donc bien sur un système de fichiers compressé mais adapté au mémoire flash (c’est à dire que l’on réparti les écritures pour moyenner l’usure (wear-levelling)) et relativement résistant au coupure électrique brusque puisque journalisé ! Reste à savoir le temps de montage au boot. Redémarrez puis arrêtez U-Boot car il nous faut modifier la ligne de passage d’arguments au noyau (lettre ’s’) :

1

console=ttySAC0,115200 root=/dev/mtdblock2 rootfstype=jffs2 init=/sbin/init quiet noswap lpj=884736

Je retire la carte SD puis on fait donc le test du temps de boot avec GrabSerial. J’obtiens un temps de 18,383s depuis la mise sous tension jusqu’a l’obtention du login. Mais ce n’est pas vraiment ce qui m’interesse. Il faut fouiller les messages du noyau pour tenter de repérer le temps de montage :

1
2
3
4
5
6
7

[21474536.705000] TCP cubic registered
[21474536.705000] NET: Registered protocol family 17
[21474536.705000] VFP support v0.3: implementor 41 architecture 1 part 20 varia5
[21474536.710000] s3c2410-rtc s3c2410-rtc: setting system clock to 2011-08-08 2)
[21474539.275000] s3c64xx_clk_doutmpll_get_rate: parent is 532000000
[21474539.560000] VFS: Mounted root (jffs2 filesystem).
[21474539.560000] Freeing init memory: 96K

On passe de 36.71s à 39.275s or ce n’est pas la synchronisation de l’horloge système avec la RTC qui prend aussi longtemps. J’estime donc que le temps de montage est 39.56 - 36.71 = 2,85s pour monter les 250Mo de cette partition. Si vous cherchez un peu sur Internet vous verrez que le reproche fait à JFFS2 est son temps de montage or ici il est loin d’être catastrophique…bon j’ai triché un peu :-). Il existe un paramètre pour le système de fichiers JFFS2 qui permet de monter beaucoup plus vite le système de fichiers dans le noyau :  [*] JFFS2 summary support. J’ai fait le test sans ce paramètre et le temps de montage sur la même partition est alors de 14s ! Bon on s’éloigne de notre but : démarrez plus vite mais on s’est rapproché de coté ‘clair’ de la force : on a un système rootfs sur une flash NAND et pas sur une SD.

Conclusion: globalement on va moins vite mais on s’est rapproché d’un ‘vrai’ système embarqué…de plus la compression, la jounalisation et le wear-levelling sont interessants.

Système de fichiers YAFFS2 sur flash NAND

On va recommencer un peu la même chose que précédemment avec un système de fichiers YAFFS2. Cette fois-ci je commence par la capture d’écran des paramètres noyau pour le système de fichiers YAFFS2:

Donc on redémarre sur notre carte SD pour pouvoir manipuler sans problème la flash NAND. On enchaine donc les commandes suivantes:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56

root@TQ6410-Iris:~# flash_eraseall /dev/mtd2
Erasing 128 Kibyte @ 62c0000 -- 39 % complete.
Skipping bad block at 0x062e0000
Erasing 128 Kibyte @ 8e60000 -- 56 % complete.
Skipping bad block at 0x08e80000
Erasing 128 Kibyte @ 95e0000 -- 59 % complete.
Skipping bad block at 0x09600000
Erasing 128 Kibyte @ fa80000 -- 100 % complete.
root@TQ6410-Iris:~# mount -t yaffs2 /dev/mtdblock2 /mnt
[21474611.890000] yaffs: dev is 32505858 name is "mtdblock2"
[21474611.890000] yaffs: passed flags ""
[21474611.895000] yaffs: Attempting MTD mount on 31.2, "mtdblock2"
[21474612.095000] yaffs_read_super: isCheckpointed 0
root@TQ6410-Iris:~# mount
tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
udev on /dev type tmpfs (rw,mode=0755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620)
rootfs on / type rootfs (rw)
/dev/mtdblock2 on /mnt type yaffs2 (rw)
root@TQ6410-Iris:~# df -h
Filesystem            Size  Used Avail Use% Mounted on
rootfs                1.9G  477M  1.4G  26% /
/dev/mtdblock2        251M  1.5M  249M   1% /mnt
root@TQ6410-Iris:~# cd /mnt
root@TQ6410-Iris:/mnt# tar jxf /debian-squeeze-grip-OD.tar.bz2 .
root@TQ6410-Iris:/mnt# ls /mnt
bin   dev  home  lost+found  mnt  proc  sbin     srv  tmp  var
boot  etc  lib   media       opt  root  selinux  sys  usr
root@TQ6410-Iris:/mnt# df -h
Filesystem            Size  Used Avail Use% Mounted on
rootfs                1.9G  477M  1.4G  26% /
/dev/mtdblock2        251M   81M  170M  33% /mnt
root@TQ6410-Iris:/mnt# du -h --max-depth=1 /mnt
532K    /mnt/etc
2.0K    /mnt/boot
18K     /mnt/root
2.0K    /mnt/home
2.0K    /mnt/mnt
2.0K    /mnt/srv
41M     /mnt/usr
3.3M    /mnt/sbin
2.0K    /mnt/tmp
2.0K    /mnt/opt
2.0K    /mnt/selinux
2.0K    /mnt/media
3.9M    /mnt/bin
8.4M    /mnt/var
2.0K    /mnt/proc
92K     /mnt/dev
2.0K    /mnt/sys
7.3M    /mnt/lib
2.0K    /mnt/lost+found
64M     /mnt

Quelques remarques sur ce qui précède : on efface d’abord la flash NAND, puis on monte cette partition en YAFFS2, on voit que trés peu de place est occupé au montage (à peine 1,5Mo). On désarchive le ‘rootfs’. Puis on regarde la place occupée sur le support : prés de 80Mo !! sur 64Mo effectif…on perd donc beaucoup de bloc mémoire. Le système de fichiers n’est pas compressé. On redémarre sur ce système de fichier avec les paramètres suivants:

1

console=ttySAC0,115200 root=/dev/mtdblock2 rootfstype=yaffs2 init=/sbin/init quiet noswap lpj=884736

A nouveau on regarde ce que ça donne au point de vue temps de boot avec GrabSerial. J’obtiens un temps de 13,215s depuis la mise sous tension jusqu’à l’obtention du login. Ce n’est pas mal du tout puisque l’on est au même niveau que le boot sur la SD en ext3. Fouillons les messages du noyau pour tenter de repérer le temps de montage :

1
2
3
4
5
6

[21474536.710000] yaffs: dev is 32505858 name is "mtdblock2"
[21474536.710000] yaffs: passed flags ""
[21474536.710000] yaffs: Attempting MTD mount on 31.2, "mtdblock2"
[21474536.960000] yaffs: restored from checkpoint
[21474536.960000] yaffs_read_super: isCheckpointed 1
[21474536.960000] VFS: Mounted root (yaffs2 filesystem).

On obtient un temps de 36.96 - 36.71 = 250ms ce qui est assez remarquable…à moins que je me sois trompé quelque part mais là je vois pas où car j’ai suivi la même procédure que pour le JFFS2.

Conclusion: on est au même niveau que la carte SD en ext3 mais avec un système de fichier pour flash NAND journalisé. On est aussi plus ’système embarqué’. Le seul souci c’est qu’il ne compresse pas à la volée. Je n’ai pas cherché si cela est possible…En tout cas cela semble être un bon choix comme futur système de fichiers pour notre système.

Système de fichiers UBIFS sur flash NAND

C’est sans doute le système de fichiers le plus compliqué à mettre en place avec une méthode identique aux précédents. Les paramètres du noyau sont les suivants:

Pour mémoire on travaille sur la MTD2 qui doit contenir le rootfs.On va donc commencer par effacer la flash NAND puis formater le MTD avec ubiformat:

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

root@TQ6410-Iris:~# flash_eraseall /dev/mtd2
Erasing 128 Kibyte @ 62c0000 -- 39 % complete.
Skipping bad block at 0x062e0000
Erasing 128 Kibyte @ 8e60000 -- 56 % complete.
Skipping bad block at 0x08e80000
Erasing 128 Kibyte @ 95e0000 -- 59 % complete.
Skipping bad block at 0x09600000
Erasing 128 Kibyte @ fa80000 -- 100 % complete.
root@TQ6410-Iris:~# ubiformat /dev/mtd2
ubiformat: warning!: your MTD system is old and it is impossible to detect sub-page size. Use -s to get rid of this warning
ubiformat: assume sub-page to be 2048
ubiformat: mtd2 (nand), size 262668288 bytes (250.5 MiB), 2004 eraseblocks of 131072 bytes (128.0 KiB), min. I/O size 2048 bytes
libscan: scanning eraseblock 2003 -- 100 % complete
ubiformat: 2001 eraseblocks have valid erase counter, mean value is 0
ubiformat: bad eraseblocks: 791, 1140, 1200
ubiformat: formatting eraseblock 2003 -- 100 % complete

J’essaye alors “d’attacher” ce mtd au système (paramètres -m 2 ci-dessous) :

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

oot@TQ6410-Iris:~# ubiattach /dev/ubi_ctrl -m 2
[  748.290000] UBI: attaching mtd2 to ubi0
[  748.290000] UBI: physical eraseblock size:   131072 bytes (128 KiB)
[  748.295000] UBI: logical eraseblock size:    129024 bytes
[  748.300000] UBI: smallest flash I/O unit:    2048
[  748.305000] UBI: sub-page size:              512
[  748.310000] UBI: VID header offset:          512 (aligned 512)
[  748.315000] UBI: data offset:                2048
[  748.330000] UBI error: validate_ec_hdr: bad VID header offset 2048, expected 512
[  748.330000] UBI error: validate_ec_hdr: bad EC header
[  748.335000] UBI error: ubi_io_read_ec_hdr: validation failed for PEB 0
ubiattach: error!: cannot attach mtd2
           error 22 (Invalid argument)

Bon il y a un soucis…Aprés une petite recherche sur internet, je trouve la réponse sur ce site : http://www.linux-mtd.infradead.org/faq/ubifs.html#L_mount_ubifs. Il faut reformatter la MTD en précisant la taille des “sous-pages” puis on retente d’attacher :

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

root@TQ6410-Iris:~# ubiformat /dev/mtd2 -s 512
ubiformat: mtd2 (nand), size 262668288 bytes (250.5 MiB), 2004 eraseblocks of 131072 bytes (128.0 KiB), min. I/O size 2048 bytes
libscan: scanning eraseblock 2003 -- 100 % complete
ubiformat: 2001 eraseblocks have valid erase counter, mean value is 1
ubiformat: bad eraseblocks: 791, 1140, 1200
ubiformat: warning!: VID header and data offsets on flash are 2048 and 4096, which is different to requested offsets 512 and 2048
ubiformat: use new offsets 512 and 2048? (yes/no)  yes
ubiformat: use offsets 512 and 2048
ubiformat: formatting eraseblock 2003 -- 100 % complete
root@TQ6410-Iris:~# ubiattach /dev/ubi_ctrl -m 2
[ 1443.140000] UBI: attaching mtd2 to ubi0
[ 1443.140000] UBI: physical eraseblock size:   131072 bytes (128 KiB)
[ 1443.145000] UBI: logical eraseblock size:    129024 bytes
[ 1443.150000] UBI: smallest flash I/O unit:    2048
[ 1443.155000] UBI: sub-page size:              512
[ 1443.160000] UBI: VID header offset:          512 (aligned 512)
[ 1443.165000] UBI: data offset:                2048
[ 1444.270000] UBI: attached mtd2 to ubi0
[ 1444.270000] UBI: MTD device name:            "File System"
[ 1444.275000] UBI: MTD device size:            250 MiB
[ 1444.280000] UBI: number of good PEBs:        2001
[ 1444.285000] UBI: number of bad PEBs:         3
[ 1444.290000] UBI: max. allowed volumes:       128
[ 1444.295000] UBI: wear-leveling threshold:    4096
[ 1444.300000] UBI: number of internal volumes: 1
[ 1444.305000] UBI: number of user volumes:     0
[ 1444.305000] UBI: available PEBs:             1977
[ 1444.310000] UBI: total number of reserved PEBs: 24
[ 1444.315000] UBI: number of PEBs reserved for bad PEB handling: 20
[ 1444.320000] UBI: max/mean erase counter: 2/2
[ 1444.345000] UBI: background thread "ubi_bgt0d" started, PID 1727
UBI device number 0, total 2001 LEBs (258177024 bytes, 246.2 MiB), available 1977 LEBs (255080448 bytes, 243.3 MiB), LEB size 129024 bytes (126.0 KiB)

On vient d’attacher un périphérique ‘ubi0′ à notre système, il faut maintenant créer un volume sur celui-ci (le paramètre ‘-m’ permet d’utiliser la totalité de l’espace disponible dans ‘ubi0′ et -N spécifie le nom : ici ‘rootfs’ qui sera utilisé plus tard):

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

root@TQ6410-Iris:~# ubimkvol -h
ubimkvol version 1.0 - a tool to create UBI volumes.
 
Usage: ubimkvol <UBI device node file name> [-h] [-a <alignment>] [-n <volume ID>] [-N &lt;name&gt;]
                        [-s &lt;bytes&gt;] [-S &lt;LEBs&gt;] [-t &lt;static|dynamic&gt;] [-V] [-m]
                        [--alignment=&lt;alignment&gt;][--vol_id=&lt;volume ID&gt;] [--name=&lt;name&gt;]
                        [--size=&lt;bytes&gt;] [--lebs=&lt;LEBs&gt;] [--type=&lt;static|dynamic&gt;] [--help]
                        [--version] [--maxavsize]
 
Example: ubimkvol /dev/ubi0 -s 20MiB -N config_data - create a 20 Megabytes volume
         named "config_data" on UBI device /dev/ubi0.
 
-a, --alignment=&lt;alignment&gt;   volume alignment (default is 1)
-n, --vol_id=&lt;volume ID&gt;      UBI volume ID, if not specified, the volume ID
                              will be assigned automatically
-N, --name=&lt;name&gt;             volume name
-s, --size=&lt;bytes&gt;            volume size volume size in bytes, kilobytes (KiB)
                              or megabytes (MiB)
-S, --lebs=&lt;LEBs count&gt;       alternative way to give volume size in logical
                              eraseblocks
-m, --maxavsize               set volume size to maximum available size
-t, --type=&lt;static|dynamic&gt;   volume type (dynamic, static), default is dynamic
-h, -?, --help                print help message
-V, --version                 print program version
 
The following is a compatibility option which is deprecated, do not use it
-d, --devn=&lt;devn&gt;             UBI device number - may be used instead of the UBI
                              device node name in which case the utility assumes
                              that the device node is "/dev/ubi&lt;devn&gt;"
root@TQ6410-Iris:~# ubimkvol /dev/ubi0 -N rootfs -m
Set volume size to 255080448
Volume ID 0, size 1977 LEBs (255080448 bytes, 243.3 MiB), LEB size 129024 bytes (126.0 KiB), dynamic, name "rootfs", alignment 1

On regarde si ‘udev’ a créé les périphériques concernés dans /dev:

1
2

root@TQ6410-Iris:~# ls /dev/ubi*
/dev/ubi0  /dev/ubi0_0  /dev/ubi_ctrl

On est prêt à monter ce périphérique dans notre système et prendre quelques renseignements dessus:

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

root@TQ6410-Iris:~# mount -t ubifs ubi0:rootfs /mnt
[ 2589.845000] UBIFS: default file-system created
[ 2589.950000] UBIFS: mounted UBI device 0, volume 0, name "rootfs"
[ 2589.950000] UBIFS: file system size:   253532160 bytes (247590 KiB, 241 MiB, 1965 LEBs)
[ 2589.955000] UBIFS: journal size:       12644352 bytes (12348 KiB, 12 MiB, 98 LEBs)
[ 2589.960000] UBIFS: media format:       4 (latest is 4)
[ 2589.965000] UBIFS: default compressor: LZO
[ 2589.970000] UBIFS: reserved for root:  5182151 bytes (5060 KiB)
root@TQ6410-Iris:~# mount
tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
udev on /dev type tmpfs (rw,mode=0755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620)
rootfs on / type rootfs (rw)
ubi0:rootfs on /mnt type ubifs (rw)
root@TQ6410-Iris:~# df -h
Filesystem            Size  Used Avail Use% Mounted on
rootfs                1.9G  477M  1.4G  26% /
ubi0:rootfs           227M     0  223M   0% /mnt

On continue donc comme les autres systèmes de fichiers. On désarchive le rootfs dans /mnt et on regarde la place occupé.

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

root@TQ6410-Iris:~# cd /mnt
root@TQ6410-Iris:/mnt# tar jxf /debian-squeeze-grip-OD.tar.bz2 .
root@TQ6410-Iris:/mnt# df -h
Filesystem            Size  Used Avail Use% Mounted on
rootfs                1.9G  477M  1.4G  26% /
ubi0:rootfs           227M   47M  176M  21% /mnt
root@TQ6410-Iris:/mnt# du -h --max-depth=1 /mnt
4.0M    /mnt/bin
4.0K    /mnt/dev
896K    /mnt/etc
8.0M    /mnt/lib
0       /mnt/mnt
0       /mnt/opt
0       /mnt/srv
0       /mnt/tmp
0       /mnt/sys
11M     /mnt/var
48M     /mnt/usr
0       /mnt/boot
0       /mnt/home
0       /mnt/proc
3.5M    /mnt/sbin
24K     /mnt/root
0       /mnt/media
0       /mnt/lost+found
0       /mnt/selinux
75M     /mnt

La compression utilisée ici est LZO. On peut la changer en le spécifiant sur la commande mount. On a bien affaire à un système de fichiers compressés 47Mo utilisé sur 227Mo disponible et 75Mo de fichiers réels. Notez au passage que c’est un peu moins bien que JFFS2. On va pouvoir tester le démarrage sur ce système de fichier. Il faut encore une fois modifié la ligne d’arguments passé au noyau par U-Boot:

1

console=ttySAC0,115200 ubi.mtd=2 root=ubi0:rootfs rootfstype=ubifs init=/sbin/init quiet noswap lpj=884736

A nouveau on regarde ce que ça donne au point de vue temps de boot avec GrabSerial. Fouillons les messages du noyau pour tenter de repérer le temps de montage :

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

[21474536.690000] UBI: attaching mtd2 to ubi0
[21474536.690000] UBI: physical eraseblock size:   131072 bytes (128 KiB)
[21474536.690000] UBI: logical eraseblock size:    129024 bytes
[21474536.690000] UBI: smallest flash I/O unit:    2048
[21474536.690000] UBI: sub-page size:              512
[21474536.690000] UBI: VID header offset:          512 (aligned 512)
[21474536.690000] UBI: data offset:                2048
[21474537.760000] UBI: attached mtd2 to ubi0
[21474537.760000] UBI: MTD device name:            "File System"
[21474537.760000] UBI: MTD device size:            250 MiB
[21474537.760000] UBI: number of good PEBs:        2001
[21474537.760000] UBI: number of bad PEBs:         3
[21474537.760000] UBI: max. allowed volumes:       128
[21474537.760000] UBI: wear-leveling threshold:    4096
[21474537.760000] UBI: number of internal volumes: 1
[21474537.760000] UBI: number of user volumes:     1
[21474537.760000] UBI: available PEBs:             0
[21474537.760000] UBI: total number of reserved PEBs: 2001
[21474537.760000] UBI: number of PEBs reserved for bad PEB handling: 20
[21474537.760000] UBI: max/mean erase counter: 3/2
...
[21474537.915000] UBIFS: mounted UBI device 0, volume 0, name "rootfs"
[21474537.915000] UBIFS: file system size:   253532160 bytes (247590 KiB, 241 Mi
B, 1965 LEBs)
[21474537.915000] UBIFS: journal size:       12644352 bytes (12348 KiB, 12 MiB,
98 LEBs)
[21474537.915000] UBIFS: media format:       4 (latest is 4)
[21474537.915000] UBIFS: default compressor: LZO
[21474537.915000] UBIFS: reserved for root:  5182151 bytes (5060 KiB)
[21474537.920000] VFS: Mounted root (ubifs filesystem).

On remarque qu’il y a deux parties distinctes dans les message du noyau: la partie association du MTD avec le système UBI qui prend 37.76-36.69=1,07s et le montage du système de fichiers UBIFS qui prend 0,005s. Pour comparer aux autres systèmes de fichiers, le temps de démarrage global est de 16,8s. C’est donc un peu plus lent que YAFFS2 et du même niveau que JFFS2. Cependant UBI et UBIFS semble être promis à un bel avenir comme on peut le voir sur ces tests.

Conclusion: c’est un bon compromis entre yaffs2 et jffs2. De plus il semble que ce système se développe dans les noyaux récents. De plus il a de trés bonne performance en lecture/écriture par rapport à YAFFS2. La mise en oeuvre est juste un peu plus délicate….

Conclusion sur les systèmes de fichiers

Pendant la phase de développement, je dirais que le plus simple est de travailler avec une carte SD : c’est pas cher, vous avez des capacités énormes mais “ca fait pas embarqué” comme dirais Denis Bodor dans ces articles. Au niveau du choix du système de fichiers sur la flash NAND il faudra tester à l’utilisation YAFFS2 et UBIFS. YAFFS2 a pour lui l’ancienneté et une trés bonne stabilité, UBI quand à lui est plus récent et évolue encore assez fortement.

Lectures enrichissantes voire obligatoires !!

Non vous n’êtes pas seul, des dizaines de personnes sur Internet ont déjà rédigé des tutoriaux sur la mise en place d’un noyau personnalisé ou la réalisation d’un ‘rootfs’. Pour ma part je livre les liens qui m’ont réellement permis d’avancer sur cette carte :

• Le forum du vendeur de la carte et en particulier les sections S3C6410, S3C2440 et Linux,
• Les forums du site FriendlyARM,
• Le blog de Bill (Bill’s Blog) : très bon ‘HowTo’ et un excellent forum. Bill se définit lui même comme un ‘installeur’ et pas comme un ‘programmeur’,
• Le site de la distribution Emdebian : Debian facilite énormément la création d’un ‘rootfs’ pour l’embarqué !,
• Un bon tutoriel sur la mise en place d’emdebian sur une mini6410 ainsi que le site voisin pour une mini2440,
• Le site BoundaryDevice qui m’a permis de régler une bonne fois pour toute mes problèmes de calibration du touchscreen sous Xorg !
• Et enfin je réserve la place d’honneur pour l’article en FRANÇAIS qui m’a donné envie de travailler avec cette carte : l’article de Denis Bodor dans le magazine OpenSilicium N°1 : Plateforme FriendlyARM Mini2440

Les étapes de la personnalisation de la carte TQ6410

1. Installation d’une chaine de cross-compilation sur une station de développement fonctionnant de préférence sous GNU/Linux Debian Squeeze,
2. Compilation et installation d’un ‘bootloader’ : dans notre cas U-Boot,
3. Compilation et installation d’un noyau linux personnalisé,
4. Génération, installation et configuration d’un système de fichiers racine (rootfs en anglais). Dans notre cas, ce rootfs sera basé sur emdebian squeeze Grip,
5. Développement d’applications sur la plateforme…

1. Installation d’une chaine de cross-compilation

Avant de poursuivre, on considère que votre machine de développement est fonctionnelle et que vous avez un minimum de connaissance d’un système GNU/Linux. La distribution choisie est, comme indiqué ci-dessus, une debian 6.0 (Squeeze). La carte est équipée d’un SoC Samsung S3C6410. C’est donc un cœur ARM11 qui équipe cette puce. La chaine de compilation sera donc une chaine arm-linux-gnueabi. Pour installer cette chaine de cross compilation, il faut tout d’abord importer les clés des archives emdebian :

1

root@casimir:~# aptitude install emdebian-archive-keyring

il faut ensuite rajouter le dépôt suivant et mettre à jour la base des paquets:

1
2

root@casimir:~# echo "deb http://www.emdebian.org/debian/ squeeze main" >> /etc/apt/sources.list
root@casimir:~# aptitude update

on installe alors les paquets suivants:

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

root@casimir:~# aptitude install linux-libc-dev-armel-cross libc6-armel-cross libc6-dev-armel-cross binutils-arm-linux-gnueabi gcc-4.4-arm-linux-gnueabi g++-4.4-arm-linux-gnueabi
Les NOUVEAUX paquets suivants vont être installés :
  binutils{a} binutils-arm-linux-gnueabi cpp-4.4-arm-linux-gnueabi{a}
  g++-4.4-arm-linux-gnueabi gcc-4.4-arm-linux-gnueabi
  gcc-4.4-arm-linux-gnueabi-base{a} gcc-4.4-base-armel-cross{a}
  libc-bin-armel-cross{a} libc-dev-bin-armel-cross{a} libc6-armel-cross
  libc6-dev-armel-cross libgcc1-armel-cross{a} libgomp1-armel-cross{a}
  libstdc++6-4.4-dev-armel-cross{a} libstdc++6-armel-cross{a}
  linux-libc-dev-armel-cross
0 paquets mis à jour, 16 nouvellement installés, 0 à enlever et 2 non mis à jour.
Il est nécessaire de télécharger 23,8 Mo d'archives. Après dépaquetage, 56,5 Mo seront utilisés.
Voulez-vous continuer ? [Y/n/?]  y

Après l’installation des différents paquets vous disposez alors d’une chaine de compilation croisée pour processeur ARM. Une petite vérification pour la route:

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

root@casimir:~# arm-linux-gnueabi-
arm-linux-gnueabi-addr2line  arm-linux-gnueabi-gcov-4.4
arm-linux-gnueabi-ar         arm-linux-gnueabi-gprof
arm-linux-gnueabi-as         arm-linux-gnueabi-ld
arm-linux-gnueabi-c++filt    arm-linux-gnueabi-nm
arm-linux-gnueabi-cpp        arm-linux-gnueabi-objcopy
arm-linux-gnueabi-cpp-4.4    arm-linux-gnueabi-objdump
arm-linux-gnueabi-g++        arm-linux-gnueabi-ranlib
arm-linux-gnueabi-g++-4.4    arm-linux-gnueabi-readelf
arm-linux-gnueabi-gcc        arm-linux-gnueabi-size
arm-linux-gnueabi-gcc-4.4    arm-linux-gnueabi-strings
arm-linux-gnueabi-gcov       arm-linux-gnueabi-strip
root@casimir:~# arm-linux-gnueabi-gcc -v
Using built-in specs.
Target: arm-linux-gnueabi
Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.5-8' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.4 --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/arm-linux-gnueabi/include/c++/4.4.5 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --disable-sjlj-exceptions --enable-checking=release --program-prefix=arm-linux-gnueabi- --includedir=/usr/arm-linux-gnueabi/include --build=i486-linux-gnu --host=i486-linux-gnu --target=arm-linux-gnueabi --with-headers=/usr/arm-linux-gnueabi/include --with-libs=/usr/arm-linux-gnueabi/lib
Thread model: posix
gcc version 4.4.5 (Debian 4.4.5-8)

Cela semble correct ! La première étape est complétée… Nous allons pouvoir compiler pour notre carte TQ6410.

2. Compilation du chargeur U-Boot et installation sur la carte TQ6410

Pour mémoire la carte dispose de deux types de mémoire : Flash NOR et Flash NAND. Ces deux mémoires contiennent à l’achat le chargeur U-Boot. En particulier, si pour une raison ou une autre, le chargeur de la flash NAND est défectueux, vous pouvez le réinstaller en démarrant sur la flash NOR. Donc normalement vous ne pouvez pas bloquer la carte (la ‘bricker’). Dans tous les cas, on peut réinstaller le chargeur U-Boot avec un programmateur type OpenOCD par le port JTAG mais je ne dispose pas d’une sonde JTAG. Le boot de la carte sur la flash NOR ou NAND se fait par l’intermédiaire des mini-interrupteurs présents dans le coin inférieur gauche de la carte. On dispose de trois choix pour le boot:

La version de U-Boot livrée sur le DVD fourni avec la carte est nommé ‘u-boot-tq6410-20100829.tar.gz’ ce qui me parait un peu ancien. Je décide donc de me rendre sur le site de U-Boot et de télécharger une version plus récente. La gestion des sources se fait avec Git et de plus il y a un dépot pour les SoC de Samsung. On va donc rapatrier tout ça et en profiter pour jeter un coup d’oeil au ‘README’:

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

root@casimir:~# aptitude install git
root@casimir:~# mkdir u-boot-TQ6410
root@casimir:~# cd u-boot-TQ6410/
root@casimir:~/u-boot-TQ6410# git clone git://git.denx.de/u-boot-samsung.git
Cloning into u-boot-samsung...
remote: Counting objects: 146388, done.
remote: Compressing objects: 100% (36699/36699), done.
remote: Total 146388 (delta 118824), reused 135758 (delta 108242)
Receiving objects: 100% (146388/146388), 38.18 MiB | 30 KiB/s, done.
Resolving deltas: 100% (118824/118824), done.
root@casimir:~/u-boot-TQ6410# cd u-boot-samsung/
root@casimir:~/u-boot-TQ6410/u-boot-samsung# more README

Dans ce README, vous aurez la liste de tous les paramètres de configuration ainsi que la méthode de compilation (entre autres). En fouillant dans la liste des cartes, je ne trouve qu’une carte SMDK6400, je vais donc compiler pour cette cible…

Je n’ai pas d’installer ni la commande ‘make’, ni les compilateurs gcc et g++, donc on installe le tout:

1

root@casimir:~/u-boot-TQ6410/u-boot-samsung# aptitude install make gcc g++

On configure la génération de code pour une carte smdk6400 et on lance la cross-compilation:

1
2

root@casimir:~/u-boot-TQ6410/u-boot-samsung# make smdk6400_config
root@casimir:~/u-boot-TQ6410/u-boot-samsung# make CROSS_COMPILE=arm-linux-gnueabi-

Au bout de quelques minutes, on obtient un fichier u-boot.bin. Je démarre ensuite la carte sur la flash NAND et je choisis l’option ‘Download u-boot.bin’ (lettre ‘v’) dans le menu de U-Boot. Par l’intermediaire du logiciel DNW sous Windows je télécharge le u-boot.bin fraichement compilé dans la NAND de la carte. Je redémarre la carte et… cela ne fonctionne pas !!

Ce n’est pas très étonnent en soi car on a compilé pour un s3c6400 et pas s3c6410. Pour revenir à une situation normale, il faut démarrer sur la flash NOR, choisir la lettre ‘v’ dans le menu de U-Boot puis transférer le fichier u-boot.bin du DVD fourni avec la carte grace au logiciel DNW. Ouf…Situation redevenu normale !

Je ne peux pas compiler directement un u-boot à partir du site, donc je me rabat sur l’archive fournie sur le DVD du nom de ‘u-boot-tq6410-20100829.tar.gz’ dans le répertoire ‘linux’. Je copie cette archive dans le répertoire u-boot-TQ6410 sur ma machine de travail puis je désarchive l’ensemble et enfin je rentre dans le répertoire ‘u-boot-tq6410:

1
2
3

root@casimir:~/u-boot-TQ6410# cp /multimedia/Electronique/TQ6410/DVD/linux/u-boot-tq6410-20100829.tar.gz .
root@casimir:~/u-boot-TQ6410# tar xzvf u-boot-tq6410-20100829.tar.gz
root@casimir:~/u-boot-TQ6410# cd u-boot-tq6410

Avant de me lancer dans la compilation de u-boot, je parcours les répertoires de cette archive…Ce qui est rassurant c’est de trouver un changelog de chez Samsung, dans le Makefile on trouve des entrées pour smdk2440, smdk6410, tq6410,etc…On nettoie l’ensemble puis on lance la compilation:

1
2
3

root@casimir:~/u-boot-TQ6410# make CROSS_COMPILE=arm-linux-gnueabi- distclean
root@casimir:~/u-boot-TQ6410# make CROSS_COMPILE=arm-linux-gnueabi- tq6410_config
root@casimir:~/u-boot-TQ6410# make CROSS_COMPILE=arm-linux-gnueabi-

Au bout de quelques minutes, vous obtenez un nouveau fichier u-boot.bin qu’il faut transférer sur la carte avec l’utilitaire DNW. Au lancement de la carte, le menu est identique seul la date de compilation à changer (dans mon cas Aug 1 2011). Le menu de U-Boot est personnalisé, j’aimerai modifier ce menu, je cherche donc dans les codes sources. En fait il faut éditer le fichier ‘common/main.c’ et modifier la fonction ‘FriendlyARMMenu’. Je fais juste une modification cosmétique pour vérifier que l’on peut modifier ce menu. Je recompile le tout et j’obtient:

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

##### U-Boot 1.1.6 B01 for 6410, by esky-sh #####
##### Modif. par O. DARTOIS pour BTS IRIS   #####
 
[f] Format the nand flash
[v] Download u-boot.bin
[k] Download Linux/Android kernel
[y] Download root yaffs2 image
[a] Download Absolute User Application
[n] Download Nboot.nb0 for WinCE
[w] Download WinCE NK.nb0
[s] Set the boot parameter of Linux
[b] Boot Linux
[q] Quit to shell
NAND Flash size: 256 MiB
Enter your Selection:

Cela semble correct, si vous devez modifier de manière plus conséquente le menu, vous pourrez donc le faire…

Conclusion: même si l’on a réussi à compiler et à installer un nouveau U-Boot sur la carte, je ne suis qu’à moitié satisfait. J’aurais voulu pouvoir compiler les nouvelles versions de U-Boot pour cette carte. De plus malgré ma demande sur le site de samsung pour obtenir un accès au code opensource de leurs SoCs, je n’ai pas eu de réponse de leur part. Donc je ne sais pas si Samsung maintient toujours un ‘U-Boot personnalisé’ pour leurs cartes SMDK. Je passe donc maintenant à la troisième étape : la compilation d’un noyau linux personnalisé.

3. Compilation d’un noyau linux personnalisé pour la carte TQ6410

Cette carte sera utilisée dans un milieu industriel, nous ne nous servirons donc pas de toutes ces capacités ‘multimédia’ et de supports externes (USB, carte SD,etc…). Par contre il faut impérativement garder les GPIOs, l’ethernet  et les ports séries.

Cette fois-ci je prends le noyau linux livré sur le DVD. Le fichier s’appelle “linux-2.6.28.6-20110319.tar.gz” dans le répertoire linux. Je créé un répertoire ‘Noyau_Linux’ puis je désarchive le noyau:

1
2
3
4
5

root@casimir:~# mkdir Noyau_Linux
root@casimir:~# cd Noyau_Linux
root@casimir:~/Noyau_Linux# cp /multimedia/Electronique/TQ6410/DVD/linux/linux-2.6.28.6-20110319.tar.gz .
root@casimir:~/Noyau_Linux# tar xzvf linux-2.6.28.6-20110319.tar.gz
root@casimir:~/Noyau_Linux# cd linux-2.6.28.6

Dans le répertoire vous trouverez les configurations du vendeur de la carte (config_tq6410_xx avec xx fonction de la taille de l’écran tactile). Nous disposons de l’écran 7 pouces donc la configuration à prendre sera config_tq6410_a70 et nous allons la prendre comme configuration par défaut. Pour configurer votre noyau, nous allons utiliser l’interface texte (menuconfig), il faut donc installer les paquets suivants:

1
2
3
4

root@casimir:~/Noyau_Linux/linux-2.6.28.6# aptitude install ncurses-bin
root@casimir:~/Noyau_Linux/linux-2.6.28.6# make mrproper
root@casimir:~/Noyau_Linux/linux-2.6.28.6# cp config_tq6410_a70 .config
root@casimir:~/Noyau_Linux/linux-2.6.28.6# make arch=arm menuconfig

Choix dans la configuration du noyau:

• Pas de “ramdisk” initial
• Désactivation du chargements des modules : noyau monolitique
• Dans “System type” prendre le SoC Samsung S3C64XX
• Dans “Floating Point Emulation” je prends l’option VFP car le S3C6410 dispose d’une telle unité de calcul
• Désactivation du convertisseur analogique numérique du SoC car erreur de compilation
• Désactivation complète du support SCSI
• Désactivation du “S3C Keybord” : les boutons poussoirs sur la carte
• Désactivation du support SPI et I2C
• Désactivation de la partie “Multimédia” : V4L
• Dans la gestion du framebuffer du S3C6410, je met le nombre de framebuffer à 1
• Pas de support pour les cartes sons, pas de support HID, pas de support de l’USB
• Support du système de fichier ext3, yaffs2, ubifs (pas de support ext4, dos, vfat)
• Pas de support de NFS car le système racine ne sera pas exporté par ce moyen, en conséquence je désactive aussi l’IP Kernel autoconfiguration’
• Diverses optimisations pour réduire la taille du noyau…(allocation mémoire par SLUB)

Cette configuration minimum est disponible au téléchargement en fin d’article sous le nom ‘config_TQ6410_OD_mini’.

U-Boot nécessite un noyau spécialement préparé pour lui, il faut donc installer la commande ‘mkimage’ puis lancez la compilation pour une image ‘uImage’:

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

root@casimir:~/Noyau_Linux/linux-2.6.28.6# aptitude install uboot-mkimage
root@casimir:~/Noyau_Linux/linux-2.6.28.6# make CROSS_COMPILE=arm-linux-gnueabi-
ARCH=arm CFLAGS="-march=armv6" CXXFLAGS="-march=armv6" uImage
...
  Kernel: arch/arm/boot/Image is ready
  Kernel: arch/arm/boot/zImage is ready
  UIMAGE  arch/arm/boot/uImage
Image Name:   Linux-2.6.28.6-IRIS-Turgot-O.Dar
Created:      Wed Aug  3 11:43:54 2011
Image Type:   ARM Linux Kernel Image (uncompressed)
Data Size:    1478116 Bytes = 1443.47 kB = 1.41 MB
Load Address: 0x50008000
Entry Point:  0x50008000
  Image arch/arm/boot/uImage is ready

Le noyau est disponible dans le répertoire arch/arm/boot/ sous le nom uImage. Il faut maintenant transférer ce noyau dans la flash NAND de la carte. Lancez minicom, arrêtez U-Boot puis choisissez l’option ‘Download Linux/Android Kernel’ (lettre ‘k’) puis transférer le noyau avec l’utilitaire DNW:

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

Enter your Selection:k
Downloading Linux/Android Kernel from USB...
Insert a OTG cable into the connector!
OTG cable Connected!
Download address 0xc0000000
Download Done!! Download Address: 0xc0000000, Download Filesize:0x168e24
Checksum is being calculated..
Checksum O.K.
Downloading Linux/Android Kernel successed
Writing Linux/Android Kernel into NAND...
Erasing at 0x560000 -- 100% complete.
 
Writing data at 0x1ff800 -- 100% complete.
Writing Linux/Android Kernel successed

Il faut maintenant démarrer ce nouveau noyau même sans système de fichiers racine pour le tester. Pour cela on va modifier la ligne de paramètres que l’on passe au noyau avec l’option ‘Set the boot parameter of Linux’ (lettre ’s’). Tapez alors la ligne suivante pour obtenir la sortie du noyau vers la voie série, préciser le futur ‘root-fs’ (ici sur une carte SD) et attendre que celui-ci soit prêt lors du montage de la carte (rootwait), l’exécutable à lancer aprés le noyau (ici /sbin/init).

1

console=ttySAC0,115200 root=/dev/mmcblk0p1 init=/sbin/init rootwait

Normalement tout doit bien se passer. La taille, après optimisation, de mon noyau est de 1,1Mo. Cette petite taille permet un chargement rapide depuis la flash, une décompression rapide et un boot du noyau jusqu’au passage à INIT en moins de 4s. Si j’ai le temps je ferais un article sur l’optimisation du boot. Ci-dessous les messages de boot du noyau:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146

Starting kernel ...
 
Uncompressing Linux............................................................................. done, booting the kernel.
Linux version 2.6.28.6-IRIS-Turgot-O.Dartois (root@casimir) (gcc version 4.4.5 (Debian 4.4.5-8) ) #10 PREEMPT Thu Aug 4 10:53:55 CEST 2011
CPU: ARMv6-compatible processor [410fb766] revision 6 (ARMv7), cr=00c5387f
CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
Machine: SMDK6410
Memory policy: ECC disabled, Data cache writeback
CPU S3C6410 (id 0x36410101)
S3C24XX Clocks, (c) 2004 Simtec Electronics
S3C64XX: PLL settings, A=532000000, M=532000000, E=24000000
S3C64XX: HCLKx2=266000000, HCLK=133000000, PCLK=66500000
div1: 00000555
mout_apll: source is fout_apll (1), rate is 532000000
mout_epll: source is fout_epll (1), rate is 24000000
mout_mpll: source is mpll (1), rate is 532000000
mmc_bus: source is dout_mpll (1), rate is 44333333
mmc_bus: source is dout_mpll (1), rate is 44333333
mmc_bus: source is dout_mpll (1), rate is 44333333
usb-host-bus: source is mout_epll (0), rate is 24000000
uclk1: source is dout_mpll (1), rate is 66500000
spi-bus: source is mout_epll (0), rate is 24000000
spi-bus: source is mout_epll (0), rate is 24000000
audio-bus0: source is mout_epll (0), rate is 24000000
audio-bus1: source is mout_epll (0), rate is 24000000
audio-bus2: source is mout_epll (0), rate is 24000000
irda-bus: source is mout_epll (0), rate is 24000000
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 32512
Kernel command line: console=ttySAC0,115200 root=/dev/mmcblk0p1 rootwait int=/sbin/init printk.time=1
[    0.000000] PID hash table entries: 512 (order: 9, 2048 bytes)
[21474536.480000] Console: colour dummy device 80x30
[21474536.480000] s3c24xx_serial_init_ports: initialising ports=4...
[21474536.480000] console [ttySAC0] enabled
[21474536.485000] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
[21474536.495000] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
[21474536.510000] Memory: 128MB = 128MB total
[21474536.510000] Memory: 127216KB available (2132K code, 286K data, 96K init)
[21474536.515000] SLUB: Genslabs=12, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[21474536.520000] Calibrating delay loop... 353.89 BogoMIPS (lpj=884736)
[21474536.635000] Mount-cache hash table entries: 512
[21474536.635000] CPU: Testing write buffer coherency: ok
[21474536.640000] net_namespace: 288 bytes
[21474536.645000] NET: Registered protocol family 16
[21474536.670000] S3C6410: Initialising architecture
[21474536.670000] S3C DMA-pl080 Controller Driver, (c) 2006-2007 Samsung Electronics
[21474536.675000] Total 32 DMA channels will be initialized.
[21474536.720000] NET: Registered protocol family 2
[21474536.765000] IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
[21474536.765000] TCP established hash table entries: 4096 (order: 3, 32768 bytes)
[21474536.770000] TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
[21474536.775000] TCP: Hash tables configured (established 4096 bind 4096)
[21474536.780000] TCP reno registered
[21474536.800000] NET: Registered protocol family 1
[21474536.825000] yaffs Aug  4 2011 10:49:48 Installing.
[21474536.830000] msgmni has been set to 248
[21474536.830000] io scheduler noop registered (default)
[21474536.835000] S3C_LCD clock got enabled :: 133.000 Mhz
[21474536.850000] LCD TYPE :: LTE480WV will be initialized
[21474536.850000] Window[0] - FB1: map_video_memory: clear ff000000:000bb800
[21474536.855000]             FB1: map_video_memory: dma=57100000 cpu=ff000000 size=000bb800
[21474536.860000] Window[0] - FB2: map_video_memory: clear ff05dc00:0005dc00
[21474536.865000]             FB2: map_video_memory: dma=5715dc00 cpu=ff05dc00 size=0005dc00
[21474536.880000] Console: switching to colour frame buffer device 100x30
[21474536.890000] fb0: s3cfb frame buffer device
[21474536.895000] backlight	initialized
[21474536.900000] backlight: 60
[21474536.940000] leds	initialized
[21474536.940000] buttons	initialized
[21474536.940000] pwm	initialized
[21474536.940000] s3c6400-uart.0: s3c2410_serial0 at MMIO 0x7f005000 (irq = 16) is a S3C6400/10
[21474536.945000] s3c6400-uart.1: s3c2410_serial1 at MMIO 0x7f005400 (irq = 20) is a S3C6400/10
[21474536.950000] s3c6400-uart.2: s3c2410_serial2 at MMIO 0x7f005800 (irq = 24) is a S3C6400/10
[21474536.955000] s3c6400-uart.3: s3c2410_serial3 at MMIO 0x7f005c00 (irq = 28) is a S3C6400/10
[21474536.960000] dm9000 Ethernet Driver
[21474536.965000] dm9000: dm9000_probe, init GPIO/EINT.
[21474536.970000] dm9000: dm9000_probe2
[21474536.975000] dm9000: dm9000_probe3
[21474536.980000] eth0: dm9000 at f7b00300,f7b00304 IRQ 108 MAC: 08:90:90:90:90:90
[21474536.985000] S3C NAND Driver, (c) 2008 Samsung Electronics
[21474536.990000] S3C NAND Driver is using hardware ECC.
[21474536.995000] NAND device: Manufacturer ID: 0xec, Chip ID: 0xda (Samsung NAND 256MiB 3,3V 8-bit)
[21474537.000000] Creating 3 MTD partitions on "NAND 256MiB 3,3V 8-bit":
[21474537.005000] 0x00000000-0x00080000 : "Bootloader"
[21474537.015000] 0x00080000-0x00580000 : "Kernel"
[21474537.020000] 0x00580000-0x10000000 : "File System"
[21474537.065000] mice: PS/2 mouse device common for all mice
[21474537.065000] S3C Touchscreen driver, (c) 2008 Samsung Electronics
[21474537.070000] S3C TouchScreen got loaded successfully : 12 bits
[21474537.080000] input: S3C TouchScreen as /class/input/input0
[21474537.125000] S3C24XX RTC, (c) 2004,2006 Simtec Electronics
[21474537.125000] s3c2410_rtc: tick irq 34, alarm irq 92
[21474537.130000] s3c2410-rtc s3c2410-rtc: rtc disabled, re-enabling
[21474537.135000] s3c2410-rtc s3c2410-rtc: rtc core: registered s3c as rtc0
[21474537.140000] S3C2410 Watchdog Timer, (c) 2004 Simtec Electronics
[21474537.145000] s3c2410-wdt s3c2410-wdt: watchdog inactive, reset disabled, irq enabled
[21474537.150000] sdhci: Secure Digital Host Controller Interface driver
[21474537.155000] sdhci: Copyright(c) Pierre Ossman
[21474537.155000] s3c-sdhci s3c-sdhci.0: clock source 0: hsmmc (133000000 Hz)
[21474537.160000] s3c-sdhci s3c-sdhci.0: clock source 1: hsmmc (133000000 Hz)
[21474537.165000] s3c-sdhci s3c-sdhci.0: clock source 2: mmc_bus (44333333 Hz)
[21474537.170000] [SDHCI]to add external irq as a card detect signal......
[21474537.175000] [SDHCI]if (pdata->cfg_ext_cd)......
[21474537.180000] mmc0: SDHCI controller on samsung-hsmmc [s3c-sdhci.0] using ADMA
[21474537.185000] [SDHCI]request_irq......
[21474537.190000] sdhci: card inserted.
[21474537.205000] TCP cubic registered
[21474537.205000] NET: Registered protocol family 17
[21474537.205000] VFP support v0.3: implementor 41 architecture 1 part 20 variant b rev 5
[21474537.225000] s3c2410-rtc s3c2410-rtc: setting system clock to 2011-08-04 09:50:52 UTC (1312451452)
[21474537.225000] Waiting for root device /dev/mmcblk0p1...
[21474537.250000] mmc0: new high speed SD card at address 0007
[21474537.250000] mmcblk0: mmc0:0007 SD02G 1.83 GiB
[21474537.255000]  mmcblk0: p1
[21474537.340000] EXT3-fs warning: maximal mount count reached, running e2fsck is recommended
[21474537.340000] kjournald starting.  Commit interval 5 seconds
[21474537.475000] EXT3 FS on mmcblk0p1, internal journal
[21474537.475000] EXT3-fs: mounted filesystem with ordered data mode.
[21474537.480000] VFS: Mounted root (ext3 filesystem).
[21474537.485000] Freeing init memory: 96K
INIT: version 2.88 booting
Using makefile-style concurrent boot in runlevel S.
Starting the hotplug events dispatcher: udevd.
Synthesizing the initial hotplug events...done.
Waiting for /dev to be fully populated...done.
Activating swap...done.
Cleaning up ifupdown....
Setting up networking....
Activating lvm and md swap...done.
Checking file systems...fsck from util-linux-ng 2.17.2
done.
Mounting local filesystems...done.
Activating swapfile swap...done.
Cleaning up temporary files....
Configuring network interfaces...[21474550.970000] eth0: link down
done.
Cleaning up temporary files....
Setting kernel variables ...done.
INIT: Entering runlevel: 2
Using makefile-style concurrent boot in runlevel 2.
Starting enhanced syslogd: rsyslogd.
Starting periodic command scheduler: cron.
Starting system message bus: dbus.
 
Debian GNU/Linux 6.0 TQ6410-Iris s3c2410_serial0
 
TQ6410-Iris login:

Remarque: vous pouvez voir que le boot noyau prend environ 1s aprés décompression ! Ici le ‘rootfs’ existe c’est pour cette raison que l’on arrive à un ‘login’. Toutes les optimisations de temps de boot ne sont pas exploitées ici…

Puisque l’on parle de système de fichiers racine, voyons comment le réaliser…

4. Création du système de fichiers racine (ou ‘rootfs’) basé sur Debian Squeeze  Grip

On part d’une distribution Debian pour la stabilité et le système de gestion des paquets. Dans un premier temps, on ne va pas faire de l’embarqué pur, on va faire en sorte d’avoir une plateforme de test assez souple. Par la suite on pourra optimiser le ‘rootfs’ en travaillant avec BusyBox. Tout commence sur la machine de développement, on va construire le système de fichiers racine avec l’utilitaire ‘Debootstrap’. En résumé on va :

• formater en ext3 une carte SD de 2Go
• créer sur cette carte un système de fichier racine avec debootstrap
• effectuer quelques modifications pour démarrer sur ce système
• démarrer sur cette carte SD depuis la carte TQ6410 et terminer l’installation
• faire les modifications finales sur le système

Les traces de ces étapes sont présentés ci-dessous (sdd est à remplacer avec le bon périphérique : affichez les messages du  noyau avec dmesg et lisez les dernières lignes après avoir inséré votre carte) :

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

root@casimir:~# fdisk /dev/sdd
...création d'une partition primaire de type linux non bootable de la taille de la carte SD
root@casimir:~# mkfs.ext3 -L rootfs -m 0 /dev/sdd1
root@casimir:~# tune2fs -c 200 -C 0 /dev/sdd1
root@casimir:~# tune2fs -l /dev/sdd1
root@casimir:~# mount /dev/sdd1 /mnt
root@casimir:~# aptitude install debootstrap
root@casimir:~# debootstrap --arch=armel --foreign squeeze /mnt http://www.emdebian.org/grip/
root@casimir:~# echo "deb http://www.emdebian.org/grip/ squeeze main" >> /mnt/etc/apt/sources.list
root@casimir:~# echo "proc /proc proc none 0 0" >> /mnt/etc/fstab
root@casimir:~# echo "TQ6410-Iris" > /mnt/etc/hostname
root@casimir:~# mkdir -p /mnt/usr/share/man/man1/
root@casimir:~# umount /mnt

Maintenant insérez la carte SD sur la TQ6410, démarrez puis arrêtez U-Boot. Changez les paramètres de chargement du noyau (lettre ’s’) pour démarrer sur la carte SD avec un shell minimum pour terminer l’installation:

1

ttySAC0,115200 root=/dev/mmcblk0p1 rootwait init=/bin/sh

On passe à la deuxième phase d’installation du système de fichiers racine, cette fois ci directement sur la carte:

1
2
3
4
5
6
7

# /debootstrap/debootstrap --second-stage
[... ...]
#echo s3c2410_serial0 >> /etc/securetty
#printf "T0:123:respawn:/sbin/getty 115200 s3c2410_serial0\n" >> /etc/inittab
#printf "auto eth0\niface eth0 inet dhcp\n" >> /etc/network/interfaces
#passwd
#reboot

Explications des commandes qui précèdent : suite de l’installation des paquetages (second stage install) soyez patient…puis on rajoute à securetty (terminaux sur lesquels on peut se connecter)  le port série par lequel on va se logger. Ici vous n’avez plus ttySAC0 car udev est passé par là et à donc changer les noms des ports séries (regardez les messages du noyau). On rajoute aussi dans /etc/inittab une ligne qui permet de lancer automatiquement une console sur le port série dans les niveaux d’exécution 1,2 et 3. On configure le réseau en mode automatique (DHCP) en rajoutant les lignes dans le fichier /etc/network/interfaces. On fixe le mot de passe root et enfin on redémarre.

Encore une fois il faudra modifier la ligne de commande que U-Boot passe au noyau en:

1

console=ttySAC0,115200 root=/dev/mmcblk0p1 init=/sbin/init rootwait

Vous allez observer les messages du noyau, puis le lancement de INIT qui va amorcer le système jusqu’à l’obtention d’un login. Identifiez-vous ‘root’ avec le mot de passe que vous avez saisi précédemment. Si pendant le démarrage noyau le démon udevd se plaint que le répertoire .udev/ existe déjà dans le répertoire /dev, il faudra redémarrer avec init=/bin/sh puis supprimer ce répertoire.

Vous avez donc maintenant une plateforme debian qui fonctionne sur un système embarqué. Ce système de base utilise près de 80Mo (ce qui est déjà lourd) mais vous avez toutes les fonctionnalités d’une debian classique. Le système est donc facilement administrable par la suite, l’ajout/suppression de paquets se fera très simplement avec aptitude.

Pour mémoire, cette carte doit être utilisé dans le cadre du développement d’une application graphique pour superviser un process industriel. Dans un premier temps, on facilite donc la tache des programmeurs en ayant une plateforme ressemblant à une station de travail avec de l’espace disque (on travaille avec une carte SD de 2G0). Une fois l’application développée et testée, on optimisera le système (utilisation de busybox, binaire statique, rootfs réduit au minimum sur flash NAND).

Pour terminer cette partie, une trace complète du boot de la carte réalisé avec GrabSerial pour faire des tests de temps de démarrage:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178

Opening serial port /dev/ttyS0
115200:8N1:xonxoff=0:rtcdtc=0
Printing timing information for each line
Matching pattern 'Starting kernel.*' to set base time
Use Control-C to stop...
[    0.000004]
[    0.288957]
[    0.289171] U-Boot 1.1.6 (Aug  5 2011 - 11:50:17) for TQ6410
[    0.293743]
[    0.293901]
[    0.294050] CPU:     S3C6410@532MHz
[    0.296300]          Fclk = 532MHz, Hclk = 133MHz, Pclk = 66MHz, Serial = CLKUART (SYNC Mode)
[    0.303853] Board:   TQ6410
[    0.305418] DRAM:    128 MB
[    0.306917] Flash:   0 kB
[    0.308178] NAND:    256 MB
[    0.403949] In:      serial
[    0.405456] Out:     serial
[    0.406855] Err:     serial
[    0.483983] MAC: 08:90:90:90:90:90
[    0.486081] Hit any key to stop autoboot:  3  2  1  0
[    3.471948]
[    3.472140] NAND read: device 0 offset 0x80000, size 0x140000
[    3.476632]
[    3.476805] Reading data from 0x80000 --   0% complete....
[    4.712153]  1310720 bytes read: OK
[    4.714419] ## Booting image at c0008000 ...
[    4.717525]    Image Name:   Linux-2.6.28.6-IRIS-Turgot-O.Dar
[    4.722157]    Image Type:   ARM Linux Kernel Image (uncompressed)
[    4.727189]    Data Size:    1246092 Bytes =  1.2 MB
[    4.730954]    Load Address: 50008000
[    4.733404]    Entry Point:  50008000
[    5.039941] OK
[    5.040271]
[    5.040459] Starting kernel ...
[    0.001796]
[    0.007486] Uncompressing Linux................................................................................. done, booting the kernel.
[    0.567520] [    0.000000] Linux version 2.6.28.6-IRIS-Turgot-O.Dartois (root@casimir) (gcc version 4.4.5 (Debian 4.4.5-8) ) #23 PREEMPT Sun Aug 7 13:22:45 CEST 2011
[    0.581501] [    0.000000] CPU: ARMv6-compatible processor [410fb766] revision 6 (ARMv7), cr=00c5387f
[    0.589758] [    0.000000] CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
[    0.597419] [    0.000000] Machine: SMDK6410
[    0.600475] [    0.000000] Memory policy: ECC disabled, Data cache writeback
[    0.606403] [    0.000000] CPU S3C6410 (id 0x36410101)
[    0.614901] [    0.000000] S3C24XX Clocks, (c) 2004 Simtec Electronics
[    0.616787] [    0.000000] S3C64XX: PLL settings, A=532000000, M=532000000, E=24000000
[    0.621468] [    0.000000] S3C64XX: HCLKx2=266000000, HCLK=133000000, PCLK=66500000
[    0.627644] [    0.000000] div1: 00000555
[    0.628648] [    0.000000] mout_apll: source is fout_apll (1), rate is 532000000
[    0.635804] [    0.000000] mout_epll: source is fout_epll (1), rate is 24000000
[    0.640155] [    0.000000] mout_mpll: source is mpll (1), rate is 532000000
[    0.647749] [    0.000000] mmc_bus: source is dout_mpll (1), rate is 44333333
[    0.652045] [    0.000000] mmc_bus: source is dout_mpll (1), rate is 44333333
[    0.657073] [    0.000000] mmc_bus: source is dout_mpll (1), rate is 44333333
[    0.664213] [    0.000000] usb-host-bus: source is mout_epll (0), rate is 24000000
[    0.671772] [    0.000000] uclk1: source is dout_mpll (1), rate is 66500000
[    0.676240] [    0.000000] spi-bus: source is mout_epll (0), rate is 24000000
[    0.683605] [    0.000000] spi-bus: source is mout_epll (0), rate is 24000000
[    0.688184] [    0.000000] audio-bus0: source is mout_epll (0), rate is 24000000
[    0.695644] [    0.000000] audio-bus1: source is mout_epll (0), rate is 24000000
[    0.700284] [    0.000000] audio-bus2: source is mout_epll (0), rate is 24000000
[    0.707533] [    0.000000] irda-bus: source is mout_epll (0), rate is 24000000
[    0.712576] [    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 32512
[    0.720433] [    0.000000] Kernel command line: console=ttySAC0,115200 root=/dev/mmcblk0p1 rootwait init=/sbin/init
[    0.731529] [    0.000000] PID hash table entries: 512 (order: 9, 2048 bytes)
[    0.745040] [21474536.480000] Console: colour dummy device 80x30
[    0.746652] [21474536.480000] s3c24xx_serial_init_ports: initialising ports=4...
[    0.752795] [21474536.480000] console [ttySAC0] enabled
[    0.754150] [21474536.485000] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
[    0.760837] [21474536.490000] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
[    0.771485] [21474536.505000] Memory: 128MB = 128MB total
[    0.775965] [21474536.505000] Memory: 127088KB available (2276K code, 286K data, 96K init)
[    0.780887] [21474536.510000] SLUB: Genslabs=12, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[    0.791570] [21474536.515000] Calibrating delay loop... 353.89 BogoMIPS (lpj=884736)
[    0.896457] [21474536.625000] Mount-cache hash table entries: 512
[    0.900846] [21474536.625000] CPU: Testing write buffer coherency: ok
[    0.908049] [21474536.630000] net_namespace: 288 bytes
[    0.911823] [21474536.635000] NET: Registered protocol family 16
[    0.916045] [21474536.645000] S3C6410: Initialising architecture
[    0.920419] [21474536.645000] S3C DMA-pl080 Controller Driver, (c) 2006-2007 Samsung Electronics
[    0.928430] [21474536.650000] Total 32 DMA channels will be initialized.
[    0.947479] [21474536.675000] NET: Registered protocol family 2
[    0.991496] [21474536.720000] IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
[    0.996502] [21474536.720000] TCP established hash table entries: 4096 (order: 3, 32768 bytes)
[    1.004716] [21474536.725000] TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
[    1.013681] [21474536.730000] TCP: Hash tables configured (established 4096 bind 4096)
[    1.021195] [21474536.735000] TCP reno registered
[    1.031494] [21474536.755000] NET: Registered protocol family 1
[    1.043492] [21474536.765000] JFFS2 version 2.2. (NAND) (SUMMARY)  © 2001-2006 Red Hat, Inc.
[    1.049080] [21474536.770000] yaffs Aug  7 2011 00:09:52 Installing.
[    1.057092] [21474536.775000] msgmni has been set to 248
[    1.058617] [21474536.775000] io scheduler noop registered (default)
[    1.063791] [21474536.780000] S3C_LCD clock got enabled :: 133.000 Mhz
[    1.068993] [21474536.795000] LCD TYPE :: LTE480WV will be initialized
[    1.075952] [21474536.795000] Window[0] - FB1: map_video_memory: clear ff000000:000bb800
[    1.080818] [21474536.800000]             FB1: map_video_memory: dma=57100000 cpu=ff000000 size=000bb800
[    1.091572] [21474536.805000] Window[0] - FB2: map_video_memory: clear ff05dc00:0005dc00
[    1.099483] [21474536.810000]             FB2: map_video_memory: dma=5715dc00 cpu=ff05dc00 size=0005dc00
[    1.123509] [21474536.825000] Console: switching to colour frame buffer device 100x30
[    1.131343] [21474536.835000] fb0: s3cfb frame buffer device
[    1.137452] [21474536.840000] backlight	initialized
[    1.143489] [21474536.845000] backlight: 60
[    1.144485] [21474536.860000] leds	initialized
[    1.148332] [21474536.860000] pwm	initialized
[    1.151957] [21474536.860000] s3c6400-uart.0: s3c2410_serial0 at MMIO 0x7f005000 (irq = 16) is a S3C6400/10
[    1.160224] [21474536.870000] s3c6400-uart.1: s3c2410_serial1 at MMIO 0x7f005400 (irq = 20) is a S3C6400/10
[    1.168514] [21474536.875000] s3c6400-uart.2: s3c2410_serial2 at MMIO 0x7f005800 (irq = 24) is a S3C6400/10
[    1.176715] [21474536.880000] s3c6400-uart.3: s3c2410_serial3 at MMIO 0x7f005c00 (irq = 28) is a S3C6400/10
[    1.186421] [21474536.885000] dm9000 Ethernet Driver
[    1.190548] [21474536.885000] dm9000: dm9000_probe, init GPIO/EINT.
[    1.197018] [21474536.890000] dm9000: dm9000_probe2
[    1.201072] [21474536.895000] dm9000: dm9000_probe3
[    1.202422] [21474536.900000] eth0: dm9000 at f7b00300,f7b00304 IRQ 108 MAC: 08:90:90:90:90:90
[    1.208523] [21474536.905000] S3C NAND Driver, (c) 2008 Samsung Electronics
[    1.215927] [21474536.915000] S3C NAND Driver is using hardware ECC.
[    1.220201] [21474536.915000] NAND device: Manufacturer ID: 0xec, Chip ID: 0xda (Samsung NAND 256MiB 3,3V 8-bit)
[    1.230312] [21474536.920000] Creating 3 MTD partitions on "NAND 256MiB 3,3V 8-bit":
[    1.236422] [21474536.925000] 0x00000000-0x00080000 : "Bootloader"
[    1.241708] [21474536.930000] 0x00080000-0x00580000 : "Kernel"
[    1.247327] [21474536.935000] 0x00580000-0x10000000 : "File System"
[    1.287488] [21474536.980000] S3C Touchscreen driver, (c) 2008 Samsung Electronics
[    1.293536] [21474536.980000] S3C TouchScreen got loaded successfully : 12 bits
[    1.299182] [21474536.985000] input: S3C TouchScreen as /devices/virtual/input/input0
[    1.311489] [21474537.005000] S3C24XX RTC, (c) 2004,2006 Simtec Electronics
[    1.318452] [21474537.005000] s3c2410_rtc: tick irq 34, alarm irq 92
[    1.324809] [21474537.010000] s3c2410-rtc s3c2410-rtc: rtc disabled, re-enabling
[    1.332221] [21474537.015000] s3c2410-rtc s3c2410-rtc: rtc core: registered s3c as rtc0
[    1.340306] [21474537.020000] S3C2410 Watchdog Timer, (c) 2004 Simtec Electronics
[    1.347792] [21474537.030000] s3c2410-wdt s3c2410-wdt: watchdog inactive, reset disabled, irq enabled
[    1.357097] [21474537.035000] sdhci: Secure Digital Host Controller Interface driver
[    1.364903] [21474537.040000] sdhci: Copyright(c) Pierre Ossman
[    1.370816] [21474537.045000] s3c-sdhci s3c-sdhci.0: clock source 0: hsmmc (133000000 Hz)
[    1.379047] [21474537.050000] s3c-sdhci s3c-sdhci.0: clock source 1: hsmmc (133000000 Hz)
[    1.387309] [21474537.055000] s3c-sdhci s3c-sdhci.0: clock source 2: mmc_bus (44333333 Hz)
[    1.395645] [21474537.060000] [SDHCI]to add external irq as a card detect signal......
[    1.403593] [21474537.065000] [SDHCI]if (pdata->cfg_ext_cd)......
[    1.409657] [21474537.070000] mmc0: SDHCI controller on samsung-hsmmc [s3c-sdhci.0] using ADMA
[    1.418297] [21474537.075000] [SDHCI]request_irq......
[    1.423347] [21474537.080000] sdhci: card inserted.
[    1.428779] [21474537.085000] TCP cubic registered
[    1.434598] [21474537.090000] NET: Registered protocol family 17
[    1.436263] [21474537.095000] VFP support v0.3: implementor 41 architecture 1 part 20 variant b rev 5
[    1.441529] [21474537.105000] s3c2410-rtc s3c2410-rtc: setting system clock to 2011-08-07 20:03:34 UTC (1312747414)
[    1.446252] [21474537.115000] Waiting for root device /dev/mmcblk0p1...
[    1.839493] [21474537.520000] mmc0: new high speed SD card at address 0002
[    1.844010] [21474537.520000] mmcblk0: mmc0:0002 00000 1.86 GiB
[    1.847723] [21474537.525000]  mmcblk0: p1
[    1.859526] [21474537.545000] kjournald starting.  Commit interval 5 seconds
[    1.867483] [21474537.550000] EXT3 FS on mmcblk0p1, internal journal
[    1.872305] [21474537.550000] EXT3-fs: mounted filesystem with ordered data mode.
[    1.879762] [21474537.555000] VFS: Mounted root (ext3 filesystem).
[    1.885848] [21474537.560000] Freeing init memory: 96K
[    2.135521] INIT: version 2.88 booting
[    2.335501] Using makefile-style concurrent boot in runlevel S.
[    2.951538] Starting the hotplug events dispatcher: udevd.
[    3.439497] Synthesizing the initial hotplug events...done.
[    3.843493] Waiting for /dev to be fully populated...done.
[    5.083503] Activating swap...done.
[    7.415484] Cleaning up ifupdown....
[    7.523493] Setting up networking....
[    8.247491] Activating lvm and md swap...done.
[    8.287498] Checking file systems...fsck from util-linux-ng 2.17.2
[    8.403493] done.
[    8.455494] Mounting local filesystems...done.
[    8.487493] Activating swapfile swap...done.
[    8.563490] Cleaning up temporary files....
[    8.935547] Configuring network interfaces...[21474544.705000] eth0: link down
[    9.119495] done.
[    9.211492] Cleaning up temporary files....
[    9.531489] Setting kernel variables ...done.
[    9.807515] INIT: Entering runlevel: 2
[    9.875529] Using makefile-style concurrent boot in runlevel 2.
[   10.495507] Starting enhanced syslogd: rsyslogd[21474546.705000] eth0: link up, 100Mbps, full-duplex, lpa 0xC5E1
[   11.647491] .
[   11.715496] Starting periodic command scheduler: cron.
[   13.063506]
[   13.067494] Debian GNU/Linux 6.0 TQ6410-Iris s3c2410_serial0
[   13.072671]
[   13.079498] TQ6410-Iris login:

On remarquera que le compteur de temps est remis à 0 lorsque la chaine “Starting Kernel” apparait. Le boot de noyau (décompression comprise) jusqu’au passage à INIT prend 2,1s. Le login apparait lui après 13s. Dans ce cas la configuration IP était fixé donc pas de requête DHCP.

5. Développement d’applications graphiques sur plateforme TQ6410

Comme je ne sais pas encore avec “quoi” on va programmer pour faire une application graphique, je reste une fois de plus générique : on va compléter l’installation précédente par l’installation de X.org et de l’écran tactile. Peut-être X ne sera pas utilisé et on travaillera directement avec le framebuffer sous Qt Embedded…

Il existe sous GNU/Linux deux manières de gérer les écrans tactiles evtouch et tslib. Comme je n’ai jamais pu faire fonctionner correctement evtouch, nous allons installer tslib. Il faut juste installer un paquetage, exporter une variable qui indique le périphérique qui pointe vers l’écran tactile (ici /dev/input/event0 car les boutons poussoirs de la carte sont désactivés) et enfin on lance l’utilitaire de calibration puis de tests:

1
2
3
4

root@TQ6410-Iris:~# aptitude install libts-bin
root@TQ6410-Iris:~# export TSLIB_TSDEVICE=/dev/input/event0
root@TQ6410-Iris:~# ts_calibrate
root@TQ6410-Iris:~# ts_test

On se lance alors dans l’installation de X.org par la commande suivante (attention pas du tout optimisé on installe en ‘gros’) puis on installe le gestionnaire de l’écran tactile pour X, on lance le client X à l’ancienne mode (fond d’écran ‘hachuré’) et un petit xeyes pour la route :

1
2
3
4

root@TQ6410-Iris:~# aptitude install xorg
root@TQ6410-Iris:~# aptitude install xserver-xorg-input-tslib
root@TQ6410-Iris:~# X -retro &;
root@TQ6410-Iris:~# xeyes -display :0.0

Si vous voulez directement lancer l’interface graphique, il faut installer le paquetage nodm :

1

root@TQ6410-Iris:~# aptitude install nodm

Puis faire les modifications suivantes dans son fichier de configuration /etc/default/nodm:

1
2
3

NODM_ENABLE = true
NODM_FIRST_VT=2 car j'ai désactivé les autes terminaux virtuels dans /etc/inittab
NODM_X_OPTIONS = 'vt2 -nolisten tcp'

Redémarrez et vous allez obtenir au bout de quelques secondes un écran ‘graphique’ avec un terminal qui prend tout l’écran. Donc ca fonctionne correctement mais c’est pas top…il faudrait installer un gestionnaire de fenêtre voire de bureau…

Alors je ne vous encourage pas à installer gnome ou kde mais plutôt matchbox…et exporter la variable DISPLAY=:0.0 !

Déballage

En déballant le paquet de la TQ6410 vous trouvez:

• La carte électronique TQ6410
• Un écran LCD TFT de 7 pouces de marque Innolux AT070TN92 avec dalle tactile résistive et cadre de fixation
• un câble série droit équipé avec des connecteurs DB9
• un câble ethernet droit
• un câble USB
• un DVD-R gravé avec les ressources logiciels (cross-compilateur, source du noyau linux, “rootfs” linux, android,WinCE, exemples de codes,etc…)
• une alimentation à découpage 12V-1A (livrée avec une fiche américaine !). Cette alimentation est insuffisante pour assurer un fonctionnement correct de la carte et de l’écran 7 pouces. Il faudra donc faire l’acquisition d’un autre bloc d’alimentation.

Si vous voulez des “visuels” de cette carte, faites une recherche avec un moteur de recherche !

Découverte de la carte

Pour faire quelques tests sur la carte, je câble l’ensemble:

• Connexion de l’écran sur la carte (attention les connecteurs sont TRÈS fragiles)
• Connexion de l’alimentation après changement de la fiche d’origine pour une fiche française
• Connexion du câble série sur la carte et sur un PC fonctionnant sous GNU/Linux
• Connexion du câble USB sur la carte en vu d’une connexion ultérieure sur un PC fonctionnant sous Microsoft Windows7

Avant d’alimenter le tout en basculant l’interrupteur M/A sur le coté de la carte, je lis quelques documentations du DVD. Vous y apprendrez que :

• le chargeur de démarrage est U-Boot aussi bien dans la FLASH NAND que NOR (normalement il est donc impossible de bloquer la carte en écrasant le chargeur de démarrage : on démarre toujours depuis la NAND, si problème on démarre depuis la NOR et on réinstalle U-Boot sur la NAND).
• le noyau linux est un 2.6.28 patché pour supporter le S3C6410 de Samsung
• le système pré-installé dans la NAND est un GNU/Linux avec un environnement QTExtended (Qtopia)

Pour avoir quelques informations supplémentaires, nous allons observer la voie série. L’environnement de développement sera une machine sous GNU/Linux Debian 6 (Squeeze). Pour interagir avec la voie série, nous allons utiliser Minicom. Il faut donc l’installer :

root@casimir:~#aptitude install minicom

puis le configurer :

root@casimir:~#minicom -s

La rubrique qui nous intéresse est “Configuration du port série”. Dans cette rubrique il faut régler le port série sur “/dev/ttyS0″ si vous utilisez le premier port série (COM1: sous Microsoft Windows) (remarque: si vous utilisez un adaptateur USB-Série son nom sera vraisemblablement ttyUSB0), le “Débit/Parité/Bits” sur 115200 8N1, le “Contrôle de flux matériel et logiciel” sur “Non”. Sauvegardez vos réglages en revenant au menu principal et en choisissant l’option “Enregistrer config. sous dfl”. Sortez de minicom puis relancez-le en ignorant l’initialisation du modem avec:

root@casimir:~#minicom -o

Minicom attend alors du trafic sur la voie série…

Amorçage par défaut : Noyau Linux et environnement QTopia

Allumez alors la carte, vous devriez voir des messages du chargeur U-Boot. Appuyez sur la touche ‘entrée’ pour interrompre le chargement ! Vous devriez avoir les messages suivants:

OK

U-Boot 1.1.6 (Aug 29 2010 - 16:56:31) for TQ6410

CPU:     S3C6410@532MHz
         Fclk = 532MHz, Hclk = 133MHz, Pclk = 66MHz, Serial = CLKUART (SYNC Mode)
Board:   TQ6410
DRAM:    128 MB
Flash:   0 kB
NAND:    256 MB
In:      serial
Out:     serial
Err:     serial
MAC: 08:90:90:90:90:90
Hit any key to stop autoboot:  3     <= Appui sur la touche entrée
##### U-Boot 1.1.6 B01 for 6410, by esky-sh #####
[f] Format the nand flash
[v] Download u-boot.bin
[k] Download Linux/Android kernel
[y] Download root yaffs2 image
[a] Download Absolute User Application
[n] Download Nboot.nb0 for WinCE
[w] Download WinCE NK.nb0
[s] Set the boot parameter of Linux
[b] Boot Linux
[q] Quit to shell
NAND Flash size: 256 MiB
Enter your Selection:

La carte dispose donc de U-Boot en version 1.1.6. On retrouve bien les quantités de mémoire prévues (pas de NOR car on démarre pour l’instant depuis la NAND). On arrête le chargement et on se retrouve avec le menu de U-Boot préparé par le revendeur esky-sh. Nous utiliserons centaines de ces options pour changer le noyau à charger ou encore le système de fichier racine. Pour continuer le chargement, appuyez sur la lettre ‘b’. Le noyau linux préparé par FriendlyARM démarre puis le système de fichier racine est chargé…On peut alors tester l’environnement QTopia préparé par FriendlyARM après avoir calibré l’écran tactile…Je ne détaille pas plus pour l’instant, ci-dessous deux photographies de l’écran sous QTopia :

Remarque: si l’interface est en chinois, il faut aller sur le deuxième onglet et cliquez sur le drapeau pour passer la langue en anglais (voir la capture d’écran de droite ci-dessus).

Amorçage sur un système Android

La carte est vendu comme étant compatible avec un système Android 2.1. Il faut donc charger le noyau et le “rootfs” android précompilé fourni sur le DVD. Il faut démarrer sur la NAND flash, interrompre U-Boot puis dans le menu proposé, choisir l’option “Download Linux/Android kernel” (lettre ‘k’) pour le noyau ou “Download root yaffs2 image” (lettre ‘y’) pour le système de fichier racine. U-Boot attend alors la connexion du cable USB. Le transfert du noyau ou du système de fichier racine s’effectue avec l’utilitaire DNW.exe disponible dans le répertoire ‘Tools’ du DVD. Ce logiciel fonctionne sous Windows et nécessite l’installation d’un pilote lors de la première insertion du câble (disponible lui aussi sur le DVD dans ‘Tools’). Si la carte est reconnu par le logiciel DNW, vous verrez dans la barre de titre [USB:OK]. Vous pouvez alors transférer votre noyau ou votre système de fichiers racine avec le menu ‘USB Port’ puis ‘Transmit/Restore’. Sous Linux, il existe un logiciel du nom de USBPUSH qui a les mêmes fonctionnalités mais je ne l’ai pas utilisé.

Dans notre cas le noyau Linux s’appelle zImage_a70_New et le système de fichier racine rootfs_android.img. La trace de ces opérations est présenté ci-dessous :

##### U-Boot 1.1.6 B01 for 6410, by esky-sh #####
[f] Format the nand flash[v] Download u-boot.bin
[k] Download Linux/Android kernel
[y] Download root yaffs2 image
[a] Download Absolute User Application
[n] Download Nboot.nb0 for WinCE
[w] Download WinCE NK.nb0
[s] Set the boot parameter of Linux
[b] Boot Linux
[q] Quit to shellNAND
Flash size: 256 MiB
Enter your Selection:k
Downloading Linux/Android Kernel from USB...
OTG cable Connected!
Download address 0xc0000000
Download Done!!
Download Address: 0xc0000000, Download Filesize:0x2b6c0c
Checksum is being calculated...
Checksum O.K.
Downloading Linux/Android Kernel successed
Writing Linux/Android Kernel into NAND...
Erasing at 0x80000 --   2% complete.Erasing at 0xa0000 ... -- 100% complete.

Writing data at 0x80000 --   0% complete.
Writing data at 0x87000
...
Writing data at 0x33f800 -- 100% complete.
Writing Linux/Android Kernel successed

##### U-Boot 1.1.6 B01 for 6410, by esky-sh #####
[f] Format the nand flash
[v] Download u-boot.bin
[k] Download Linux/Android kernel
[y] Download root yaffs2 image
[a] Download Absolute User Application
[n] Download Nboot.nb0 for WinCE
[w] Download WinCE NK.nb0
[s] Set the boot parameter of Linux
[b] Boot Linux[q] Quit to shell
NAND Flash size: 256 MiB
Enter your Selection:y
Downloading yaffs2-image from USB...
Insert a OTG cable into the connector!
OTG cable Connected!
Download address 0xc0000000
Download Done!!
Download Address: 0xc0000000, Download Filesize:0x5ae7b40
Checksum is being calculated.......
Checksum O.K.
Downloading yaffs2-image successed
Writing yaffs2-image into NAND...
Erasing at 0x580000 --   0% complete.Erasing at 0x800000
...
99% complete.Erasing at 0xffe0000 -- 100% complete.

Writing data at 0x580000 --   0% complete.Writing data at 0x661800
...
Writing data at 0x5da6000 -- 100% complete.
Writing yaffs2-image successed

Remarques:

• On voit que le chargement des noyaux ou des images ‘rootfs’ ce fait en mémoire vive à l’adresse 0xC0000000 donc la taille du noyau ou du rootfs ne pourra excéder 128Mo même si l’on dispose de plus en mémoire NAND. Il faudra donc passer par une étape intermédiaire pour flasher un rootfs plus gros que 128Mo dans la NAND (indice: passer par une mémoire SD).
• On note aussi l’adresse dans la NAND à laquelle est stocké le noyau: adresse de début: 0×80000 et adresse de fin:0xA0000 soit un espace de XX octets. Pour le rootfs on a: adresse de début: 0×580000 et adresse de fin: 0xFFE0000 soit un espace de XX octets.
• On retrouvera ces valeurs lors du boot du noyau linux lors de la découverte des “partitions” de la NAND

On lance alors le système avec l’option “Boot linux” (lettre ‘b’). Si ça ne démarre pas, fixez les paramètres à passer au noyau avec “Set the boot parameter of Linux” (lettre ’s’) comme suit:

root=/dev/mtdblock2 rootfstype=yaffs2 init=/linuxrc console=ttySAC0,115200

On obtient les messages suivants:

NAND read: device 0 offset 0x80000, size 0x500000
Reading data from 0x80000 --   0% complete
...
Reading data from 0x57f800 -- 100% complete. 5242880 bytes read:
OK
Boot with zImage
Starting kernel ...
Uncompressing Linux......................................................................
Done. Booting the kernel.Linux version 2.6.28.6 (root@NX-W-3) (gcc version 4.4.1 (Sourcery G++ Lite 2009q3-67) )
#3 Sat Mar 19 18:36:33 CST 2011CPU: ARMv6-compatible processor [410fb766] revision 6 (ARMv7), cr=00c5387f
CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
Machine: SMDK6410
Memory policy: ECC disabled, Data cache writeback
CPU S3C6410 (id 0x36410101)
...
yaffs_read_super: isCheckpointed
0xres = 800, yres = 480Took 62 samples...
Top left : X = 3268 Y = 1504Took 50 samples...
Top right : X =  762 Y = 1522Took 42 samples...
Bot right : X =  760 Y = 2731Took 49 samples...
Bot left : X = 3282 Y = 2746Took 43 samples...
Center : X = 2031 Y = 2124959.654785
-0.278430 0.001384-419.278076 0.000
pointercal_ioctl: -18247 90 62891936 11 20317 -27477808 65536180 0.310019
init: cannot open '/initlogo.rle'
eth0: link down
sh: can't access tty; job control turned off
# warning: `rild' uses 32-bit capabilities (legacy support in use)
eth0: link up, 100Mbps, full-duplex, lpa 0xC5E1
# uname -a
Linux localhost 2.6.28.6 #3 Sat Mar 19 18:36:33 CST 2011 armv6l GNU/Linux
# free
              total         used         free       shared      buffers
Mem:       106952        38028        68924            0            0
Swap:            0            0            0
Total:       106952        38028        68924
# free
              total         used         free       shared      buffers
Mem:       106952       104704         2248            0            0
Swap:            0            0            0
Total:       106952       104704         2248
# reboot

Remarques:

• Le noyau utilisé ici est un 2.6.28 compilé pour un SoC SMDK6410
• L’écran tactile n’étant pas calibré vous passez par cette étape (lignes Top Left, Top Right, etc…)
• La mémoire vive utilisé avant lancement de l’interface graphique d’android est de 38Mo, lorsque l’environnement est complètement chargé on est à 104Mo sur 106Mo utilisé ! D’où trés certainement les problèmes de lenteur…

Après 1 minute vous avez l’écran d’accueil d’Android puis on vérifie la version du noyau :

Android fonctionne donc sur cette plateforme cependant la dalle tactile n’est pas très réactive et globalement le fonctionnement est très lent. Selon moi, il n’est donc pas utilisable dans l’état, le peu de mémoire vive est très certainement la cause de cette lenteur (voir remarques ci-dessus). Cela peut donc servir ponctuellement de plateforme de développement android mais sans plus. Cependant un accès shell ‘root’ est disponible par le biais de la voie série.

Les tests préliminaires s’arrêtent ici…Je ne teste pas Windows CE sur cette plateforme car nous n’avons pas de projet dans l’immédiat avec celui-ci. Je passe donc maintenant à la partie la plus intéressante pour nous : la personnalisation de cette plateforme pour nos besoins spécifiques.

Cette carte est réalisable avec des moyens classiques. Les deux circuits CMS et les deux petits condensateurs CMS sont soudables “à la main” sans trop de problèmes. Le circuit imprimé est en simple face avec des straps du coté composants. Tous les composants sont disponibles chez Farnell sauf le connecteur ethernet chez RS (RadioSpares).

Cette carte permet les connections suivantes:

• Sur connecteur HE10-10 ou barrette mâle: Port A sur 8 bits, Port B sur 8 bits, Port C sur 4 bits, Alimentation 3,3V et Masse
• Ports série: le port série complet (tous les signaux sont gérés matierellement, COM1) est disponible sur une barrette mâle au niveau 3,3V ou sur un connecteur DB9 au niveau RS232. Le deuxième port série (COM2) ne dispose que des signaux TX/RX matériellement, il est possible de piloter les signaux RTS/CTS et DSR/DTR logiciellement, encore une fois en 3,3V ou RS232 sur le deuxième connecteur DB9.
• USB Host et USB Device
• Port ethernet 10/100 Mb/s
• Support de pile pour la RTC embarqué (pile CR2032)
• Connecteur pour carte SD/MMC
• Alimentation 3,3V protégé jusqu’à 500mA et alimentation 5V jusqu’à 100mA

Cette carte est exploitée dans le cadre de projet de fin d’étude de BTS IRIS avec comme thème “Linux Embarqué”.

Si vous souhaitez obtenir le circuit imprimé de cette carte ou une version complète assemblée (sans le module DNP9200), merci de me contacter par mél. Les documents de fabrication sont disponibles ci-dessous au format Proteus Isis et Ares 7.8, ainsi qu’au format PDF.

Le cahier des charges était le suivant:

• l’ensemble doit rester à un prix abordable
• le réglage de la température se fait à l’aide de deux boutons plutôt qu’un potentiomètre
• la température de consigne et la température mesurée doivent être visualisées
• la régulation de température doit se faire à +/- 0.2°C prés
• la partie commande de puissance doit être isolée de la partie basse tension
• le tout doit tenir dans un boitier plastique pour éviter le contact avec le secteur

Les solutions retenues sont donc les suivantes:

• utilisation de composants standards facilement disponibles: un PIC16F886, un afficheur LCD 16×2 standard, un capteur de température bon marché mais suffisamment précis sur bus I2C, un triac pour la commande de puissance
• deux boutons poussoirs, un rouge et un bleu, serviront à régler la température de consigne ainsi que l’hystérésis
• la visualisation de la température mesurée, de la température de consigne et de l’hystérésis se font à l’aide d’un afficheur LCD alphanumérique 2 lignes de 16 caractères (afficheur 16×2). Le contraste est réglable par un potentiomètre
• la sonde de température sera un DS1621 sur bus I2C. On utilisera un mode de mesure particulier pour obtenir une meilleure précision (de l’ordre de +/- 0.1°C)
• l’isolation entre la partie basse tension et haute tension se fera à l’aide d’un optotriac MOC3021
• une DEL visualisera la mise en et hors tension de la résistance chauffante
• le tout tient dans un boitier plastique transparent de chez Hammond
• enfin la régulation se fera par hystérésis et non sous forme d’un PID
• l’alimentation se fera à l’aide de n’importe quel bloc secteur du commerce pouvant fournir une tension alternative ou continu de 9V sous 200mA
• les connections se font à l’aide de bornier à vis

J’obtiens donc le schéma électrique suivant:

Première remarque: le capteur de température analogique LM35 du schéma n’est pas câblé sur le prototype final. C’était juste “au cas où” je n’aurais pas été satisfait du capteur I2C. En adaptant le code C, on peut supprimer le capteur I2C et le remplacer par ce capteur. La précision par contre sera bien moindre.

Deuxième remarque: la résistance R9 du schéma est un résistance de rappel au plus. Elle n’est pas câblée dans le prototype final car la sortie RA4 du PIC16F886 n’est pas une sortie à collecteur ouvert. Par contre si vous changez de PIC, par exemple pour un 16F876, cette résistance est indispensable pour piloter correctement l’afficheur LCD.

Troisième remarque: le réseau R7-C7 permet au triac d’encaisser un “dV/dT” important, c’est-à-dire une montée rapide de la tension. Il est surtout utile si le triac commande une charge inductive. Suivant le modèle de triac employé (”snubberless” ou non: voir dans la documentation constructeur du triac) ce réseau est nécessaire ou non. Ici on pourrait le supprimer car on doit commander un élément purement résistif mais comme on ne sait jamais ce circuit protègera le triac.

Quatrième remarque: les fusibles FU1 et FU2 sont en fait des fusibles “polyswitch”. Le fusible polyswitch s’ouvre lorsque sa température interne dépasse 110°C. Cette augmentation de température peut être du à un courant fort le traversant. Lorsque le polyswitch refroidi, il retrouve sa conductivité. Il remplace donc un fusible classique. Par contre le temps de réaction de ces fusibles peut être assez long (de l’ordre de la seconde) donc s’il faut protéger un système de manière très rapide, le fusible rapide reste la meilleure solution.

Un exemple de routage et une réalisation du typon sont présentés ci-dessous:

Remarque: Sur le typon ci-dessus, il manque trois composants: les fusibles FU1, FU2 et la diode zener de protection D2. Sur le routage Ares présenté à la fin de cet article, ces composants sont bien implantés.

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

	Dans la photographie ci-contre, vous voyez les boutons de réglage de l’hysteresis et de la consigne : bouton bleu (-) et bouton rouge (+). L’écran LCD est visible à travers le capot du boitier. Sur le coté droit, vous avez l’arrivée du 220V et la sortie vers la charge résistive. Sur le coté gauche, vous avez le fil d’alimentation de l’électronique basse tension issu d’un “bloc secteur” de récupération et le fil qui part vers le capteur I2C de température (cordon de souris usagé). Le porte fusible à l’intérieur n’est pas câblé, c’était juste un essai d’encombrement
	Sur le coté droit du boitier, on voit les câbles “secteur” : l’arrivée 220V à gauche et le départ vers la charge résistive à droite. Les fils sont introduits dans des borniers à vis et le boitier est percé en conséquence.
	Sur le coté gauche du boitier vous trouvez le bornier pour l’alimentation continue issue d’un bloc secteur quelconque fournissant une tension de 7V à 20V continu ou alternatif sous 200mA. Le fil blanc du capteur de température a été récupéré sur une vieille souris.
	Les composants sont visibles sur le dessous du boitier. Vous reconnaitrez le PIC16F886, le régulateur linéaire 5V au dessus de lui, le triac sur la droite. Le CI blanc est l’optotriac. Enfin si vous êtes observateur (la photographie est relativement floue), vous verrez que le boitier est percé pour utiliser un tournevis plat pour serrer les câbles dans les différents borniers ainsi que pour le réglage du contraste de l’afficheur LCD.

Un petit test avant de mettre le tout dans son boitier plastique :

Je met en pièce jointe le schéma électrique ainsi que le routage au format Proteus 7.4 (Isis et Ares). Le code C de l’application a été développé avec CCS et est disponible sur demande.

Comme d’habitude si vous êtes intéressé par cette réalisation, vous pouvez obtenir un kit complet ou partiel en me contactant. Le prix du kit complet pour ce montage (CI percé et composants : PIC programmé) s’élève à 60euros.

Module Pinguino avec le module à DELs

Bien sur la petite vidéo qui va bien :

En fin d’article vous trouverez trois programmes :

• le premier programme montre comment faire un BarGraph
• le deuxième simule un analyseur de spectre
• le troisième est celui de la vidéo ci-dessus

Si vous souhaitez un module pinguino ou le circuit imprimé (percé ou non) n’hésitez pas à me contacter.

Bonne lecture et bon test !