Limites et inconvénients de Micropython ?

En toute honnêteté on devrait pouvoir trouver quelques limites ou problématiques liées à l'usage de Micropython. Nous essayions ici d'en dégager quelques unes.

Communication série "over USB" en mode "synchrone" préférentiel

Concrètement, avec Micropython, on perd la possibilité d'une communication série asynchrone "over USB" car la communication "over USB" est utilisée par l'interpréteur.

Pour dire les choses simplement, il faut choisir entre un mode "raw_repl" qui permet d'interagir avec l'interpréteur de la carte, y compris depuis un code, et un mode "série asynchrone" qui n'est fonctionnel qu'en émission et fait perdre l'interaction en mode interpréteur.

Plus exactement, c'ets possible avec certaines cartes, telle la Pyboard, mais en pratique, il est intéressant de communiquer avec la carte plutôt via "interpréteur" que via "série asynchrone", dans ce cas, on a une communication de type synchrone, la réponse de l'interpréteur étant liée à la commande envoyée.

Ceci fondamentalement, ne posera pas problème dans les situations où l'on a une communication série qui est en fait une synchrone : on pense notamment à une communication entre firmware et interface de type GUI CNC. Dans ce cas, la carte renvoie un accusé de réception qui est en fait un mode synchrone de fait.

A noter que plutôt que d'être vu comme une limite, le mode "synchrone préférentiel" pour communiquer avec une carte Micropython, notamment à partir d'une application système en Python, peut aussi être vue comme un avantage à certains points de vue, et du coup doit être vue comme une adaptation à opérer plutôt que comme une limite à proprement parler. Par exemple, la communication série est déjà gérée par l'utilitaire de communication avec la carte, et on n'a pas à le faire. Cette communication est de plus robuste et rapide (cf le mode interpréteur en mode manuel).

Ceci étant, le mode asynchrone est possible en émission facilement : il suffit d'utiliser un print() dans le code pour envoyer quelque chose sur le porte série, vers l'ordinateur donc.

Pour écrire vers la carte via le port série en asynchrone, c'est le plus compliqué, possible avec seulement certaines cartes, via une classe USB_VCP (Virtual Comm Port). Mais encore une fois, le mode "synchrone" est préférable dans ce cas.

Quelles solutions ?

La première est de renoncer au mode "asynchrone" pour basculer en mode "synchrone" = 1 requête, un réponse.

Si on a absolument besoin du mode "asynchrone", on a plusieurs possibilités :

• soit on fait cette communication sur un port UART (avec le Raspberry Pi par exemple) , la connexion directe étant possible entre une carte Micropython et le raspberry Pi. Noter que l'UART matérielle n'est pas la communication USB et par conséquent, on peut toujours communiquer avec l'interpréteur "over USB". Cela ouvre un champ de possibilités intéressant avec une double communication avec la carte Micropython : mode synchrone interpréteur via le port USB, asyncrone série via l'UART.

• soit on utilise un "pont", une application système Python qui réalise une communication synchrone avec la carte Micropython, mais renvoie uniquement les réponses de la carte Micropython de façon asynchrone sans attendre de requête. C'est une solution possible pour une Webapp qui monitorerai la carte Micropython par exemple. La webapp pourrait simplement envoyer au "pont" la vitesse de requête au Micropython.

Au final, cela va dépendre du besoin.

Consommation des cartes Micropython élevée versus consommation d'une carte micro-contrôleur plus light ?

En soi, la consommation n'est pas liée à Micropython mais plutôt à la carte elle-même, au microcontrôleur lui-même. Lorsque l'on passe de 16Mhz à 100Mhz et plus, on augmente d'un facteur équivalent la consommation énergétique en première approximation.

Typiquement, une carte Arduino UNO consommerait 1W environ (~200mA x 5V = 1W).

Une carte Pi pico est mesurée à 100mA de consommation avec cartes associées, ce qui le place dans la même catégorie de consommation, à savoir ~1W.