Utilisez le bon outil pour le travail: programmation intégrée

Le plus souvent dans les systèmes embarqués, le langage dans lequel vous programmez est déterminé par le compilateur réellement disponible.
Si votre matériel n'a qu'un compilateur C, c'est ce que vous allez utiliser. S'il a un compilateur C++ décent, il n'y a vraiment aucune raison de préférer C à C++.
J'oserais dire que Java n'est pas un choix très populaire dans les systèmes embarqués.

La programmation embarquée couvre aujourd'hui un large éventail d'applications.
En gros, cela va des capteurs / commutateurs aux systèmes de sécurité complets.
Vous devez baser votre langue sur la complexité et les ressources matérielles.
Il est 1 des choix à côté de HW (CPU,...), OS, protocoles,...
choix possibles:

• commutateurs: assembleur
• périphériques de type routeur: C et / ou C++
• ordinateurs de poche: Java ou QT / C++
• systèmes complets: combinaisons C et / ou C++ avec python

Ou C++ n'est-il OK que si certaines fonctionnalités du langage (par exemple RTTI, exceptions et modèles) sont exclues?

Il est bon de penser dans ce sens. La complexité à la compilation n'est pas un gros problème, mais la complexité de l'exécution a un coût en ressources.

C++ facilite la modularité des classes/espaces de noms (par exemple la méthode foo() dans plus d'un contexte) et la modularité des instances (champ membre bar appartenant à plus d'un objet), qui sont tous deux un gros avantage dans la conception logicielle. Il existe également des fonctionnalités telles que const, des références, des moulages statiques et des modèles, qui peuvent aider à appliquer des contraintes et avoir peu ou pas de coût d'exécution.

Je voudrais pas exclure modèles. Ils sont complexes à penser et vous avez besoin d'un compilateur qui les gère bien , mais le coût des ressources est presque tout le temps de compilation what ce qui va vous "coûter", c'est le fait que chaque fois que vous utilisez un modèle avec des paramètres de classe différents, vous produisez un nouvel ensemble de code à instancier les fonctions de membres. Mais vous auriez presque certainement à faire la même chose sans modèles. En outre, les modèles vous permettent de concevoir et de tester des bibliothèques pour des circonstances générales, dans des fichiers séparés qui sont instanciés au moment de la compilation plutôt qu'au moment du lien. Juste pour clarifier cela: les modèles vous permettent d'avoir un fichier A. h que vous testez. Ensuite, vous l'utilisez avec le fichier B. h ou B. c pour l'instancier au moment de la compilation. (Une bibliothèque serait liée plutôt que compilée, ce qui la rend moins flexible -- les méthodes de modèle peuvent être optimisées afin qu'elles n'entraînent pas d'appel de fonction.) J'ai utilisé des modèles dans les systèmes embarqués pour implémenter du code CRC et des mathématiques à point fixe: je peux tester le code général, le mettre dans le contrôle de version, puis le réutiliser plusieurs fois en écrivant une classe simple qui dérive d'un modèle ou a un champ membre du modèle. L'exemple classique est bien sûr STL.

RTTI et exceptions : elles ajoutent de la complexité à l'exécution. Je n'ai pas une bonne idée du coût des ressources mais je m'attends à ce que RTTI soit assez simple (ajoute simplement une balise de type, coûtant de l'espace supplémentaire) alors que les exceptions sont probablement bestiales, impliquant le déroulement de la pile.

Fonctions virtuelles : J'avais l'habitude de les exclure en raison des coûts mémoire + temps d'exécution (minimes mais toujours là), ainsi que de la complexité du débogage, mais ils vous permettent de découpler les objets les uns des autres. Si vous n'utilisez pas de fonctions virtuelles, lorsqu'une instance d'une classe (par exemple Foo) doit exécuter du code associé avec une instance d'une autre classe (par exemple Bar), la première classe doit tout savoir sur la seconde (pour compiler Foo, vous devez avoir une liaison statique à toutes les méthodes de Bar) - cela ajoute beaucoup de couplage serré.

Allocation de mémoire dynamique: c'est une autre grande chose (qui est également en C), que nous évitons comme la peste dans mon entreprise not non seulement il y a toutes sortes d'erreurs qui peuvent survenir , mais le gros coût d'exécution est l'allocateur/ désallocateur,et vous devez soyez prêt et capable de savoir quel est ce coût et de l'accepter.

Edit: Je voudrais aimer utiliser Java au lieu de C++ dans le monde intégré. Malheureusement, mes choix sont limités et les coûts des ressources d'exécution (taille du code, taille de la mémoire, contraintes de temps de collecte des ordures) sont trop élevés dans l'espace dans lequel je travaille. Ma raison d'utiliser Java est moins à cause de ses goodies d'exécution et plus pour le fait que sa conception logicielle est beaucoup plus propre, et les outils sont beaucoup mieux (OMG! refactoring! woohoo!)... la clé pour moi semble résider dans deux choses, qui rendent C / C++ très maladroit en comparaison:

1. Que tout est un objet et que toutes les méthodes sont virtuelles, vous pouvez donc vous appuyer fortement sur les abstractions des interfaces.

