Les membres ayant 30 points peuvent parler sur les canaux annonces, projets et hs du chat.

Forum Casio - Projets de programmation


Index du Forum » Projets de programmation » gint : un noyau pour développer des add-ins
Lephenixnoir Hors ligne Administrateur Points: 21353 Défis: 149 Message

gint : un noyau pour développer des add-ins

Posté le 20/02/2015 17:30

Les SDKs classiques pour écrire des add-ins sont le fx-9860G SDK de Casio avec fxlib (pour Graph monochrome) et le PrizmSDK avec libfxcg (pour Prizm et Graph 90+E). Voici mon alternative : le fxSDK avec gint, pour toutes les plateformes.

Contrairement à fxlib et libfxcg, qui appellent les fonctions de l'OS pour faire leur travail, gint est un noyau indépendant de l'OS qui exploite seul le matériel et le met à disposition de votre add-in. Il vous offre plus de finesse sur le contrôle du matériel, notamment le clavier, l'écran et les horloges, de meilleurs performances sur le dessin, les drivers et la gestion de interruptions, et des choses entièrement nouvelles comme le moteur de gris.

Toutes les sources de gint sont publiques et accessibles sur la forge de Planète Casio :

» Dépôt Gitea Lephenixnoir/gint «

Voici plus précisément ce que gint vous offre de nouveau :

• Un contrôle détaillé du clavier pour les jeux, parfait pour les combos !
• Des timers avec une précision de 60 ns, d'autres à 30 µs
• Toutes vos images converties automatiquement sans code à copier (plus de Sprite Coder)
• Des polices personnalisées
• Des fonctions de dessin, d'images et de texte fulgurantes et optimisées la main
• Mesurer les performance de votre code à la microseconde près (avec libprof)
• Le contrôle du matériel et des interruptions
• Plein de petites choses pratiques comme dprint(1, 1, "x=%d", x)

• (Graph monochrome) Un moteur de gris pour faire des jeux en 4 couleurs !
• (Graph monochrome) La compatibilité SH3 et SH4, avec le même fichier g1a
• (Graph 35+E II) Une API Unix/POSIX pour accéder au système de fichiers

• (Graph 90+E) Une nouvelle police de texte, plus lisible et économe en espace
• (Graph 90+E) Le dessin en plein écran, sans les bordures blanches et la barre de statut !
• (Graph 90+E) Un driver écran capable de triple-buffering
• (Graph 90+E) Une API Unix/POSIX pour accéder au système de fichiers

Le coût de tout ceci, c'est que vous avez une copie du code de gint dans votre add-in. Cela prend environ 20 ko de place (selon la quantité de fonctions que vous utilisez), soit à peu près comme le sprintf() de fxlib qui fait 18 ko !

Et voici quelques photos et captures d'écran !





Tester gint sur votre machine

La fin du portage vers la Graph 90+E signera la sortie de gint v2. L'add-in de test de l'application est désormais gintctl :

» Dépôt Gitea Lephenixnoir/gintctl «

En plus de tester les fonctionnalités de gint, cet add-in contient quelques outils permettant d'inspecter la machine, la mémoire, et les registres. Je le développe au fur et à mesure, et je posterai un protocole de test complet avec la sortie de la v2 !

Utiliser gint pour développer des add-ins

Normalement, vous avez besoin du fxSDK pour développer avec gint. Le fxSDK est compatible avec Linux et Mac OS, et on peut réfléchir à un portage sous Windows s'il y a vraiment des intéressés. Il faut l'installer en premier (et avoir un cross-compilateur GCC).

La procédure de compilation et d'installation de gint est décrite sur le README du dépôt, c'est du configure - make tout à fait banal.

Une fois que gint est installé sur votre système, voyez les tutoriels de développement pour avoir un aperçu de son fonctionnement. La plupart des choses sont expliquées dans les en-têtes (fichiers .h) de la bibliothèque que vous pouvez consulter en ligne, sur votre copie locale du dépôt, ou dans les dossiers d'installation du compilateur.

Obtenir la dernière version de gint après une mise à jour

Je pousse régulièrement des mises à jour de gint sur le dépôt du projet. Pour les télécharger, tapez git pull, puis recompilez et réinstallez gint avec fxsdk build-cg install.

Changelog et infos de migration

Ci-dessous se trouve la liste des posts indiquant les nouvelles versions de gint, et les instructions pour modifier vos add-ins quand c'est nécessaire.

