L’une des plus belles commodités des langages de programmation interprétés est que vous pouvez tester le code que vous développez dans un shell, une ligne à la fois, et voir les résultats instantanément. Quelle que soit la rapidité avec laquelle votre cycle d’écriture-compilation-flash a atteint le microcontrôleur de votre choix, c’est toujours moins amusant que d’écrire blink_led() et le faire faire sur-le-champ. Pourquoi n’avons-nous pas encore cette expérience?

Si vous avez utilisé un langage de script moderne sur votre gros ordinateur, il est livré avec un shell, une boucle read-eval-print (REPL) dans laquelle vous pouvez essayer interactivement votre code à peu près aussi vite que vous pouvez le taper. C’est idéal pour la programmation interactive ou exploratoire, et c’est idéal pour les débutants qui peuvent tester et apprendre les choses étape par étape. Un bon REPL vous permet de tester vos idées ligne par ligne, en exécutant essentiellement un petit test de votre code chaque fois que vous appuyez sur Entrée.

Ceci est votre environnement de développement

Le compromis évident pour la facilité de développement est la rapidité. Les langages compilés sont presque toujours plus rapides, ce qui est particulièrement pertinent dans le monde contraint des microcontrôleurs. Ou peut-être que c’était le cas. J’ai appris à programmer dans un langage interprété – BASIC – sur des ordinateurs qui n’étaient pas beaucoup plus puissants qu’un microcontrôleur à 5 $ ces jours-ci, et il y a un BASIC pour presque tous les micro. J’écris en Forth, qui est plus rapide et moins gourmand en ressources que BASIC, et a une REPL très complète, mais c’est certes un goût acquis. MicroPython a été porté sur un certain nombre de micros et est probablement beaucoup plus familier.

Mais quand même, développer MicroPython pour votre microcontrôleur ne se développe pas sur votre microcontrôleur, et si vous suivez l’un des guides disponibles, vous finirez par éditer un fichier sur votre ordinateur, le télécharger sur le microcontrôleur et l’exécuter depuis le REPL. Cela crée un flux à peu près aussi gênant que le cycle d’écriture-compilation-flash de C.

Qu’est-ce qui manque? Un bon éditeur (ou IDE?) Fonctionnant sur le microcontrôleur qui vous permettrait à la fois de faire votre codage exploratoire et d’enregistrer son histoire sous une forme plus permanente. Imaginez, par exemple, un IDE MicroPython basé sur le Web servi à partir d’un ESP32, qui fournissait à la fois un shell pour les expériences et un moyen de copier la ligne que vous venez de taper dans le shell dans le fichier sur lequel vous travaillez. Nous sommes très proches du fait que cette idée est viable, et cela réduirait à presque rien les obstacles d’introduction pour les débutants, tout en laissant jouer les programmeurs expérimentés.

Ou quelqu’un a-t-il déjà fait cela? Pourquoi une introduction interprétée aux microcontrôleurs n’est-elle pas la norme?

LAISSER UN COMMENTAIRE

Rédigez votre commentaire !
Entrez votre nom ici