Voici le sujet du concours 2012 que nous avons le plaisir de lancer suite au succès du concours 2011. Il s’agit de développer un oscilloscope sur une carte FriendlyARM en prenant en compte les problématiques temps réel. Vous trouverez tous les détails ici : http://linuxembedded.fr/concours2012.

De nombreux lots sont à gagner et ce concours vous apprendra beaucoup. N’hésitez pas à utiliser les canaux de discussion mis à disposition : IRC (Freenode #linuxembedded), mailing list, mails aux organisateurs.

Enregistrement des traces

Pour effectuer l’enregistrement de traces, le noyau Linux doit être compilé avec le support de Ftrace. Son activation (via make menuconfig) se fait dans le menu Kernel hacking -> Tracers. Il faudra ensuite activer les traceurs qui vous intéressent (kernel functions, scheduling, syscalls, …).

Ensuite, il vous faudra installer trace-cmd. Si votre gestionnaire de paquets ne le propose pas, récupérez la dernière version ici (prenez l’archive snapshot du dernier tag). Compilez et installez trace-cmd à l’aide des commandes make trace-cmd && make install.

Une fois votre environnement en place, il est possible d’enregistrer tous les évènements ayant lieu sur le système de manière interactive (l’enregistrement s’arrête avec Ctrl^C) :

trace-cmd record -e all -o mes_traces.dat

… ou pendant l’exécution d’un programme (ici ls) :

trace-cmd record -e all -o ls_traces.dat ls /

Pour plus d’informations sur les options, consultez l’aide :

shell> trace-cmd record -h

trace-cmd version 1.0.3

usage:
 trace-cmd record [-v][-e event [-f filter]][-p plugin][-F][-d] \
 [-o file][-s usecs][-O option ][-l func][-g func][-n func] \
 [-P pid][-N host:port][-t][-r prio][-b size][command ...]
 -e run command with event enabled
 -f filter for previous -e event
 -p run command with plugin enabled
 -F filter only on the given process
 -P trace the given pid like -F for the command
 -l filter function name
 -g set graph function
 -n do not trace function
 -v will negate all -e after it (disable those events)
 -d disable function tracer when running
 -o data output file [default trace.dat]
 -O option to enable (or disable)
 -r real time priority to run the capture threads
 -s sleep interval between recording (in usecs) [default: 1000]
 -N host:port to connect to (see listen)
 -t used with -N, forces use of tcp in live trace
 -b change kernel buffersize (in kilobytes per CPU)

Visualisation des traces

Pour visualiser les traces, il est nécessaire d’installer kernelshark. Si votre gestionnaire de paquets ne le propose pas, dans le répertoire des sources de trace-cmd téléchargées précédemment, tapez la commande suivante make gui && make install_gui.

Une fois installé, vous pouvez ouvrir le fichier ls_traces.dat généré précédemment :

kernelshark ls_traces.dat

L’interface est séparée en deux parties :

• une visualisation de graphes
• une visualisation précise des évènements

Voici quelques éléments qui pourront aider à commencer :

• Le menu Filter permet de filtrer des types d’évènements
• le menu Plots permet de sélectionner les graphes à afficher
• le zoom en avant se fait en sélectionnant une section du graphe vers la droite
• le zoom en arrière se fait en sélectionnant une section du graphe vers la gauche
• le marqueur vert se pose avec un clic gauche
• le marqueur rouge se pose avec un SHIFT + clic gauche
• un double clic permet de placer le curseur (pour visualiser les évènements)
• les couleurs du graphe d’une tâche correspondent aux CPUs sur lesquels celle-ci s’exécute
• les couleurs du graphe d’un CPU correspondent aux tâches exécutées

Pour plus de détails, consultez cette page.

kernelshark avec PREEMPT_RT

Jouons maintenant avec Linux PREEMPT_RT. Soit le programme téléchargeable ici qui se réveille toute les millisecondes avec un timer POSIX (cf. article sur les timers). Enregistrons alors son exécution sur un système Linux classique que l’on charge avec la commande stress :

On observe donc que la propriété temps réel de l’application n’est pas respectée et qu’un nombre important de réveils sont manqués. Observons ce même programme sur un Linux patché avec PREEMPT_RT :

Cette fois-ci, l’ordonnancement est quasi parfait.

Aller plus loin

trace-cmd et kernelshark permettent donc d’observer le comportement d’un système et de visualiser les résultats graphiquement. Attention cependant, la sortie générée par trace-cmd est volumineuse et pourrait donc modifier le comportement de votre système. L’option « -e all » n’est donc pas toujours appropriée.

Pour aller plus loin, je vous recommande les documents suivants :

• documentation de kernelshark
• installation et utilisation de ftrace
• trace-cmd – command line reader for ftrace
• documentation du noyau (répertoire Documentation/trace des sources)

usleep et nanosleep

Supposons que nous souhaitons effectuer une action toutes les millisecondes. Il pourrait sembler évident d’écrire un code comme celui-ci (attention, pour plus de lisibilité, ce code ne tient pas compte du dépassement des variables) :

gettimeofday(&tv, NULL);
while (1)
{
  tv.nsec += 1000000; // calcul de l'heure à attendre
  gettimeofday(&time);
  nanosleep(tv.nsec - time.nsec); // attente de l'échéance
  /* Exécution du code périodique */
}

Pour une application temps réel, ce code n’est cependant pas correct. En effet,  celle-ci pourrait être ordonnancée entre les appels à gettimeofday() et nanosleep() et reprendrait son exécution après une durée indéterminée pour appeler nanosleep() avec un temps d’attente trop important.

Timer POSIX

Afin de respecter la période, il est donc nécessaire d’utiliser les timers POSIX. Contrairement aux fonctions du type sleep(), un timer va émettre un signal à l’application elle-même qui peut le traiter de deux façons :

• en déclarant un handler pour le signal concerné (man sigaction)
• en attendant la réception du signal (fonctions sigwaitinfo ou sigtimedwait)

Voici un exemple avec sigwaitinfo :

#include <signal.h>
#include <time.h>
#include <stdio.h>

#define PERIOD_SIG      SIGRTMIN
#define PERIOD_SEC      0
#define PERIOD_NSEC     1000000 // 1ms

int main(int argc, char *argv[])
{
  sigset_t mask;
  timer_t timerid;
  struct itimerspec its;
  struct sigevent evp = {
    .sigev_notify = SIGEV_SIGNAL,
    .sigev_signo = TIMER_SIG,
  };
  siginfo_t si;
  int sig;

  sigemptyset(&mask);
  sigaddset(&mask, TIMER_SIG);
  sigprocmask(SIG_BLOCK, &mask, NULL);

  timer_create(CLOCK_REALTIME, &evp, &timerid);

  its.it_value.tv_sec = PERIOD_SEC;
  its.it_value.tv_nsec = PERIOD_NSEC;
  its.it_interval.tv_sec = PERIOD_SEC;
  its.it_interval.tv_nsec = PERIOD_NSEC;
  timer_settime(timerid, 0, &its, NULL);

  while (1)
  {
    sig = sigwaitinfo(&mask, &si);
    if (sig != TIMER_SIG)
      continue;
    /* Periodic task... */
  }

  return 0;
}

Attention, ce code ne contient aucune vérification d’erreurs. Le code complet se trouve ici (à compiler avec `gcc timer_sigwait.c -rt`).

Timer en environnement multithread

L’utilisation des signaux dans un environnement multithread est délicat puisque, par défaut, le thread en charge de les traiter peut être choisi aléatoirement. Dans un environnement temps réel, ceci peut avoir des conséquences importantes sur l’ordonnancement des threads.

Il est cependant possible de forcer le timer à envoyer ses signaux vers un thread spécifique en précisant le thread ID lors de sa création :

/* ... */
struct sigevent evp = {
  .sigev_notify = SIGEV_THREAD_ID,
  .sigev_signo = PERIOD_SIG,
  .sigev_notify_thread_id = mygettid(),
};

/* ... */
timer_create(CLOCK_REALTIME, &evp, &timerid);

Le code complet est téléchargeable ici (à compiler avec `gcc timer_sigwait_thread.c -pthread -rt`).

Aller plus loin …

Les timers offrent d’autres possibilités comme la possibilité d’appeler un handler dans un nouveau thread. Pour plus d’informations, n’hésitez pas à consulter les pages de man bien complètes :

• timer_create
• sigevent
• …

Parmi les points techniques évoqués, voici une liste non exhaustive de ceux qui ont été les plus efficaces :

• réduction de la taille du système en utilisant un noyau Linux allégé et une libc légère (klibc, uclibc) afin d’obtenir, pour certains, un système de moins de 2Mo tenant en NOR
• utilisation d’une application liée en statique et inclue dans un initramfs
• utilisation d’un bootloader plus léger ou même réécriture de celui-ci
• initialisation des contrôleurs Ethernet et MMC/SD au plus tôt dans le démarrage du système (dans le bootloader ou au tout début du chargement du noyau)
• diminution de certains délais de polling (par exemple pour une meilleure réaction au changement d’état de la carte réseau)
• utilisation du client DHCP du noyau Linux (exécuté dans un thread)

Ces points feront sans doute l’objet de futures publications dans Linux Magazine ou Open Silicium.

Mais venons-en aux chiffres. Les temps de démarrage des différents projets ont été mesurés à l’aide d’une caméra. Voici les temps obtenus :

Équipe des Poussins :

Équipe des Vieux gnoux :

Les meilleurs temps ont donc été effectués par l’équipe CLAX et Fabrice Jouhaud. Ils gagnent une tablette multimédia et un abonnement à Open Silicium.

Le jury a aussi retenu le projet de Cédric Roux pour son originalité et le développement d’outils. Il gagne une tablette multimédia.

Pour leurs deuxièmes places, Jean-baptiste Théou et Julien HEYMAN sont repartis avec un Wobe ainsi qu’un abonnement à Open Silicium pour la très bonne documentation de leurs projets.

Gabriel Huau et Laurent NAVET remportent une sonde JTAG, une caméra, et un kit de câbles pour la FriendlyARM provenant de notre partenaire Industrial ARMWorks.

Voici les photos de la soirée :

Les sources des différents projets seront publiées ici dans les jours qui viennent.

La nouvelle édition EWili 2012 sera un évènement indépendant et aura lieu le 7 juin 2012 à Lorient. Un appel est présentation est
d’ores et déjà disponible sur http://www.sigops-france.fr/Main/EWiLi

Cette deuxième phase du concours consistait à optimiser un système Linux embarqué afin qu’il démarre le plus vite possible sur une carte FriendlyARM (gagnée par les candidats à la fin de la première phase du concours).

Nous tenons à remercier les 7 finalistes dont les rendus semblent très prometteurs.

Un jury étudiera et départagera les différents projets le mardi 24 janvier. Il s’en suivra une remise des prix à laquelle 15 places sont réservées aux lecteurs de linuxembedded.fr. Cet événement sera l’occasion de rencontrer les organisateurs, le jury et les participants qui exposeront les différentes solutions techniques mises en oeuvre. Le jury est constitué de :

• Pierre Ficheux (Open Wide Ingénierie)
• Jean-Marc Lacroix (Thales Communication)
• Yann Lopez (Plugnsurf)
• Thomas Monjalon (6Wind)
• Olivier Viné (Open Wide Ingénierie)

Afin d’assister à la remise des prix et recevoir une invitation, envoyez au plus vite un email à l’adresse concours@linuxembedded.fr. L’évènement aura lieu mardi 24 janvier à 19h dans nos locaux :

Open Wide (6ème étage)
23-25, rue Daviel
75 013 Paris
Plan d’accès
Accès par le métro 6, station Glacière

1. Qt

Qt est un toolkit graphique écrit en C++. Il a été développé par deux étudiants norvégiens, Haavard Nord et Eirik Chambe-Eng. Initialement prévu pour Unix et l’environnement X11, il devient rapidement multi-plate-forme, et permet donc de développer sur des environnements comme Unix, Windows et Mac OS X. Les deux étudiants décident de créer la société Trolltech et sortent la version 1.0 de Qt fin 1996.

Le projet KDE est lancé en 1997 par Matthias Ettrich. Il est l’un des bureaux les plus célèbres sur Linux et est entièrement développé en Qt. Le fondateur est rapidement embauché par la société Trolltech. C’est entre autre grâce à KDE que Qt devient célèbre. Il faudra attendre 2000 pour que Trolltech publie Qt2 et Qt/Embedded (à l’époque plus connu sous le nom de Qtopia). Ajourd’hui QtSDK est composé de « Qt framework » et d’un ensemble d’outils permettant de développer des applications aussi bien sur des ordinateurs personnels que sur des systèmes embarqués (Symbian, Maemo et Meego, Android via Qt Necessitas).

Jusqu’en 2008, Qt était sous double licence, GPL et commerciale. Après le rachat par Nokia la même année, Qt est diffusé également sous licence LGPL, ce qui permet de l’utiliser avec d’autres bibliothèques propriétaires sans avoir besoin d’acquérir de licence commerciale.

Aujourd’hui Qt est sans doute le toolkit le plus avancé et le plus célèbre pour développer des applications graphiques sous Linux. Il est parfois considéré comme une extension du C++ par certains développeurs dans la mesure ou il facilite de façon non négligeable le travail d’un développeur. En effet, il n’est pas uniquement un toolkit graphique, mais fournit également une abstraction de composants standards comme l’accès au réseau, l’accès à la base de donnée, les threads, l’unicode qui est supporté nativement et bien d’autres.

Du fait de sa notoriété, une grande communauté s’est créée autour de ce projet. Sa documentation est très complète, contrairement à beaucoup de projets libres. De plus, de nombreux exemples sont fournis avec le toolkit afin de se familiariser avec la logique de programmation de Qt.

Points forts de Qt :

• Portabilité
• Abstraction de nombreux composants standards (réseau, thread, dbus, webkit)
• Outils de traduction
• QtCreator qui intègrent et utilisent de façon transparente des outils Qt :
  • designer pour créer des interfaces graphiques à la main
  • uic pour générer du code C++ à partir d’une interface graphique
  • rcc pour compiler un fichier de ressource
• Documentation très complète
• Accès à de nombreux exemples de code
• Communauté active

Inconvénients de Qt :

• Plus lourd que les EFL
  • Mémoire vive
  • Grosses bibliothèques (stockage)
• Temps de compilation d’un programme développé en Qt est plus long que la compilation d’un programme compilé avec les EFL

2. EFL

Les EFL sont un ensemble de bibliothèques écrites en C sous license BSD et LGPL, elles ont été créées et développées pour le gestionnaire de fenêtres Enlightenment. Ce dernier existe depuis 1997 date de la sortie de la première version. En 1999, la version 0.16 du projet semblait déjà révolutionnaire de par ses effets graphiques précurseurs. Début décembre 2011 la version stable 1.1 des EFL a vu le jour, elles sont maintenant utilisées dans Enlightenment 0.17 qui n’a officiellement pas encore de date de sortie.

Ces bibliothèques sont conçues à la base pour être très optimisées (tant en performance du rendu graphique qu’en empreinte mémoire), et peuvent être utilisées aussi bien sur un ordinateur personnel que dans des systèmes embarqués. Le projet s’est d’ailleurs orienté vers le tactile en pensant (à juste titre), que Linux avait plus d’avenir dans l’embarqué que sur ordinateur. Les EFL fonctionnent sur des architectures peu performantes (ARM 50MHz, 16MB RAM) tout en tirant parti au mieux des systèmes plus puissants. De plus, elles sont compatibles avec un certain nombre de systèmes (Linux, BSD, MAC OS X, Windows) ainsi qu’avec plusieurs architectures (ARM, x86, powerPC, MIPS, Sparc), ce qui fait qu’elles sont tout à fait adaptées à une utilisation dans l’embarqué.

La communauté autour des EFL est assez petite comparée à la communauté Qt. Néanmoins, certaines grosses entreprises comme Samsung supportent activement le développement du projet. De plus, la technologie commence à être utilisée par des industriels tels que Free, Zodiac Aerospace, Intel, Ordissimo, Calaos, Electrolux, ce qui montre clairement la maturité du projet. La documentation des bibliothèques ainsi que les outils pour faciliter le développement ne sont par contre clairement pas au niveau de leur équivalent sous Qt.

Points forts EFL :

• Portabilité
• Légèreté
• Optimisation
• Très bien adapté à l’embarqué
• Communauté active

Inconvénients :

• Documentation moins complète que sur Qt
• Jeunesse du projet (manque certaines fonctionnalités)
• Pas d’outils WYSIWYG pour créer des interfaces

Cet article est le premier d’une longue série. Les suivants se focaliseront plus sur l’aspect technique de ces deux projets, et surtout sur la comparaison et l’utilisation de ceux-ci.

Pour ne citer que les plus connus :

• Atmel (serie AT91)
• Samsung (series S3xxxx / S5xxxx)
• Qualcomm (serie SnapDragon)
• Texas Instrument (serie OMAP)
• Nvidia (serie Tegra)
• Freescale (serie i.MX)

Les processeurs ARM sont de type RISC (Reduced Instruction Set Computer) et possédaient jusqu’à maintenant un espace d’adressage de 32 bits seulement, alors qu’Intel et AMD produisent des processeurs x86 64 bits pour le grand public depuis plus de 10 ans.

Leur principale caractéristique est leur grand rapport puissance / consommation. Ils sont pour cela incontournables dans le monde de l’informatique embarqué. Arm ltd tente depuis peu de pénétrer le marché des serveurs, la dernière annonce en date ayant été faite par HP.

Le 27 octobre 2011, Arm ltd annonce le jeu d’instructions 64 bits ARM nommé A64, compatible avec les instructions 32 bits, au travers de sa nouvelle génération de processeurs : ARMv8.

Profitons-en pour faire un tour rapide (non exhaustif) des familles de processeurs ARM.

• ARMv1 : premier prototype (1985)
• ARMv2 : premier produit commercial (1987)
• ARMv4T : Arrivé MMU + thumb
• ARMv5TE : arrivé fonctionnalitées DSP
• ARM11 : arrivé de l’unité de calculs flottants
• Cortex-A5 (ARMv7-A) : processeurs d’applications premier de la famille ARMv7
• Cortex-A9 (ARMv7-A) : ajout du support multicore (MPCore)
• ARMv8 : Jeu d’instructions 64 bits (2011)

Cette annonce du passage en 64 bits est couplée à celle de Applied Micro qui a présenté lors du ARM techcon la première implémentation du ARMv8 : le X-Gene. Ce type de processeur n’est à priori pas orienté systèmes embarqués (avec ses 128 coeurs cadencés à 3GHz), mais de nouvelles implémentations devraient voir le jour en 2012, pour une commercialisation courant 2014…
Le jeu d’instructions ARMv8 est entièrement rétrocompatible avec celui ARMv7. Il reste en taille fixe et à 32 bits par instruction. Les changements introduits par le passage en 64 bits sont globalement circonscrits aux seules parties le nécessitant. Par exemple :

• Les General Purpose Registers sont bien entendus étendus à 64 bits.
• Passage à 31 General Purpose Registers.
• Un modèle d’exceptions entièrement revu.
• L’espace d’adressage passe à 64 bits.
• Les modules de cryptographie hardware sont améliorés.
• Le thumb2 et simd restent équivalent à l’architecture 32 bits.

En clair, un processeur ARMv8 avec un OS 64 bits sera capable de faire fonctionner des applications 32 bits en parallèle avec des applications 64 bits sans soucis.
Arm ltd précise bien que cela ne signifie pas la fin de l’architecture 32 bits. Celle ci pourra même bénéficier de certaines améliorations de l’architecture 64 bits.

Les périphériques embarqués devenant de plus en plus gourmands (et donc puissants), l’avenir nous dira comment cette nouvelle gamme de processeurs pourra suivre, voir même influencer le marché.

Le concours consiste à mettre au point un système Linux embarqué démarrant le plus vite possible pour une cible FriendlyARM. La première phase s’est déroulée dans un environnement émulé par Qemu.

Premièrement, nous voulons remercier et féliciter tous les participants !
Nous avons eu un total de 14 rendus dont la qualité globale a été remarquée par l’équipe du jury.

Nous sommes heureux d’avoir pu aider la catégorie Poussin (les étudiants) en essayant d’être le plus pédagogique possible, pensant que ce concours est un excellent moyen d’acquérir de l’expérience dans le domaine de l’informatique embarquée.

Aussi, ce concours a permis d’améliorer le fork Qemu de Michel Pollet (alias BusError) supportant la carte mini2440. D’autres contributions et techniques d’optimisation très intéressantes ont également été observées, mais feront l’objet d’un autre article à la fin du concours.

Les heureux gagnants sont donc :

Équipe des Poussins :

Équipe des Vieux gnoux :

De par la nature de l’émulateur, les temps indiqués ne correspondent pas à un temps que l’on pourrait observer en situation réelle et sont donc affichés ici à titre indicatif.

Les participants dont le nom est cité ci-dessus recevront une carte FriendlyARM mini2440 afin de poursuivre le concours dans sa deuxième phase.

Pour les autres participants, étant donnés les projets prometteurs reçus mais non retenus, nous vous accordons une seconde chance pour cette phase et ce jusqu’au 15 Novembre 2011 à 12h00.
La date limite de la seconde phase du concours n’est quant à elle pas modifiée et maintenue au 31 Décembre 2011, les retardataires auront donc moins de temps d’optimisation sur la carte FriendlyARM.

Bon courage et merci à tous les participants !

Plus de 30 professionnels, issus de plusieurs secteurs d’activités, se sont donc retrouvés le 20 octobre dernier. Ils ont pu profiter de l’expertise de consultants Open Wide (Pierre Ficheux et Pierre Le Magourou) et d’un contributeur majeur aux EFL (Cédric Bail). Les questions ont été nombreuses, en particulier concernant les EFL qui ont suscité un vif intérêt.

Les supports de présentation sont disponibles à cette adresse : ingenierie.openwide.fr/…/Conferences-techniques/…

Fort de ce succès, une nouvelle édition de cette conférence aura lieu le 24 novembre à Toulouse.