gint 2.7.0 (31 Décembre 2021)
gint 2.6.0 (29 Août 2021)
gint 2.5.2 (8 Juin 2021)
gint 2.5.1 (2 Juin 2021)
gint 2.5.0 (26 Mai 2021) — Intégration de fxlibc (dépôt)
gint 2.4.0 (27 Avril 2021) — Api GINT_CALL() pour les callbacks
gint 2.3.1 (2 Février 2021)
gint 2.3.0 (29 Janvier 2021)
gint 2.2.1 (12 Janvier 2021)
gint 2.2.0 (11 Janvier 2021)
gint 2.1.1 (16 Septembre 2020)
gint 2.1.0 (21 Août 2020) — Polices UnicodeNouvelle API du moteur de gris
gint 2.0.3-beta (10 Juillet 2020) — Modifications de l'API timer
gint 2.0.2-beta (17 Juin 2020)


Anecdotes et bugs pétés

Ô amateurs de bas niveau, j'espère que vous ne ferez pas les mêmes erreurs que moi.

Toujours spécifier les flags dans .section en assembleur
Ne pas oublier des registres lors de la sauvegarde du contexte durant une interruption
Aligner correctement les adresses des sections dans le linker script
Toujours spécifier l'alignement des structures packed (message du 01/03/2017)

Fichier joint


Précédente 1, 2, 3 ··· 10 ··· 20 ··· 30 ··· 40 ··· 50 ··· 59, 60, 61, 62
Lephenixnoir Hors ligne Administrateur Points: 21353 Défis: 149 Message

Citer : Posté le 20/12/2021 18:51 | #


Slyvtt a écrit :
Prépare ta soirée, je vais bientôt poster la v0.9B qui sera "almost done", la v1.0 sera la version avec tous les niveaux dispos et la fin de l'histoire afin de ne pas tout "teaser" avant ...

Wow j'ai vu ça c'est génial ! Je le teste ce soir après manger.

Tu sais quand ça va passer en release ?

Je suis en train de finaliser l'API. En gros non seulement je veux m'assurer que toutes les fonctions de base sont fournies, mais aussi que toutes les fonctionnalités offertes par BFile de base sont couvertes histoire qu'utiliser BFile soit vraiment inutile sur la Graph 35+E II et la Graph 90+E.

Pour information, l'API Unix actuelle supporte les fonctions suivantes :

  • open(2) pour les fichiers, avec O_RDONLY, O_WRONLY, O_RDWR (évidemment) ; mais aussi O_CREAT, O_TRUNC et O_EXCL.
  • creat(2) (trivial)
  • read(2), write(2)
  • lseek(2), sauf la position courante qui n'est pas suivie sur Graph 35+E II (mais la libc devra la suivre, je serai peut-être obligé de la garder à la main)
  • pread(2), pwrite(2) (pwrite(2) nécessite la position courante)
  • close(2)
  • unlink(2)

Note que l'API des descripteurs de fichiers supporte des descripteurs customisés, ce qui permettra à terme d'ajouter des fichiers en RAM (facile) et des descripteurs de fichiers pour communiquer par USB (facile aussi a priori). Ou des trucs à la demande... et bien sûr tu pourras toujours faire fdopen(3) dessus et derrière ça roule comme sur un OS sérieux.

Le but dans l'immédiat est de rajouter l'API pour les répertoires. Note qu'il n'y a pas d'API standardisée pour lire depuis une répertoire au niveau syscall (Linux utilise l'obsolète readdir(2), ou désormais getdents(2), mais c'est tout caché). À la place, gint fournit directement les fonctions POSIX, à savoir opendir(3), readdir(3) etc. J'ai quasiment fini de coder et tester :

  • mkdir(2)
  • rmdir(2), qui pour l'instant supprime aussi les dossiers non-vides
  • open(2) supporte les répertoires, ainsi que les opérations lseek(2) et close(2)
  • opendir(3), readdir(3), seekdir(3), telldir(3), rewinddir(3), closedir(3)
  • dirfd(3), fdopendir(3)

Pour l'instant il n'y a pas de plan de supporter un truc plus avancé comme scandir(3) ou glob(3), mais ça viendra peut-être plus tard. La deadline que je vise se compte en jours tout au plus.

Une fois que ça ce sera fait (mon espoir secret est que ce soit le cas ce soir) je retourne sur <stdio.h> dont j'ai codé les toutes bases (la structure FILE et le buffering).
Slyvtt Hors ligne Membre Points: 260 Défis: 0 Message

Citer : Posté le 20/12/2021 20:38 | #


Super, tu avances bien.
Avec ça tu auras une API compatible standard C, c'est nickel.

