Seuls les membres ayant 30 points peuvent parler sur le chat.

Forum Casio - Projets de programmation


Index du Forum » Projets de programmation » gint : un environnement de développement d'add-ins
LephenixnoirHors ligneAdministrateurPoints: 15231 Défis: 136 Message

gint : un environnement de développement d'add-ins

Posté le 20/02/2015 17:30

En général, quand on veut écrire un add-in, on dégaine le fx-9860G SDK de Casio et sa bibliothèque fxlib, ou bien le PrizmSDK si la calculatrice visée est en couleurs.

gint est une alternative à tout ça. C'est un environnement de développement qui fonctionne sous Linux (et avec un peu de travail sous Windows) et vous permet de créer des add-ins avec gcc et sa suite. Il marche bien sur Graph monochromes, et je suis en train de le porter sur Graph 90. Un joli programme !

Comparé aux SDKs habituels, gint est plus proche du matériel et contrôle donc le clavier, l'écran ou l'horloge avec plus de finesse. Concrètement, ça veut dire que vous pouvez appuyer sur plusieurs touches à la fois, faire exécuter une fonction toutes les 5 ms, ou ne rafraîchir que la moitié de l'écran.

gint sur Graph monochrome



gint existe sur Graph monochrome depuis un moment et le cœur de la bibliothèque arrivera bientôt à sa version finale.

Comparé à fxlib, vous pouvez faire ce genre de joyeusetés...
– Des graphismes en 4 couleurs avec le moteur de gris
– Un contrôle détaillé du clavier pour les jeux, parfait pour les combos !
– Des timers avec une précision de 30 µs, d'autres à 60 ns
– Des fonctions de dessin de texte et d'image fulgurantes
– La conversion automatique des images grâce à fxconv (du fxSDK)
– La compatibilité SH3 et SH4 sans avoir à modifier les sources.

L'inconvénient principal est que gint est un gros morceau qui se baladera dans votre g1a. Ça représenté environ 30 ko, que vous pouvez comparer au 18 ko de sprintf() quand vous utilisez le SDK !

gint sur Graph 90



