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

Forum Casio - Vos tutoriels et astuces


Index du Forum » Vos tutoriels et astuces » [Tutoriel] Compiler sous Linux avec un cross-compilateur gcc
LephenixnoirEn ligneAdministrateurPoints: 16091 Défis: 140 Message

[Tutoriel] Compiler sous Linux avec un cross-compilateur gcc

Posté le 31/05/2014 17:02

Qui dit Linux implique son puissant compilateur gcc, et de nombreux outils permettant de développer plus librement, plus efficacement. Dans ce tutoriel, je vous propose de compiler GCC et sa suite pour développer des programmes pour les calculatrices Casio.

Pour pouvoir bien suivre, vous devez savoir vous servir d'un terminal et des commandes de base. Ouvrez-en un pour commencer, et essayez de ne pas le fermer par erreur, ça pourrait gêner. Accrochez-vous bien !

Sommaire

1. Installation des dépendances
2. Considérations sur l'architecture cible
3. Préparation de l'environnement de compilation

4. Compilation de binutils
5. Compilation de gcc et de libgcc
6. Compilation de newlib (experts)

7. Choisir un environnement de développement



1. Installation des dépendances

Dans ce tutoriel, on va compiler plusieurs programmes : d'abord binutils, une suite d'outils qui gère les programmes en assembleur, l'édition des liens, les fichiers exécutables et tout ce qui n'est pas du C ; ensuite le compilateur gcc qui compile le code C en assembleur ; et si vous êtes aventureux, peut-être même une version expérimentale de newlib, une bibliothèque standard qui fournit les fonctions fondamentales du C.

Le gcc qui compile vers la calculatrice produit du code en assembleur SuperH, ce n'est pas celui de votre système qui compile probablement en assembleur x86_64. Il ne s'appelle pas gcc mais quelque chose de plus long comme sh-elf-gcc. Vous devez faire très attention à ne pas confondre les deux !

À l'heure où j'écris cette version du tutoriel (12 Septembre 2019), les dernières versions disponibles sont binutils-2.32 et gcc-9.2.0. N'hésitez pas à prendre des versions plus récentes, tant que vous les prenez proches dans le temps. Attention, la dernière version n'est pas toujours en bas de la liste ! La communauté d'OSDev (qui compile gcc à tour de bras) a un tableau où elle indique les combinaisons qui ont marché. Si vous en réusissez une nouvelle, allez leur dire.

La manipulation peut échouer à cause d'erreurs de compilation imprévisibles et que vous ne saurez souvent pas résoudre ; en général soit il vous manque des dépendances soit vous êtes tombé sur des versions qui ne veulent pas marcher chez vous, vous pouvez alors essayer avec d'autres.

Téléchargement de binutils
Téléchargement de gcc
Compilations réussies par la communauté d'OSDev

Bien sûr gcc est un logiciel complexe qui s'appuie sur différentes bibliothèques pour faire son boulot : il y a donc un certain nombre de dépendances à installer. Les noms de paquets ci-dessous sont pour Debian et ses dérivés (Ubuntu, Mint, ElementaryOS...), à utiliser avec apt. Si vous avez une autre distribution vous saurez vous débrouiller.

mpfr (libmpfr-dev) : flottants à précision variable
mpc (libmpc-dev) : complexes à précision variable
gmp (libgmp-dev) : arithmétique à multi-précision
png (libpng-dev) : manipulation d'images
ppl (libppl-dev) : polyèdres Parma (optimisation magique)
flex (flex) : générateur d'analyseurs lexicaux
g++ (g++) : compilateur C++
git (git) : gestionnaire de versions



2. Considérations sur l'architecture cible

Les processeurs des calculatrices Casio font partie de la lignée des SuperH, et vous savez peut-être qu'il y en a deux versions en circulation : les vieilles machines d'avant 2012 utilisent des processeurs SuperH-3, et les autres des SuperH-4A. Un certain nombre de membres anciens et respectés utilisent toujours des SH3, donc il est important de pouvoir créer des programmes pour les deux.

Dans ce tutoriel, on va compiler un GCC qu'on appellera sh-elf-gcc qui sera capable de cibler deux architectures : SuperH-3 et SuperH-4 sans FPU.

La méthode proposée dans les anciennes versions du tutoriel ne permettait que de cibler une seule architecture à la fois. Les compilateurs s'appelaient alors sh3eb-elf-gcc et sh4eb-nofpu-elf-gcc. Vous pouvez toujours utiliser le premier, mais cela n'a plus vraiment d'intérêt puis qu'on peut avoir les deux ensemble. Le deuxième n'est pas véritablement sans FPU et pose des problèmes sérieux : ne l'utilisez pas.

Passons aux choses sérieuses maintenant !



3. Préparation de l'environnement de compilation

Tout ce qu'on va créer aujourd'hui ira dans un dossier de votre ordinateur. Le compilateur sera installé là, et les bibliothèques pour programmer sur la calculatrice seront là aussi. Je vous conseille vivement de choisir un dossier dans votre répertoire personnel. Pour moi, ce sera dans $HOME/opt avec le numéro de version car j'en compile souvent. Vous pouvez choisir ce que vous voulez, par exemple $HOME/Documents/Casio/gcc (ça ne changera rien à la suite).