2. La séparation interface/implémentation en Java n'est pas cette chose maladroite et laide .c/.h qui rend les compilateurs si lents. En constrast, j'utilise Java dans Eclipse et il compile automatiquement le code juste comme je le modifie. C'est énorme! Je trouve la plupart de mes erreurs tout de suite. En C / C++, je dois attendre tout un cycle de compilation.

Un jour, j'espère qu'il y aura un langage entre C/C++ et Java qui offre les avantages de Java pour le développement de logiciels, sans nécessiter les cloches et les sifflets qui rendent Java si attrayant pour les applications de bureau/serveur mais peu attrayant dans la plupart du monde embarqué.

C et C++ peuvent être utilisés sur les systèmes embarqués. Si vous limitez les fonctionnalités de C++ que vous utilisez, il utilisera à peu près la même vitesse et l'espace que C. Quant à l'utilisation de ces fonctionnalités supplémentaires, cela dépend vraiment de vos contraintes. Par exemple, si vous créez un système temps réel, les exceptions peuvent ne pas être une bonne idée, simplement parce que la prise en compte du temps de propagation des exceptions et de tous les chemins par lesquels les exceptions peuvent éventuellement se propager peut rendre le temps réel difficile garanties assez difficiles (bien que, là encore, l'implémentation ACE / Tao en temps réel CORBA utilise des exceptions). Alors que les modèles et RTTI peuvent conduire à des programmes plus importants, il y a beaucoup de variabilité dans les systèmes embarqués, et donc en fonction de vos contraintes de ressources, cela peut être parfaitement correct ou inacceptable. La même chose vaut pour Java. Java (enfin, techniquement, le langage de programmation Java avec un sous-ensemble de l'API Java) fonctionne sur Android, par exemple, en utilisant la machine virtuelle Dalvik. J2ME fonctionne sur une variété de dispositifs embarqués. Que cela fonctionne ou non pour votre application, dépend de vos contraintes particulières.

C est le langage le plus utilisé dans les systèmes embarqués.

Cependant, je pense que l'avenir de C++réside dans le domaine du système embarqué. Je pense que les normes C++0x aideront à cette résolution. Je ne serais donc pas surpris de voir C++ utilisé beaucoup plus dans ce domaine.

Je pense que vous avez déjà une excellente réponse de Clifford, mais je vais y ajouter mon expérience. Comme l'a souligné, le type de système embarqué est le principal moteur. En Défense / Aérospatiale, C et Ada sont les langages embarqués les plus populaires que je rencontre. Bien qu'au fil du temps, je vois plus de C++ à mesure que le développement basé sur un modèle devient populaire avec des outils tels que Rhapsody. Dans la liste des emplois, voir les exigences pour l'expérience de conception orientée objet me porte également à croire que le marché est se déplaçant lentement pour suivre les tendances du développement traditionnel.

Si vous êtes vraiment intéressé par le développement embarqué, je commencerais par C. C'est assez universel. Presque tous les systèmes d'exploitation, y compris les systèmes d'exploitation en temps réel tels que Integrity, Nucleus, VxWorks et embedded Linux, ont un compilateur et des outils pour cela. Les choses que vous apprendrez sur les pointeurs, la gestion de la mémoire, etc... se traduira bien dans le développement C++ dans le monde embarqué au moins.

Comme pour Java, si vous êtes intéressé par de développement pour les plateformes mobiles comme les téléphones intelligents, c'est un choix solide (Android vient à l'esprit). Mais dans le monde des Systèmes d'exploitation en Temps Réel, je ne l'ai pas vu.

Sur cette note, cela m'amène à mon dernier point et conseil. Si je voulais me lancer dans la programmation intégrée (ce que j'ai fait il y a seulement 4 ans), je me concentrerais sur l'apprentissage du C d'un point de vue de bas niveau comme mentionné ci-dessus. Ensuite, j'apprendrais aussi ce qui rend la programmation en temps réel si difficile/différente. J'ai trouvé le livre ci-dessous assez bon pour vous apprendre à penser comme un programmeur intégré par rapport à un développeur d'applications. Bonne chance!

Une amorce de logiciel embarqué

Cela se résume vraiment à la plate-forme matérielle sur laquelle vous opérez et donc aux plates-formes logicielles qui vous sont ouvertes. Pour beaucoup de kit intégré récent-conçu autour d'un système sur puce, un mégaoctet ou deux de RAM, quelques appareils-vous voulez vraiment un petit système d'exploitation pour gérer le matériel de bas niveau pendant que vous vous concentrez sur votre application. Votre choix de système d'exploitation limite alors votre jeu de langues disponible.

Il est certainement possible d'utiliser C++ dans l'espace intégré, mais le plein ensemble de fonctionnalités de la langue prend beaucoup de travail pour porter correctement. Par exemple, eCos est implémenté dans un mélange de C et de ce que vous pourriez appeler les aspects structurels de C++; le support de RTTI, les exceptions et le STL font défaut dans la version gratuite, bien qu'il y ait des gens qui travaillent dessus (et un port commercial disponible).

De même, il est possible d'utiliser Java - je sais, j'ai porté une JVM vers un environnement intégré; ce n'était pas amusant-bien que vous obteniez généralement un Java réduit configuration de la langue, souvent quelque chose basé sur J2ME.