Bon courage pour le test
Ninestars Hors ligne Membre Points: 2449 Défis: 24 Message

Citer : Posté le 21/12/2021 10:34 | #


Super ! Ça va bien simplifier la gestion des fichiers ! Bravo
Lephenixnoir Hors ligne Administrateur Points: 21353 Défis: 149 Message

Citer : Posté le 21/12/2021 10:35 | #


Merci. Que sur la Graph 35+E II et Graph 90+E pour l'instant. Le vieux système de fichiers est trop mauvais pour supporter une telle interface. Après ce sera toujours possible d'ouvrir des fichiers en RAM et de faire majoritairement pareil je pense, à voir.
Ninestars Hors ligne Membre Points: 2449 Défis: 24 Message

Citer : Posté le 21/12/2021 10:42 | #


Ohhh pas de problèmes pour moi tu sais... avec ma nouvelle 90E+ je suis au gout du jour désormais
Lephenixnoir Hors ligne Administrateur Points: 21353 Défis: 149 Message

Citer : Posté le 21/12/2021 10:45 | #


Ok bien reçu
Lephenixnoir Hors ligne Administrateur Points: 21353 Défis: 149 Message

Citer : Posté le 23/12/2021 01:22 | #


Tout ce qui est mentionné dans ce message est maintenant poussé, et testé plutôt en détail.

Je pense qu'il me manque encore un genre de stat() pour pouvoir supporter tout <stdio.h> mais pour l'instant on va dire que ça peut attendre.
Massena Hors ligne Rédacteur Points: 1961 Défis: 11 Message

Citer : Posté le 23/12/2021 08:40 | #


Du coup l'API de fichiers est complète et fonctionnelle maintenant ? Et gint passe à une nouvelle version ?
Lephenixnoir Hors ligne Administrateur Points: 21353 Défis: 149 Message

Citer : Posté le 23/12/2021 09:22 | #


Quasiment ouais ! Niveau gint c'est à peu près bon, j'attends juste de voir si j'ai besoin de stat() etc. Mais une nouvelle version est imminente en effet.

Côté fxlibc il y a encore <stdio.h> à supporter (fopen() et compagnie).
Kikoodx Hors ligne Membre Points: 2834 Défis: 11 Message

Citer : Posté le 23/12/2021 11:10 | #


Super j'attendais ça avec impatience depuis quelques jours

Cependant j'ai de petites erreurs. J'inclus fnctl.h, sys/stat.h, unistd.h et O_WRONLY n'est pas trouvé par gcc. Si je remplace par 0 ça compile, mais close et open sont indéfinis. Faut mettre à jour autre chose que gint ? Inclure d'autres headers ? Merci d'avance

Logs complets :
> fxsdk build-cg
Consolidate compiler generated dependencies of target proj
[  3%] Building C object CMakeFiles/proj.dir/src/input.c.obj
/home/kdx/projects/jtmm2/src/input.c: In function ‘input_init’:
/home/kdx/projects/jtmm2/src/input.c:22:52: error: ‘O_WRONLY’ undeclared (first use in this function)
   22 |         if (log) input.fd_log = open("jtmm2.demo", O_WRONLY);
      |                                                    ^~~~~~~~
/home/kdx/projects/jtmm2/src/input.c:22:52: note: each undeclared identifier is reported only once for each function it appears in
make[3]: *** [CMakeFiles/proj.dir/build.make:132: CMakeFiles/proj.dir/src/input.c.obj] Error 1
make[2]: *** [CMakeFiles/Makefile2:83: CMakeFiles/proj.dir/all] Error 2
make[1]: *** [Makefile:91: all] Error 2
make: *** [Makefile:2: all] Error 2

> fxsdk build-cg
Consolidate compiler generated dependencies of target proj
[  3%] Building C object CMakeFiles/proj.dir/src/input.c.obj
[  6%] Linking C executable proj
/home/kdx/.local/share/giteapc/Lephenixnoir/sh-elf-gcc/lib/gcc/sh3eb-elf/11.1.0/../../../../sh3eb-elf/bin/ld: CMakeFiles/proj.dir/src/input.c.obj: in function `_input_deinit':
input.c:(.text+0x24): undefined reference to `_close'
/home/kdx/.local/share/giteapc/Lephenixnoir/sh-elf-gcc/lib/gcc/sh3eb-elf/11.1.0/../../../../sh3eb-elf/bin/ld: CMakeFiles/proj.dir/src/input.c.obj: in function `_input_init':
input.c:(.text+0x6c): undefined reference to `_open'
collect2: error: ld returned 1 exit status
make[3]: *** [CMakeFiles/proj.dir/build.make:396: proj] Error 1
make[2]: *** [CMakeFiles/Makefile2:83: CMakeFiles/proj.dir/all] Error 2
make[1]: *** [Makefile:91: all] Error 2
make: *** [Makefile:2: all] Error 2

