5 façons dont une couche d'abstraction matérielle peut transformer vos projets

Jacob du Bénin | 05 juin 2023

Les développeurs de logiciels embarqués ont généralement évité les couches d'abstraction matérielles (HAL) en affirmant qu'elles diminuent les performances et augmentent la complexité du code. Malheureusement, lorsque les développeurs adoptent un HAL, un HAL fourni par le fournisseur n'abstrait souvent pas le matériel et garantit toujours un couplage étroit avec le matériel. Après tout, un véritable HAL abstrait permettrait à un développeur d'utiliser n'importe quel fournisseur en un clin d'œil. Cependant, l'utilisation ou le développement de votre propre HAL peut avoir un impact sur votre logiciel de plusieurs façons. Dans cet article, nous explorerons cinq manières surprenantes dont un HAL peut transformer vos projets logiciels et libérer une vitesse et une valeur que vous ne pensiez pas possibles.

J'ai généralement constaté que les développeurs ont souvent un fournisseur de microcontrôleurs préféré. Il s'agit généralement du fournisseur sur lequel vous avez écrit votre logiciel embarqué pour la première fois ou avec lequel vous êtes familier. J'ai mes favoris comme n'importe qui d'autre, mais il peut être dangereux d'écrire votre logiciel en fonction de leur HAL ou de leurs bibliothèques de logiciels. Par exemple, que faites-vous si vous ne pouvez soudainement pas obtenir leurs microcontrôleurs ? Vous devrez sélectionner un nouveau fournisseur, puis réécrire, tester et peut-être même certifier votre produit. Ce n'est ni rapide ni bon marché ! Bien que vous puissiez penser que cela est peu probable, cela s'est produit pendant COVID et plusieurs fois auparavant.

L'utilisation d'un bon HAL vous permettra d'écrire un code d'application plus portable et réutilisable, indépendant du matériel. Il s'agit d'une transformation massive pour de nombreuses équipes embarquées. Par exemple, vous pouvez exécuter votre code à l'aide du fournisseur A et, en modifiant un indicateur dans votre build, compiler pour le fournisseur B. L'indépendance matérielle vous donne la possibilité d'utiliser le matériel de votre choix et supprime votre dépendance vis-à-vis de votre fournisseur de microcontrôleurs.

Si vous aimez l'idée d'utiliser le HAL fourni par le fournisseur, c'est bien tant que vous passez en revue plusieurs fonctionnalités essentielles. Tout d'abord, la HAL doit être une vraie HAL. Cela signifie que vous devez avoir une interface définie qui rompt la dépendance matérielle. Nous en avons discuté dans mon blog intitulé "Writing Hardware Abstraction Layers (HALs) in C." Je vois souvent des "HAL" qui ne sont rien de plus que des fonctions avec l'implémentation. Cela n'obéit pas au principe d'inversion de dépendance et est tout aussi difficile à mettre à jour le code. Ensuite, la couche HAL doit être définie séparément de l'implémentation. Enfin, vous devriez pouvoir échanger rapidement la fonction appelée par l'interface. Si vous n'avez pas ces trois choses, alors vous n'avez pas d'indépendance matérielle ; vous avez une dépendance matérielle !

La clé pour libérer de la valeur et transformer votre développement logiciel commence par l'utilisation d'un HAL. Le HAL permet en outre des transformations supplémentaires telles que l'activation des tests unitaires et d'intégration automatisés. Les développeurs embarqués ont souvent du mal avec les tests unitaires car ils écrivent du code qui touche le matériel. Cela signifie que vous devez exécuter vos tests sur le microcontrôleur. Lorsque vous avez un HAL approprié en place, oui, vous devez toujours tester vos pilotes sur la cible, mais tout votre code d'application est soudainement libéré ! Votre code d'application peut désormais être testé à l'unité et en intégration sur une machine hôte indépendante du matériel.

La suppression du matériel de l'équation et le transfert des tests vers l'hôte profitent aux développeurs. Premièrement, c'est plus rapide. Vous n'avez pas à vous soucier de tous ces cycles lents d'effacement et d'écriture sur la pièce. Deuxièmement, vous n'avez pas à vous soucier de la taille de votre harnais de test ou du nombre de tests dont vous disposez. Au lieu d'essayer d'adapter votre code et vos tests sur le microcontrôleur, vous testez d'abord tout le code de l'application sur votre hôte. Ensuite, passer au test hors cible vous permet d'utiliser l'intégration continue et même le déploiement continu si vous le souhaitez. Le résultat sera de détecter les bogues plus tôt et plus rapidement, de réduire les coûts et d'améliorer la qualité.

