Les outils logiciels : l’opinion d’Haakon Skar Director, AVR product marketing chez Atmel
ECI : Quel est aujourd’hui le véritable différentiateur entre tous ces outils ?
Haakon Skar : La ligne de démarcation la plus évidente sépare les chaînes professionnelles, pour lesquelles vous payez des sommes importantes, des produits d’amateurs, qui semblent avoir été créés par quelque développeur pour son usage personnel et mis ensuite sur Internet. Donc on voit que les produits réellement bons sont rares et disparates. Une autre tendance dans l’industrie, où l’on parle volontiers d’écosystème, est de rencontrer plutôt le type d’écosystème évoquant une jungle peuplée de clans défendant leur territoire, que les partenariats et échanges harmonieux associés à un environnement contrôlé.
ECI : L’un de ces écosystèmes ou communautés est Eclipse. Que pensez-vous d’Eclipse ?
Haakon Skar : Nous connaissons bien Eclipse ; nous étions le premier fabricant de microcontrôleurs à nous engager dans cette voie. A première vue, nous pensions qu’une plate-forme ouverte, permettant à chacun d’apporter sa contribution et de partager, est un excellent moyen pour que tout le monde participe à la création d’un environnement commun. Les outils deviendraient interopérables, et nos outils pourraient s’insérer facilement dans les chaînes de nos partenaires.
Malheureusement, il s’avère que la réalité d’Eclipse est fort éloignée du rêve originel de la communauté et continue à évoluer, je le pense, dans la mauvaise direction. Voici quelques exemples : quand vous développez un outil fonctionnant avec tous les composants pouvant exister sur le marché, inévitablement, votre processus de configuration devient très compliqué et votre écran se couvre d’options. La majorité de ces options ne s’applique même pas aux outils que vous venez de connecter ; ce qui fait que vous êtes obligé d’utiliser une interface offrant vingt ou trente options dont seulement deux peut-être vous concernent. Autre exemple, lorsqu’un plug-in est développé pour un outil, l’extraction des données peut être, ou ne pas être, un standard ouvert. Ce qui rendra éventuellement plus difficile ensuite pour les autres fournisseurs de collaborer avec Eclipse et de développer des add-on s’insérant de manière homogène les uns dans les autres.
ECI : Quelles différences trouve-t-on entre les outils pour systèmes embarqués ?
Haakon Skar : Je pense que vous pouvez les séparer en outils modulaires et propriétaires, en pensant plus spécifiquement à ceux basés sur la plate-forme Eclipse, qui est la plate-forme appuyée par la communauté. Vous trouvez aussi les solutions intégrées des fabricants. Avec ces dernières, vous avez souvent droit à un environnement homogène dont le fournisseur a pris soin d’intégrer parfaitement les éléments les uns avec les autres et dont vous n’avez que peu ou pas d’options à configurer. S’il y en a, les réglages sont en fait très conviviaux et calqués sur des informations disponibles dans les diverses documentations et fiches techniques des composants eux-mêmes.
En examinant l’alternative modulaire, vous vous apercevez que certains de ces outils, en particulier ceux basés sur Eclipse, ont tendance à pâtir de leur nature " ouverte ". Ils sont ouverts aux débogueurs hardware de chacun, et présentent en conséquence toutes les options disponibles pour chacun. Les débutants placés pour la première fois devant ce choix peuvent être intimidés. Une grande partie de ces options n’a sans doute même rien à voir avec les outils matériels qu’ils utilisent. Il y a trente options ou plus à sélectionner, dont peut-être trois seulement concernent réellement le matériel qu’ils viennent de connecter.
ECI : Alors, 8, 16 ou 32 bits, comment un ingénieur peut-il décider quel outil il lui faut ?
Haakon Skar : On ne peut pas vraiment dire que les concepteurs 8 bits ont besoin de ceci et les concepteurs 32 bits de cela. L’architecture des composants 32 bits est plus avancée car ils font transiter plus de données et leur CPU pose de plus fortes contraintes de bande passante à la RAM. De plus, leur contrôleur d’interruption a sans doute davantage de niveaux et d’options ; mais cela n’a aucun sens de dire que les outils doivent être différents juste parce que le composant a plus d’options. Si vous avez l’habitude d’un environnement, et si vous l’avez utilisé avec succès pour un projet, la dernière chose à faire lorsque vous changez de composant est de changer en même temps d’environnement. Cela introduit en effet un nouveau jeu d’inconnues, de sorte qu’en cas d’erreur, vous ne pouvez pas savoir si la cause est due au nouveau composant, au logiciel ou simplement au fait que vous n’avez pas configuré correctement votre outil. Notre avis est que les utilisateurs restent dans le même environnement de conception s’ils le peuvent, lorsqu’ils passent d’un microcontrôleur à l’autre. Il existe de nombreuses chaînes de développement supportant plusieurs composants ; en fait la plupart des chaînes propriétaires sont ouvertes à une variété de microcontrôleurs, de 8 bits aussi bien que de 32 bits.
Si vous avez apprécié cet article, vous aimerez les suivants : ne les manquez pas en vous abonnant à :