Time is running out
Lephenixnoir Hors ligne Administrateur Points: 21353 Défis: 149 Message

Citer : Posté le 23/12/2021 11:12 | #


Ah pardon j'ai oublié de spécifier que les en-têtes et une partie des définitions sont dans la fxlibc ! Ça fait partie du standard POSIX et compte tenue de l'approche qu'on a prise avec Yatis c'est défini dans la fxlibc même si les détails sont implémentés dans gint.

Si tu veux la motivation c'est que Yatis pourra implémenter pareil dans Vhex et ensuite les abstractions construites par-dessus (comme fopen()) il en bénéficiera dans Vhex sans avoir à les recoder.
Lephenixnoir Hors ligne Administrateur Points: 21353 Défis: 149 Message

Citer : Posté le 31/12/2021 10:58 | #


Nouvelle version : gint 2.7.0

Une assez grosse release qui contient surtout des corrections de bugs ainsi que -tenez-vous bien- le support pour le système de fichiers !

Release associée du fxSDK : fxSDK 2.7.0
Release associée de la fxlibc : fxlibc 1.3.0

Ajouts :
  • Un système de descripteurs de fichiers qui permet d'accéder aux fichiers avec BFile (sur Graph 35+E II et Graph 90+E), mais permettra aussi dans le futur de manipuler des fichiers dans la RAM (sur tous les modèles) ou de communiquer par USB avec les fonctions standard (write(), fwrite(), etc - sur SH4).
  • Beaucoup de fonctions de l'API Unix et standard pour manipuler les fichiers de la mémoire de stockage - plus de détails ci-dessous.
  • Le type de systèmes de fichiers est maintenant exposé dans gint[HWFS] (<gint/hardware.h>) : soit HWFS_FUGUE (Graph 35+E II, Prizm et Graph 90+E), soit HWFS_CASIOWIN (les autres mono).

Changements :
  • Les images pour bopti au format p4 qui sont de taille impaire ont maintenant un demi-octet nul à la fin de chaque ligne. Précédemment, les lignes pouvaient commencer au milieu d'un octet. Ce changement est utile pour supporter les formats p4 et p8 optimisés dans Azur.
  • La pile fait maintenant 14 kio au lieu de 8 kio sur Graph 35+E II parce que BFile utilise des grosses variables locales. Ça réduit donc de 6 kio la taille du (déjà petit) tas disponible dans la RAM utilisateur. Une System ERROR pour les dépassements de pile a été ajoutée, mais elle ne détecte pas l'overflow tout le temps (c'est un problème difficile).
  • <gint/bfile.h> expose maintenant BFile_Seek() (tous modèles), BFile_GetPos() (Graph 90+E uniquement), et les codes d'erreur.

Corrections de bugs :
  • Les lignes verticales à x=395 sur Graph 90+ étaient ignorées.
  • sleep_us_spin() pouvait tourner à l'infini si les interruptions étaient activées durant l'appel, parce que TCR.UNIE était laissé actif sur le timer. L'interruption pouvait alors effacer TCR.UNF sans qu'il ne soit vu par le thread principal.
  • Exécuter dupdate() très fréquemment sur Graph 90+E pouvait freeze parce que la fonction attendait la fin d'un dupdate() précédent avant d'envoyer les pixels mais après avoir envoyé les coordonnées de la fenêtre. Les écritures par le DMA d'un dupdate() encore en cours pouvaient donc interférer avec les commandes qui indiquent les coordonnées.
  • Les registres mach et macl n'étaient pas sauvegardés correctement lors d'une interruption sur SH3, ce qui cassait les multiplications d'une façon assez marrante par moments.

Support des API Unix et standard pour le système de fichiers

Sur les calculatrices avec Fugue (ie. Graph 35+E II et Graph 90+E), gint supporte l'accès au système de fichiers par les API Unix et une partie du standard POSIX. N'oubliez pas de faire un world switch pour accéder au système de fichiers.

Les headers <unistd.h>, <fcntl.h>, <dirent.h> et <sys/stat.h> sont fournis par la fxlibc, tandis que le code est fourni par gint.

