[Bêta] PythonExtra.
Posté le 29/10/2022 09:49
PythonExtra est un add-in Python alternatif pour (à ce stade) Graph 35+E II, Prizm et Graph 90+E. L'objectif est de fournir plus de fonctionnalités : modules standard,
getkey(), fonctions de dessin plus performantes, etc.
Version Bêta 0.2
Graph 35+E II / 
Prizm / 
Graph 90+E : PythonExtra-pe-0.2.0-beta.zip
Aperçu de PythonExtra sur Graph 90+E. (Cliquez pour agrandir)
Description sommaire des fonctionnalités :
- Compile pour Graph 90+E (fx-CG 10/20/50) et Graph 35+E II (fx-9860G III)
- Peu de RAM sur Graph 35+E II (c'est difficile d'en trouver sur ce modèle)
- Un shell pas trop mal (saisie rapide, scrolling) avec de bonnes performances
- Plein de modules standard
- array, builtins, cmath, collections, io, math, random, struct, sys, time
- Le module spécifique CASIO : casioplot (fidèle à part sur les polices)
- Un nouveau module gint avec les fonctionnalités avancées de gint :
- Pour l'instant, une bonne partie de <gint/display.h> et <gint/keyboard.h>
- Donc getkey() (attente de touche) ainsi que keydown() (test instantané) !
- Et des fonctions de dessin rapides comme dline() ou drect()
Le plan actuel :
- Être sensiblement compatible avec l'appli Python officielle.
- Pousser les fonctionnalités ajoutées pour vraiment relever le niveau de Python !
- Si du temps de développement se débloque : support autres Graph mono (pas de promesses).
Updates et screenshots à venir. Je n'ai pas l'intention d'implémenter un million de fonctionnalités, juste ce qu'il faut pour s'assurer que ça ne finisse pas mal documenté et non maintenu comme CasioPython.
Dépôt Git :
https://gitea.planet-casio.com/Lephenixnoir/PythonExtra
PythonExtra est notamment possible grâce à l'aide précieuse de
Mb88.
Comparaison directe
Dans l'exemple ci-dessous (
réalisé par Mb88), un Flappy Bird déjà bien optimisé (dessin partiel etc, à gauche) est accéléré un bon gros coup en utilisant PythonExtra et le module
gint pour le dessin (à droite).
Contexte historique
Aux
journées APMEP 2022, redgl0w racontait comment le port MicroPython pour Numworks n'était finalement pas super difficile. Moi je parlais de comment un port maison résoudrait le problème de
getkey(), et Critor m'a convaincu d'essayer sur-le-champ.
En fin de compte, j'ai clôné MicroPython Dimanche à midi et à 1 heure du matin j'avais un port fonctionnel avec
getkey() sur ma Graph 90+E (que j'ai d'ailleurs montré à CASIO Lundi, pour la démo). Comme quoi, des fois ça marche tout seul !
(Enfin, le début marche tout seul. Faire une bonne UI et gérer tous les détails ensuite c'est une autre paire de manches !)
Fichier joint
Citer : Posté le 12/02/2024 22:00 | #
Désolé pour demander mais il y a quoi qui est en priorité? Genre, le moteur de gris est combientième dans la list? Car je l'attend impatiemment
Merci d'avance
Tuper
Citer : Posté le 12/02/2024 22:50 | #
Faut clairement résoudre les problèmes de mémoire avant sur la G35+EII car le moteur de gris va encore piquer dans la mémoire dispo, donc autant dire qu'on va pas aller loin après.
Pour la TODO list, on a déjà pas mal avancé, je pense que c'est plus trop à jour désormais. Faudrait qu'on regarde de plus près. Laisse nous un peu de temps qu'on regarde ça.
Citer : Posté le 12/02/2024 22:57 | #
Ah oui me problème de la mémoire :/ . Je ne demande absolument rien
Bravo
Tuper
Citer : Posté le 14/02/2024 08:26 | # |
Fichier joint
Yo,
Hier soir a été pour moi un peu comme les montagnes russes émotionnelles, outre la perte dramatique et subite de ma G90+E (mais heureusement sans souffrance
Bon en fait, il s'agit de ulab (à prononcer "micro lab") qui est une implémentation légère de Numpy pour le matériel embarqué. ulab est un module pour micropython et ses dérivés, destiné à simplifier et accélérer les opérations mathématiques courantes sur les tableaux. Il implémente un petit sous-ensemble de numpy et scipy. Les fonctions implémentées ont été choisies de telle sorte qu'elles puissent être utiles dans le contexte d'un microcontrôleur.
La documentation du module peut être trouvée ici https://micropython-ulab.readthedocs.io/en/latest/index.html ou ici https://micropython-ulab.readthedocs.io/en/stable/index.html .
Au programme donc tout un ensemble de fonctions de manipulation de tableaux, d'opérations matricielles, de traitement du signal, etc.
Par exemple le code suivant permet d'afficher les vecteurs propres et valeurs propres de la matrice "a" :
a = np.array([[1, 2, 1, 4], [2, 5, 3, 5], [1, 3, 6, 1], [4, 5, 1, 7]], dtype=np.uint8)
x, y = np.linalg.eig(a)
print('eigenvectors of a:\n', y)
print('\neigenvalues of a:\n', x)
et vous affichera un truc du genre :
array([[0.8151560042509081, -0.4499411232970823, -0.1644660242574522, 0.3256141906686505],
[0.2211334179893007, 0.7846992598235538, 0.08372081379922657, 0.5730077734355189],
[-0.1340114162071679, -0.3100776411558949, 0.8742786816656, 0.3486109343758527],
[-0.5183258053659028, -0.292663481927148, -0.4489749870391468, 0.6664142156731531]], dtype=float)
eigenvalues of a:
array([-1.165288365404889, 0.8029365530314914, 5.585625756072663, 13.77672605630074], dtype=float)
ulab est un module majeur qui est très largement utilisé en lieu et place de numpy du fait de sa compacité. Il devrait permettre aux plus matheux d'étendre sensiblement le domaine d'application de PythonExtra en offrant des fonctions mathématiques avancées et performantes. Le Python officiel peut aller se rhabiller désormais
Comme d'habitude, je vous mets en PJ une version up-to-date qui contient les dernières MaJ de PythonExtra :
- bugfix de Lephe concernant les initialisations du module random
- bugfix dans le module kandinsky Numworks dans la fonction get_pixel()
- ajout du support des touches NW par leur numéro dans le module ion Numworks
- ajout du module ulab
Citer : Posté le 14/02/2024 08:49 | #
Cool tout ça! Le module ulab est aussi dispo pour les monochromes? Car un moment je voulais faire une matrice mais je ne pouvais pas
Merci beaucoup
Tu per (ta graph 90+E)
Citer : Posté le 14/02/2024 09:18 | #
J'ai pas essayé de compiler pour G35+EII. Je pourrais tester pour voir si ça passe côté mémoire.
Pour ton problème de matrice, clairement l'utilisation visée de ulab n'est pas d'utiliser les tableaux/matrices pour stocker des images (je pense que c'est ce que tu as en tête), c'est juste inadapté d'un point de vue ressources utilisées.
Citer : Posté le 14/02/2024 10:11 | #
Non non, ce n'est pas ce que j'ai pensé
Tuper
Citer : Posté le 14/02/2024 11:49 | #
Faut clairement résoudre les problèmes de mémoire avant sur la G35+EII car le moteur de gris va encore piquer dans la mémoire dispo, donc autant dire qu'on va pas aller loin après.
Pour la TODO list, on a déjà pas mal avancé, je pense que c'est plus trop à jour désormais. Faudrait qu'on regarde de plus près. Laisse nous un peu de temps qu'on regarde ça.
La mémoire, on ne peut pas en inventer à part une intervention matérielle... il faudra sur cette machine se résigner à faire des choix restrictifs.
Comme il y a deux machines différentes, probablement avoir deux PE différents, un pour chaque modèle ?, mais la maintenance en serait sans doute plus compliquée; à vous de voir Lephe et Slyvtt
Citer : Posté le 14/02/2024 11:54 | #
comment ca deux machines différentes? Il y a la Graph 90+E et la 35+E II et ils ont déja 2 PE différents... Je ne comprends pas ce que tu veux dire
Citer : Posté le 14/02/2024 12:01 | #
La mémoire, on ne peut pas en inventer à part une intervention matérielle... il faudra sur cette machine se résigner à faire des choix restrictifs.
Alors oui et non. On ne peut pas rajouter physiquement de la mémoire, mais actuellement c'est une question de trouver des plages de mémoire utilisables, sachant que la puce est en fait assez grande
Comme il y a deux machines différentes, probablement avoir deux PE différents, un pour chaque modèle ?, mais la maintenance en serait sans doute plus compliquée; à vous de voir Lephe et Slyvtt
C'est déja un peu le cas, et effectivement ça veut dire qu'on ne peut avoir certains modules.
Caltos : G35+EII, G90+E (briquée
Citer : Posté le 14/02/2024 12:07 | #
J'aurais tendance a réserver les modules Numworks à la G90+E seulement :
- écran couleur comme sur la NW
- mémoire très largement suffisante pour encaisser
Je ne vois pas l'utilité sur G35+EII sachant que l'écran sera à la rue et en plus on manque de mémoire.
Pour ulab, je suis plus dans l'interrogation. D'un point de vue utilisation, ce sera nettement plus confortable sur la G90+E qui est destinée BAC et Post BAC. Mais peut être que certains verraient une utilité sur G35+EII. Donc si ça passe pourquoi pas, mais là il faut que je teste car en l'état c'est pas prévu.
Dites moi ce que vous voulez, on verra si on peut faire ou pas ensuite.
Citer : Posté le 14/02/2024 12:11 | #
La mémoire, on ne peut pas en inventer à part une intervention matérielle... il faudra sur cette machine se résigner à faire des choix restrictifs.
Comme il y a deux machines différentes, probablement avoir deux PE différents, un pour chaque modèle ?, mais la maintenance en serait sans doute plus compliquée; à vous de voir Lephe et Slyvtt
Un PythonExtra par modèle ? Il y a déjà une différence entre la Graph 90+E et la 35+E II et on peut déjà faire ce qu'on veut dans l'un sans toucher l'autre.
La bonne nouvelle, c'est que le nombre de fonctions n'importe pas vraiment ! Les fonctions font partie de l'add-in (le .g1a) et le code n'est pas chargé en RAM. On peut en avoir jusqu'à 500 ko sans problème. Donc PythonExtra pourra toujours ajouter des fonctions pour vous simplifier la tâche.
L'autre bonne nouvelle, c'est qu'il y a plein de compromis possibles. Par exemple, quand on charge des images/etc, les lister dans le code prend de la place, ce qui met de la pression sur la RAM au chargement du fichier (pour lire le texte) et ensuite pour stocker la donnée elle-même (grosse liste d'entiers ou bytes). Mais on pourrait laisser les données dans un fichier externe en ROM dans beaucoup de cas, libérant de la RAM. Autre exemple, la Graph 35+E II a une grosse région de RAM (PRAM0 - 140 ko) qui est un peu dure à utiliser mais peut avec un peu d'effort. On pourrait par exemple y stocker l'historique de la console pour libérer de la place dans la RAM principale (PRAM0 ne survit pas au power-off donc l'historique disparaîtrait dans ce cas, mais on s'en fout).
Je ne code pas vite voire pas du tout en ce moment parce que je suis à fond sur un projet de recherche, désolé. Mais je suis convaincu qu'on peut faire un truc bien à la fin (avec genre 1 semaine de travail hein pas dans 2 ans).
Citer : Posté le 14/02/2024 20:25 | #
Pour info, j'ai testé une version de PythonExtra compilée avec le module ulab et c'est juste inutilisable, une pauvre inversion de matrice ne fonctionne pas pour cause de mémoire insuffisante et la moindre sortie de valeur sur la console fait dramatiquement descendre la RAM disponible.
Là ça va être compliqué. En l'état, je considère qu'il faut pas intégrer ce module. On verra si l'avenir permet de gagner de la RAM, auquel cas je reconsidérerai le moment venu.
Citer : Posté le 14/02/2024 20:29 | #
Ok, pas de souci. Laisse-le uniquement sur la Graph 90+E, c'est déjà pas mal.
Citer : Posté le 14/02/2024 21:11 | #
C'est hyper facile à remettre, et je sais que ça fonctionne car j'ai pu faire quelques opérations, donc d'un point de vue purement programmation, il suffira juste d'activer le module en ajoutant la liste des sources dans le Makefile pour la G35+EII.
Citer : Posté le 17/02/2024 07:41 | #
Voilà pour le fun, maintenant que j'ai reçu ma Numworks N0110, une petite comparaison "side-by-side" des performances de la fxCG50 faisant tourner des scripts Python natifs de la NW et les mêmes scripts tournants sur leur machine de destination.
C'est vraiment pas mal, sachant qu'il faut conserver en tête que la NW a un processeur ARMv7 32bits fonctionnant en fréquence de base à 216MHz tandis que la fxCG50 tourne avec le SH4 32bits à 118MHz. C'est donc vraiment bien car on a clairement pas un ratio de 2 en performances comme pourrait le laisser penser le delta de fréquence.
Citer : Posté le 17/02/2024 18:48 | #
J'ai pas trop suivi, mais est ce que ça veut dire que les scripts python pour Numworks tourne sur sur python extra, ou c'est encore en face de développement ?
Citer : Posté le 17/02/2024 18:51 | #
C'est les deux
Caltos : G35+EII, G90+E (briquée
Citer : Posté le 17/02/2024 18:52 | #
Ah, ok, tant mieux car j'avais vu plein de script pour Numworks qui avaient vraiment l'air cool
Citer : Posté le 25/02/2024 13:38 | #
Eeeeh, on doit pouvoir faire mieux sur les perfs. Je suis sûr qu'il y a plein de tricks de précompilation qu'on peut choper. Enfin, plus tard...
J'arrive enfin à respirer un peu (si j'ignore le fait que j'ai un papier à soumettre Mercredi) donc j'ai repris les besoins urgents sur ce projet.
J'ai réduit la consommation mémoire de la console sur Graph 35+E II, ce qui sans rentrer dans les détails devrait empêcher pour de bon les crashs du type "après un certain temps d'usage de l'add-in" comme celui-ci rapporté par Ptitjoz.
Quelques news récentes sur ce qui a été fait, pour ceux qui voudraient du contexte :
- Fonctions de dessin d'image sur mono (Lephe #195877) et sur 90 (Lephe #195910)
- Support des modules Numworks ion/kandinksy sur G90 (SlyVTT #195883, #196031, #196075, #196124, #196190)
Les priorités du moment sont les suivantes, et c'est également ma TODO list ordonnée pour la prochaine release (en remplacement de celle-ci) :
Je relègue pour l'instant les points suivants à la release d'après, qui arrivera après que j'aurai fait un tour sur d'autres tâches dans la liste dans ma signature :
Citer : Posté le 25/02/2024 16:20 | #
ouah! bomme chance pour tout ca!