Vous n'avez pas besoin de différents appareils pour utiliser ces langues, vous avez juste besoin du système logiciel approprié.

Les principaux problèmes pour lesquels cela n'est pas fait plus souvent sont:

• Ces langages ont généralement besoin de plus de ressources (mémoire, exécution) pour la même tâche. Pour les gros volumes, l'effort réduit de programmation serait plus que compensé par des coûts matériels plus élevés.

• La plupart des langages de niveau supérieur nécessitent une allocation de mémoire dynamique avec garbage collection, ce qui est difficile à faire en temps réel.

• Il est plus difficile d'obtenir des développeurs intégrés pour ces langages.

Cela dit, il existe des éléments tels que Java en temps réel, qui sont utilisés dans les systèmes embarqués réels.

Il existe des projets open source travaillant sur de tels objectifs. Il existe un projet pour Ada sur les MCU Atmel (bien que je ne puisse pas le faire fonctionner). Un de mes collègues programme son MCU 68HC11 avec une version réduite de Ruby sur laquelle il travaille lui-même. Et il y a une société, BlueSpec, qui a un nouveau HDL pour FPGA / ASIC basé sur Haskell. Mais ce n'est pas un outil auquel la plupart auraient accès.

Les vendeurs ont tendance à s'en tenir à C car il y a un large public pour C et il est largement accepté. De même, pour les FPGA / PLD, VHDL / Verilog sont largement acceptés et éprouvés. Au lieu d'avoir à prendre en charge de nombreux langages différents, la plupart préfèrent se concentrer sur leurs puces, en essayant d'améliorer les performances de leurs compilateurs C et d'offrir de meilleurs outils pour configurer et gérer les ressources sur leurs puces. Je suis en quelque sorte d'accord avec cette approche moi-même. Je préfère de loin que Texas Instruments améliore ses outils de configuration de périphériques avancés sur ses puces plutôt que d'implémenter une métaprogrammation avancée de modèles sur son compilateur C ++ minimal.

Vous êtes gracié.

La raison pour laquelle C, et moins C ++, (parmi d'autres langages comme VHDL) est utilisé pour ces types de périphériques est qu'il est facile de traduire les constructions de langage vers le matériel sous-jacent. C est considéré comme lingua franca, compris par beaucoup et pour porter un nouveau langage sur le périphérique, surtout si la lecture / écriture dans les registres est délicate, ne vaut pas la peine si le langage n'est pas beaucoup mieux pour exprimer des constructions utiles.

Les exemples que vous utilisez en tant que langages plus récents et plus brillants, D, par exemple, pourraient être un candidat pour un langage "de bas niveau" si plus de programmeurs l'utilisent. D est présenté comme un C ++ moderne sans tout compromis avec C et implémenté dès le début. Malheureusement sans toutes les bibliothèques C ++. Je pense que vous pouvez appeler des bibliothèques C depuis D.

La question n'est pas de savoir si c'est plus récent, la question est de savoir si ce sont de meilleurs outils. Pour autant que je sache, ce n'est pas le cas.
modifier
Quand j'ai écrit du code intégré (en C), j'ai souhaité de meilleures macros / modèles que C offre. Comme il s'agit d'une construction au moment de la compilation, cela n'a vraiment rien à voir avec le matériel sous-jacent. Mais beaucoup plus compliqué à implémenter dans un compilateur.

Les appareils ont été conçus pour utiliser efficacement d'autres langages, tels que LISP / Scheme, Forth et Java. Je ne crois pas qu'aucun d'entre eux ait été conçu pour les langages que vous avez mentionnés, peut-être qu'ils ne conviennent pas aux systèmes embarqués (à part D qui devrait fonctionner efficacement sur tout ce qui est conçu pour C / C ++). Ils pourraient vraisemblablement être implémentés sur n'importe quel MCU approprié, si quelqu'un le souhaite.

Il y a toujours netduino, qui vous permet de coder en .NET.

Jetez un œil à Micro Python http://micropython.org/

Micro Python est une implémentation légère et rapide du langage de programmation Python 3 qui est optimisé pour fonctionner sur un microcontrôleur. La carte Micro Python est une petite carte électronique qui exécute le langage Micro Python.

Elle a été financée avec succès en tant que projet kickstarter en décembre 2013 et ils ont un tableau de référence.

Vous recherchez un microprocesseur. Intel les vend, tout comme AMD et ARM. Vous pouvez utiliser n'importe quelle langue de programmation sur ces appareils.

Quant aux FPGA: votre choix de langues est limité. C'est parce que vous avez besoin d'un outil de synthèse qui traduira votre code en netlist. En plus de VHDL, Verilog et (C restreint), vous pouvez utiliser des langages plus modernes comme MyHDL (construit sur Python) ou Bluespec (semblable à Haskell).

Premièrement, vos exemples sont de petits appareils qui ont un ensemble limité de ressources, puis les anciens langages qui sont proches du matériel comme c et vhdl font bien le travail.

Les nouveaux langages "cool" ont besoin de plus ressources pour bien fonctionner, donc je suppose que ce que vous cherchez viendra très bientôt puisque le MCU devient de plus en plus puissant avec le temps.

Mon point est que la plupart des MCU: s sont toujours programmés en C, et le gars cool vient juste de commencer à jouer avec C ++ sur ces appareils.

Mais si vous jetez un œil au MCU 32 bits basé sur ARM qui a beaucoup plus de ressources que les anciens 8 bits vous peut trouver un projet fou comme eLua, qui essaie d'exécuter le langage de script lua sur un mcu basé sur Cortex-M3 ...

Donc, nous y arriverons, mais il va Et je ne pense pas qu'aucun de ces projets fous ne soit (encore) prêt pour une utilisation en production, mais certains le seront car il est plus rapide de se développer dans des langages avec un niveau d'abstraction plus élevé.

Il existe une application de preuve de concept fonctionnant sous Rust sur les microcontrôleurs ARM STM32F4xx. Les modifications étonnamment mineures nécessaires pour porter Rust sont disponibles dans ce fork de Rust.