gint était à l'origine conçu pour Graph 85. J'avance tranquillement sur le portage avec la Graph 90, qui demande de réorganiser pas mal de code. J'arrive désormais à faire pas mal de choses :
– Installer gint et remplacer le gestionnaire d'interruptions
– Communiquer avec l'écran (méthode lente et non finale)
– Utiliser les 9 timers disponibles
– Configurer la RTC (horloge) et l'utiliser comme un timer
– Mesurer la fréquence des horloges (préparatif pour l'overclock)
– Les fondamentaux sur la manipulation du clavier

Si vous avez déjà programmé une Prizm, vous savez qu'il y a une bande blanche dans laquelle on ne peut rien afficher. Ce genre de choses se contourne bien avec gint, comme le montre la photo

Tester gint sur une Graph monochrome

Note : la procédure ci-dessous est pour la dernière version publique de gint, que j'ai publiée avant d'attaquer le portage sur Graph 90. Ça date un peu ^^'

Si vous avez un moment, je suis toujours à la recherche de tests pour vérifier que tout marche bien. Vous en avez pour 15 minutes environ !

1. Transférez l'add-in de test de gint (téléchargeable ici), sur votre machine, et lancez-le en maintenant EXE appuyé. L'écran de contrôle (image 1) apparaît.
2. Notez ses contenus quelque part pour me les envoyer. S'il n'y a pas "Boot OK" en haut à droite, faites un RESET et arrêtez là, car gint ne fonctionne pas. Sinon, appuyez sur une touche.
3. Effectuez les différents tests de l'onglet TEST. N'hésitez pas à signaler ce qui peut vous sembler bizarre !


Images 1 et 2 : L'écran de contrôle de gint, et le menu principal

Keyboard & events : vous devez pouvoir appuyer sur 3 ou 4 touches simultanément et visualiser des nom et nombre de répétition corrects, même si vous suivez des séquences exotiques. Vous pouvez voir le shadowing en constant que Left + Down + SHIFT déclenche ALPHA.
Gray engine : vérifiez que le réglage initial (DEFT) est satisfaisant pour un contraste moyen. Vous pouvez jouer avec les délais et voir comment l'illusion varie.
Image rendering : les images doivent s'afficher correctement dans tous les positions, mêmes si elles dépassent de l'écran.
Text rendering : vous devez voir les 6 lignes de 32 caractères en entier pour chaque police.
Real-time clock : l'horloge doit avancer seconde après seconde. Mettez-la à l'heure ou modifiez légèrement l'heure indiquée : le réglage doit persister.
Clocks and timers : dans l'onglet TIME, le timer et l'horloge doivent avancer sensiblement à la même vitesse.

4. Placez-vous ailleurs que dans le menu principal, appuyez sur MENU et vérifiez que vous retournez bien au menu de la calculatrice. Retournez dans l'application de test, vous devez réapparaître à l'endroit où vous l'aviez laissée.
5. Envoyez-moi vos résultats par un message sur ce topic. Et soyez remerciés !

Installer et utiliser gint sur votre système, pour développer

L'utilisation normale de gint est en l'associant avec le fxSDK, qui fournit les options de compilation/édition des liens appropriées, le linker script particulier de gint ainsi que les outils de conversion compatibles avec la bibliothèque. Si vous voulez utiliser le fxSDK tout entier (recommandé), suivez ses instructions d'installation, gint est fourni avec.

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. Ils sont tous dans le sous-dossier gint du dossier d'installation du fxSDK, que vous pouvez afficher en exécutant fxsdk --folder.

Si vous voulez utiliser directement gint sans le fxSDK (soyez sûrs que vous savez ce que vous faites), vous pouvez ou télécharger l'archive, ou le compiler à la main. Notez que la compilation requiert quand même le fxSDK... pas besoin de l'installer par contre, il vous suffit de placer fxsdk/bin dans le PATH après compilation.

$ git clone "http://git.planet-casio.com/lephe/gint" && cd gint
$ ./configure --startup-log # Ce que vous voulez
$ make all-lib

Ici aussi, vous ne voudrez probablement pas l'installer, juste linker la bibliothèque. Je rappelle que l'ordre de linkage compte, et que vous devez absolument compiler avec gcc <options> <objets...> -lgint -lc -lgcc, et dans cet ordre.


Comment ça marche

gint est essentiellement organisé autour d'un gestionnaire d'interruptions, une routine qui répond aux signaux émis par les composants pour signaler des événements intéressants (décompte du temps, timer arrivé à expiration, touches du clavier pressées, données reçues sur le port série... entre 20 et 40 sources différentes sur la calculatrice). Normalement c'est le système qui fournit le sien, mais gint le change parce qu'il a besoin de le contrôler pour implémenter ses fonctionnalités et se rendre indépendant de fxlib.

Une fois qu'on contrôle les interruptions, installer un moteur de gris avec un timer à deux délais est un jeu d'enfant. Le moteur de Kucalc (Revolution-FX) ne les contrôlait pas, et devait toutes les supprimer sauf celle du timer, désactivant du même coup les autres timers, l'horloge, la fonction GetKey()... tout un dérangement qui se soldait par un redémarrage à la fin de l'exécution.


Fichier joint


Pages : Précédente1 ... , 17, 18, 19, 20, 21, 22
LephenixnoirHors ligneAdministrateurPoints: 15231 Défis: 136 Message

Citer : Posté le 06/08/2019 16:19 | # | Fichier joint


Du côté de fxconv tout est bon, il ne supprime pas de ligne ou de colonne tant que tu ne spécifies un area sur la ligne de commande. Je viens de tester avec ton image, la première colonne est bien là.

Ce que tu décris doit marcher tout seul, c'était bien un bug dans l'algo de tracé ! (Un bug que j'avais déjà vu mais pas corrigé totalement, con comme je suis...) J'ai corrigé et poussé, Je te joins un g1a qui démontre le code fonctionnel ci-dessous et trace chaque élément de ton image indépendamment.

Merci de ta patience avec mon code encore jeune...

#include <gint/display.h>
#include <gint/keyboard.h>

int main(void)
{
    dclear(C_WHITE);
    dtext(0, 0, "Sample fxSDK add-in.", C_BLACK, C_NONE);

    extern image_t img_brouillard;
    dimage(0, 9, &img_brouillard);

    for(int i = 0; i < 16; i++)
    {
        dsubimage(4 + 16 * (i&7), 32 + 16 * (i>=8), &img_brouillard,
            8 * i, 0, 8, 8, DIMAGE_NONE);
    }
    dupdate();

    getkey();
    return 1;
}
MilangHors ligneMembrePoints: 240 Défis: 0 Message

Citer : Posté le 06/08/2019 18:25 | #


Super, ça marche, merci beaucoup ! bon au début ça a pas marché 3x de suite parce que j'avais pas make install, mais là c'est bon x)
Une alternative intéressante à toutes les boucles que vous avez vu jusque là :
For 1→X To 2:X-1→X:Next :E

Projet de jeu multijoueur : 1V1 3D
LephenixnoirHors ligneAdministrateurPoints: 15231 Défis: 136 Message

Citer : Posté le 08/08/2019 23:07 | #


Bon... j'ai intégré la pull request de Milang (merci encore !) et commencé à tester dclear() avec un dma_memset().

La première chose à noter est que le DMA part avec un désavantage. Pour memset(), la version CPU naïve contient l'opérande de remplissage dans un registre donc tous les accès à la RAM sont faits en écriture. Le DMA, à l'inverse, est obligé de relire l'opérande à chaque cycle de lecture/écriture et fait donc deux fois plus d'accès en RAM.

Sur la même taille de 4 octets par accès, le DMA met donc 15 ms alors que la version CPU naïve met 6 ms.

Heureusement le DMA peut copier jusqu'à 32 octets par bloc, mais ça nous amène aussi à 6 ms.

La solution que j'ai trouvée est de placer l'opérande source dans une mémoire plus rapide que la RAM ; et là ça se complique. Principalement il y en a deux : la mémoire RS et la mémoire IL. Quand je place mon opérande dans la mémoire RS, le transfert se complète en 2.5 ms. Cependant la mémoire RS est utilisée pour des choses critiques comme le redémarrage et il est hors de question d'y toucher sur des add-ins en production. Quand je place l'opérande en mémoire IL, les accès par le DMA freezent.

J'ai des pistes pour avancer un peu mais c'est pas gagné tout de suite. D'un autre côté la mémoire IL est très rapide et est un super plan pour mettre du code ou des données critiques, donc ça vaut le coup de rechercher.

Notez que pour memcpy(), cette fois-ci le CPU perd son avantage car il est lui aussi obligé de lire les données en RAM, en plus de lire le code en ROM (mais pas longtemps car le cache prend le relai je suppose).

Enfin, je cherche vaguement la possibilité qu'il y ait un 2D-DMA dans le microprocesseur, qui pourrait copier des zones non continues pour afficher rapidement des images de n'importe quelle taille. En effet avec le DMA on ne peut qu'afficher des images qui font toute la largeur de l'écran, à savoir 396 pixels, c'est assez restrictif. SimLo n'indique pas de 2D-DMA dans sa doc mais ça ne coûte rien d'en chercher un je suppose.

Voilà voilà, un peu de recherche en perspective.
MilangHors ligneMembrePoints: 240 Défis: 0 Message

Citer : Posté le 09/08/2019 14:31 | #


De toute façon, même si le temps pris par le dma est supérieur, cela ne fait rien si on peut faire autre chose en même temps
Une alternative intéressante à toutes les boucles que vous avez vu jusque là :
For 1→X To 2:X-1→X:Next :E

Projet de jeu multijoueur : 1V1 3D
LephenixnoirHors ligneAdministrateurPoints: 15231 Défis: 136 Message

Citer : Posté le 09/08/2019 14:53 | #


Well, pas tout à fait, parce que seuls les cycles de calculs sont vraiment économisés. Il n'y a qu'un seul bus et c'est chacun son tour. Tous les cycles où tu fais des accès mémoire, le DMA ne peut pas tourner. De plus, c'est pas forcément codé de façon à te permettre de faire autre chose en même temps... x_x

J'ai progressé. En cherchant un peu j'ai découvert que le problème qui se pose quand j'utilise la mémoire IL comme source est en fait une erreur d'adresse juste après la fin du transfert. C'est assez bizarre, et les effets dépendent aussi du channel DMA utilisé. Pour l'instant j'ai un contournement qui consiste à faire un transfert sans interruptions, et ça marche bien !

Donc dclear() ne prend plus 6 ms mais 2.5 ms. Yay !

Côté un peu moins bien maintenant, j'ai voulu tenter de faire une copie d'une image en plein écran vers la VRAM avec le DMA. C'est très facile à coder, mais un problème subsiste : l'image est dans la ROM, plus précisément dans la zone de la ROM qui est mappée en userspace... et n'est donc pas forcément continue sur le stockage physique, selon les caprices du système de fichiers. Or le DMA interagit quasi-exclusivement avec l'espace d'adressage physique. Et donc, la copie n'est pas possible dans le cas général...

Je vais aller voir dans le TLB quelle taille font les pages et comment elles sont agencées mais je pense que c'est 64k, et qu'une image en plein écran prend donc 3 pages. La continuité n'est donc pas garantie. On peut réfléchir à découper le transfert en 3 si l'image est extrêmement bien alignée, mais ça reste très fin. Ce ne sera sans doute pas le comportement par défaut...

Ah et btw, j'ai mesuré avec libprof le temps de dessin, exactement comme Darks le suggérait. Comme prévu, c'est 24.8 ms, soit un poil plus que 40 FPS. Avec le dclear() et les épées par-dessus, on passe en-dessous donc le programme n'arrive plus à suivre les entrées clavier (qui sont à 40 Hz par défaut dans gint). Je vais continuer de chercher des optimisations pour améliorer ça au bas niveau qu'est gint, pour que vos applications bénéficient des meilleures performances possibles.

Au passage, pour les fonctions qui écrivent directement en RAM, la facteur limitant est la vitesse de la RAM donc les optis comme dérouler des boucles pour réduire le temps CPU n'ont quasiment aucun effet.
MilangHors ligneMembrePoints: 240 Défis: 0 Message

Citer : Posté le 17/08/2019 20:02 | #


J'ai un problème en utilisant le dma :

J'ai un zbuffer que je dois effacer à chaque frame. Ce buffer est aligné sur 32 octets grâce aux fonctions suivantes :
#define ALIGN 32
static void* buffer_malloc(uint_fast16_t size)
{
    void *mem = malloc(size+ALIGN+sizeof(void*));
    void **ptr = (void**)((uintptr_t)(mem+ALIGN+sizeof(void*)) & ~(ALIGN-1));
    ptr[-1] = mem;
    return ptr;
}
static void buffer_free(void *ptr)
{
    free(((void**)ptr)[-1]);
}


Pour effacer le buffer à chaque frame j'utilise la fonction suivante :
static const int32_t clearval[8]={3000,3000,3000,3000,3000,3000,3000,3000}; // je remplis le buffer avec la valeur 3000
void FE_zbuffer_clear()
{
    if (isSH3())
    { // effacer avec le CPU
        uint_fast16_t indice;
        for (indice = 0; indice < size_uint32; indice ++)
            address[indice] = clearval[0];
    }
    else
    { // effacer avec le DMA
        dma_transfer(0, DMA_32B, size_blocks, &clearval, DMA_FIXED, address, DMA_INC);
    }
}

Logiquement, je copie donc mon tableau de 4 octets dans le zbuffer qui est aligné sur 32 octets.
Enfin, j'attends par sécurité que le transfert s'achève avec dma_transfer_wait(0); avant d'écrire dedans

Cependant, lors des tests, je m'aperçois que les valeurs présentes dans le zbuffer avec le memset du dma ne sont pas celles obtenues avec l'effacement du cpu >_<
Quelle est l'erreur dans mon utilisation du dma ?

Ajouté le 17/08/2019 à 20:08 :
J'ajoute que *src (clearval) est également aligné sur 32 bits grâce à cette fonction
Une alternative intéressante à toutes les boucles que vous avez vu jusque là :
For 1→X To 2:X-1→X:Next :E

Projet de jeu multijoueur : 1V1 3D
LephenixnoirHors ligneAdministrateurPoints: 15231 Défis: 136 Message

Citer : Posté le 18/08/2019 21:06 | #


Je te fais confiance sur l'allocation ; n'oublie pas que tu peux simplement écrire __attribute__((aligned(32))) uint16_t zbuffer[...] si tu peux l'allouer en statique. Vérifie juste au cas où que le pointeur est bon...

clearval devrait être aligné sur 32 octets, tu peux justement utiliser cette technique :

#include <gint/defs/attributes.h>

GALIGNED(32) GSECTION(".rodata") static const int32_t clearval[8]={3000,3000,3000,3000,3000,3000,3000,3000}; // je remplis le buffer avec la valeur 3000

Et au passage le placer explicitement en ROM ne fait pas de mal.

Sinon ça m'a l'air légitime...
MilangHors ligneMembrePoints: 240 Défis: 0 Message

Citer : Posté le 18/08/2019 22:43 | #


L'allocation statique, j'aimerais bien, mais je ne suis pas sûr qu me cela fonctionne pour 32 768 octets d'un coup
Sinon merci pour tes conseils, j'essaierai la semaine prochaine
Une alternative intéressante à toutes les boucles que vous avez vu jusque là :
For 1→X To 2:X-1→X:Next :E

Projet de jeu multijoueur : 1V1 3D
LephenixnoirHors ligneAdministrateurPoints: 15231 Défis: 136 Message

Citer : Posté le 19/08/2019 10:17 | #


Milang a écrit :
L'allocation statique, j'aimerais bien, mais je ne suis pas sûr qu me cela fonctionne pour 32 768 octets d'un coup

Tu peux utiliser la zone statique sur SH4, elle fait 64k contre 8k sur SH3. Quitte à modifier un poil le linker script...

Sinon tu as la fin de la RAM qui est semble-t-il libre.
MilangHors ligneMembrePoints: 240 Défis: 0 Message

Citer : Posté le 19/08/2019 11:31 | #


Cela me parait une bonne option.

Cependant, il y a des points qui m'échappent :
Si j'alloue statiquement un tableau de 32 ko, cette opération ne fonctionnera jamais sur les modeles sh3 et je ne sais pas du tout comment modifier le linker script
Une alternative intéressante à toutes les boucles que vous avez vu jusque là :
For 1→X To 2:X-1→X:Next :E

Projet de jeu multijoueur : 1V1 3D
LephenixnoirHors ligneAdministrateurPoints: 15231 Défis: 136 Message

Citer : Posté le 19/08/2019 11:59 | #


Les SH3 disposent de la deuxième moitité inutilisée de RAM. Tu peux certainement juste faire :

static const int32_t *zbuffer = (void *)0x88080000 - 32768;

ce qui te place tout à la fin de la RAM. Faudra juste vérifier que c'est libre sur la Graph 35+E II (de mémoire oui, mais ne me crois pas sur parole avant de tester sur cette machine) et c'est bon.
MilangHors ligneMembrePoints: 240 Défis: 0 Message

Citer : Posté le 19/08/2019 12:17 | #


Mais c'est genial ça !
Je code ça tout de suite. (par contre je n'aurai accès à mon pc pour compiler et tester seulement la semaine prochaine

Quand à la graph 35 e II, ben je n'en ai pas, donc ce sera aux risques et perils du premier heureux (ou pas ) testeur.

Une alternative intéressante à toutes les boucles que vous avez vu jusque là :
For 1→X To 2:X-1→X:Next :E

Projet de jeu multijoueur : 1V1 3D
Pages : Précédente1 ... , 17, 18, 19, 20, 21, 22

Planète Casio v42 © créé par Neuronix et Muelsaco 2004 - 2019 | Il y a 32 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