% export PREFIX="$HOME/opt/sh-elf-2.32-9.2.0"
% mkdir -p $PREFIX
% cd $PREFIX

Si vous fermez votre terminal au milieu du tutoriel, et en ouvrez un autre ensuite, retapez ces trois commandes, retapez le export PATH plus bas, puis reprenez le tutoriel là où vous étiez arrêté.

Extrayez le contenu des archives que vous avez téléchargées dans ce dossier, et créez deux répertoires build-binutils et build-gcc. Si par exemple les archives sont au format .tar.xz dans le dossier que vous venez de choisir, vous pouvez les extraire avec tar. Pour créer les sous-dossiers, utilisez mkdir comme d'habitude.

% tar -xJf binutils-2.31.1.tar.xz
% tar -xJf gcc-8.2.0.tar.xz
% mkdir build-binutils build-gcc

Après cela, votre dossier doit ressembler ceci quand vous exécutez la commande "tree -L 1" :

% tree -L 1
.
├── binutils-2.32
├── binutils-2.32.tar.xz
├── build-binutils
├── build-gcc
├── gcc-9.2.0
└── gcc-9.2.0.tar.xz

Le compilateur et tous les outils de sa suite vont arriver dans un sous-dossier bin. Pour pouvoir les utiliser sur la ligne de commande, vous devez les ajouter au PATH. (Le PATH est l'ensemble des dossiers dans lesquels le terminal cherche les commandes.) Utilisez la commande ci-dessous pour modifier temporairement le PATH.

% export PATH="$PATH:$PREFIX/bin"

La modification sera perdue quand le terminal sera fermé. Pour que ce changement soit permanent, il faut ajouter la commande à la fin du fichier $HOME/.profile. La commande suivante le fait pour vous.

% echo "export PATH=\$PATH:$PREFIX/bin" >> $HOME/.profile



4. Compilation de binutils

La compilation de binutils est très classique : d'abord on configure nos options avec ./configure, ensuite on compile avec make, puis on installe avec make install. C'est comme ça pour un nombre incalculable de logiciels.

Notez (ça marche jusqu'à la fin du tutoriel) que make possède une option -j pour compiler avec plusieurs processus en même temps, pour aller plus vite. Utilisez toujours -j suivi d'un nombre, typiquement votre nombre de coeurs. Pour moi, -j4.

Choisir le bon nombre de threads pour -j (pour ceux que ça intéresse)

% cd build-binutils
% ../binutils-2.32/configure --prefix=$PREFIX --target=sh3eb-elf --with-multilib-list=m3,m4-nofpu --disable-nls --program-prefix=sh-elf-

Ici, l'option --prefix indique où on va installer le compilateur. --target avec --with-multilib-list permet de spécifier à la fois SuperH-3 et SuperH-4 sans FPU comme cibles. Enfin, --program-prefix permet de donner un nom personnalisé au compilateur, ici sh-elf-gcc.

(experts) La liste complète des options de compilation est donnée par configure --help, en voici quelques-unes suscesptibles de vous intéresser :

--disable-nls pour forcer les diagnostics en anglais
--disable-werror pour supprimer l'option -Werror
--enable-libssp pour compiler libssp (protection de pile)
--enable-lto pour activer le support des optimisations au linkage (puissant)

Une fois que tout est configuré, il n'y a plus qu'à compiler et à installer. Normalement ça va assez vite, comptez quelques minutes. Si vous avez une erreur de compilation, vérifiez les dépendances et les en-têtes possiblement manquants. Sinon, changez de version de binutils et éventuellement de gcc.

% make -j4
% make install

Les exécutables de binutils ont dû apparaître dans $PREFIX/bin. Essayez de taper $PREFIX/bin/sh-elf-as --version pour vérifier que ça marche !



5. Compilation de gcc et de libgcc

Maintenant, on recommence pareil, mais cette fois on compile un morceau beaucoup plus gros : gcc. L'option --enable-languages vous permet de choisir les langages que vous voulez pouvoir compiler, notamment C, C++, Ada, Go ou Fortran. Attention au temps de compilation qui va vite monter !

% cd $PREFIX/build-gcc
% ../gcc-9.2.0/configure --prefix=$PREFIX --target=sh3eb-elf --with-multilib-list=m3,m4-nofpu --enable-languages=c,c++ --without-headers --with-newlib --disable-nls --program-prefix=sh-elf-

(experts) Les options --disable-werror, --enable-libssp et --enable-lto doivent être passées ici aussi si vous les avez passées à binutils.

Et c'est parti pour compiler ! Comptez entre 10 et 30 minutes (pour c,c++) selon la puissance de votre ordinateur, 5 à 6 heures sur un vieux Raspberry Pi !

% make -j4 all-gcc
% make install-gcc

GCC fournit également une bibliothèque appelée libgcc qui contient des fonctions indispensables. Tout le code compilé avec gcc doit être linké avec libgcc. On compile donc cette bibliothèque, ce qui se passe très vite et sans la moindre difficulté.

% make -j4 all-target-libgcc
% make install-target-libgcc

Vous pouvez désormais taper sh-elf-gcc -m3 et sh-elf-gcc -m4-nofpu et vous devez avoir juste une erreur fatale indiquant que vous n'avez pas donné de fichier à compiler. Si on prend une autre cible, par exemple avec sh-elf-gcc -m4, GCC doit se plaindre que -m4 n'est pas supporté parce que ne l'a pas demandé.

Si tout s'est bien passé, alors vous avez terminé ce tutoriel ! La partie 7 vous guidera vers un SDK pour créer vos add-ins


6. Compilation de newlib (experts)

Memallox a construit un port de newlib (en anglais) pour supporter une libc avec gcc. Pour l'instant c'est au stade expérimental ; vous pouvez sauter cette section jusqu'à ce que ce soit bien étudié. Si vous savez de quoi vous parlez, vous pouvez le compiler maintenant.

Clônez le dépôt de Memallox dans le répertoire de travail ou créez un lien symbolique. Ensuite, configurez de la même façon :

% git clone https://git.planet-casio.com/Memallox/libc
% mkdir build-newlib
% cd build-newlib
% ../libc/configure --prefix=$PREFIX --target=sh3eb-elf --enable-target-optspace
% make -j4
% make install

Là aussi les options de configuration --enable-libssp et --enable-lto peuvent vous intéresser. Ensuite, recompilez gcc (avec les mêmes options, en particulier --without-headers et --with-newlib) :

% cd build-gcc
% ../gcc-9.2.0/configure --prefix=$PREFIX --target=sh3eb-elf --with-multilib-list=m3,m4-nofpu --enable-languages=c,c++ --without-headers --with-newlib --disable-nls --program-prefix=sh-elf-
% make -j4 all-gcc
% make install-gcc
% make -j4 all-target-libgcc
% make install-target-libgcc

Je ne suis pas sûr qu'il soit nécessaire de recompiler libgcc mais ça ne coûte rien !



7. Choisir un environnement de développement

Maintenant que vous avez le compilateur, vous pouvez écrire des add-ins ! Enfin... presque. Il vous manque encore de quoi écrire à l'écran, récupérer les touches pressées sur le clavier, et convertir vos images.

Pour ça, vous avez (à l'heure où j'écris cette version du tutoriel), deux choix : utiliser fxlib porté pour GCC, ou bien utiliser le fxSDK.

Jusqu'ici le tutoriel pour développer des add-ins avec fxlib était sur cette page, mais je vais le déplacer dans un topic à part. Je l'ai temporairement laissé dans le spoiler ci-dessous.

Pour le fxSDK, la page du projet détaille son installation et son utilisation. C'est plus facile que GCC donc vous avez déjà quasiment tout fait !

Ancien tutoriel d'utilisation de fxlib (commence à être très vieux)
Cliquez pour recouvrir

Installation du g1a-wrapper

Votre binutils produit des fichiers au format ELF. Il y a encore un peu de travail à faire avant d'obtenir un g1a. Le g1a-wrapper est un petit programme qui va nous y aider. Clônez-le depuis un dépôt git et installez-le dans le dossier des binaires du compilateur.

% cd $PREFIX
% git clone "https://Lephenixnoir""@""bitbucket.org/Lephenixnoir/add-in-wrapper.git"
% cd add-in-wrapper
% make
% cp build/g1a-wrapper $PREFIX/bin


Environnement de projet

On va créer un modèle de projet que vous pourrez réutiliser. Tout ça se passe en-dehors de la compilation de gcc, je vous conseille donc de changer de dossier. ~/my-awesome-project pourrait être sympa. Dans tous les cas, vous pouvez fermer le terminal pour l'instant. Si vous avez de l'expérience dans la programmation C, je ne vais pas vous apprendre à organiser un projet... il vous faudra juste quelques fichiers donnés plus bas.

Voilà par exemple comment on pourrait organiser un projet:
- un dossier include contenant les 6 headers de fxlib (dispbios.h, endian.h, filebios.h, fxlib.h, keybios.h, timer.h)
- la bibliothèque libfx.a
- les fichiers addin.ld et crt0.s
- une icône, par exemple icon.bmp
- les sources (dans un dossier src par exemple)

Le code de base est un peu plus simple qu'avec le SDK (toutes les choses bourrines ayant été mises dans crt0.s) :[/justify]
#include <fxlib.h>

int main(void)
{
    unsigned int key;
    locate(1, 1);
    Print((unsigned char *)"gcc add-in");
    while(1) GetKey(&key);
    return 1;
}

Tous ces fichiers sont prêts à utiliser dans l'archive suivante.
Télécharger le projet d'exemple

Voilà sans plus attendre la commande à utiliser pour compiler ce nouveau projet. Y'a plein d'options, mais rien de bien méchant, vous allez voir...

$ sh3eb-elf-gcc -m3 -mb -mrenesas -ffreestanding -nostdlib -T addin.ld crt0.s addin.c -o addin.elf -I include -lgcc -L . -lfx -O2

- Les options -m3 et -mb indiquent qu'on veut du code pour SH3 (même si on utilise déjà le sh3eb-elf, il y a plusieurs variantes) utilisant le big-endian (cela concerne l'ordre des octets en mémoire dans des variables de plusieurs octets)
- L'option -mrenesas demande à GCC de produire du code compatible avec fxlib
- L'option -ffreestanding signale que le programme compilé tient « tout seul », sans s'appuyer sur un système d'exploitation (gcc fournit alors deux-trois choses en plus)
- L'option -I include indique que certains de nos fichiers d'en-tête sont dans le dossier include
- L'option -nostdlib indique que l'on n'a pas de bibliothèque standard (elle est dans fxlib)
- L'option -O2 active l'optimisation du code (facultatif, mais utile)

Ça c'est les options de compilation proprement dites. Ici, on compile tout d'un coup et on effectue l'édition des liens (génération du fichier exécutable) dans la foulée, donc les options se mélangent. Si vous avez un gros projet, vous allez compiler les fichiers un par un avec -c et tout linker ensuite. Les options que j'ai citées pour l'instant sont celles qu'on utilisera à la compilation. Les options suivantes sont spécifiques au linkage :

- L'option -T addin.ld indique au compilateur que les règles qu'on l'on veut voir respecter lors de l'édition des liens sont dans le fichier addin.ld
- Les options -L . et -lfx indiquent qu'on veut utiliser fxlib, et que le fichier libfx.a se trouve dans le dossier courant
- L'option -lgcc spécifie l'utilisation de libgcc (il faut toujours utiliser libgcc !)
- Bien sûr, -o addin.elf indique le nom du fichier de sortie

Notez que le fichier crt0.s est un autre fichier source qui contient du code indispensable. Pensez à le compiler aussi, ici en même temps que le programme addin.c. Le fichier de sortie est au format ELF (le format classique sous Linux), ce qu'on avait prévu en compilant un gcc pour l'architecture sh3eb-elf.

Génération du g1a

Le format ELF a plein d'avantages, mais on ne veut que du binaire pur. Pour cela, on va utiliser un programme de binutils, objcopy, qui va nous permettre de changer le format. En deux mots, supprimer l'ELF et ne garder que le binaire pur (ce qui est dit par -O binary). On supprime aussi deux-trois sections au passage (.comment et .bss), n'oubliez pas de le faire sinon vous aurez un fichier énormissime en sortie.

$ sh3eb-elf-objcopy -R .comment -R .bss -O binary addin.elf addin.bin

On n'a plus maintenant qu'à ajouter les informations de l'application add-in pour obtenir un fichier g1a. C'est le boulot du g1a-wrapper. Il y a des options pour pas mal de champs (que vous pouvez obtenir en exécutant g1a-wrapper --help), mais faisons simple et mettons juste une icône :

$ g1a-wrapper addin.bin -o addin.g1a -i icon.bmp


Terminé ! Vous n'avez plus qu'à transférer votre nouvel add-in... pour ça, seul un bon vieux terminal et des programmes en ligne de commande sont désormais dignes de vous. On en a quelques-uns :
- Le grand P7 de Cakeisalie5
- CasioUsb de Nessotrin


Merci d'avoir suivi ce tuto ! N'hésitez pas à laisser vos impressions, idées d'amélioration, messages de réussite ou même messages d'erreur dans les commentaires !


Fichier joint


Pages : Précédente1 ... , 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, ... 18Suivante
LegolasHors ligneAncien rédacteurPoints: 3266 Défis: 104 Message

Citer : Posté le 17/02/2018 19:12 | #


Tu veux dire, cette ligne ?

configure:4528: checking for suffix of object files


Ok, je lance ;

La Fontaine a écrit :
Patience et longueur de temps valent mieux que force ni que spam.



Ajouté le 17/02/2018 à 19:31 :
J'ai comme réponse :


/usr/lib/x86_64-linux-gnu/libmpfr.so.4.1.4
/usr/lib/x86_64-linux-gnu/libmpfr.a
/usr/lib/x86_64-linux-gnu/libmpfr.so
/usr/lib/x86_64-linux-gnu/libmpfr.so.4
/usr/share/doc/libmpfr4
/usr/share/doc/libmpfr-dev
/var/lib/dpkg/info/libmpfr-dev:amd64.md5sums
/var/lib/dpkg/info/libmpfr-dev:amd64.list
/var/lib/dpkg/info/libmpfr4:amd64.list
/var/lib/dpkg/info/libmpfr4:amd64.md5sums
/var/lib/dpkg/info/libmpfr4:amd64.shlibs
/var/lib/dpkg/info/libmpfr4:amd64.symbols
/var/lib/dpkg/info/libmpfr4:amd64.triggers
/var/cache/apt/archives/libmpfr-dev_3.1.4-1_amd64.deb

Mes programmes
Cacher les programmes
Mes défis
Cacher les défis



LephenixnoirEn ligneAdministrateurPoints: 16091 Défis: 140 Message

Citer : Posté le 17/02/2018 19:33 | #


Ok, essaie :

$ export LD_LIBRARY_PATH="/usr/lib/x86_64-linux-gnu/:$LD_LIBRARY_PATH"

Si ça marche, ajoute cette ligne à ton .bashrc ou ton .profile une fois que tu auras fini de compiler, sinon tu risques de ne pas pouvoir utiliser le compilateur à la fin.
LegolasHors ligneAncien rédacteurPoints: 3266 Défis: 104 Message

Citer : Posté le 17/02/2018 19:37 | #


Merci ! J'ai encore la même erreur quand je relance le makefile (make all-target-libgcc), donc je teste avec les autres dossiers
Mes programmes
Cacher les programmes
Mes défis
Cacher les défis



TheprogHors ligneMembrePoints: 1447 Défis: 20 Message

Citer : Posté le 19/02/2018 20:10 | # | Fichier joint


Salut salut !
Oui je reviens d'un peu loin (boh 6 mois c'est si peu)
J'ai rouvert mon vieux PC linux pour un projet à l'école et je me suis dit que ça pourrait être sympa de se reprendre un peu la tête sur la Casio.
Donc j'ai voulu compiler mon petit AGBSW encore une fois avec le dernier linker que m'avait donné Lephé et ,en effet, l'add-in plante direct comme prévu. Enfin pour être précis, il me fait le premier affichage, mais après impossible de se déplacer dans les menus, y'a plus qu'à faire un Reset.
Voilà voilà, le fichier principal est en pièce jointe
Merci d'avance
LephenixnoirEn ligneAdministrateurPoints: 16091 Défis: 140 Message

