fxSDK, un SDK alternatif pour écrire des add-ins
Posté le 29/08/2014 22:00
Cette page sert d'index pour la série de topics du fxSDK.
Le fxSDK est une collection d'outils permettant de développer des add-ins pour les calculatrices Casio des séries Graph. C'est une alternative au
fx-9860G SDK et
PrizmSDK qui ne sont plus activement maintenus, et le compagnon classique de mon noyau
gint.
Index des topics
Ce projet existe depuis 2015, alors il y a pas mal de topics liés. En voici une liste complète !
Topics principaux
Installation du fxSDK
Tutoriels
Compatibilité sur calculatrice et PC
Côté PC, le fxSDK est compatible avec
Linux, Mac OS, et WSL pour Windows ; normalement tout le monde peut l'utiliser. Je teste constamment sous Linux, et WSL est un Linux donc c'est testé aussi. Je n'ai pas de Mac OS donc il peut y avoir quelques surprises, mais en général c'est l'affaire de corriger un bug ou deux.
En termes de calculatrices, le fxSDK supporte :
Calculatrices monochromes
Graph 35+E II
Graph 35+ USB / Graph 35+E (SH3/SH4)
Graph 75/75+/75+E
Graph 85/85 SD/95 (SD) (pas activement testé)
Calculatrices couleurs
Graph 90+E / fx-CG 50
Prizm fx-CG 10/20
Comment installer le fxSDK et coder des add-ins
Le fxSDK s'installe à partir de dépôts Git sur la
forge de Planète Casio (par exemple
Lephenixnoir/fxsdk). Il y en a un peu beaucoup, donc manuellement c'est assez long. Pour que ça aille plus vite et pour simplifier le travail des débutants, il y a un outil appelé
GiteaPC qui peut faire ça pour vous.
Si vous utilisez Windows, vous aurez besoin de WSL pour accéder à un système Linux dans Windows. Heureusement, Microsoft a fait ça bien et c'est facile à faire. Voyez le
tutoriel d'installation de WSL 2 (et l'explication rapide de
ce que WSL 2 est).
Si vous utilisez Mac OS, ouvrez l’œil en lisant les topics pour ne pas manquer les informations supplémentaires et éventuelles déviations par rapport à la procédure normale sous Linux.
Méthode automatique avec GiteaPC (plus rapide / recommandée pour les débutants)
- Suivez le tutoriel d'utilisation de GiteaPC, qui explique comment obtenir le fxSDK.
Méthode automatique avec plugin VS Code
- Yannis300307 a créé un plugin VS Code Casio Dev Tools qui fonctionne sous Windows (avec WSL) et Debian (probablement les dérivés aussi).
Méthode AUR pour les utilisateurs Arch/Manjaro/dérivés (ils se reconnaîtront)
- Dark Storm maintient MiddleArch, un dépôt de paquets précompilés qui a entre autres le fxSDK.
Méthode manuelle (plus fine / classique pour les habitués)
- Compilez et installez le cross-compilateur GCC pour SuperH.
- installez (dans cet ordre) les dépôts fxSDK, OpenLibm, fxlibc, gint ; en option, Slyvtt/µSTL_2.3.
Description sommaire du fxSDK
Pour une introduction à l'utilisation du fxSDK qui montre comment utiliser les outils pour développer un add-in, lisez plutôt les
tutoriels d'utilisation de gint. Cette section est juste une description sommaire.
Le cœur du fxSDK est un cross-compilateur GCC pour SuperH, habituellement nommé
sh-elf-gcc. Bien sûr on a avec toute la suite d'outils, dont
as,
ld,
objdump,
objcopy (entre autres). Contrairement au vieux compilateur du SDK, GCC est un compilateur moderne avec beaucoup d'options et capable de très solides optimisations.
Sur la calculatrice, c'est
le noyau gint qui fait la majorité du travail. Il remplace fxlib/libfxcg et une partie de l'OS pour vous offrir des fonctionnalités plus cool et plus rapides. Les add-ins développés avec le fxSDK utilisent gint toutes les trois lignes !
Il y a enfin plusieurs outils utiles sur le PC qui sont utilisés durant le développement ou l'utilisation des add-ins :
- fxsdk est un script shell qui permet de créer et compiler les projets sans se prendre trop la tête. Le système de compilation officiel pour les add-ins est CMake, mais un système plus ancien de Makefile est encore supporté.
- fxconv est un outil très polyvalent qui convertit à la compilation les assets (images, polices, maps....). Il permet de travailler avec des logiciels et formats de fichiers normaux sur le PC et d'avoir automatiquement un format optimisé sur la calculatrice. fxconv est extrêmement extensible et chaque projet peut ajouter des conversions personnalisées.
- fxgxa crée les fichiers g1a (format des add-ins pour Graph monochromes) et g3a (format des add-ins pour Graph couleurs) à partir des programmes compilés.
- fxlink est un outil de communication qui peut transférer des fichiers vers les Graph 35+E II et Graph 90+E en ligne de commande, mais aussi échanger interactivement avec les add-ins gint par le câble USB, et est couramment utilisé pour réaliser des captures d'écran ou captures vidéo des add-ins.
Changelog et informations techniques
Ci-dessous se trouve la liste des posts annonçant les nouvelles versions du fxSDK, ainsi que des liens vers les instructions/tutoriels supplémentaires publiés avec.
Citer : Posté le 10/07/2015 22:45 | #
Ah, chouette
faut que je me compile un petit GCC
Citer : Posté le 12/07/2015 10:47 | #
Ça me donne des fichiers comme ça :
##
# fxSDK syntax definition file.
# Warning: this file follows a strict syntax. Please do not edit.
##
[Meta]
lang: C/C++
[SingleRules]
name: types.native
regex: \b(?:void|char|short|int|long|float|double|enum|union [i][...][/i]
color: #55afff
name: types.extra
regex: \b(?:ushort|u?int(?:8|16|32)_t|s?size_t|template|class [i][...][/i]
color: #55afff
name: types.qualifiers
regex: \b(?:register|extern|const|static|volatile|inline [i][...][/i]
color: #ff2e4c
name: constants.define
regex: \b(?:true|false|NULL|nullptr)\b
color: #ae6deb
name: constants.numeric
regex: \b\d+\b|\b0x[\dA-Fa-f]\b
color: #ae6deb
name: functions.call
regex: \b[A-Za-z_]\w*(?=\()
color: #55afff
name: functions.def
regex: \b[A-Za-z_]\w*\s+([A-Za-z_]\w*)(?=\()
color: #80d435
name: statements
regex: \b(?:if|else|for|do|while|switch|case|default|continue [i][...][/i]
color: #ff2e4c
name: statements.cpp
regex: \b(?:try|catch|throw|new|delete|operator|namespace)\b
color: #ff2e4c
name: preprocessor
regex: ^\s*#\s*(if|else||elif|ifdef|ifndef|endif|undef|include|define|pragma|not [i][...][/i]
color: #ff2e4c
name: iso646
regex: \b(?:and|and_eq|bitand|bitor|compl|not|not_eq|or|or_eq [i][...][/i]
color: #ff2e4c
name: comment.single
regex: //[^\n]*
color: #464646
[MultiRules]
name: comment.multi
open: /\*
close: \*/
color: #464646
Au fait, Je trouve que c'est pas très super de faire des trucs comme ça
<Rule>
name: iso646
regex: \b(?:and|and_eq|bitand|bitor|compl|not|not_eq|or|or_eq [i][...][/i]
color: #ff2e4c
</Rule>
<Rule>
name: comment.single
regex: //[^\n]*
color: #464646
</Rule>
Ainsi il suffit de parser récupérer toutes les <Rule>text</Rule> avec un regex puis de parser les attributs dans chaque règle, ça évite les erreurs et c'est plus joli
Citer : Posté le 12/07/2015 11:10 | #
Moi je vois deux problèmes à ça.
D'une part ça alourdit vachement la syntaxe. Ce fichier est fait pour être simple et compréhensible par tout le monde.
Tu pourrais au moins mettre ça :
regex: //[^\n]*
color: #464646
</comment.single>
même sans vérifier la balise fermante.
Mais franchement, je trouve ça moche. Ça mélange la syntaxe originelle avec du HTML (oui, c'est aussi ce que fais mon style parser, mais c'est aussi pour ça que je veux le modifier), c'est moins intuitif à éditer (il est fait pour être léger et compréhensible) et c'et pas franchement utile.
Ben oui, pourquoi ne pas ajouter des guillemets aussi pour que ce soit plus représentatif ?
regex: "//[^\n]*"
color: "#464646"
En plus ta syntaxe a le défaut que contrairement à la mienne, elle ne permet pas du tout de faire ça :
regex: [i]regex[/i]
color: #ff0000
name: rule2
regex: [i]regex[/i]
Où implicitement, la règle deux prend la même couleur que la une.
Tu fais comme tu veux, mais moi je trouve ça vraiment inutile et superficiel. Une ligne vide sépare deux règles, ça suffit largement.
Citer : Posté le 12/07/2015 13:44 | #
J'ai un gros bug : lorsque je lance la compil' depuis le fxSDK, il me dit que GCC n'a pas été trouvé.
Si je lance à la main le Makefile généré, tout va bien…
Citer : Posté le 12/07/2015 15:52 | #
C'est pas vraiment un gros bug, mais plus probablement de ta faute : tu as du ajouter le dossier de ton gcc au path dans le .bashrc, qui est lancé quand on ouvre un terminal (ce qui explique que ça fonctionne manuellement), mais pas dans le .profile, qui est exécuté au lancement de la session (ce qui explique que ça ne fonctionne pas automatiquement) !
Citer : Posté le 12/07/2015 15:56 | #
Ah, c'est donc ça.
Ajouté le 13/07/2015 à 19:28 :
Idées de trucs à ajouter :
Raccourcis clavier :
→ Ctrl (+ Shift) + Tab pour changer d'onglet, dans un sens et dans l'autre
→ Ctrl + Lettre pour ajouter le fichier ouvert au projet (ce qui permet de faire Ctrl + N > Ctrl + touche pour ajouter rapidement un nouveau fichier)
Éventuellement la coloration du log d'erreur de GCC (orange le mot "warning" rouge "error", pas besoin de plus je pense) histoire de rapidement trouver la ligne qui pose problème dans le log.
Ajouté le 13/07/2015 à 21:02 :
Ah si, aussi : une petite icone à coté du nom de l'onglet pour savoir si un fichier est enregistré ou non
Citer : Posté le 13/07/2015 22:47 | #
→ Ctrl (+ Shift) + Tab pour changer d'onglet, dans un sens et dans l'autre
→ Ctrl + Lettre pour ajouter le fichier ouvert au projet (ce qui permet de faire Ctrl + N > Ctrl + touche pour ajouter rapidement un nouveau fichier)
Bonne idée ! Je m'en occuperai.
Éventuellement la coloration du log d'erreur de GCC (orange le mot "warning" rouge "error", pas besoin de plus je pense) histoire de rapidement trouver la ligne qui pose problème dans le log.
C'est que je commence à être calé niveau coloration !
Ok, ça aussi c'est facilement faisable.
Ah si, aussi : une petite icone à coté du nom de l'onglet pour savoir si un fichier est enregistré ou non
Ah oui, y'a ça aussi... va pas falloir que ça encombre trop l'interface
Citer : Posté le 13/07/2015 23:51 | #
Un petit cercle (caractère unicode ça doit se faire non ?) qui est vide lorsque le fichier est enregistré, plein sinon. En se démerdant bien ça peut même être ton trigger pour fermer le fichier (comme dans ST quoi
Je me suis dit que pour tester, y'a qu'un test grandeur nature qui peut fonctionner, du coup je me fais le moteur de MS4 dans la soirée
MS4 parce que je saute MS3 (comme MS1) parce qu'il ne me convient pas…
Citer : Posté le 14/07/2015 09:22 | #
Un petit cercle (caractère unicode ça doit se faire non ?) qui est vide lorsque le fichier est enregistré, plein sinon. En se démerdant bien ça peut même être ton trigger pour fermer le fichier (comme dans ST quoi
Ben oui
Je me suis dit que pour tester, y'a qu'un test grandeur nature qui peut fonctionner, du coup je me fais le moteur de MS4 dans la soirée
Hey oh, brutalise pas mon SDK hein ! X)
MS4 parce que je saute MS3 (comme MS1) parce qu'il ne me convient pas…
Impossible pour moi de trouver le 3 ou le 4.
Mais faut dire aussi que le nom de MS3 a quelques restes peu propices à un développement efficace...
Citer : Posté le 14/07/2015 09:40 | #
Le 4 c'est normal, le 3 est là : http://www.planet-casio.com/Fr/programmes/voir_un_programme_casio.php?showid=2024
Bref, [/HS]
Citer : Posté le 14/07/2015 10:22 | #
Sur insistance prononcée de Dark Storm (j'ai failli me faire passer à tabac), j'ai créé un repo pour le fxSDK.
Je pense que je vais suivre un modèle de mise à jour semblable à la rolling release, comme ça vous pourrez mettre le logiciel à jour quand vous le voulez à partir du repo.
Pour cloner la version actuelle :
Ensuite, pour la compiler et l'utiliser :
$ ./fxSDK
Pour l'instant, vous devez lancer le fxSDK depuis son dossier. Évitez le raccourci bureau.
Ajouté le 14/07/2015 à 12:12 :
J'ai mis à jour le repo avec différentes améliorations et corrections signalées par Dark Storm :
→ Oublis sur le colorateur syntaxique
→ Options de compilation et de linkage
→ Numéros de ligne et polices dans l'éditeur de code
→ Quelques améliorations mineures dans le code
Citer : Posté le 14/07/2015 12:14 | #
Cool, je màj
Ajouté le 14/07/2015 à 12:22 :
Rapidement, quelques question :
→ Les options de compilation sont pas sauvegardées ?
→ C'est quoi la police de l'éditeur ? Chez moi elle est pas monospacée. Peut être l'inclure dans les fichiers source si elle n'est pas courante.
→ Manque aussi l'option "Rebuild all" (si tu peux la rendre automatique lorsque les options du compilo ont changé, ça serai top
Bref, c'est pas si évident que ça de faire un truc 100% fxSDK à l'heure actuelle
Citer : Posté le 14/07/2015 12:25 | #
→ Les options de compilation sont pas sauvegardées ?
Aah m*rde !
→ C'est quoi la police de l'éditeur ? Chez moi elle est pas monospacée. Peut être l'inclure dans les fichiers source si elle n'est pas courante.
« font-family: 'Droid Sans Mono', 'Free Mono', 'Liberation Mono', 'Inconsolata', 'Consolas'; »
Faudrait peut-être que j'en rajoute encore derrière... peut-être avec 'monospace' ?
→ Manque aussi l'option "Rebuild all" (si tu peux la rendre automatique lorsque les options du compilo ont changé, ça serai top
Hmm, pas facile : comme le Makefile change à chaque fois... enfin, je vais m'en occuper.
Bref, c'est pas si évident que ça de faire un truc 100% fxSDK à l'heure actuelle
Qui a jamais prétendu le contraire ?
Citer : Posté le 14/07/2015 12:39 | #
Rebuild all == make clean > génération du makefile > make
Ajouté le 14/07/2015 à 12:49 :
J'ai l'impression que t'as pas commit la nouvelle feuille de style… J'ai changé manuellement, j'ai bien Droid Sans M.
Citer : Posté le 14/07/2015 13:21 | #
Rebuild all == make clean > génération du makefile > make
Je sais, c'est bien ce que je vais faire.
J'ai l'impression que t'as pas commit la nouvelle feuille de style… J'ai changé manuellement, j'ai bien Droid Sans M.
Non, je ne commit pas chaque modification unique.
Ajouté le 14/07/2015 à 13:47 :
→ Les options de compilation sont pas sauvegardées ?
→ C'est quoi la police de l'éditeur ? Chez moi elle est pas monospacée. Peut être l'inclure dans les fichiers source si elle n'est pas courante.
→ Manque aussi l'option "Rebuild all" (si tu peux la rendre automatique lorsque les options du compilo ont changé, ça serai top
Les trois sont faites. Je rajoute l'automatisation lorsqu'on modifie les options.
Citer : Posté le 14/07/2015 13:57 | #
Parfait, merci
Citer : Posté le 15/07/2015 15:06 | #
J'ai envoyé quelques commits sur le repo du wrapper.
Au programme, beaucoup de modifications et nettoyage interne, plus notablement des changements dans la gestion des erreurs et un support bien plus évolué des bitmaps (supporte le 32 bits, 24 bits, monochrome et partiellement le 16 bits).
Ajouté le 15/07/2015 à 16:51 :
Hop, j'ai également ajouté une option appelée « dump » (-d) qui fait l'exact inverse du wrapper : elle affiche le contenu du header d'un fichier g1a
Une option bien pratique pour moi. Ajoutez à cela du nettoyage, encore et toujours (oui c'est incessant, mon dieu ce que je programmais mal il y a... euh... oups).
J'avance bien, une fois que le wrapper sera vraiment fonctionnel il pourra accompagner le fxSDK sans causer des problèmes toutes les deux minutes
Citer : Posté le 15/07/2015 17:29 | #
Ah, chouette. Une idée supplémentaire, dans le Make, ajouter un install: sudo cp g1a-wrapper /usr/local/cross/bin
Comme ça il se retrouve dans le path avec les autres utilitaires de compilation
Citer : Posté le 15/07/2015 17:32 | #
Ah, chouette. Une idée supplémentaire, dans le Make, ajouter un install: sudo cp g1a-wrapper /usr/local/cross/bin
Comme ça il se retrouve dans le path avec les autres utilitaires de compilation
Hmm, j'ai déjà un make install qui le fout dans le $HOME/bin, je peux éventuellement le mettre dans /usr/bin pour plus de convenance, mais /usr/local/cross/bin ça m'emmerde vraiment puisque personne n'est vraiment supposé l'avoir installé là.
Ajouté le 15/07/2015 à 17:33 :
Je peux toujours m'arranger pour le foutre à côté du sh3eb-elf mais bon, c'est pas terrible.
Citer : Posté le 15/07/2015 17:33 | #
Bah, comme c'est ça ira quand même.
Citer : Posté le 15/07/2015 17:36 | #
Je pense quand même le mettre dans /usr/bin parce que c'est plus commode... t'en penses quoi ?