5 conseils pour choisir un langage de programmation embarqué

Au cours des dernières années, le nombre de langages de programmation utilisés pour le développement embarqué a commencé à exploser. Les développeurs ont à leur disposition des langages tels que Assembly, C, C++, Python, MicroPython, Java et Rust. (Il existe même des outils disponibles qui peuvent être utilisés pour modéliser des applications et générer le code pour les développeurs). Pour les nouveaux projets, quel langage de programmation les développeurs embarqués doivent-ils utiliser ? Cet article explorera plusieurs recommandations pour sélectionner le bon langage de programmation pour les développeurs embarqués.

Recommandation #1 – Éviter les langues mortes ou mourantes

Au fil du temps, les langages de programmation perdent de leur popularité ; c’est inévitable. De nouvelles méthodes pour faire les choses sont inventées. De nouveaux langages sont inventés pour résoudre les problèmes de programmation de l’époque. Les langues autrefois couramment utilisées disparaissent et sont remplacées par quelque chose de nouveau. Un outil passionnant que j’aime pour suivre la popularité des langues est l’index TIOBE. L’indice TIOBE suit la popularité des langages de programmation dans l’industrie du logiciel depuis 2002. Je le mentionne parce qu’il s’agit de tous les langages, pas seulement des langages intégrés.

En examinant l’index, il est intéressant de voir le classement des différents langages utilisés dans les systèmes embarqués :

