gint : un noyau pour développer des add-ins
Posté le 20/02/2015 17:30
Ce topic fait partie de la série de topics du fxSDK.
En plus des options de programmation intégrée comme le Basic Casio ou Python, la plupart des calculatrices Casio supportent des
add-ins, des programmes natifs très polyvalents avec d'excellentes performances. Les add-ins sont généralement programmés en C/C++ avec l'aide d'un ensemble d'outils appelé SDK.
Plusieurs SDK ont été utilisés par la communauté avec le temps. D'abord le
fx-9860G SDK de Casio avec fxlib pour Graph monochromes (plus maintenu depuis longtemps). Puis le
PrizmSDK avec libfxcg pour Prizm et Graph 90+E (encore un peu actif sur Cemetech). Et plus récemment celui que je maintiens, le
fxSDK, dont gint est le composant principal.
gint est un unikernel, ce qui veut dire qu'il embarque essentiellement un OS indépendant dans les add-ins au lieu d'utiliser les fonctions de l'OS de Casio. Ça lui permet beaucoup de finesse sur le contrôle du matériel, notamment la mémoire, le clavier, l'écran et les horloges ; mais aussi de meilleures performances sur le dessin, les drivers et la gestion des interruptions, plus des choses entièrement nouvelles comme le moteur de gris sur Graph monochromes.
Les sources de gint sont sur la forge de Planète Casio :
dépôt Gitea Lephenixnoir/gint
Aperçu des fonctionnalités
Les fonctionnalités phares de gint (avec le fxSDK) incluent :
- Toutes vos images et polices converties automatiquement depuis le PNG, sans code à copier (via fxconv)
- Un contrôle détaillé du clavier, avec un GetKey() personnalisable et un système d'événements à la SDL
- Une bibliothèque standard C plus fournie que celle de Casio (voir fxlibc), et la majorité de la bibliothèque C++
- Plein de raccourcis pratiques, comme pour afficher la valeur d'une variable : dprint(1,1,"x=%d",x)
- Des fonctions de dessin, d'images et de texte optimisées à la main et super rapides, surtout sur Graph 90+E
- Des timers très précis (60 ns / 30 µs selon les cas, au lieu des 25 ms de l'OS), indispensables pour les jeux
- Captures d'écran et capture vidéo des add-ins par USB, en temps réel (via fxlink)
Avec quelques mentions spéciales sur les Graph monochromes :
Un moteur de gris pour faire des jeux en 4 couleurs !
La compatibilité SH3, SH4 et Graph 35+E II, avec un seul fichier g1a
Une API Unix/POSIX et standard C pour accéder au système de fichiers (Graph 35+E II seulement)
Et quelques mentions spéciales sur les Graph 90+E :
Une nouvelle police de texte, plus lisible et économe en espace
Le dessin en plein écran, sans les bordures blanches et la barre de statut !
Un driver écran capable de triple-buffering
Une API Unix/POSIX et standard C pour accéder au système de fichiers
Galerie d'add-ins et de photos
Voici quelques photos et add-ins réalisés avec gint au cours des années !
Arena (2016) — Plague (2021)
Rogue Life (2021)
Momento (2021)
Communication avec le PC (cliquez pour agrandir)
Utiliser gint pour développer des add-ins
Les instructions pour installer et utiliser gint sont données dans les divers tutoriels recensés dans le
topic du fxSDK. Il y a différentes méthodes de la plus automatique (GiteaPC) à la plus manuelle (compilation/installation de chaque dépôt). Le fxSDK est compatible avec Linux, Mac OS, et marche aussi sous Windows avec l'aide de WSL, donc normalement tout le monde est couvert
Notez en particulier qu'il y a des
tutoriels de développement qui couvrent les bases ; tout le reste est expliqué dans les en-têtes (fichiers
.h) de la bibliothèque que vous pouvez
consulter en ligne, ou dans les ajouts aux changelogs ci-dessous.
Changelog et informations techniques
Pour tester les fonctionnalités et la compatibilité de gint, j'utilise un add-in de test appelé gintctl (
dépôt Gitea Lephenixnoir/gintctl). Il contient aussi une poignée d'utilitaires d'ordre général.
Ci-dessous se trouve la liste des posts indiquant les nouvelles versions de gint, et des liens vers des instructions/tutoriels supplémentaires qui accompagnent ces versions.
Anecdotes et bugs pétés
Ô amateurs de bas niveau, j'espère que vous ne tomberez pas dans les mêmes pièges que moi.
TODO list pour les prochaines versions (2023-04-03)
gint 2.11
- Changements de contextes CPU. À reprendre du prototype de threading de Yatis pour permettre l'implémentation d'un véritable ordonnanceur. Demandé par si pour faire du threading Java.
- Applications USB. Ajouter le support de descripteurs de fichiers USB. Potentiellement pousser jusqu'à avoir GDB pour debugger.
- Support de scanf() dans la fxlibc. Codé par SlyVTT, plus qu'à nettoyer et fusionner.
Non classé
- Regarder du côté serial (plus facile que l'USB) pour la communication inter-calculatrices (multijoueur) et ultimement l'audio (libsnd de TSWilliamson).
- Un système pour recompiler des add-ins mono sur la Graph 90+E avec une adaptation automatique.
- Support des fichiers en RAM pour pouvoir utiliser l'API haut-niveau sur tous les modèles et éviter la lenteur de BFile à l'écriture quand on a assez de RAM.
Citer : Posté le 28/01/2023 11:29 | #
Pas directement car tu ne compiles pas avec gint. Il est envisageable que le code de communication GDB, le jour où on l'écrit, sera à base de lectures/écritures USB et pourra être porté pour le SDK. Pas de promesses, car à ma connaissance pour utiliser GDB il faut un "terminal" USB (ie. un périphérique texte de la classe CDC/ACM) et l'OS n'implémente que les transferts bulk un peu bourrins (comme gint pour l'instant). Il est possible qu'un montage un peu bizarre avec un programme intermédiaire soit nécessaire.
On parle bien de l'alternative à l'écran de la mort error system? C'est ça dont j'aimerais disposer, pour les opérations de debug je peux utiliser l'émulateur avec la dll modifiée. Mais si ça ne peut pas s'adapter, ce n'est pas très gênant, avec l'écran de la mort de Casio, la plupart du temps on peut déjà faire MENU, lancer une autre application et ça fonctionne presque toujours.
Citer : Posté le 28/01/2023 11:31 | #
Ah pardon, j'ai peut-être mal compris. J'ai pensé que tu parlais de GDB parce que l'autre partie (ie. le fait de pouvoir quitter une System ERROR par le clavier au lieu RESET au dos de la calculatrice) on peut en effet déjà le faire avec l'OS.
Dans tous les cas peu probable qu'on puisse modifier des choses dans l'écran System ERROR de l'OS, on n'a pas de contrôle de ce côté-là.
Citer : Posté le 24/02/2023 23:17 | # |
Fichier joint
Ça fait un moment que je dois faire une update donc voici quelque chose de bref.
Je suis sur l'USB en train de voir la communication PC → calto. J'ai passé pas mal de temps à améliorer le driver USB côté calto pour solidifier ce qui existait déjà dans le sens calto → PC (qui n'était vraiment qu'un prototype) et créer les abstractions nécessaires pour gérer aussi l'autre sens. Ça c'est fait et l'interface fxlink expose maintenant un deuxième endpoint OUT (ie. PC → calto), donc en principe je peux commencer à coder la réception.
Sauf que j'ai rien pour tester parce que le mode interactif de fxlink (fxlink -i) il n'est là que pour logger ce qui vient de la calto, et en plus c'est écrit un peu avec les mains (ça aussi c'est du prototype).
Du coup, là tout de suite je suis en train d'améliorer tout ça. J'ai commencé à écrire un mode interactif en TUI que j'avais en tête (fxlink -t), où on peut voir les calculatrices branchées en temps réel, recevoir des messages de la calto en fond, et taper en premier plan des commandes pour envoyer des réponses. J'en suis presque là, vous pouvez voir sur cette capture que j'en suis au point où je peux commencer à communiquer avec la calto.
Cette interface est très différente de l'ancien mode interactif dans le sens où il faut utiliser libusb bien plus intelligemment pour pouvoir gérer les calculatrices en tâche de fond (en particulier il faut utiliser l'API asynchrone), d'où le temps que ça prend. En tous cas j'en suis content, c'est classe.
Citer : Posté le 25/02/2023 09:46 | #
Superbe. J’ai hate que ca sorte en production 😃. On va avoir un outil au top.
Bravo Lephe.
Citer : Posté le 25/02/2023 20:42 | # |
Fichier joint
Nouveauté d'aujourd'hui, les transferts habituels calto → PC commencent à marcher proprement (même si les données ne sont pas sauvegardées là tout de suite), et y'a même des barres de progression et tout. Dans la vidéo ci-dessous je lance fxlink en mode TUI et ensuite j'utilise une fonction de gintctl pour copier tout la ROM via USB vers le PC.
Sans surprise le transfert (33 Mo !) va beaucoup plus vite que quand il s'agit de copier des fichiers dans la mémoire de stockage de la calto. x)
Quelques avantages un peu plus concrets avec cette version en TUI :
En gros fxlink sert un peu de "terminal spécifique calto" d'une certaine façon.
Citer : Posté le 25/02/2023 20:51 | #
C'est super puissant !! Je sens que ça va vraiment bien aider.
Je suppose qu'on garde les formats de transfert USB calculatrice (Casio --> PC) comme les images/videos/textes pour l'envoi et la récupération par fxlink (et éventuellement stockage sur le disque).
Pour les vidéos, on saurait combiner avec je sais pas quoi (par exemple ffmpeg) pour générer direct une vidéo.
On pourrait peut être aussi ajouter dans le header de data envoyé à fxlink par la calculatrice un nom de fichier de sortie.
Citer : Posté le 03/03/2023 00:37 | #
Le code de la TUI ci-dessous est en ligne sur la branche dev du fxSDK.
C'est définitivement pas un petit commit... x)
45 files changed, 4622 insertions(+), 1721 deletions(-)
Citer : Posté le 03/03/2023 07:59 | #
Installé ! ça rend vraiment bien.
Par contre si je comprends bien, pour le moment ça se contente d'afficher ou au contraire on peut déjà envoyer des trucs (équivalence de -s) ?
J'ai juste trouvé le q pour quitter. Faudra que tu nous fasses un tuto (when its done )
Bravo en tout cas, joli taf, comme d'habitude
Citer : Posté le 03/03/2023 08:24 | #
Ah oui oups comment quitter. C'est la seule commande pour l'instant.
Attention à ne pas mélanger -i et -t (qui sont du libusb où on pilote manuellement la calculatrice) avec -s (qui est de la clé USB pilotée par le noyau). -s c'est un peu un script de copie utile pour envoyer en ligne de commande et c'est à peu près tout, y'a pas grand-chose de plus à faire avec et ça marche qu'avec LINK.
Du reste, c'est effectivement le prochain truc sur la liste de pouvoir envoyer des données, mais ça ne sera pas dans le style de LINK ce sera plutôt le dual des fonctions de screenshot/vidéo qu'on a actuellement dans gint.
Citer : Posté le 03/03/2023 08:58 | #
Oui c'est vrai, tu as tout à fait raison.
En fait je me demandais (je reformule ma question, mais tu as partiellement répondu dans le dernier § de ton message), dans la zone console, a priori si j'ai bien compris, on tapera des commandes pour interagir avec la calculatrice connectée. Y aura-t-il des commandes style :
Pourrait on aussi par exemple rediriger stdin/stdout vers la console interractive ? Ce serait hyper cool et utile.
Sur ta vidéo du 25/02/2023, on voit une progression de transfert. Pour le moment si je comprends bien c'est dans le sens Calto-->PC exclusivement.
Citer : Posté le 03/03/2023 09:11 | #
Peu probable parce que l'enregistrement du fichier dans la mémoire de stockage nécessiterait de quitter gint (et donc de couper le driver USB). Pour les envois via Add-In Push ça n'a pas trop de sens de le faire sans compiler donc l'idée c'est plutôt que tu tapes fxsdk build-cg-push -s dans ton terminal (ou dans mon cas l'alias fcgp) pendant que fxlink est ouvert à côté.
Oui ça tout à fait.
Oui, comme tu peux le voir il y a une fenêtre "Text output from calculators" qui capture déjà tous les messages texte envoyés par la calculatrice. C'est pas parfait parce qu'on ne peut pas scroll malheureusement, mais ça viendra peut-être plus tard.
Un truc qui pourrait être intéressant c'est qu'après l'envoi via Add-In Push l'add-in démarre automatiquement. S'il se connecte au PC, alors fxlink en fond pourra le détecter. Il est envisageable que fxlink démarre automatiquement la capture vidéo + clavier et permette de contrôler la calculatrice sur le PC. Ça améliorerait grandement la vitesse du cycle compilation/envoi/test.
C'est ça ; ce sera la même chose pour le sens inverse.
Citer : Posté le 03/03/2023 09:26 | #
Ok je comprends mieux la philosophie.
En fait on aura typiquement un fxlink -t ouvert en permanence dans un terminal pour interagir avec la machine (capture/envoyer du texte à la machine et à l'add-in qui tourne, récupérer/déclencher des captures écran/vidéo) et à côté un autre terminal pour la compilation et l'envoi de données qui permettra d'envoyer soit des g3a/ soit des Bin à USB Push (via soit fxlink -s fichier.g3a ou si pas déjà compilé via un fxsdk build-cg/fx/cg-push -s selon la machine/le mode d'envoi (LINK/USB Push) ).
Citer : Posté le 04/03/2023 15:38 | # |
Fichier joint
Les lectures commencent à marcher. Ci-dessous une capture d'écran où l'en-tête d'un message fxlink (44 octets) a été envoyé par le PC. L'interruption est reçue, l'infrastructure de lecture commence à être en place, et je peux récupérer les données. Le header est décodé et affiché à la ligne qui commence par [ff-bulk 1.0].
C'est en cours bien sûr, pour l'instant je suis même pas sur que si j'essaie de lire plusieurs trucs d'affilée ça marche. Si on essaie de lire un non multiple de 4 octets ça marche probablement pas, etc. x)
Citer : Posté le 07/03/2023 00:03 | # |
Fichier joint
Nouvelle update ! J'ai affiné le modèle au point où dans ma tête c'est presque complètement figé. Je n'ai pas encore essayé ni les messages longs, ni les lectures non alignées, ni la performance, mais j'arrive à récupérer des contenus.
Sur la photo ci-dessous vous pouvez voir que la commande /echo xyz envoyée dans la TUI fxlink (fenêtre "Console" en bas à gauche) a été reçue par la calcularice ("Command is: 'echo xyz'"), laquelle a répondu par un message texte "xyz" qui est affiché dans la TUI (fenêtre "Text output from calculators" en haut à gauche).
En bref j'ai quasiment un prototype de chat calto/PC par USB quoi
Citer : Posté le 07/03/2023 13:28 | #
C'est vraiment super ! Ca avance gentiment, mais sûrement.
Quand tu parles d'écritures alignées, j'imagine que tu parles de multiples de 4 octets, ceci étant l'unité de base si j'ai bien compris.
J'avais une question, est ce que l'on pourra avoir plusieurs machines de connectées simultanément ?
Comment ça se passe avec fxlink ?
Citer : Posté le 07/03/2023 13:30 | #
Ce serait bien, comme ça on pourrait faire du multijoueur avec USB.
Citer : Posté le 07/03/2023 13:34 | #
Ce serait bien, comme ça on pourrait faire du multijoueur avec USB.
tu as lu dans mes pensées
Citer : Posté le 07/03/2023 13:40 | #
Pour l'instant en effet mais le temps que je finisse ce sera totalement invisible et on pourra lire dans un pipe USB le nombre d'octets qu'on veut avec l'alignement qu'on veut (ce qu'on peut déjà faire avec l'écriture).
Comment ça se passe avec fxlink ?
La réécriture de fxlink qui a permis l'ajout de la TUI fournit, entre autres, toutes les fonctionnalités nécessaires pour connecter plusieurs calculatrices simultanément. Là tout de suite on peut déjà le faire et recevoir plusieurs messages en même temps. La commande /echo dans la démo ci-dessus envoie à la première calculatrice connectée qui est trouvée, mais on peut tout à fait communiquer avec plusieurs.
Donc de là à équiper fxlink d'un mode "routage" où une calculatrice pourrait faire serveur et les autres périphériques... oui, c'est carrément possible. L'intérêt est un peu limité par rapport au 3-pin puisqu'il faut un PC, mais oui c'est tout à fait raisonnable.
Citer : Posté le 07/03/2023 14:16 | #
Avec un PC oui c'est pas l'idéal, mais avec un PI par exemple, un "serveur réseau Casio", ça s'imagine
Y'a plein de trucs vraiment cool en perspective ...
Citer : Posté le 12/03/2023 18:13 | #
Petite update depuis la dernière fois... de l'extérieur je suis toujours "au même endroit" mais en interne pas mal de progrès ont été faits pour consolider le driver.
J'arrive maintenant à lire des messages "longs", ie. que le module USB de la calto reçoit en plusieurs fois (le buffer interne est limité à 2048 octets).
J'ai encore quelques problèmes quand les messages ont une taille multiple de la taille d'un paquet ; le module ne semble pas toujours envoyer une interruption (en plus des innombrables détails d'API que je pense cependant avoir réussi à traiter).
Citer : Posté le 12/03/2023 18:25 | #
Superbe. En plus, il faut noter la qualité du pixel art dans la doc gint associée ...
Va falloir que tu nous fasses un joli tuto, when done
Bon courage.