ARM European Technical Conference 2009
Par gblanc le mardi, décembre 22 2009, 15:45 - linux embarqué - Lien permanent
Comme l'année dernière, et certainement celles d'avant (j'avoue ne pas connaître les origines exactes de l'événement), avait lieu en ce jeudi 10 décembre passé l'ARM European Technical Conference (AETC pour les intimes) 2009, au même lieu que l'année dernière, CAP15 près de la tour Eiffel. J'arrive très tôt (pour moi) mais manifestement, beaucoup de monde a son rythme de vie câlée sur nos amies aviaires, et la grande salle de conférence est déjà bien garnie. On y parle Anglais, comme toujours dans les conférences de cet événement réellement européen -- comprendre qu'il y a quantité d'Allemands (patron, ma formation de langue !), d'Anglais, et quelques Russes --, mais la langue véhiculaire laisse plus souvent que l'année dernière au vernaculaire sur les stands du forum voisin -- je n'ai pas pris de photo, mais l'organisation était tout aussi semblable qu'en 2008. Pour les personnes présentes qui passeraient sur ce compte-rendu, puisque chez Anticyp on m'a dit être déjà venu me lire, et qui ne me remettrait pas, j'étais tout de gris et violet vêtu, un chapeau sur la tête (quelques commentateurs, mais pas des plus fins, s'inquiétant régulièrement sur ce point).
Comme je ne pense jamais trop aux mékeskidi, et que chez Linagora, certains administrent des réseaux ou mettent en place des messageries, bref n'ont rien à voir avec l'embarqué mais trouvent peut-être ma prose intéressante, je rappelle donc que ARM est la société anglaise à l'origine du microprocesseur du même nom, que l'on trouve décliné sous différentes gammes depuis une vingtaine d'années dans tellement d'appareils embarqués, qu'il ne fait aucun doute qu'ils dominent le marché (et x86/Intel, me direz-vous ? Comptez le nombre de téléphones portables par foyer ; puis le nombre d'ordinateurs ; vous y êtes). ARM possède cependant une spécificité : ils ne sont pas fondeurs, comprendre qu'ils ne vendent pas directement des puces ni aucune sorte de hardware, mais seulement de la R&D pure, autrement dit pour les fondeurs que sont ST, NXP, TI ou ATMEL, pour parler des présents, il s'agit de récupérer des plans -- pour simplifier. La cible est néanmoins déterminée : il ne s'agit pas de grosses infrastructures réseautiques (plus propices à être sous PowerQUICC/PPC voire x86), ni de microcontrôleurs extrêmement simples de style PIC/68k (qui cèdent, certes, devant le Coldfire, dont on peut se demander si ARM ne gourmande pas par anticipation les parts de marché avec son dernier né, le Cortex-M3, mais je m'avance), mais il n'empêche que d'une cible de CE (Consumer Electronic), représentée sur le diagramme final par le "1 milliard de téléphones", la compagnie lorgne du côté des nouveaux mini-PCs (tout une histoire marketting, ce machin-là) avec 100 millions d'unités visées, et vers les "specialized devices" à hauteur de 10 milliards d'unités (une paille). Le démarrage en flèche du Cortex-M3, tout minuscule qu'il est (visible sur l'un des nombreux stands éparpillés d'ARM), destiné par exemple à être embarqué dans des montres, tendrait à soutenir cette espérance.
Malgré la crise, ARM va bien, et le fait savoir (quand bien même il n'y avait plus de fontaine au chocolat cette année -- mais le buffet était excellent, mes compliments au traiteur et à son équipe dévouée). Une slide montrant le foisonnement des microprocesseurs disponibles il y a une bonne quinzaine d'années, et de ce qu'il en reste en comparaison, fait l'impasse sur SH4 (pourtant très présent dans les STB et autres lecteurs en tout genre), sur SPARC (pourtant certaines archi intéressent le spatial -- ok, ça n'a pas empêché les CPUs de Thomson de défunter) ou sur PPC, montrant une promptitude à enterrer la concurrence qui m'a quelque peu amusé -- je n'ai pas eu le temps de demander sur le stand de ST ce qu'ils en pensaient... En fait, le concurrent principal Atom n'a pas droit de cité non plus. Et ça c'est vraiment méchant -- et pas forcément pertinent, mieux vaut prendre l'adversaire à bras le corps que de l'ignorer, en tout cas dans la bataille on sait où mon coeur va.
Il est beaucoup question de communauté, non pas libre mais autour de ARM, naturellement : par exemple, pour l'extension 3D Mali, le site malideveloper.com partage les informations plus simplement entre développeurs (le marché étant assez récent de ce côté, mais néanmoins à pente rapide comme on peut le constater en considérant les consoles de jeu video portables ; le vrai challenge pour ARM est clairement désigné : le multimédia et notamment la télévision, en concurrence frontale avec SH4) ; on évoque mbed.org, "rapid prototyping for microcontrollers" ; ou encore le projet plugcomputer, qui se donne d'agréger (le concept est un peu flou, je trouve) les idées de serveur miniature de "domotique" (le mot est devenu quelque peu tabou, à force), dans le style DLNA, connectivité centralisée à but applicatif, etc. En fait, remplacez le fameux "developers developers developers" de Ballmer par "community community community" : c'est le nouveau maître-mot. Désenclaver le développeur, mais aussi le décideur (cf la multiplication des blogs pro), voilà une idée qui a l'air aussi bête qu'évidente, mais qu'aucun ne s'était attelé à mettre en oeuvre jusqu'à présent. Si l'on considère la récente communauté autour de Montavista (meld), on voit bien que le mouvement est amorcé : c'est à qui fédèrera le plus autour de lui, en offrant comme valeur ajoutée un partage de connaissance. Ça ne vous dit rien, comme fonctionnement ? Linux embarqué, ce n'est pas seulement un OS gratuit qui entre dans le paysage, je ne cesse de le répéter, c'est l'arbre qui cache la forêt du libre dans l'embarqué, techniquement et dans la pratique : c'est une nouvelle façon de penser, de concevoir, par le partage (d'information pour le moment, mais le code commence à venir, voyez la suite), mot totalement inconnu jusqu'alors dans le monde industriel. Ça fait du bien.
Linux est un mot qui revient souvent, et que l'on trouve décliné sous les formes "Ubuntu" ou "Mozilla" (bon, on sait ce que j'en pense...). Mais ce qui revient encore plus, c'est Android, et Chrome. Le premier, on commence à le connaître, son succès, surtout depuis la dernière version, est impressionnant, et il ne faut pas s'étonner de le voir partout où l'environnement est pensé pour du fenêtrage simple, c'est-à-dire une application à la fois sur l'écran. Pour le multi-fenêtrage, ARM nous parle de Chrome : et là, j'avais raté un épisode. ChromeOS a été montré le 19 novembre dernier, et en fait, c'est l'une de mes prophéties qui se réalise (je suis meilleur que St-Jean le Baptiste, d'une manière générale, je fais donc attention à ne pas perdre la tête) : la migration de l'OS vers du tout-web, ie l'interface graphique utilisateur entièrement conçue à base de technologie web de type html/javascript, rendues par un navigateur puissant mais léger. C'est une question de logique : le but (dans lequel s'inscrit parfaitement Linux, qui est d'ailleurs le kernel sous ce ChromeOS) est d'abaisser le ticket d'entrée dans le monde de l'embarqué, et de le rendre plus fonctionnel ; fini les interfaces toutes pourries et obscures en assembleur et en frame buffer ! La montée en puissance (phénoménale) du hardware pour une consommation en énergie toujours meilleure sert exactement ces intérêts. À travers le logiciel, c'est l'utilisateur qui est remis au centre du problème. D'où la conclusion que je retiens : "Software is all about now", "software ecosystem decides !". La fin annoncée de l'électronicien raté, et l'arrivée du monde logiciel en position de force.
Après toutes ces bonnes nouvelles, place est laissée pour l'orateur suivant, qui nous parle d'un consortium rapidement identifié par mes soins comme du lobbying de hardeux, ce qui ne m'intéresse guère (on sait le milieu assez doué en la matière, parfois trop). Je migre donc vers les stands : passage chez -- ne riez pas -- Windows Embedded Business Group Microsoft France (toujours sur son WinCE 6.1, qui commence à dater, mais se voit affublé de service packs -- c'est une manie !), qui me donne gentiment une version de Windows Embedded 2011 (3cd : 32bit, 64bit et le toolkit), qui contrairement à XP standard est encore supporté quelques années ; entretien chez Montavista, qui distribue de la belle documentation sur son tout nouveau MontaVista Linux 6 (j'ai raté Maxime Petazzoni, dont je n'ai été au courant de la présence qu'à son appel en fin de journée pour gagner une mini-console de jeu, mais il était déjà parti !) ; et puis Ubuntu, qui présentait un petit PC de poche à clavier et écran tactile (dans les deux cas, mes doigts de pianistes étant déjà un peu trop gros : c'est pour le marché japonais, aussi...), de chez Sharp il me semble, sympathique mais à mon avis beaucoup trop geek, il n'y a qu'à considérer les parts de marché du N800, plus sexy quoique moins fonctionnel (mais plus réactif, en échange) -- côté software, en revanche, l'intégration est très bonne, mais firefox bouffe presque toute la mémoire, le menu convivial sur le bureau buggue encore un peu (ce n'est pas une version définitive qui était montrée), et parfois la machine freeze...
Tout le long de la journée, il y a aussi les sessions de conférences, quasiment toutes données par des gens de ARM, ou plus vastement de Keil, la partie software rachetée il y a maintenant un bon bout de temps : il ne faut alors pas s'étonner que lors du track32 "Advanced Debug and Optimization of Cortex-M processor-based Systems", on ne parle uniquement de la sonde J-Tag et des outils Keil, et nullement du JtagX ou autre sonde WindRiver que l'on vante tout aussi bien sur les stands d'Anticyp ou de Neomore. J'avoue sur la journée avoir moins assisté aux conférences que l'année précédente, ayant privilégié cette fois les stands -- sans pour autant avoir pu tout visiter, de ce qui aurait pu m'intéresser. C'est ainsi que je découvre MVD Training, dont le site affreux prouve bien qu'il s'agit de barbus de l'embarqué très bas niveau, et si l'on se fait concurrence sur les formations Linux embarqué/drivers, le reste est tout à fait complémentaire (notamment en terme de programmation), et l'offre assez unique à ma connaissance sur les formations très bas niveau (microprocesseur particulier, programmation, et au milieu : VHDL) me fait penser que mon DIF est plein à craquer (message subliminal).
Et puis je passe beaucoup de temps sur le stand Texas Instrument (Angleterre et Allemagne), pas seulement parce qu'ils possèdent la plus charmante des communicantes qui m'ait été de rencontrer (ciel, une Anglaise blonde -- immigrée en Allemagne --, je n'aurais jamais cru, si on peut lui donner mon URL, puisqu'elle doit manifestement savoir lire le Français, que l'on n'hésite surtout pas !), mais parce que ce sont des personnes extrêmement agréables et Elizabete De Freitas (TI serait-il un avant-goût du paradis ? Des femmes aussi sympathiques que belles...) ne met pas longtemps, alors que je lui explique un projet, pour m'offrir une beagle board ! (que j'ai failli me faire dérober à la station Tour Eiffel, mais après avoir piqué une gueulante monumentale sur les pickpockets, ils ont bizarrement fini par retrouver mon objet) Autant dire que ce geste me touche beaucoup, et à présent, je cherche du temps pour m'impliquer dans le support de la bête, le problème principal étant pour le moment de chercher comment en sortir une console (c'est très bête, mais brancher un video proj sur la sortie S-Video me semble un peu compliqué pour bosser, et monter un RS232 va nécessiter un passage en magasin d'électronique et une séance de soudage : autant dire que ça attendra après les fêtes, puisque je serai... en Allemagne).
J'arrête ici mon compte-rendu par anticipation de bonne résolution pour l'année prochaine : faire plus synthétique. Et puis surtout, parce que je suis en vacances dès demain. Enfin, parce que je n'ai pas encore reçu les slides (par mail, nous a-t-on dit, attention, ça veut dire "courrier" en anglais -- en ricain, ça aurait donné "snail mail", désambigüisé --, on se laisse toujours avoir... :) ), de fait il est plus difficile de tout se rappeler (et comme l'année dernière je m'étais ruiné la santé à prendre un maximum de notes, alors que j'avais ensuite reçu le CD complet...). Bref, je vous souhaite de bonnes fêtes, plein de beagle boards sous le sapin (non, je ne suis pas sponsorisé, juste un peu corrompu -- et puis la concurrence n'est pas facile à débusquer, alors même qu'on m'en a parlé), et j'espère bien me rendre à l'AETC 2010 l'an prochain !
Commentaires
" le but [...] est d'abaisser le ticket d'entrée dans le monde de l'embarqué, et de le rendre plus fonctionnel ;"
De mon point de vue, les solutions basées sur des navigateurs fait au contraire monter considérablement le prix du ticket d'entrée: le surcoût en termes de CPU, mémoire vive et mémoire de masse est notable. Il faut réaliser que la taille d'un Webkit en termes de SLOC est proche de celle d'un noyau Linux.
D'autre part, encore faut-il à voir la "chance" que le navigateur ait déjà été porté sur votre cible; sinon s'embarquer dans un portage est un peu comme jouer à la roulette russe, vu qu'à mon sens le développeurs PC et embarqués n'ont pas tout à fait la même notion du mot "rigueur" (cf. les fuites mémoire de certains navigateurs).
Enfin, les standards du Web sont nombreux et complexes, et la "portabilité" d'une interface Web d'un navigateur à l'autre n'est pas jouée d'avance (a fortiori pour les navigateurs légers); le contournement de bugs à ce niveau peut se payer cash par des heures supplémentaires de développement.
"fini les interfaces toutes pourries et obscures en assembleur et en frame buffer"
Cette remarque est injuste; il existe plusieurs toolkits GUI de différente tailles (de Nano-X à Qt) qui offre des possibilités de rendu correctes. Je crois plutôt que la difficulté est de trouver un développeur compétent pour ce type de projet qui a également un bon sens de l'interface, une compétence à part entière.
A mon avis, le navigateur a pris pied dans l'embarqué avec les "smartphones" (pour résumer), pour lesquels la connectivité Web était un atout considérable. Pour un produit qui n' a nullement besoin de cela, l'utilisation d'un navigateur pour l'interface utilisateur est probablement une fausse bonne idée.
"le but (dans lequel s'inscrit parfaitement Linux, qui est d'ailleurs le kernel sous ce ChromeOS) est d'abaisser le ticket d'entrée dans le monde de l'embarqué, et de le rendre plus fonctionnel ; fini les interfaces toutes pourries et obscures en assembleur et en frame buffer"
Cela dépend de quel prix on parle: les technologies et standards du Web sont complexes; faire tourner un navigateur nécessite beaucoup de ressources (CPU, mémoire vive, mémoire de masse). Il s'ensuit mécaniquement une hausse du prix de revient de la plateforme matérielle.
A contrario, il existe beaucoup de toolkits GUI de différentes tailles (de nano-x/microwindows à Qt) beaucoup plus sobres et offrant un rendu très correct (d'aiileurs les navigateurs les utilisent).
La véritable difficulté est de trouver un développeur ayant les compétence pour programmer ce type d'application en embarqué, et qui a de plus un bon sens de l'interface utilisateur.
L'utilisation d'un navigateur pour une interface graphique ne se justifie réellement que si la connectivité Web/réseau est essentielle au produit.
Dans le cas contraire, il vaut mieux bien examiner les choses avant d'adopter cette solution: existe-t--il déjà un portage d'un navigateur pour la plateforme considéré? Ce navigateur est-il fiable? (pas de plantages, pas de fuites mémoire)? Supporte-t-il correctement les standards du Web (CSS+HTML+Javascript+...) dont l'application a besoin?
Je suis tout à fait d'accord avec la première partie du commentaire, mais je précise que le coût du hardware devient négligeable (il faut considérer la puissance d'un Cortex-A9 !!), tandis que le développement software de plus en plus complexe et long prend le devant de la scène en terme de coûts.
Je ne suis pas d'accord en revanche avec la seconde partie du commentaire : cela date d'un autre temps ! (disons... 2 ans :) ) La révolution s'appelle Webkit (je ne considère pas Firefox plus fonctionnel que Access ou autre daube d'Opera pour l'embarqué applicatif), que ce soit sous iPhone, dans Qt, ou... ChromeOS, justement. Cela dépasse bien le cadre de la simple connectivité sur le web : faire une interface pour SetTopBox en html (et l'on se fiche royalement des standards -- extrêmement bien respectés par Webkit au demeurant) a énormément de sens. Reste évidemment à doser et à utiliser les bons outils où il faut, mais à mon avis, ce genre de solutions étudiées depuis un bon bout de temps (du Mozilla sur STB Philips il y a 3 ans -- bonne idée, mauvaise techno) va clairement exploser.
Il semble que nous n'ayons pas le même vécu en ce que concerne l'embarqué. Il est vrai que c'est un domaine assez vaste: du micro-contrôleur 8 bits au système haut de gamme 32 bits avec MMU (et maintenant le multi-coeur), en passant par le temps réel...
" [...] le coût du hardware devient négligeable [...]"
Dans mon vécu, le prix de revient d'une carte a une importance certaine, en particulier quand on produit en grande série et/ou que l'on est sur un marché concurrentiel.
" [...] faire une interface [...] en html [...] a énormément de sens".
Il faudrait développer ce point, car je ne vois quel est ce sens - du moins en dehors de contextes particuliers.
Pour être franc, ceci ressemble à une "Solution Ultime", d'où mon scepticisme.
Ah, c'est bien le problème de l'embarqué et de l'industriel : c'est vaste. :) Le microprocesseur 8bits est devenu négligeable en terme de marché devant les milliards de chip ARM du CE ; et même pour des montres le Cortex-M8 fait son trou !!
Énormément de sens pour une interface graphique : des menus (faire une suite de balises <li>), des items clickables (liens ou onclick ?), de l'intéractivité en Ajax, et peut-être même des animations graphiques complexes en SVG pour le futur (rappelons qu'on peut y embarquer du javascript : le but est de faire la même chose que flash) ; le tout s'adaptant facilement à la taille des écrans (réutilisation du code facilité). Utiliser une bibliothèque graphique nécessite des connaissances en programmation (la lib Qt ne s'apprend pas en un jour -- la lib GTK en embarqué ne vivant essentiellement que par Maemo, et sa place est à mon sens dans la poubelle, comme l'a finalement compris Nokia en rachetant Trolltech), qui justifie une restriction de l'investissement nécessaire au "bas niveau" (les briques basiques de fonctionnement) optimisé (ie ce qui doit être très réactif, à emprunte mémoire faible puisque chargé en permanence).
L'évolution est tout à fait logique, dans l'absolu : considérons une imprimante ou un modem ; depuis quelques années, une interface web de configuration est proposée via un serveur embarqué. Il ne s'agit à présent ni plus ni moins que d'appliquer les mêmes méthodes (CGI) en affichant les pages web (en plus joli, évidemment) directement sur l'écran du device.
Quand on a vu le code tout pourri en frame buffer qui tourne sur les téloches, on comprend je pense beaucoup mieux ce que je veux dire...
(à noter que le tout premier commentaire avait été injustement spamassassiné, mais repris dans un second commentaire, et donc répondu -- je suis victime de beaucoup de spam, si mon anti-spam vous a erronément détecté alors que vous étiez bien humain, n'hésitez pas à m'envoyer un mail !)