Citer : Posté le 19/02/2018 22:02 | #


Theprog a écrit :
Donc j'ai voulu compiler mon petit AGBSW encore une fois avec le dernier linker que m'avait donné Lephé et ,en effet, l'add-in plante direct comme prévu.

Peu de surprise, mais c'est cool que tu t'y sois remis ! o/

Avant que j'oublie, ML_display_vram() ne fonctionnera pas. Il faut passer les pointers du driver en volatile pour ça.

Je vois pas trop de raisons que ça plante. Tu peux faire un exemple minimal de programme qui ne marche pas (ie. isoler juste le code qui plante) ? Je voudrai tester demain mais ça va être serré (en temps) donc ça m'aiderait.
TheprogHors ligneMembrePoints: 1447 Défis: 20 Message

Citer : Posté le 20/02/2018 11:25 | #


Je suis pas complètement sûr de moi mais ça serait pas le GetKey qui fait planter l'AddIn ?
Avec ce code:
#include <display.h>
#include <keyboard.h>
#include <fxlib.h>

int main(void)
{
    extern image_t assets_image_title;
    extern font_t assets_font_island;
    unsigned int key=0;

    text_configure(&assets_font_island, color_black);

    dclear();
    dimage(0, 1, &assets_image_title);
    dtext(9, 31, "NEW GAME");
    dtext(9, 39, "NEW GAME");
    dtext(9, 47, "NEW GAME");
    dupdate();

    GetKey(&key);
    // getkey();
    return 0;
}