Pour ce qui est des fichiers, gint implémente les fonctions suivantes :

  • open(2), avec O_RDONLY, O_WRONLY, O_RDWR (évidemment) ; mais aussi O_CREAT, O_TRUNC et O_EXCL.
  • creat(2) (trivial)
  • read(2), write(2)
  • lseek(2), sauf la position courante qui n'est pas suivie sur Graph 35+E II
  • pread(2), pwrite(2) (pwrite(2) nécessite la position courante)
  • close(2)
  • unlink(2)
  • stat(2)

Et côté répertoires :

  • mkdir(2) et rmdir(2)
  • open(2), lseek(2) et close(2) sur les répertoires (mais il vaut mieux utiliser opendir(3))
  • opendir(3), readdir(3), seekdir(3), telldir(3), rewinddir(3), closedir(3)
  • dirfd(3), fdopendir(3)

Ça veut dire que, sur Graph 90+E au moins, personne ne devrait plus jamais avoir à s'embêter avec BFile
Ninestars Hors ligne Membre Points: 2449 Défis: 24 Message

Citer : Posté le 31/12/2021 11:26 | #


Excellent, super maj
Lephenixnoir Hors ligne Administrateur Points: 21353 Défis: 149 Message

Citer : Posté le 10/01/2022 14:43 | #


Après avoir bataillé 4 jours, j'ai fini par mettre le doigt sur un bug qui était passé inaperçu durant la précédente mise à jour.

(Pour ceux qui se demandent comment ce genre de choses arrive, c'est assez facile : ça marche très bien pendant des jours, parfois des semaines ou des mois, et tout à coup ça crashe parce que les étoiles se sont «alignées» pour permettre la manifestation du bug. Et là je sors mon manteau, ma pipe, ma loupe et ma déprime jusqu'à ce que le crash élusif mène à une explication concrète.)

Donc l'origine de ce bug c'est un détail que j'avais oublié depuis longtemps et qui est qu'on ne peut pas écrire dans un fichier depuis la ROM (virtualisée ou pas) ; les données qu'on envoie doivent être dans la RAM. On ne sait pas exactement pourquoi, parce que l'explication dépend de plein de détails cachés de l'OS. Le truc c'est que plein de choses sont dans la ROM. Par exemple :

write(fd, "Hello, world!\n", 14);
//        ^^^^^^^^^^^^^^^^^
//        Ça c'est dans la ROM!

Donc voilà un de mes tests a crashé Jeudi pour ça et j'ai compris ce matin. Du coup j'ai modifié write() pour que si on lui demande d'écrire depuis la ROM il se débrouille pour copier d'abord les données vers la RAM (par blocs ou d'un coup selon combien de mémoire est disponible à ce moment-là), ce qui est transparent pour vous.

Un nouveau patch de gint arrivera donc sous peu, le temps que tout ça soit bien testé.
Précédente 1, 2, 3 ··· 10 ··· 20 ··· 30 ··· 40 ··· 50 ··· 59, 60, 61, 62

LienAjouter une imageAjouter une vidéoAjouter un lien vers un profilAjouter du codeCiterAjouter un spoiler(texte affichable/masquable par un clic)Ajouter une barre de progressionItaliqueGrasSoulignéAfficher du texte barréCentréJustifiéPlus petitPlus grandPlus de smileys !
Cliquez pour épingler Cliquez pour détacher Cliquez pour fermer
Alignement de l'image: Redimensionnement de l'image (en pixel):
Afficher la liste des membres
:bow: :cool: :good: :love: ^^
:omg: :fusil: :aie: :argh: :mdr:
:boulet2: :thx: :champ: :whistle: :bounce:
valider
 :)  ;)  :D  :p
 :lol:  8)  :(  :@
 0_0  :oops:  :grr:  :E
 :O  :sry:  :mmm:  :waza:
 :'(  :here:  ^^  >:)

Σ π θ ± α β γ δ Δ σ λ
Veuillez donner la réponse en chiffre
Vous devez activer le Javascript dans votre navigateur pour pouvoir valider ce formulaire.

Si vous n'avez pas volontairement désactivé cette fonctionnalité de votre navigateur, il s'agit probablement d'un bug : contactez l'équipe de Planète Casio.

Planète Casio v42 © créé par Neuronix et Muelsaco 2004 - 2022 | Il y a 49 connectés | Nous contacter | Qui sommes-nous ? | Licences et remerciements

Planète Casio est un site communautaire non affilié à Casio. Toute reproduction de Planète Casio, même partielle, est interdite.
Les programmes et autres publications présentes sur Planète Casio restent la propriété de leurs auteurs et peuvent être soumis à des licences ou copyrights.
CASIO est une marque déposée par CASIO Computer Co., Ltd