Est-il possible d'écrire du code en C ++ pour les microcontrôleurs PIC à l'avenir?

Est-il possible d'utiliser C ++ pour coder des PIC? Y a-t-il des limitations matérielles qui nous empêchent d'utiliser C ++? Quelle est la taille du fichier .hex généré et la durée d'exécution du programme lorsque nous utilisons C ++ au lieu de C? Est-il pratiquement possible d'utiliser C ++ pour les PIC actuels? Y a-t-il des plans futurs ou des développements en cours à ce sujet?

Est-il possible d'utiliser C ++ pour coder des PIC?

Oui, c'est possible maintenant. Pour dsPIC, il existe le compilateur IAR Systems C ++ (bien qu'il soit très ancien et non pris en charge).

Une autre option consiste à utiliser un convertisseur C ++ vers C. À l'aide d'une étape de pré-génération, convertissez le C ++ en C, puis donnez le (méchant) C à votre compilateur C normal. Jetez un oeil à LLVM ou au compilateur C ++ de Comeau qui font tous les deux cela. Comeau ne coûte que 50 $, mais il faudra probablement un certain effort pour que la chaîne d'outils et les bibliothèques fonctionnent correctement.

Y a-t-il des limitations matérielles qui nous empêchent d'utiliser C ++?

Réponse courte, non, il n'y a pas de limitations matérielles. Réponse longue, C ++ encourage certainement l'utilisation d'un tas et / ou d'une pile, avec laquelle les plus petits MCU avec une RAM limitée auront du mal.

Pourquoi ont-ils du mal avec un tas / pile? Pour deux raisons: A) de nombreux MCU ont une mémoire RAM limitée, pas assez pour un tas certainement, et à peine assez pour une pile. B) de nombreux MCU ne gèrent pas bien les pointeurs, donc l'utilisation de variables sur la pile tue vraiment les performances.

Quand les gens demandent à propos de l'utilisation de C ++ sur un MCU, je trouve constructif de comparer C ++ à C. Les mêmes questions précises ont été (et sont toujours) posées à propos de C sur un MCU. Les gens rechignaient à l'idée. Un langage de haut niveau, sur 256 octets de RAM MCU ?? Impossible. Mais maintenant, nous savons tous que c'est possible. J'ai écrit C pour un PIC12. Aucun problème. C'est possible car A) les développeurs de logiciels savent qu'ils doivent être un peu prudents: n'utilisez pas malloc () etc. et B) le compilateur a été écrit spécialement pour le MCU. Le compilateur sera également très prudent avec l'allocation de mémoire, il n'essaiera pas de créer un tas et ne créera pas de pile. Certains compilateurs C ne vous permettent tout simplement pas d'écrire du code rentrant (récursif) qui nécessite absolument une pile.

Sachant qu'il est possible d'écrire C pour un MCU, les mêmes réponses s'appliquent à la question de l'écriture C ++ sur un MCU. Tant que le compilateur comprend les limites du périphérique cible et que l'utilisateur comprend également la langue, il n'y a vraiment aucun problème. En C ++, vous ne payez que ce que vous utilisez. Il est parfaitement possible d'écrire C ++ (avec des objets et tout) qui produit la sortie asm exacte que vous auriez obtenue si vous aviez utilisé C.

Désormais, les PIC32 peuvent certainement faire face au C ++. Ils ont jusqu'à 64 Ko de RAM et sont basés sur le noyau MIPS, qui est un processeur 32 bits correctement développé. Il peut gérer des pointeurs et une pile ainsi qu'un PC. En effet, il existe des PC basés sur le MIPS (ou du moins, il y en avait).

Malheureusement, il y a tellement de malentendus autour de C ++. Même les codeurs très expérimentés semblent n'avoir aucune idée du fonctionnement du langage. Voir ma réponse sur pourquoi C ++ convient aux processeurs intégrés.

Quelle est la taille du fichier .hex généré et la durée d'exécution du programme lorsque nous utilisons C ++ au lieu de C?

Comme je l'ai dit, il n'y a peut-être pas de différence. Bjarne Stroustrup a fait une comparaison d'un tas de compilateurs C / C ++ pour comparer les performances de temps et d'espace pour un certain nombre d'opérations. Les résultats variaient considérablement. Dans certains cas, le C ++ est sorti plus lentement et plus grand, certains cas plus lent et plus petit, ou plus rapide et plus grand, et encore plus rapide et plus petit! Donc, la réponse à votre question est que cela dépend fortement du compilateur, mais en général, cela ne doit faire aucune différence. Pour plus de détails, voir le rapport technique sur les performances C ++

Y a-t-il des plans futurs ou des développements en cours à ce sujet?

Ça je ne sais pas. Je sais que le compilateur Microchip C32 est open source, et vous pouvez télécharger la source. Je sais également que quelqu'un avec qui j'ai travaillé a trouvé des instructions en ligne et a réussi à faire compiler du code C ++ par le compilateur. Mais il a quitté l'entreprise avant de pouvoir me mettre en place avec une chaîne d'outils appropriée.

MISE À JOUR

Microchip dispose désormais d'un compilateur C ++ disponible pour sa gamme PIC32 de microcontrôleurs intégrés.

Quelle est la taille du fichier .hex généré et la durée d'exécution du programme lorsque nous utilisons C ++ au lieu de C?

Cela dépend des fonctionnalités que vous utilisez. Si vous utilisez les principales fonctionnalités orientées objet (classe + méthodes), cela n'aura probablement que très peu d'effet (les noms de variable / fonction modifiés plus longtemps, la table des symboles augmentera probablement quelque peu). Les modèles ne devraient pas non plus ajouter grand-chose avec un bon compilateur.

Si vous devenez fou et tirez des choses comme la bibliothèque de modèles standard, et utilisez l'allocation de mémoire dynamique et les exceptions, vous risquez de tomber dans du code.

Il existe déjà des compilateurs c ++ pour pic, par exemple http://www.sourceboost.com/Products/BoostCpp/Overview.html

Je ne l'ai pas utilisé et je ne sais rien d'autre que ça ...

Pour généraliser quelque peu votre question, il existe des processeurs ARM conçus pour le marché embarqué qui contiennent une MMU (unité de gestion de la mémoire). La taille et l'allocation de la mémoire ont rendu les langages tels que java et c ++ mauvais choix intégrés. Alors que les processeurs intégrés continuent de devenir plus rapides et plus puissants, et que la mémoire devient plus dense et moins chère, les choix de langue disponibles pour les ingénieurs embarqués changent considérablement. Un processeur ARM 32 bits 600 MHz avec MMU et une carte Flash 64G est un excellent candidat pour les applications c ++. Qu'il corresponde à la définition du processeur embarqué classique est un autre problème.

Probablement oui .. mais vous ne devriez pas quand même ... C est le langage de l'embedded et il n'y a aucun avantage à utiliser C ++. Ou plutôt, les avantages de C l'emportent de loin sur les avantages de C ++ pour l'embarqué. Ne perdez pas votre temps.

• si vous savez utiliser des pointeurs de fonction, etc. Vous pouvez coder comme C ++, il n'y a pas de problème là-bas.