Lorsque vous sortez le matériel de l'équation en utilisant un bon HAL, cela vous permet de mettre n'importe quelle implémentation derrière. Cela signifie que vous pouvez avoir une implémentation pour votre cible, votre harnais de test et un environnement de simulation ! Dans de nombreux cas, les développeurs de logiciels embarqués doivent commencer à écrire des logiciels avant que le matériel ne soit disponible. Ainsi, bien que nous puissions utiliser des cartes de développement pour démarrer, avec un bon HAL, nous pouvons exécuter des simulations sur notre code d'application à la place !

La simulation de code d'application présente de nombreux avantages pour les développeurs. Tout d'abord, cela leur permet d'obtenir le code d'application devant leurs clients le plus tôt possible. Nous savons tous que les clients aiment changer d'avis et ont du mal à visualiser le fonctionnement d'un produit tant qu'ils ne peuvent pas jouer avec. La simulation peut aider le client à comprendre le produit et à fournir des commentaires productifs plus tôt, réduisant ainsi les modifications coûteuses et chronophages plus tard dans le cycle de développement.

Ensuite, la simulation permet des tests plus robustes en permettant de tester les défauts et autres comportements aberrants sans le matériel. Par exemple, faire en sorte qu'un capteur se comporte mal ou forcer une exception matérielle sur le processeur cible peut souvent être difficile. Dans un environnement de simulation, ce n'est pas un problème. Le résultat est à nouveau un logiciel plus robuste.

Lorsque vous déboguez sur la cible, chaque fois qu'une modification est apportée, il y a un cycle de compilation croisée, d'effacement du flash, de programme du flash et d'exécution de l'application. L'ensemble du processus peut prendre un certain temps, selon l'application, même avec des outils professionnels. L'utilisation d'un HAL pour séparer l'application permet au code d'être débogué plus rapidement ! Sur un hôte, le cycle de compilation et d'exécution est beaucoup plus court. Cela signifie que les développeurs peuvent résoudre les problèmes plus rapidement, puis tester la version finale déboguée sur leur matériel si nécessaire.

Si vous permettez aux autres transformations fournies par HAL de se concrétiser, vous utiliserez des tests unitaires pour piloter le développement, ce qui signifie que vous passerez même moins de temps à déboguer. Vous n'écrirez du code que pour réussir un test. Votre logiciel sera écrit par petits incréments, avec des tests le validant tout au long du processus. Si vous cassez quelque chose, les tests de régression le détecteront immédiatement. Le résultat sera un débogage plus rapide et plus efficace et la suppression presque complète du débogage de votre vie et de votre projet ! Cela ne semble-t-il pas merveilleux ?

La transformation ultime de l'utilisation d'un HAL pour développer des logiciels embarqués est que vous réduisez les coûts et les délais de mise sur le marché. Un HAL crée une flexibilité dans le logiciel embarqué dont la plupart des équipes ne rêvent jamais. Vous pouvez facilement voir que si vous pouvez obtenir rapidement les commentaires des clients, vous aurez moins de retouches à la fin du cycle de développement. De plus, si vous pouvez éliminer le débogage, c'est énorme ! La plupart des équipes consacrent en moyenne 20 à 40 % de leur cycle de développement au débogage ! Cela représente 2,4 à 4,5 mois par an et par personne ! Tout cela parce que vous avez utilisé un HAL qui permet de tester votre code d'application et de réduire le temps de débogage.

Avec des délais de mise sur le marché réduits, il devient évident que le coût sera moindre. Il y a certainement un investissement dans le développement HAL, les harnais de test et d'autres outils pour garantir le bon déroulement du cycle de développement. Cependant, ces coûts sont souvent inférieurs d'un ordre de grandeur à ce qui sera économisé. Je n'ai même pas mentionné les dépenses liées à la maintenance qui peuvent facilement dépasser les coûts de développement initiaux.

J'ai souvent eu des commentaires de clients et de collègues sur tout ce que je peux faire. Le secret est que j'ai déverrouillé les transformations qu'un HAL peut fournir aux développeurs embarqués. Comme vous l'avez vu dans cet article, l'utilisation d'un "vrai" HAL peut transformer radicalement votre projet et la façon dont vous développez des logiciels embarqués.

Certaines des transformations dont nous avons discuté peuvent sembler un peu étrangères car les développeurs de logiciels embarqués n'ont traditionnellement pas utilisé ces techniques. Cependant, il ne faut pas beaucoup de temps pour se familiariser avec eux et leur permettre d'améliorer considérablement la façon dont vous développez des logiciels embarqués. Vous avez vu les avantages ; la question est de savoir si vous allez les adopter et commencer à construire un HAL indépendant du microcontrôleur dans votre logiciel. Si vous le faites, je pense que vous révolutionnerez la façon dont vous développez vos produits embarqués.

Plus d'informations sur les formats de texte