et en compilant avec ces commandes:
sh3eb-elf-gcc -c src/main.c -o build/main.o `fxsdk --cflags` -I include
fxconv -image assets/image_title.bmp -o build/image_title.bmp.o -n assets_image_title
fxconv -image assets/font_island.bmp -o build/font_island.bmp.o -n assets_font_island
sh3eb-elf-gcc build/main.o build/image_title.bmp.o build/font_island.bmp.o -o build/moisland.elf `fxsdk --cflags --libs` -I include -L . -lfx
sh3eb-elf-objcopy -R .comment -R .bss -O binary build/moisland.elf build/moisland.bin
g1a-wrapper build/moisland.bin -o moisland.g1a -i moisland.bmp --version='01.00.0000' --date='2017.0101.0000'

l'add-in plante, et il n'affiche rien, alors qu'avec le getkey(); à la place, ça se lance tranquillement...
Après c'est possible que je compile comme un sagouin
-florian66-En ligneAncien rédacteurPoints: 2303 Défis: 20 Message

Citer : Posté le 20/02/2018 11:29 | #


Je crois que tu ne peux pas utiliser fxlib quand tu utilises Gint

Dans ce cas, déclare #include "heyboard.h" et utilises getkey() de Gint
In Arch, I trust ! And you ?
TheprogHors ligneMembrePoints: 1447 Défis: 20 Message