• Python (#1)
• C (#2)
• Java (#3)
• C++ (#4)
• Assemblage (#8)
• Matlab (#16)
• Rouille (#26)
• Vue de laboratoire (#41)

Notez que les langages d’assemblage sont les 8^e langages de programmation les plus populaires au monde ! Cependant, combien de personnes connaissez-vous qui écrivent activement des applications en langage assembleur ? Pour la plupart, les langages d’assemblage sont morts. Bien sûr, nous écrivons occasionnellement de l’assembleur pour optimiser certaines fonctions, mais nous n’écrivons pas quotidiennement du langage assembleur. Assurez-vous donc que vous sélectionnez une langue qui n’est pas déjà morte ou en train de disparaître.

Recommandation n ° 2 – Sélectionnez des langages orientés objet

Aujourd’hui, presque tous les systèmes peuvent être décrits dans une architecture orientée objet et pilotée par les données. Je crois que de nombreux systèmes embarqués tombent naturellement dans ce paradigme de conception, et il n’est pas nécessaire de torturer nos conceptions pour les y amener. Cependant, la sélection d’un langage de programmation prenant en charge les concepts de programmation orientés objet est essentielle pour créer des systèmes logiciels évolutifs et réutilisables.

Lorsque nous examinons notre liste de langages de programmation pour les systèmes embarqués, nous remarquons un léger problème avec nos cinq principaux langages ; C et l’assembleur ne sont pas des langages orientés objet ! Je dirais que c’est une des raisons pour lesquelles nous devrions considérer les deux comme des langues mortes ou mourantes. Ils ne fournissent pas l’ensemble d’outils modernes dont les développeurs ont besoin pour mettre en œuvre une architecture logicielle moderne. De plus, ces langages nécessitent beaucoup de travail supplémentaire pour obtenir des fonctionnalités qui sont naturellement intégrées dans d’autres langages.

Recommandation #3 – Utiliser uniquement des langages standardisés

Quelqu’un qui construit un produit commercial qui doit être maintenu et mis à jour au fil des ans ne devrait pas lancer les dés avec un langage qui n’est pas standardisé à moins qu’il ne puisse se permettre la dette technique associée à la mise à jour constante de son logiciel. Avant qu’un langage ne soit standardisé, comme Rust, la spécification du langage est en constante évolution. Cela change continuellement à mesure que le langage évolue et que les meilleures façons de faire les choses sont identifiées. Cela signifie que vous pouvez utiliser un compilateur et obtenir le résultat A, puis utiliser un autre compilateur et obtenir le résultat B. Même langage, résultats différents, tout cela parce que le langage n’est pas standardisé !

Aussi passionnant qu’un nouveau langage puisse être, il est logique d’utiliser un langage standardisé pour la plupart des entreprises. Je dirais qu’il est logique d’utiliser un langage avec des normes et de mettre activement à jour ces normes pour faire évoluer le langage et ses capacités. Une autre raison pour laquelle je pense que C est mort est que ses normes changent si lentement et que les améliorations apportées ressemblent davantage à des corrections de bogues qu’à des ajouts de fonctionnalités.

Des langages comme C++ sont une bonne option. C++ a une norme bien définie et la norme est mise à jour tous les trois ans. En conséquence, les développeurs disposent de nouvelles techniques et fonctionnalités pour améliorer leur logiciel, rendant le langage vivant. Il fournit également une norme cohérente afin que les équipes n’aient pas à assumer la dette technique du changement si elles ne le souhaitent pas. Au lieu de cela, ils continuent d’utiliser la version standard qu’ils ont adoptée.

Recommandation n ° 4 – Équilibrer le poids d’exécution des langues

Nous pourrions décider à partir des recommandations précédentes que Python, Java et C++ sont les langages embarqués de choix. Peut-être devrions-nous tous en manquer maintenant et commencer à convertir nos applications en Python ; Cependant, jusqu’à présent, nous n’avons pas encore discuté de toute l’histoire. Une considération critique pour les équipes est le poids d’exécution de leur langage.

Si vous deviez examiner C/C++, vous découvririez que la taille de code requise pour exécuter une application C est bien inférieure à un kilo-octet. La surcharge nécessaire à l’exécution du code est également négligeable, voire inexistante. C/C++ a un poids d’exécution léger. Si vous deviez examiner Python ou MicroPython, vous découvririez que ce n’est pas le cas. L’interpréteur MicroPython construit généralement entre 300 et 400 kilo-octets ! Les frais généraux pour exécuter l’interpréteur sont relativement légers, mais le poids de l’interpréteur est assez élevé.

Un temps d’exécution lourd peut ne pas être un gros problème si le coût de la mémoire est considéré comme bon marché ou non préoccupant. Dans ces circonstances, l’utilisation d’un langage comme MicroPython peut présenter de nombreux avantages. Par exemple, presque tout le monde connaît Python ou peut l’apprendre assez rapidement. De plus, il est adaptable et a plus de normes de codage que l’on ne pourrait jamais rêver. La mise à niveau du code d’application peut également être aussi rapide que la mise à jour de quelques modules de script.

Dans les deux cas, les équipes doivent examiner attentivement les frais généraux associés à la langue qu’elles choisissent. Par exemple, Python, Java, Labview et d’autres peuvent avoir un coût d’exécution plus élevé que d’autres langages.

Recommandation #5 – Utilisez le langage qui vous convient

En fin de compte, vous, l’équipe, devez décider quelles fonctionnalités et quelle langue correspondent le mieux à vos besoins. Par exemple, si toute l’industrie passe à Python, mais que le langage d’assemblage a plus de sens parce que vous fournissez des bibliothèques optimisées à la main, choisissez le langage d’assemblage. D’autre part, si vous avez un tas de code hérité écrit en C et que vous souhaitez continuer à tirer parti de cet actif déjà existant, utilisez C. (Ou encapsulez votre code C et utilisez C++ !).

Ne laissez pas les modes linguistiques de notre époque vous convaincre de changer. Au lieu de cela, utilisez ce qui a du sens et tenez compte des recommandations dont nous avons discuté dans cet article.

conclusion

Les développeurs et les équipes embarqués disposent d’un large choix de langages de programmation qu’ils peuvent utiliser pour développer leur logiciel embarqué. Les langages qu’ils choisiront dépendront du type de logiciel qu’ils écrivent, des besoins de leur entreprise et de la dette technique qu’ils contractent pour maintenir leur code. Lors de la sélection d’une langue à utiliser, les recommandations de cet article devraient fournir quelques réflexions supplémentaires à prendre en compte. C/C++, en particulier C++, peut être une excellente valeur par défaut en cas de doute.