machine virtuelleIS2T, fabricant français de plateformes Java, annonce MicroEJ®, la première plateforme Java du marché prenant en charge le développement et l'intégration de fonctionnalités Java pour les applications C et C++ économiques et à faible consommation de mémoire, exécutées sur des microcontrôleurs Cortex-M.
MicroEJ offre une plateforme d'exécution Java comprenant la machine virtuelle Java MicroJvm® d'IS2T (28 Ko), un système d'exploitation temps réel (RTOS) optionnel (~10 Ko), toutes les bibliothèques nécessaires à l'exécution d'une interface homme-machine (IHM) graphique avancée, ainsi qu'une plateforme de code binaire entièrement déboguée et testée, prête à être transférée directement sur tout microcontrôleur compatible. La machine virtuelle Java MicroJvm d'IS2T ne requiert que 28 Ko de mémoire flash, moins de 1,5 Ko de RAM et son temps de démarrage est de seulement 2 ms à 120 MHz. Une IHM graphique avancée et pleinement fonctionnelle nécessite entre 90 et 140 Ko de mémoire programme.


Apparu en 1995, Java s'est imposé depuis longtemps comme la plateforme de prédilection pour les interfaces graphiques (GUI), l'Internet des objets (IoT), les architectures orientées services (SOA), les applications web et les applications mobiles. Java se compose de deux éléments : le langage Java orienté objet et un jeu d'instructions 32 bits (204) incluant un gestionnaire de modèle de mémoire. La programmation orientée objet et la machine virtuelle Java (JVM) autonome offrent une portabilité et une évolutivité de type « programmer une fois, exécuter partout », permettant aux ingénieurs de mieux gérer la complexité logicielle et de découpler les cycles de développement matériel et logiciel grâce à la virtualisation et à la simulation.


Avant les plateformes MicroEJ, une plateforme Java classique pesait 5 Mo et nécessitait une puissance de traitement d'au moins 400 MHz, la rendant inadaptée aux systèmes embarqués aux ressources limitées. Les ingénieurs embarqués qui devaient implémenter des IHM avancées étaient contraints d'utiliser des processeurs externes onéreux, des processeurs d'interface graphique externes complexes et des outils de développement générant des applications gourmandes en mémoire. Ils devaient également tenter de traduire directement les composants graphiques en routines C standard, ce qui pouvait compromettre la fiabilité, les performances et la maintenabilité du système.


MachineVirtuelle1.tiffPlateformes MicroEJ Java embarquées et simulées (JPF) identiques : la plateforme MicroEJ JPF embarquée inclut la machine virtuelle MicroJVM, des bibliothèques standard telles que B-ON+ CLDC (interface de programmation d'applications Java de base – API embarquée), MicroUI® (interface utilisateur embarquée), MWT (environnement de widgets embarqué), NLS (National Embedded Support), un décodeur d'images PNG fonctionnel et des outils graphiques pour la conception de polices, de panneaux frontaux et de storyboards. MicroEJ peut fonctionner sans système d'exploitation temps réel (RTOS) ou avec n'importe quel RTOS, notamment uOS de Micrium, RTX de Keil ou EmbOS de Segger. La carte prend en charge des packages qui seront disponibles pour diverses cartes d'évaluation spécifiques à différents fournisseurs.


Le simulateur JPF de MicroEJ offre une simulation complète des plateformes Java embarquées grâce à ses options extensibles d'objets simulés (matériels ou logiciels). Il permet ainsi une simulation exhaustive du matériel cible, qui peut exploiter des interfaces spécialisées telles que des capteurs, des actionneurs et des liaisons de communication spécifiques. Les applications peuvent être prototypées en Java et testées sur une plateforme simulée, indépendamment du dispositif physique. Ceci évite les modifications de code liées à la disponibilité du matériel ou les phases d'intégration complexes lors du déploiement. Une fois le prototype validé, la conception peut se poursuivre en Java jusqu'à ce que l'application soit entièrement testée à l'aide de l'infrastructure de test fournie par la plateforme simulée et le SDK MicroEJ. Enfin, l'application peut être déployée sur la cible via JTAG ou d'autres systèmes de programmation embarqués.


Ces plateformes simulées utilisent les mêmes bibliothèques logicielles, fournissent les mêmes schémas de programmation et les mêmes modèles de mémoire afin que les ingénieurs sachent exactement quelle quantité de mémoire sera nécessaire pour l'application et puissent choisir le microcontrôleur (MCU) le plus rentable.


Interface simplifiée pour le C existant : les pilotes C/ASM et la logique applicative existants peuvent être facilement intégrés à la plateforme Micro EJ JPF, rendant ainsi le nouveau code Java accessible tout en préservant le code C existant. La bibliothèque d'interface SNI native permet d'appeler directement des fonctions C depuis Java et des méthodes Java depuis C, y compris des arguments de types de base tels que les entiers, les flottants et les tableaux. SNI permet un échange de données très efficace entre ces deux environnements, évitant les tampons intermédiaires et les copies de tampon inutiles (notez que les périphériques DMA peuvent également partager des données à l'aide d'une implémentation de tampon)


Pour le découplage des données et les tâches plus avancées, les développeurs peuvent utiliser l'interface ShieldedPlug. Basée sur un mécanisme de publication/abonnement avec un système d'événements, ShieldedPlug assure un découplage spatial et temporel entre les
environnements C et Java.

Pour plus d'informations ou un devis