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 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.
Citer : Posté le 12/03/2023 18:36 | #
C'est du ASCII art
Citer : Posté le 12/03/2023 18:53 | #
C'est du ASCII art
Citer : Posté le 14/03/2023 10:08 | #
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
Il faut au moins ce niveau de détail rien que dans ma tête sinon je rate des cas ! Il est super important d'avoir tout sous les yeux, au propre et au clair. Cela dit, tous les détails de ce header ne vous concernent pas, ils ne sont destinés qu'aux drivers USB et serial en gros. Vous, vous voyez uniquement les fonctions de lecture dans <gint/usb.h>, qui ont leurs détails subtils mais sont quand même bien plus simples.
Citer : Posté le 14/03/2023 11:16 | #
C’est moins sexy
Citer : Posté le 16/03/2023 19:18 | #
Bon ben je voudrais dire, c'est compliqué ces bêtises. Je me dis que tout le monde n'a peut-être pas en tête en quoi ça consiste de développer un truc bas-niveau de ce genre, alors voilà un bout d'histoire...
TL;DR : J'avance mais ne vous fiez pas à l'absence de photos concrètes c'est dur.
Il y a deux problèmes majeurs : les cas particuliers (à la fois logiciels et matériels), et construire une API qui marche bien.
Les cas particuliers il y en a partout. Attendre qu'un bout de données arrive sur le module USB et lire des trucs c'est pas dur. Le faire de façon consistante sans jamais planter dans tous les scénarios ça l'est beaucoup plus ! Un cas particulièrement méchant est le suivant : le module USB de la calto reçoit les données par paquets de 2048 octets. Déjà, comment sait-on quand un envoi est fini ? Si je reçois moins de 2048 octets c'est clair que c'est la fin. Mais si je reçois exactement 2048 octets, impossible de savoir s'il y a une suite ou pas. En l'occurrence si le transfert se finit il faut que l'ordinateur envoie un paquet de plus avec zéro octets dedans pour bien clarifier qu'il n'y a plus rien (et devinez quoi, c'est pas très clair dans la norme USB quand et comment il faut en ajouter, du coup c'est pas par défaut dans libusb !).
Mais tout ça ne suffit pas. Voyez-vous, quand le buffer reçoit des données le module USB déclenche une interruption pour nous l'annoncer, et la première chose qu'on fait c'est de tester le bit "Buffer Status" qui nous indique si on a le droit d'aller lire le buffer (quand le module lit/écrit dans le buffer il nous bloque l'accès). Bon ben cas particulier : si le buffer est vide le bit "Buffer Status" ne passe pas à 1, autrement dit le module te dit en même temps "psst y'a des trucs à lire" et "t'as pas le droit de lire" (parce que le buffer est vide).
Et puis je rentre pas dans les détails juteux où du coup quand on reçoit un buffer complet de 2048 octets potentiellement ça peut répondre à plusieurs appels à usb_read si jamais l'utilisateur demande peut de données ; mais aussi l'inverse, un seul appel à usb_read peut manger plusieurs buffers complets si jamais l'utilisateur demande des grandes quantités de données. Et si on a un appel à usb_read qui vide tout pile le buffer, devinez quoi ? Encore un cas particulier !
Ces choses deviennent encore plus drôles quand on rajoute les questions d'API. Si à la fin de l'histoire le driver marche mais l'API est immonde ça sera toujours insupportable à utiliser. Un truc classique c'est qu'on veut (1) ne pas se lancer dans une lecture s'il n'y a rien à lire (ça bloquerait potentiellement indéfiniment, ce qui est un freeze, ce qui est super chiant à debugger pour tout le monde), et donc (2) quand on lit en boucle, savoir quand on aura fini. De la même façon que pour le buffer de 2048 octets la solution élégante c'est que tant que usb_read demande X octets et que j'ai X octets à donner, la lecture continue. Même si j'avais exactement X octets et que donc après la lecture il en reste 0, le driver ne passe pas à l'envoi suivant avec le PC. Il attend que l'utilisatrice demande encore 1 octets de plus, auquel cas il en renvoie 0 et il passe à l'envoi suivant. De cette façon l'utilisatrice peut appeler usb_read tant qu'elle récupère autant d'octets qu'elle en demande, et elle sait que l'envoi est fini une fois que usb_read en donne moins que demandé.
Tout ça c'est donc mignon mais c'est compliqué et donc on limite ce mécanisme à la version asynchrone de usb_read (celle pour les utilisateurs avancés). La version synchrone bien de base on veut qu'elle se comporte aussi simplement que possible pour cacher tous ces détails pour les programmeurs moins aventureux. Sauf que ça laisse plein de cas particuliers en plus ! Par exemple l'appel synchrone va passer plus agressivement à l'envoi suivant (ignorant la méthode décrite dans le paragraphe précédent), mais cette illusion peut casser si jamais on alterne entre des lectures synchrones et asynchrones, et j'en passe des meilleures.
En pratique ce qui se passe c'est que je lance l'add-in, je démarre la connexion USB, et là j'essaie d'envoyer des données avec fxlink. Parfois ça marche (c'est pas mal). Parfois ça plante, les données sont pas lues correctement et donc la commande est pas comprise comme il faut (ça ça va). Mais souvent, ça freeze et du coup y'a aucun log qui sort, et faut essayer de deviner quelle est la boucle qui finit jamais et pourquoi. Sachant que quand je dis "boucle" c'est pour simplifier ; parfois c'est des appels successifs qui finissent pas parce que l'interruption qui devait les arrêter a été ignorée parce que le bit "Buffer Status" n'était pas à 1...
Une fois le problème identifié généralement soit c'est une erreur stupide de code, soit c'est une erreur stupide de code parce que la série d'appels de fonctions ou le sens des variables dans le driver a changé 20 fois et qu'un bout a pas été adapté durant la 12ème mise à jour, soit c'est un comportement du module que je connaissais pas et qui remet presque systématiquement en cause le modèle avec lequel je travaille.
Et c'est ce changement permanent qui rend fou. Si vous regardez asyncio.h c'est détaillé au point de donner la nausée parce qu'il y a besoin d'avoir tous ces détails sous les yeux en permanence pour vérifier scrupuleusement que toutes les fonctions se comportent comme exigé par le dessin et pas autrement. Quand de la logique asynchrone s'en mêle y'a juste pas moyen d'y aller à l'intuition. Après avoir un tel détail c'est satisfaisant plus qu'autre chose, c'est un bonne façon de vérifier qu'on comprend ce qu'on fait et une fois que c'est propre ça solidifie tellement le code c'est un délice.
Mais ce qui martèle le cerveau, c'est devoir faire un changement mineur, et soudain il faut adapter tout le code. À chaque fois je suis obligé de réécrire une bonne partie de asyncio.h et de la partie lecture dans gint/usb.h pour m'assurer que j'ai bien mesuré toutes les implications du changement sinon je mélange un détail de la nouvelle version avec un détail incompatible d'une version précédente. Il faut ensuite modifier le code, qui couvre environ 500 lignes pour la partie centrale, dont la majorité ne nécessite aucun changement (donc je passe assez vite dessus) sauf un petit détail dans un coin (que j'oublie et qui bien sûr créera des bugs trois itérations plus tard).
Là je vais pas vous mentir ça fait une semaine que je tourne en boucle et chaque nouvelle version ne marche pas parce qu'il y a toujours un cas particulier où soit il y a un problème prévisible que j'ai pas vu venir, soit le module matériel se comporte pas comme je le pensais. Et à chaque fois faut tout réécrire, hacker n'importe comment pour essayer de récupérer les logs quand ça freeze, et se taper la tête quand inévitablement une erreur stupide se révèle. x)
Je sais que je progresse mais je sais pas combien de temps ça va prendre pour converger...
(Ah et pendant que j'y suis : lisez pas les headers que j'ai lié trop en détail, tout ce qui trait à la lecture va pas mal changer au prochain commit. Et probablement de nouveau à celui d'après.)
Citer : Posté le 16/03/2023 20:20 | #
C'est clair que c'est une sacrée aventure le développement d'un driver/d'une API.
Il faut vraiment de la patience et de la méthode.
Merci à toi d'avoir pris le temps de faire un long post "d'état d'avancement", car c'est vrai qu'on a du mal à se représenter ce que cela signifie.
Personnellement j'ai bien pu voir durant mon essai sur le serial, j'ai absolument rien pu en tirer, clairement pas le niveau pour faire ça, alors je te tire mon chapeau.
Allez, bon courage à toi, et je ne doute pas que tu vas nous mitonner un truc aux petits oignons
Citer : Posté le 17/03/2023 09:55 | # |
Fichier joint
Le LSP clangd permet d'accéder à de nombreux outils et fonctionnalités puissantes dans votre éditeur de texte favori.
Pour utiliser clangd avec gint, créez un fichier compile_flags.txt à la racine de votre projet. Vous pouvez écrire à l'intérieur de ce fichier les flags passés à clangd, un flag par ligne.
-Wextra
-std=c99
Vous aurez besoin de spécifier une des calculatrices ciblée par macro...
#ou -DFXCG50
... ainsi que le chemin d'inclusion des headers utilisés par gint. Je recommande d'utiliser les fichiers du fxsdk directement. Vous pouvez les localiser avec locate ou find (sudo updatedb; plocate gint/defs/types.h).
-I/home/kdx/.local/share/fxsdk/sysroot/lib/gcc/sh3eb-elf/11.1.0/include/
Voici mon compile_flags.txt final :
-Wall
-Wextra
-DFXCG50
-I/home/kdx/.local/share/fxsdk/sysroot/sh3eb-elf/include/
-I/home/kdx/.local/share/fxsdk/sysroot/lib/gcc/sh3eb-elf/11.1.0/include/
Notez que mon nom d'utilisateur est "harcodé" ici, mais c'est vraiment rapide à modifier si vous êtes un contributeur et vous pouvez simplement ajouter compile_flags.txt à votre .gitignore après l'avoir commit.
Malgrès le fait que cette solution est brutale, je la partage pour qu'elle ne se perde pas. Si quelqu'un en trouve une plus propre, je mettrai à jour ce message en ajoutant un lien ci-dessous.
Citer : Posté le 17/03/2023 10:01 | #
Pas mal. Pour obtenir le chemin on peut demander au fxSDK pour éviter la recherche :
/home/el/.local/share/fxsdk/sysroot/sh3eb-elf/include
% echo "$(fxsdk path sysroot)/lib/gcc/sh3eb-elf/11.1.0/include/
/home/el/.local/share/fxsdk/sysroot/lib/gcc/sh3eb-elf/11.1.0/include/
Sinon on pourrait le faire générer. La difficulté c'est qu'il y a à la fois des flags du SDK (genre -DFXGC50) et des flags de l'utilisateur.
Citer : Posté le 17/03/2023 10:06 | #
Selon la doc, il y a un moyen pour que CMake génère compile_commands.json automatiquement. Je n'ai pas creusé, préférant gérer ce type de configuration à la main. Mais si tu veux l'automatiser pour tous les utilisateurs, ça devrait se faire.
a file named compile_commands.json listing commands for each file. Usually generated by a build system like CMake.
Citer : Posté le 19/03/2023 14:50 | #
Alright, donc update sur l'USB pour résumer ce qui s'est passé récemment ! @RDP
J'ai eu pas mal de requêtes demandant à améliorer le driver USB pour supporter les transferts dans le sens PC → calto (jusqu'ici seul le sens calto → PC était supporté). J'ai fait pas mal de progrès sur ce point :
Actuellement sur la branche dev c'est utilisable (avec fxlink/gintctl comme démo), mais pas encore très user-friendly vu qu'il n'y a pas de tutorial. Vous êtes invité·es à essayer si ça vous branche !
Image : fxlink envoie la commande /echo xyz (fenêtre "Console" en bas à gauche),
la calculatrice reçoit la commande (avec la trace "Command is..." en bas de l'écran)
et répond avec le texte xyz (fenêtre "Text output from calculators" en haut à gauche).
Ça fait très longtemps que je n'ai pas publié une nouvelle version de gint, ça arrivera sans doute une fois cette fonctionnalité finie (et dans la suivante le scanf() de SlyVTT et les projets mono/CG sans doute).
Citer : Posté le 19/03/2023 15:42 | #
Ehh beh, ça m'a l'air incroyable tout ça
Citer : Posté le 19/03/2023 16:57 | #
C'est assez hype en effet ! La démo ne fait pas honneur au temps qu'il a fallu passer dessus, mais je suis sûr que vous trouverez des trucs plus flashy à faire avec. x3
Citer : Posté le 28/03/2023 16:10 | #
Je viens depuis ta vidéo tutube. Il s'en est passé des trucs depuis que j'ai eu mon bac en 2014 et donc abandonné l'univers casio. En principe je suis devenu ingé en informatique, mais vous continuez a etre de grands malades a mes yeux.
Edit : putain ça fait dix ans jour pour jour que j'ai créé ce compte!
Minecraft de limachi
Yu-gi-oh! de intelligide
Fix-os de kristaba
Baston!
Citer : Posté le 28/03/2023 16:25 | #
Hey 10 ans sur Planète Casio ça se fête !
La valeur des calculatrices graphiques comme tremplin vers l'informatique continue de se justifier à mes yeux
Citer : Posté le 28/03/2023 16:30 | #
Bof le dev m'a vite cassé les burnes, je suis resté fan de la meme chose depuis que j'ai 7 ans et que j'ai supprimé DOS sur un pc sous win 3.1 :
apprendre en cassant des trucs. Oui je suis admin systeme linux
Minecraft de limachi
Yu-gi-oh! de intelligide
Fix-os de kristaba
Baston!
Citer : Posté le 28/03/2023 16:52 | #
Aaah on est content que vous soyez là. Tu tombes bien d'ailleurs j'ai cassé un truc ou deux avec un serveur VNC et...
Citer : Posté le 28/03/2023 21:28 | #
Aaah on est content que vous soyez là. Tu tombes bien d'ailleurs j'ai cassé un truc ou deux avec un serveur VNC et...
Minecraft de limachi
Yu-gi-oh! de intelligide
Fix-os de kristaba
Baston!
Citer : Posté le 02/04/2023 00:16 | #
Release associée du fxSDK : fxSDK 2.10.0
Release associée de la fxlibc : fxlibc 1.4.5
Une de plus grosses versions du projet, puisque gint 2.9.0 a plus de 6 mois... donc pas mal de changements !
Bien sûr la fonctionnalité phare est le support de la communication PC → calculatrice via USB, qui étend largement les possibilités de l'USB.
Changements majeurs :
Changements mineurs :
Citer : Posté le 02/04/2023 11:35 | #
Cool une nouvelle version du FxSDK !! Par contre, j'ai un problème à l'installation car il ne trouve pas ncurses...
Citer : Posté le 02/04/2023 11:36 | #
Si tu es sous Debian/Ubuntu ou dérivé, essaie d'installer le paquet ?