Citer : Posté le 20/02/2018 12:11 | #


Oui c'est possible que ça soit ça, mais dans tous les cas faudra que je réécrive tout pour n'utiliser que gint puisque c'est un des gros avantages qu'il y a à passer sur Linux.
Le problème qui vient ensuite c'est que je me fait insulter quand je cherche à compiler en C++..
Ce code là marche très bien:
Code C
Cliquer pour enrouler
#include <display.h>
#include <keyboard.h>


void Menu_Main();

int main(void)
{
    Menu_Main();

    return 0;
}

void Menu_Main()
{
    int key=0;
    char i=0;
    // extern font_t assets_font_island;

    // text_configure(&assets_font_island, color_black);

    while(1)
    {
        while(key != KEY_EXE)
        {
            dclear();
            
            dtext(0, 0, "ANGRY BIRD STAR WARS");
            dtext(10, 10, "JOUER");
            dtext(10, 18, "STATS");
            dtext(10, 26, "OPTIONS");
            dtext(10, 34, "CREDITS");
            dtext(10, 42, "QUITTER");
            
            dtext(3, 10+8*i, ">");
            dupdate();
            
            key = getkey();
            
            switch(key)
            {
                case KEY_DOWN:
                    i++;
                    if(i>4) i=0;
                    break;
                case KEY_UP:
                    i--;
                    if(i<0) i=4;
                    break;
                case KEY_EXIT:
                    return;
            }
        }
        
        key=0;
    }
}

