Seuls les membres ayant 30 points peuvent parler sur le 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: 18201 Défis: 142 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 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

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 make et make install.


Fichier joint


Précédente 1, 2, 3 ··· 10 ··· 20 ··· 30 ··· 38, 39, 40, 41, 42, 43 Suivante
Lephenixnoir Hors ligne Administrateur Points: 18201 Défis: 142 Message

Citer : Posté le 11/06/2020 19:13 | #


Ooh je ne savais pas qu'on avait le syscall 0x001 pour faire ça. Intéressant ! Ce sera sans doute plus fiable que le handler, comme tu dis. Est-ce que tu sais si ce syscall a des effets indésirables comme modifier la VBR ou ce genre de choses ? :o

L'affichage n'est pas trop un problème, je peux de toute façon vérifier que la page demandée est valide avant d'appeler le système.

Du reste oui, faut mettre plein de trucs en RAM. Est-ce que c'est mieux si les drivers y sont, je sais pas. D'un côté la RAM est plus rapide en théorie, de l'autre c'est pas de beaucoup et la RAM a déjà beaucoup plus de pression dans l'application à cause de la VRAM. Je sais pas à quel point un accès à la ROM peut être "parallèle" parce qu'il y a un bus d'adresse plus ou moins partagé entre le proco et tout le reste. Éventuellement on peut mettre du code critique dans la mémoire IL (sur SH4) mais ça je n'ai pas encore vraiment testé en termes de performance.
Yatis Hors ligne Membre Points: 513 Défis: 0 Message

Citer : Posté le 11/06/2020 19:53 | #


Ooh je ne savais pas qu'on avait le syscall 0x001 pour faire ça. Intéressant !

Tu m'as mis un doute, du coup j'ai regardé rapidement le code et en fait elle s'occupe uniquement d'afficher la popup avec les infos sur le TLB miss. J'étais persuadé que ça traitais l'exception, désolé

Est-ce que c'est mieux si les drivers y sont, je sais. D'un côté la RAM est plus rapide en théorie [...]

Je ne parlais pas en matière de rapidité mais en matière de "laisser charger les drivers" constamment pour éviter que le système les décharges ; le but étant d'être sûr que Gint aura jamais de TLB miss pour lui. Sinon je n'ai aucune idée de si ce sera plus rapide, probablement mais pas sûr que ce sois flagrant (?)
Lephenixnoir Hors ligne Administrateur Points: 18201 Défis: 142 Message

Citer : Posté le 11/06/2020 20:01 | #


Ah oui ok, l'intérêt de la RAM en ce que les drivers n'ont pas besoin d'être mappés. Oui c'est un peu mon but, mais je sais pas où mettre la limite. En plus faudra que je fasse gaffe aux interruptions parce que les callbacks peuvent créer des TLB miss et actuellement je réactive pas les interruptions dans les callbacks. Je sens que ça va me jouer des tours.

Ajouté le 11/06/2020 à 20:05 :
J'étais persuadé que ça traitais l'exception, désolé

Mais en fait ça pourrait être la bonne piste. Je vais regarder si je peux utiliser Hmem_SetMMU() ou les autres syscalls TLB que j'ai découverts en plus de ceux de SimLo !
Yatis Hors ligne Membre Points: 513 Défis: 0 Message

Citer : Posté le 11/06/2020 20:10 | #


Je vais regarder si je peux utiliser Hmem_SetMMU() ou les autres syscalls TLB que j'ai découverts en plus de ceux de SimLo !

