MicroPython : Python pour les microcontrôleurs

Une implémentation de Python pour l'embarqué

a marqué ce sujet comme résolu.

Tout le monde se secoue ! :D

J’ai commencé (mercredi 06 novembre 2019 à 19h31) la rédaction d’un article au doux nom de « MicroPython : Python pour les microcontrôleurs » et j’ai pour objectif de proposer en validation un texte aux petits oignons. Je fais donc appel à votre bonté sans limites pour dénicher le moindre pépin, que ce soit à propos du fond ou de la forme. Vous pourrez consulter la bêta à votre guise à l’adresse suivante :

Merci !


J’ai quelque chose d’assez abouti, j’aimerai des retours sur tout (fond, forme, orthographe, style, etc.) avant d’envoyer en validation.

+2 -0

Salut!

Vachement intéressant comme article! Ça m’a permis d’apprendre l’existence du micro python!
Sur le fond, je n’ai rien à redire (mais je ne suis pas expert en python, donc si ya des approximation bancales, je n’y verrais que du feu^^).
Sur la forme, j’aurais deux remarques:

  • A la fin du paragraphe "Du véritable Python adapté pour les microcontrôleurs":

    On peut également écrire de l’assembleur inline dans un script, pour accéder aux fonctionnalités au plus bas niveau.

    Je trouve la formulation de la deuxième partie de la phrase étrange. Je ne sais pas comment l’exprimer, mais pour moi elle "sonne bizarrement" je verrais plutôt "aux fonctionnalités de plus bas niveaux". Je ne sais pas si je suis le seul à ressentir ça (auquel cas, c’est probablement ne impression fausse).

  • Au début du paragraphe "Cartes « officielles »":

    de DAC et ADC, des contrôleurs CAN

    je pense que ça serait bien de mettre la signification des ces sigles (ça permet de savoir qui rechercher pour avoir plus d’infos et d’éviter de trier parmi plusieurs utilisations du sigle).

A part ça, je trouve que tu explique ben les choses (assez pour que ce soit claire pour un non expert comme moi) et je n’ai pas vue de fautes d’orthographe (mais je ne suis pas une référence dans le domaine …)

Super article !

Par contre j’ai l’impression que sur l’aspect technique il manque un tout petit peu de matière.

Par exemple, le programme finale est-il compilé d’une manière ou d’une autre ou faut-il installer un interpréteur python sur la carte ? Quel impact cela a t il sur le chargement du programme dans ce dernier cas ? Existe t’il une liste de "minimal requirements" pour prédire si une carte pourrait avoir un support uPython ?

Mais vraiment bon article d’introduction. Ça fait un moment que j’avais vu ça, faudrait que je test sur un esp8266 pour voir ce que ça donne !!

+1 -0

Par exemple, le programme finale est-il compilé d’une manière ou d’une autre ou faut-il installer un interpréteur python sur la carte ? Quel impact cela a t il sur le chargement du programme dans ce dernier cas ? Existe t’il une liste de "minimal requirements" pour prédire si une carte pourrait avoir un support uPython ?

Eskimon

Concrètement, c’est comme le Python normal : tu as un interpréteur qui tourne sur la carte. Il y a aussi la possibilité de précompiler vers du bytecode, mais je n’ai pas exploré la question.

Je ne connais pas les exigences minimales. Il me semble que les ports ajustent pas mal de choses et qu’il y a des options de compilation pour régler aux petits oignons.

Qu’est-ce que tu veux dire par « impact sur le chargement du programme » ? Sur la pyboard (je ne connais pas les autres), l’interpréteur démarre avec la carte, lis un fichier boot.py, configure des choses, puis lance main.py où tu fais ce que tu veux.

+0 -0

Pour le chargement du programme oui je faisais référence a l’aspect "fichier a envoyer dans la carte". La procédure est elle plus complexe ? Par exemple, d’ordinaire j’envoie simplement un .bin ou .hex et tout roule, le bootloader your ça c’est "prémaché".

Aussi, as tu des benchmarks comparatifs entre un programme "conventionnel" et un en upython ?

+0 -0

Pour le chargement du programme oui je faisais référence a l’aspect "fichier a envoyer dans la carte". La procédure est elle plus complexe ? Par exemple, d’ordinaire j’envoie simplement un .bin ou .hex et tout roule, le bootloader your ça c’est "prémaché".

La pyboard sait se connecter comme un stockage USB et tu copies tes fichiers dessus et c’est fini. J’aurai donc tendance à dire que c’est plus simple.

Alternativement, il y a aussi la possibilité de transférer des fichiers sur USB en mode liaison série (ce qui revient au même à la fin).

Aussi, as tu des benchmarks comparatifs entre un programme "conventionnel" et un en upython ?

Non, je n’ai rien. À mon avis, ce sera nécessairement moins bien que du compilé directement pour la cible, au moins au niveau énergétique, si tu n’es pas limité par le temps.

Ce sujet est verrouillé.