Compilation
Cliquer pour enrouler
sh3eb-elf-gcc -c src/main.c -o build/main.o `fxsdk --cflags` -I include
fxconv -image assets/image_title.bmp -o build/image_title.bmp.o -n assets_image_title
fxconv -image assets/font_island.bmp -o build/font_island.bmp.o -n assets_font_island
sh3eb-elf-gcc build/main.o build/image_title.bmp.o build/font_island.bmp.o -o build/moisland.elf `fxsdk --cflags --libs` -I include
sh3eb-elf-objcopy -R .comment -R .bss -O binary build/moisland.elf build/moisland.bin
g1a-wrapper build/moisland.bin -o moisland.g1a -i moisland.bmp --version='01.00.0000' --date='2017.0101.0000'
g1a-wrapper: warning: version string '01.00.0000' does not have expected format 'MM.mm.pppp'
g1a-wrapper: warning: date string '2017.0101.0000' does not have expected format 'yyyy.MMdd.hhmm'


Par contre dès qu'on passe sur du cpp ça marche moins:
Code C++
Cliquer pour enrouler
extern "C"
{
    #include <display.h>
    #include <keyboard.h>
}

void Menu_Main();

int main(void)
{
    Menu_Main();

    return 0;
}

void Menu_Main()
{
    int key=0;
    char i=0;
    // extern font_t assets_font_island;

    // text_configure(&assets_font_island, color_black);

    while(1)
    {
        while(key != KEY_EXE)
        {
            dclear();
            
            dtext(0, 0, "ANGRY BIRD STAR WARS");
            dtext(10, 10, "JOUER");
            dtext(10, 18, "STATS");
            dtext(10, 26, "OPTIONS");
            dtext(10, 34, "CREDITS");
            dtext(10, 42, "QUITTER");
            
            dtext(3, 10+8*i, ">");
            dupdate();
            
            key = getkey();
            
            switch(key)
            {
                case KEY_DOWN:
                    i++;
                    if(i>4) i=0;
                    break;
                case KEY_UP:
                    i--;
                    if(i<0) i=4;
                    break;
                case KEY_EXIT:
                    return;
            }
        }
        
        key=0;
    }
}

Compilation
Cliquer pour enrouler
sh3eb-elf-g++ -c src/main.cpp -o build/main.o `fxsdk --cflags` -I include
In file included from /usr/share/fxsdk/gint/display.h:67:0,
                 from src/main.cpp:3:
/usr/share/fxsdk/gint/tales.h:96:43: error: expected ')' before 'operator'
void text_configure(font_t *font, color_t operator);
                                           ^~~~~~~~
/usr/share/fxsdk/gint/tales.h:96:43: error: expected initializer before 'operator'
In file included from src/main.cpp:3:0:
/usr/share/fxsdk/gint/display.h:132:52: error: expected ')' before 'operator'
void drect(int x1, int y1, int x2, int y2, color_t operator);
                                                    ^~~~~~~~
/usr/share/fxsdk/gint/display.h:132:52: error: expected initializer before 'operator'
/usr/share/fxsdk/gint/display.h:145:41: error: expected ')' before 'operator'
void dpixel(size_t x, size_t y, color_t operator);
                                         ^~~~~~~~
/usr/share/fxsdk/gint/display.h:145:41: error: expected initializer before 'operator'
/usr/share/fxsdk/gint/display.h:154:52: error: expected ')' before 'operator'
void dline(int x1, int y1, int x2, int y2, color_t operator);
                                                    ^~~~~~~~
/usr/share/fxsdk/gint/display.h:154:52: error: expected initializer before 'operator'
Makefile:30 : la recette pour la cible « build/main.o » a échouée
make: *** [build/main.o] Erreur 1

Le problème est le même en compilant avec sh3eb-elf-gcc
LephenixnoirEn ligneAdministrateurPoints: 16091 Défis: 140 Message

Citer : Posté le 20/02/2018 13:00 | #


Oh mais attends, moi j'ai cru dans ton exemple d'hier que tu n'utilisais que fxlib. Utiliser GetKey() sous gint est une « erreur ». Ça ne marchera jamais ! Comme -florian66- l'a dit, utilise getkey(), c'est la seule façon. (Puis tu verras que y'a plus d'options aussi <3)

Ah oui, y'a une emmerde avec les headers de gint, j'ai appelé un paramètre operator, mais en C++ c'est un mot-clé du coup le compilateur apprécie pas.

Le problème est le même en compilant avec sh3eb-elf-gcc

gcc devine le langage par l'extension, et du coup invoque g++. Donc normal que ça donne la même chose.

J'ai commit un petit changement sur le repo de gint. Tu peux soit pull et réinstaller, soit modifier /usr/share/fxsdk/gint/display.h pour remplacer les trois operator par autre chose, genre _operator. Ça devrait aller mieux ensuite.

PS. Ton main() doit être dans le extern "C" {} aussi.
TheprogHors ligneMembrePoints: 1447 Défis: 20 Message

Citer : Posté le 20/02/2018 14:02 | #


C'est bon ça compile ! o/ Merci pour toutes ces précisions

Par contre j'ai un nouveau problème. En fait, un des trucs qui fait planter l'Add-In et qui y est toujours, c'est le chargement d'une police de caractère: text_configure(&assets_font_island, color_black);