Il me semblait que ces sycall là n'étaient plus implémentés ? Le mieux serai de désassembler la partie de la VBR qui gère l'exception et voir s’il y a des appels système qui trainent (dans mes souvenirs ce n'est pas le cas).
Lephenixnoir Hors ligne Administrateur Points: 18201 Défis: 142 Message

Citer : Posté le 11/06/2020 20:11 | #


J'ai refait un tour et effectivement Hmem_SetMMU() ne fait plus rien. Les autres syscalls que je connais ne sont pas spécifiques aux add-ins. Hmm... je peux regadrer dans le handler et dans App_Start() aussi. Je te dis si je trouve quelque chose d'intéressant

Ajouté le 11/06/2020 à 21:54 :
Donc j'ai regardé un peu les syscalls de plus près et en fait c'est pas 0x001 qui nous intéresse mais 0x003 (merci Yatis !). J'ai désassemblé la version 3.10 et par rapport à ce à quoi je m'attendais c'est *très* proche de ce dont j'ai besoin. Il va falloir désassembler plus, sur d'autres versions, et surtout tester, mais il est possible que cette histoire de se passe bien grâce à une bonne organisation dans l'OS (qui l'eût cru ?).

Ajouté le 11/06/2020 à 22:44 :
Bon j'ai fini de désassembler la chose avec l'aide précieuse de Yatis (qui en fait était déjà passé là avant moi donc avait compris 90% du truc xD), si vous avez envie de rigoler vous pouvez jeter un oeil à l'assembleur annoté sur notre dépôt de documentation.

Ce syscall fait vraiment *exactement* ce dont j'ai besoin (bon à part balancer un System ERROR si l'adresse est pas bonne) donc j'ai un bon espoir que ce dernier défi technique ne sera en essence qu'un simple appel de fonction et une réorganisation du linker script pour envoyer plus de code de gint dans la RAM (et deux/trois trucs sur les callbacks d'interruptions comme les timers, mais vous inquiétez pas pour ça).

Il est possible que la prochaine release majeure de gint ("v2" de son petit nom) ne soit plus qu'une question de temps. Stay tuned

Ajouté le 13/06/2020 à 20:31 :
Donc aujourd'hui j'ai modifié fxos pour supporter les OS de Graph 90+E, et j'ai vérifié que le syscall en question fait la même chose sur Graph 90+E que sur les Graph mono, et c'est bon. Les choses se concrétisent. Prochaine étape je fais des tests pour changer dynamiquement les mappings sur Graph 90+E en espérant ne pas me planter. Souhaitez-moi bonne chance :3

Ajouté le 14/06/2020 à 10:17 :
Le syscall en question fait bien son travail sur Graph 90+E d'après mes tests. Donc maintenant il faut que je m'adapte à ce nouveau mode de fonctionnement :
• Il faut que je déplace certaines zones cruciales du noyau, qui sont actuellement dans la zone gérée par le TLB et peuvent donc être déchargées (!)
• Il faut aussi que j'active les interruptions pendant les callbacks de timers et affiliés pour que les TLB miss puissent être gérés à cet endroit

La balle est dans mon camp a priori, sauf mauvaise surprise je vois comment la suite va se passer jusqu'à la prochaine release.

Ajouté le 14/06/2020 à 14:31 :
J'ai progressé ! J'ai implémenté un test dans gintctl avec deux façons de charger des pages : soit directement en appelant le syscall, soit en effectuant un TLB miss normal. La seconde marche à tous les coups avec pour l'instant aucun crash à déplorer. La première crashe de temps en temps et j'ai fini par comprendre pourquoi : parfois l'exécution de getkey() ou le dessin de l'écran charge les pages dont on a besoin par TLB miss. Dans ce cas la deuxième méthode ne fait rien car le TLB miss recherché ne se produit pas. Mais la première méthode va quand même forcer la page à être chargée une *deuxième fois*, ce qui produit un TLB multihit qui est un reset (même pas moyen d'afficher une System ERROR).

Donc... je pense que je suis bon pour l'instant, je vais continuer à isoler ce qu'il faut de gint et à jouer avec les tests pour rendre ça un peu robuste. Il faut aussi que j'active les interruptions pour avoir les TLB miss dans les callbacks de timers. Mais je pense que je suis sur la bonne voie !

Ajouté le 15/06/2020 à 20:49 :
Les progrès de cette semaine sont très bons, presque miraculeux ! Avoir une gestion dynamique du TLB simplifie plusieurs problèmes gênants rencontrés jusqu'ici. Désormais, il n'y a plus que les procédures exécutées avec les interruptions bloquées (ie. le point d'entrée des gestionnaires d'interruption et les fonctions de changement de contexte noyau) qui doivent se trouver en RAM, tout le reste est géré par le TLB.

À ce sujet, il me reste toujours à réactiver les interruptions lors d'un callback de timer pour que le callback puisse produire des TLB miss sans que ce soit une erreur. Je vais voir si je peux tout réactiver, si ça ne marche vraiment pas je bloquerai uniquement les interruptions à proprement parler (VBR + 0x600) avec IMASK.

En attendant, c'est des superbes progrès et gint sur Graph 90+E n'a jamais été aussi stable et aussi élégant !

J'ai backporté les changements liés au TLB vers les Graph mono pour supporter des add-ins jusqu'à 512k (limite imposée par l'OS) au lieu de 220k (limite imposée par le TLB). Pour rappel, la nouvelle limite sur la Graph 90+E est de 2M (limite imposée par l'OS) au lieu de 220k. Je suis hors de Lyon et sans ma Graph SH3 donc la release devra attendre au moins la semaine prochaine, mais ça marche au moins déjà sur SH4. o/

Je suis incroyablement hypé par ces nouveaux changements (même si l'accumulation de ces messages montre que le sujet est trop technique pour remplir convenablement ce topic xD). Je vais bientôt publier une nouvelle bêta sur master quand la fonctionnalité sera stable vis-à-vis des callbacks de timers. Le reste ne sera que la dernière ligne droite !

Ajouté le 16/06/2020 à 21:10 :
J'ai modifié les callbacks de timers pour y activer les interruptions. On peut donc maintenant faire plus de choses dans les callbacks, même si la limite exacte est floue. J'ai trois tests qui passent bien dans gintctl, dont deux trucs un peu tendus : un sleep() dans le callback (ce qui force une interruption à se produire pendant le callback) et lancer+attendre un timer (donc le code normal se fait interrompre, un callback est lancé, qui lance un nouveau timer, qui vient l'interrompre pour lancer un second callback). Ça ça marche, même si je promets pas qu'on puisse tout faire. Gardez vos callbacks simples de façon générale.

Étonnement un TLB miss dans un callback continue de crasher donc il me reste encore des choses à voir. Une fois ce bug passé, je pousserai la première bêta stable avec gestion du TLB. Fini les limites à 220k, enjoy les images en résolution complète sur Graph 90+E.
Lephenixnoir Hors ligne Administrateur Points: 18201 Défis: 142 Message

Citer : Posté le 17/06/2020 14:52 | #


Promis cette saga s'arrête bientôt ! J'ai fini de faire marcher cette histoire de TLB sur les Graph mono SH4 (testé : Graph 75+E, Graph 35+E II) et Graph 90+E. Il me restera à tester la SH3. J'ai donc poussé une nouvelle bêta sur le dépôt.

Nouvelle bêta : gint 2.0.2-beta

Nouvelles fonctionnalités :
• Ajouté la gestion du TLB, ce qui autorise des add-ins jusqu'à 512k (Graph mono) ou 2M (Graph 90) au lieu de 220k.

Changements :
• Renommé image_t en bopti_image_t pour faire une différence propre avec le type img_t utilisé par libimg. Vous devez faire ce changement dans votre code (un simple rechercher/remplacer). Si vous continuer d'utiliser image_t, vous aurez un warning, et à la prochaine release majeure (2.1.0) une erreur.

Corrections de bugs :
• Corrigé un bug de tracé de lignes horizontales (dline() avec y1=y2) où gint écrivait hors de la VRAM si la ligne demandée était entièrement en-dehors de l'écran.
• Corrigé un bug de la famille printf() qui rendait %% inutilisable.

Comme vous pouvez le voir je tente un format un peu plus digeste pour les nouvelles versions ; l'icône est un vieil avatar que j'ai utilisé à une époque, je l'ai choisie simplement pour que les releases soient faciles à voir dans le flot des commentaires.
Dark storm En ligne Membre d'honneur Points: 11108 Défis: 176 Message

Citer : Posté le 17/06/2020 21:57 | #


Wow, cool

Je mets à jour les paquets sur l'AUR
En fait t'as pas poussé sur master, donc gint-git peut pas être à jour
Finir est souvent bien plus difficile que commencer. — Jack Beauregard
Redeyes Hors ligne Membre Points: 561 Défis: 7 Message

Citer : Posté le 18/06/2020 19:45 | #


Salut! J'ai pu installer le fxSDK. J'ai seulement du mal à comprendre les premières instructions du Readme de Gint:
Dans le terminal, je dois me positionner dans le dossier principal de gint ou du fxsdk? (ou alors le dépôt de gint aurait dû être cloné dans le dossier du sdk)?
Ensuite, le terminal n'arrive pas à exécuter le --target=fx9860g. Je vois qu'il est aussi question d'un --prefix mais je ne sais pas quoi faire avec.
~Raisonnance...
Lephenixnoir Hors ligne Administrateur Points: 18201 Défis: 142 Message

Citer : Posté le 18/06/2020 21:12 | #


Dark storm a écrit :
Je mets à jour les paquets sur l'AUR
En fait t'as pas poussé sur master, donc gint-git peut pas être à jour

Eh oui, je l'ai pas dit sur le coup, mais c'est pas encore assez stable ; c'est une bêta, pas une release complète. Mais ça vient bientôt

Redeyes a écrit :
J'ai seulement du mal à comprendre les premières instructions du Readme de Gint:
Dans le terminal, je dois me positionner dans le dossier principal de gint ou du fxsdk? (ou alors le dépôt de gint aurait dû être cloné dans le dossier du sdk)?

Le README de gint parle uniquement du dépôt de gint, sauf mention explicite. Dans ce cas-là, il faut toujours considérer que tu es dans le dossier principal d'un dépôt clôné. C'est en-effet là que commencent les explications (même si on se déplace dans un nouveau dossier build.fx ensuite poru compiler).

Ensuite, le terminal n'arrive pas à exécuter le --target=fx9860g. Je vois qu'il est aussi question d'un --prefix mais je ne sais pas quoi faire avec.

Contrairement à ce que la coloration syntaxique maladroite de Gitea laisse entendre, la commande c'est bien ../configure --target=fx9860g. Le premier mot d'une commande est toujours le nom d'un outil ou programme à invoquer, et traditionnellement les mots qui commencent par un tiret sont des options (-o, --option, --option=valeur sont les formes les plus courantes). Ici tu dois appeler le script ../configure qui est à la racine du dépôt avec l'option --target=fx9860g (littéralement : on cible les Graph mono).

L'option --prefix te permet de choisir le dossier dans lequel gint sera installé. Le nom "prefix" est très classique et tu le retrouves partout dans les instructions d'installation (... de toute ce que tu installes depuis les sources au lieu du gestionnaire de paquets). Ici, tu ne dois normalement pas t'en servir car gint doit s'installer quelque part dans les fichiers de GCC et il trouve le bon endroit tout seul (d'ailleurs la commande affichera où).
Redeyes Hors ligne Membre Points: 561 Défis: 7 Message

Citer : Posté le 19/06/2020 01:51 | #


Je ne comprends pas...J'ai pourtant tout installé du cross-compilateur et malgré ça lorsque je veux faire le build pour fx-cg50 et pour fx-9860g, j'ai tout le temps cette erreur et ne veut plus continuer après:
redeyes@Red-VirtualBox:~/gint$ mkdir build.cg && cd build.cg
redeyes@Red-VirtualBox:~/gint/build.cg$ ../configure --target=fxcg50
No prefix specified, let's ask the compiler:
    sh-elf-gcc --print-search-dirs | grep install | sed 's/install: //'
../configure: ligne 160: sh-elf-gcc : commande introuvable
Got ' '.
Directory does not exist (or is not a directory), giving up.


Pourtant sh-elf-gcc est bien dans mon pc et mon PATH contient le dossier qui le possède:
redeyes@Red-VirtualBox:~/gint/build.cg$ echo $PATH
/home/redeyes/.local/bin:/usr/local/sbin:usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/home/redeyes/opt/sh-elf-2.34-9.3.0/bin

Résultat, je ne sais plus quoi faire.
~Raisonnance...
Dark storm En ligne Membre d'honneur Points: 11108 Défis: 176 Message

Citer : Posté le 19/06/2020 02:03 | #


Que donne un ls ~/opt ? Au passage, la commande export PATH=PATH:new/path est à lancer à chaque ouverture de terminal, sauf si tu as ajouté la commande au fichier ~/.profile ou .bashrc.
Finir est souvent bien plus difficile que commencer. — Jack Beauregard
Redeyes Hors ligne Membre Points: 561 Défis: 7 Message

Citer : Posté le 19/06/2020 20:31 | #


Que donne un ls ~/opt ?
J'obtient sh-elf-2.34-9.3.0

la commande export PATH=PATH:new/path est à lancer à chaque ouverture de terminal, sauf si tu as ajouté la commande au fichier ~/.profile ou .bashrc.
D'accord! Je l'ai fait, puis j'ai intégré la commande du tutoriel de gcc :
% echo "export PATH=\"\$PATH:$PREFIX/bin\"" >> $HOME/.profile

Je peux retenter le build de gint à présent?

edit: le build ne marche toujours pas
~Raisonnance...
Lephenixnoir Hors ligne Administrateur Points: 18201 Défis: 142 Message

Citer : Posté le 19/06/2020 21:31 | #


Je devrais préciser que .profile n'est chargé qu'au lancement de ta session donc il faut au moins te déconnecter.

Si tu as un doute, ouvre un terminal au hasard et vérifie que le dossier est bien dans ton PATH, puis que GCC est bien trouvé (which sh-elf-gcc te le dira).

Au fait ne configure pas avec sudo.
Redeyes Hors ligne Membre Points: 561 Défis: 7 Message

Citer : Posté le 20/06/2020 13:57 | #


J'ai tout recommencé à zéro pour la compilation de gcc, maintenant sh-elf-gcc est bien repéré par le terminal!
Le ../configure --target= m'autorise le make pour fx9860 et cg50, mais j'ai cette erreur qui apparaît:

FileNotFoundError: [Errno 2] No such file or directory: 'sh-elf-objcopy'
make: *** [Makefile:109: src/font5x7.png.o] Error 1


C'est quand je veux faire le build pour fx9860g. Et pour cg50 c'est à peu près la même erreur, mais pour l'autre image font8x9.png.
~Raisonnance...
Lephenixnoir Hors ligne Administrateur Points: 18201 Défis: 142 Message

Citer : Posté le 20/06/2020 14:14 | #


L'outil fxconv du fxSDK a voulu appeler sh-elf-objcopy à un moment de la conversion. Tout comme sh-elf-gcc, il devrait être quelque part dans ton PATH et disponible. Est-ce que which sh-elf-objcopy te renvoie bien quelque chose ? (Ça me surprend un peu cette erreur parce que binutils doit être installé si GCC marche, mais bon.)
Redeyes Hors ligne Membre Points: 561 Défis: 7 Message

Citer : Posté le 20/06/2020 14:30 | #


Comme les erreurs que je recevais portaient surtout sur le fait que les fichiers sh-elf-objcopy et sh-elf-ar n'étaient pas retrouvés, j'ai vu dans le dossier du PATH que ces fichiers s'appelaient sh-elfobjcopy et sh-elfar. Je les ai juste renommés dans le dossier en ajoutant le "-" manquant .
~Raisonnance...
Lephenixnoir Hors ligne Administrateur Points: 18201 Défis: 142 Message

Citer : Posté le 20/06/2020 14:45 | #


Ah mais je vois que tu as oublié un caractère dans la commande de binutils. C'est "--program-prefix=sh-elf-" avec un tiret à la fin !
Redeyes Hors ligne Membre Points: 561 Défis: 7 Message

Citer : Posté le 20/06/2020 22:26 | #


Lephenixnoir a écrit :
Ah mais je vois que tu as oublié un caractère dans la commande de binutils. C'est "--program-prefix=sh-elf-" avec un tiret à la fin !
What?! Aah mais oui c'est vrai ça, d'accoord!
Du coup dans ce même fichier je dois rajouter ce petit tiret dans tous les noms de fichiers sh-elf ?
~Raisonnance...
Lephenixnoir Hors ligne Administrateur Points: 18201 Défis: 142 Message

Citer : Posté le 20/06/2020 22:34 | #


Tu devrais oui, dans le dossier bin, renommer tout le monde. Je suppose que ça marche, enfin si un jour t'as des problèmes bizarres ça viendra peut-être de là. x)
Hackcell Hors ligne Membre Points: 1344 Défis: 11 Message

Citer : Posté le 20/06/2020 22:34 | #


faut recompiler, il me semble que le nom est utilisé en interne
Lephenixnoir Hors ligne Administrateur Points: 18201 Défis: 142 Message

Citer : Posté le 20/06/2020 22:37 | #


Aha RIP. Ça m'est arrivé une fois aussi, j'ai tout recompilé dans le doute. Sinon tu fous des liens symboliques pour tout le monde non ?

Ajouté le 20/06/2020 à 23:06 :
J'ai poussé sur la branche dev une modification de la fonction timer_setup() qui permet de configurer les timers. Je sais que c'est un point compliqué pour pas mal de gens, donc j'ai essayer de simplifier ça sans casser le code qui veut exploiter toute la puissance du système.

La nouvelle fonction a un prototype largement plus simple avec seulement trois arguments obligatoires :
• Le timer que vous voulez utiliser (vous pouvez aussi laisser gint en choisir un)
• Le délai en micro-secondes
• La fonction à appeler une fois le délai écoulé

Modification 1 : plus besoin de gérer les numéros de timers. En général vous vous en foutez pas mal de savoir qui est un TMU et qui est un ETMU, disponible ou pas, et si la précision est de 0.3 ms ou 0.3 µs. Et en général perso j'ai pas envie de traquer quel timer j'ai utilisé à quel endroit. Et donc on peut simplifier les deux situations en mettant TIMER_ANY en premier argument. gint se charge de trouver un timer disponible qui est capable d'attendre le délai que vous demandez.

/* Exécuter f() dans 25 ms */
int timer = timer_setup(TIMER_ANY, 25000, f);
if(timer >= 0) timer_start(timer);

Évidemment il faut quand même vérifier qu'un timer libre existe bel et bien; timer_setup() renvoie -1 si aucun timer n'est disponible pour répondre à votre demande.

Modification 2 : le délai directement en micro-secondes. Mais si vous voulez utiliser explicitement un timer par son ID, le délai est traité comme une valeur de TCOR, comme avant (utile pour libprof et le moteur de gris, notamment). Mais bon les power users peuvent lire le header, je détaille pas ici.

Modification 3 : plus de type bizarre sur les fonctions de callback . Grâce à de la magie noire de GCC, timer_setup() accepte différents types de callbacks, notamment int f(void) (aucun argument). Dans ce cas vous n'êtes pas obligés de passer un argument à timer_setup(). Le callback peut avoir au plus un argument qui doit forcément être de 4 octets (en gros : un entier ou un pointeur).

/* Exécuter f() dans 25 ms */
int f(void) { ... return TIMER_STOP; }
int timer = timer_setup(TIMER_ANY, 25000, f);
if(timer >= 0) timer_start(timer);

/* Exécuter g(5) dans 25 ms */
int  g(int x) { ... x ... return TIMER_STOP; }
int timer = timer_setup(TIMER_ANY, 25000, g, 5);
if(timer >= 0) timer_start(timer);

Comme avant le callback doit renvoyer un entier indiquant au timer s'il doit continuer à tourner ou s'arrêter. Mais au lieu de 0 et 1, ils s'appellent maintenant TIMER_CONTINUE et TIMER_STOP, ce qui est quand même plus agréable.

Pour adapter votre code. La plupart des appels à timer_setup() jusque-là avaient cette forme :

timer_setup(<id>, timer_delay(<id>, <delay>), timer_default [ou 0], <callback>, <arg>);

La façon safe de transposer ça dans la nouvelle API sans risquer de problème est ceci :

timer_setup(<id>, timer_delay(<id>, <delay>, TIMER_Pphi_4), <callback>, <arg>);

Mais ça c'est que si vous voulez utiliser explicitement le timer <id>. Si au fond n'importe quel timer vous convient, vous pouvez utiliser TIMER_ANY et dans de cas gint calculer timer_delay() pour vous. Votre code devient :

timer_setup(TIMER_ANY, <delay>, <callback>, <arg>);

Enfin si votre callback ne prend au fond pas d'argument (avant vous étiez obligés d'en avoir un de type volatile void *), vous pouvez le retirer (votre callback et alors de type int callback(void)) et ne plus le passer à timer_setup(). Votre code devient :

timer_setup(TIMER_ANY, <delay>, <callback>);


Voilà, j'espère que ça vous simplifiera les choses pour aborder tranquillement les timers sans maux de tête. J'ai fait de mon mieux pour garder l'API proche de l'ancienne version pour que les changements soient faciles pour vous.

Ajouté le 29/06/2020 à 21:32 :
Je continue à bosser sur la prochaine release. Actuellement, j'essaie de rendre gint compatible avec l'émulateur officiel Graph 90+E. La plupart des choses semblent fonctionner, mais l'affichage à l'écran non (ce qui rend difficile le test dans la plupart des cas !).

J'ai déjà déterminé que la méthode naïve pour afficher des données (envoyer chaque pixel à l'écran par l'action du CPU) fonctionne, seule la méthode DMA semble échouer. Je vais voir ce que je peux trouver là-dessus, au pire cas je peux toujours utiliser la méthode naïve car les problèmes de performance ne sont pas aussi intéressants sur l'émulateur que sur la calculatrice.

S'il s'est passé un bon moment depuis la dernière update (9 jours) c'est qu'en décortiquant l'émulateur j'ai trouvé plein d'infos intéressants sur le SH7305 et j'ai pris un moment pour évaluer les conséquences sur le reverse-engineering du matériel avec Yatis.

Ajouté le 02/07/2020 à 11:21 :
J'ai progressé. En fait je crois que sur la calculatrice la RAM est à 8c000000 (ou ac000000) tandis que sur l'émulateur elle est à 88000000 (ou 8c000000). La preuve c'est que je me sers de cette méthode pour différencier Prizm et Graph 90+E et l'émulateur est détecté comme une Prizm ! De plus, les problèmes d'affichage n'étaient pas liés au DMA mais au fait que j'utilisais une zone de RAM qui n'existait pas (puisque pas au bon endroit dans la RAM).

Il est donc possible que l'émulateur est la Graph 90+E n'utilisent pas tout à fait le même OS. Ça mérite d'être étudié.

Ajouté le 02/07/2020 à 16:08 :
Alright, donc grâce aux mécanismes de compatibilité Prizm de gint, la transition vers l'émulateur s'est faite sans problème. Le fx-CG Manager de Casio est désormais officiellement une platforme supportée par gint

Je pense que c'est le bon moment pour tester sur Prizm aussi.

--

Sentaro21, a couple months ago you mentioned that you might be able to test the project on fx-CG 20. If you can still do it, please download the test application gintctl.g3a (you will need to rename it).

The application has many tests but I'm interested in the following information in the GINT tab:
• In "Hardware", the "MPU/CPU" page should show "Calculator model: Prizm fx-CG 20"
• In "Memory dump", you should be able to press F3 then F6 to dump some of the RS RAM to a file called RS00.bin without a crash
• In "Switch to OS", you shoud be able to press F1 (SWITCH) repeatedly without a crash, and you should also be able to press F3 (MENU) to switch between the main menu and the add-in.
• In "TLB management", pressing F5 (MISS) and F6 (TIMER) should map new pages (more squares should be green).
• In "Timers", you should see TMU2 and ETMU5 running, and pressing F1 (SLEEP) sould make TMU0 run for about a second
Finally, in the MEMORY tab of the main menu, you should be able to press F3 (ROM) then Up and have a red "TLB error" on screen.

Because it works on fx-CG 50 and in the fx-CG Manager which behaves like an fx-CG 20, I am confident this will work.
Précédente 1, 2, 3 ··· 10 ··· 20 ··· 30 ··· 38, 39, 40, 41, 42, 43 Suivante

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
Pour coloriser votre code, cliquez ici.
Sinon cliquez sur le bouton ci-dessous.
: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 - 2020 | Il y a 44 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