Embedded weblog - Tag - salon - Commentaires

RTS10: journée spéciale Linux Embarqué - Yoann Sculo

2010-04-13T15:19:32+02:00

Sympathique compte-rendu. J'aurais dû venir ... tssk !
Ce n'est que partie remise pour l'année prochaine ! Sinon merci pour les slides, le sujet m'intéresse bien.
Il y a peut-être des chances que le mail en question sur Buildroot soit le mien :-)
Pierre Ficheux m'a pas mal sauvé la vie avec ses deux articles. J'étais tellement content de me débloquer que je lui ai envoyé un mail pour le remercier. Le hasard fait bien les choses.

ARM European Technical Conference 2009 - Gilles Blanc

2010-03-22T12:46:24+01:00

(à 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 !)

ARM European Technical Conference 2009 - Gilles Blanc

2010-01-21T18:21:29+01:00

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...

ARM European Technical Conference 2009 - Frédéric

2010-01-18T14:16:43+01:00

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.

ARM European Technical Conference 2009 - Gilles Blanc

2010-01-18T11:30:33+01:00

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.

ARM European Technical Conference 2009 - Frédéric

2010-01-07T12:46:27+01:00

"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?

ARM European Technical Conference 2009 - Frederic

2010-01-05T13:16:05+01:00

" 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.

2ème Assises franco-allemandes de l'Embarqué 2009 - Gilles Blanc

2009-09-02T14:17:39+02:00

Finalement, ça me gâchait la vue, et comme je suis en pleine lecture de "surveiller et punir", je garde l'IP pour surveiller (mise hors ligne), et je punis les mécréants.

2ème Assises franco-allemandes de l'Embarqué 2009 - Gilles Blanc

2009-08-25T12:26:05+02:00

Deux clowns d'affilée... Bon, je ne vais pas censurer, mais je vais être clair : ceci est un blog *professionnel*, qui a pour de communiquer à l'extérieur comme en interne. Autant j'encourage à avoir de l'esprit, autant le potache -- voire la grossièreté la plus crasse -- m'insupportent. Surtout lorsque c'est fait anonymement, avec des pseudonymes et des adresses mails fantaisistes -- ne pas assumer sa bêtise est peut-être signe que l'on a conscience que l'on en fait preuve, me dira-t-on.

La prochaine fois, donc, je caviarde sans préavis. Merci de votre attention.

(par ailleurs, si Linagora souhaite que j'efface ces deux preuves que l'on peut tout à fait vivre sans cervelle, je m'exécuterai avec grand plaisir)

ARM European Technical Conference - Gilles Blanc

2009-02-03T17:29:19+01:00

Merci pour cette précision, en effet :) (la solution est donc à rapprocher de Trango dans son esprit ; voire de PikeOS, qui fut développé from scratch, mais simplement utilisé pour autre chose avant d'être réadapté à la paravitualisation).

Il ne me reste plus qu'un grand mystère à élucider : comment se fait-il que tous les acteurs de ce marché pourtant pas si immense soient tous leaders ? :)

ARM European Technical Conference - Seb

2009-01-28T11:35:33+01:00

Bonjour,

Je tenais a rectifier une erreur concernant la solution de virtualisation "VLX" de VirtualLogix : celle-ci n'est pas basee sur ChorusOS mais a ete developpee "from scratch".
Par contre, les fondateurs de la societe VirtualLogix sont en effet pour beaucoup d'anciens de la societe "Chorus" qui a developpe le micro-noyau ChorusOS.
La societe VirtualLogix a commence son business en faisant du support du micro-noyau ChorusOS pour lui permettre de developper son produit de virtualisation. Dorenavant, VirtualLogix est le leader dans ce domaine et son activite de support du micro-noyau ChorusOS est une activite secondaire.
Ceci explique sans doute la confusion...

Cordialement.

ARM European Technical Conference - Gilles Blanc

2009-01-05T17:47:30+01:00

Plus qu'une simple participation : nous n'étions que deux, mon chef s'occupant de la partie nucleus et adaptation du Linux pour la virtualisation maison (en reprenant des travaux internes), et moi-même qui ai conçu le système au complet (sauf noyau, donc) ainsi que le SDK, etc. Je vous écris.

ARM European Technical Conference - lix

2008-12-27T15:49:25+01:00

Bonjour,

Si j'ai bien compris vous avez participe au development du Sagem MO300e. On est en train d'evaluer le produit pour un nouvel projet. Les docs sont encore tres minces -- il y a beacoup de questions. Le support par notre distributeur est difficile, car les questions sont tres techniques. Auriez vous le temps de nous aider un peu? il s'agit surtout sur les points du Linux embedded. Si oui, je vous en prie de m'ecrire directement.

Je vous souhaite des bonne fetes!

salon RTS 2008 - cyclopio

2008-12-23T16:56:59+01:00

c'est cool que tu mettes cette enerrgie dans tonb blog ! j'adore

ARM European Technical Conference - Gilles Blanc

2008-12-10T19:04:52+01:00

ooooohhh, ça expliquerait des choses (notamment pourquoi je n'ai jamais eu d'info sur le second kernel paravirtualisé, que je pensais être nucleus, mais pas moyen de savoir...). Si Abi, Tim ou passent par là (Brenna n'est pas très tech') et peuvent nous donner d'autres précisions... (bon, personne ne parle Français chez eux, mais qui sait, à force de fréquenter le pays...)

ARM European Technical Conference - tytouf

2008-12-09T18:05:07+01:00

Pour info, les chiffres présentés par OKLabs sont un peu bidonnés: le micronoyau OKL4 est effectivement shippé sur plusieurs millions de téléphone mais pas leur solution de virtualization. C'est Qualcomm qui utilise L4 pour leurs stacks modems.