Si je ne met pas cette ligne dans mon code, l'Add-In marche normalement avec la police par defaut, par contre avec la ligne il plante. Pourtant le fichier BMP est bien présent (j'ai repris celui du tuto), la commande 'fxconv -image assets/font_island.bmp -o build/font_island.bmp.o -n assets_font_island' ne renvoie pas d'erreur, et celle-ci non plus 'sh3eb-elf-gcc build/AGBSW.cpp.o build/font_island.bmp.o -o build/AGBSW.elf fxsdk --cflags --libs -I include'
LephenixnoirEn ligneAdministrateurPoints: 16091 Défis: 140 Message

Citer : Posté le 20/02/2018 14:04 | #


Ben c'est une police, faut passer -font à fxconv, pas -image o/
TheprogHors ligneMembrePoints: 1447 Défis: 20 Message

Citer : Posté le 20/02/2018 14:08 | #


build/%.bmp.o: assets/%.bmp
ifeq ($(findstring font, $<),)
    fxconv -image $< -o $@ -n $(<:assets/%.bmp=assets_%)
else
    fxconv -font $< -o $@ -n $(<:assets/%.bmp=assets_%)
endif


Merci !

Ajouté le 20/02/2018 à 20:24 :
J'ai un nouveau problème avec bfile.h cette fois
sh3eb-elf-gcc -c src/memory.c -o build/memory.c.o `fxsdk --cflags` -I include
In file included from src/memory.h:16:0,
                 from src/memory.c:25:
/usr/share/fxsdk/gint/bfile.h:21:24: error: unknown type name 'uint16_t'
int BFile_Remove(const uint16_t *file);

LephenixnoirEn ligneAdministrateurPoints: 16091 Défis: 140 Message

Citer : Posté le 20/02/2018 20:35 | #


J'ai commit le fix. J'avais oublié d'inclure <stdint.h>, l'en-tête qui définit uint16_t, dans bfile.h. Je me sers de ce type comme d'un synonyme de FONTCHARACTER !
TheprogHors ligneMembrePoints: 1447 Défis: 20 Message

Citer : Posté le 20/02/2018 22:53 | # | Fichier joint


Bon on arrive à la dernière étape
Mais je comprend pas trop pourquoi il veut pas travailler:
sh3eb-elf-gcc build/mobile.cpp.o build/control.cpp.o build/AGBSW.cpp.o build/piaf.cpp.o build/level.cpp.o build/bow.cpp.o build/memory.c.o build/attractor.cpp.o build/draw.cpp.o build/object.cpp.o build/pig.cpp.o build/image_bow.bmp.o build/font_island.bmp.o -o build/AGBSW.elf `fxsdk --cflags --libs` -I include
build/mobile.cpp.o: In function `Mobile::colliObject(Object*, float)':
mobile.cpp:(.text+0xb0c): undefined reference to `_sqrt'
build/mobile.cpp.o: In function `Mobile::get_spd() const':
mobile.cpp:(.text+0xd8c): undefined reference to `_sqrt'
build/level.cpp.o: In function `Level::play()':
level.cpp:(.text+0x1404): undefined reference to `IsKeyUp(int)'
level.cpp:(.text+0x1890): undefined reference to `IsKeyUp(int)'
build/memory.c.o: In function `_memory_load':
memory.c:(.text+0x7fc): undefined reference to `_BFile_GetFileSize'

J'ai bien:
- #include <math.h> dans mobile.h
- le fichier math.h dans include
- IsKeyUp défini dans control.h, et control.h inclut dans level.h
- bfile.h inclut dans memory.h
Voilà voilà
LephenixnoirEn ligneAdministrateurPoints: 16091 Défis: 140 Message

Citer : Posté le 20/02/2018 22:59 | #


IsKeyUp défini dans control.h, et control.h inclut dans level.h

Non, IsKeyUp() est déclaré dans control.h, ça dit au compilateur qu'il existe mais ça ne donne pas son code. Maintenant le compilateur exige le code. Il est dans fxlib, et tu ne peux pas l'utiliser avec gint. Fouille dans keyboard.h, tu trouveras de quoi faire des multigetkey() qui s'arrêtent « rapidement » si aucune touche n'est pressée. Je suis désolé, mais il va falloir que tu changes un peu la manière dont tu gères ton clavier.

- le fichier math.h dans include

Pareil, là le compilo veut le code de sqrt(). Et je ne l'ai pas implémentée, cette fonction... je n'en suis pas encore là. Vois avec @-florian66- pour des implémentations potentielles le temps que gint arrive à suivre.

memory.c:(.text+0x7fc): undefined reference to '_BFile_GetFileSize'

Pull et réinstalle, si tu veux bien. J'ai raté une majuscule tout à l'heure.
TheprogHors ligneMembrePoints: 1447 Défis: 20 Message

Citer : Posté le 20/02/2018 23:03 | #


Non mais temporairement j'ai bricolé un truc dans control.cpp
int IsKeyDown(int key)
{
    volatile uint8_t *adrr = keyboard_stateBuffer();

    return (adrr[key & 0x0f] & 0x1<<((key&0xf0)/16))!=0;
}

int IsKeyUp(key_t key)
{
    return !IsKeyDown(key);
}

LephenixnoirEn ligneAdministrateurPoints: 16091 Défis: 140 Message

Citer : Posté le 21/02/2018 07:54 | #


C'est ok de bricoler, mais pense à utiliser les bonnes fonctions un jour. C'est pas un hasard si ma vieille horloge programmée avec ces fonctions (à peu près) vidait les piles en 4 heures d'utilisation. x)
TheprogHors ligneMembrePoints: 1447 Défis: 20 Message

Citer : Posté le 21/02/2018 12:35 | #


Si je ne me trompe pas, t'avais oublié un autre operator dans les commits précédents:
/usr/share/fxsdk/gint/tales.h:96:43: error: expected ')' before 'operator'
void text_configure(font_t *font, color_t operator);


Du coup j'ai réglé le problème pour le sqrt, par contre j'arrive pas à régler les deux autres.

J'ai fait reinstallé gint si je ne me trompe pas (git pull de gint, puis make mrproper, ./config, make, sudo make install), mais j'ai toujours le même problème:
build/memory.c.o: In function `_memory_load':
memory.c:(.text+0x7fc): undefined reference to `_BFile_GetFileSize'


Et pour le IsKeyDown du coup je comprend pas puisque la fonction est bien définie dans le .h et le .cpp, mais malgré ça:
build/level.cpp.o: In function `Level::play()':
level.cpp:(.text+0x1404): undefined reference to `IsKeyUp(int)'
level.cpp:(.text+0x1890): undefined reference to `IsKeyUp(int)'

LephenixnoirEn ligneAdministrateurPoints: 16091 Défis: 140 Message

Citer : Posté le 21/02/2018 12:45 | #


Ah right, j'ai modifié cet autre operator. Merci du signalement !

Ta méthode de mise à jour est très bien. J'ai juste été trop vite et oublié d'exporter la fonction. Encore désolé, tu peux re-pull. x)

Mets ta définition de fonction dans un extern "C" {}. Je rappelle que le compilateur C++ modifie à la volée les noms de tes fonctions, excepté si tu les mets là-dedans. Évidemment un programme C++ qui demande à appeler une certaine fonction va être modifié pour appeler la fonction avec le nom modifié. Mais les programmes C comme memory, non. Donc il faut que tu demandes au compilateur C++ de ne pas faire de bordel avec les noms de tes fonctions.
TheprogHors ligneMembrePoints: 1447 Défis: 20 Message

Citer : Posté le 21/02/2018 13:13 | #


Les deux premiers points c'est bon

Par contre le second, si je comprend bien, ça veut dire que les fichiers control.h et control.cpp deviennent:
Control.h
Cliquer pour enrouler
#ifndef __CONTROL_H__
#define __CONTROL_H__

    extern "C"
    {
        #include <keyboard.h>

    }
    
    #ifdef __cplusplus
    extern "C"
    {
    #endif
    
        int IsKeyDown(int key);
        int IsKeyUp(int key);

    #ifdef __cplusplus
    }
    #endif

    class Control
    {
        public:
            Control();
            Control(unsigned int bind);
            Control(unsigned int bind, int cooldown);
            ~Control();
            
            bool test();
            void reset_lastDown();
            
        private:
            unsigned int m_bind;
            int m_lastDown;
            int m_cooldown;
    };

#endif


Control.cpp
Cliquer pour enrouler
#include "control.h"


int IsKeyDown(int key)
{
    volatile uint8_t *adrr = keyboard_stateBuffer();

    return (adrr[key & 0x0f] & 0x1<<((key&0xf0)/16))!=0;
}

int IsKeyUp(key_t key)
{
    return !IsKeyDown(key);
}


Control::Control() : m_bind(0), m_lastDown(0), m_cooldown(10)
{
    
}

Control::Control(unsigned int bind) : m_bind(bind), m_lastDown(0), m_cooldown(10)
{
    
}

Control::Control(unsigned int bind, int cooldown) : m_bind(bind), m_lastDown(0), m_cooldown(cooldown)
{
    
}

Control::~Control()
{
    
}


bool Control::test()
{
    if(m_lastDown>0)
        m_lastDown--;
    else
    {
        if(IsKeyDown(m_bind))
        {
            m_lastDown = m_cooldown;
            return true;
        }
        m_lastDown=0;
    }
    
    return false;
}

void Control::reset_lastDown()
{
    m_lastDown = 0;
}


Mais si je fais ça j’obtiens:
src/control.cpp: In function 'int IsKeyUp(key_t)':
src/control.cpp:14:5: error: conflicting declaration of C function 'int IsKeyUp(key_t)'
int IsKeyUp(key_t key)
     ^~~~~~~
In file included from src/control.cpp:1:0:
src/control.h:16:7: note: previous declaration 'int IsKeyUp(int)'
   int IsKeyUp(int key);

LephenixnoirEn ligneAdministrateurPoints: 16091 Défis: 140 Message

Citer : Posté le 21/02/2018 13:55 | #


Tu as déclaré la fonction IsKeyUp() comme prenant un int en argument, mais tu l'as implémentée comme prenant un key_t. Les deux sont équivalents, donc prends n'importe lequel, mais utilise-en un seul.
Pages : Précédente1 ... , 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, ... 18Suivante

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