GCCSHCBSDK mon sdk pour remplacer le fx-9860G SDK
Posté le 24/05/2015 18:44
Attention jeune voyageur!
Ne reste pas dans ces contrées abandonées, lit pour t'instruire puis retourne parmis le monde des vivants,
juste ici.
Bonjours à tous, aujourd'hui, je vous dévoile mon outil de développement personnel, ce "SDK" m'a permis de ne pas toucher le SDK de casio pendant les 10 derniers mois.
Ce "SDK" est constitué d'un cross compilateur GCC, de codeblocks, et de Calculib.
Calculib: C'est ma librairie qui permet de me passer de l'émulateur, elle permet de compiler le code pour calculatrice sur PC avec un écran et un accès au touches configurable.
Cette lib est incomplètes, mais elle est suffisante pour beaucoup, le plus gros manque sont les fonctions print.
Néanmoins, cette lib possède des avantages, elle permet par exemple de tester un addin qui rame énormément sans problème, elle permet aussi de relier deux addin à travers internet 8) (testé avec Spassus entre deux pays), pour tester le multijouer quand vous n'avez qu'une calculatrice (ou pour faire du teste rapide)
Un éditeur au choix:
-Codeblocks: Ce codeblocks n'est pas modifié, mais il est rendu portable pour pemettre de le mettre sur USB ou de modifier des options spécialement sans répercutions sur votre installation habituelle
-Sublime Text 2 (Linux seulement): Il n'est pas modifié, il est portable, mais deux build systèms ont été ajouté pour pouvoir compiler directement depuis sont interface
-Celui de voite choix ! Le sdk est designé pour pouvoir être utilisé avec n'importe quel éditeur, pas la peine de perdre vos habitudes, vos plugin et votre interface préférée, la compilation se fait simplement en appelant les .sh/.bat dans le dossier de votre projet, vous pouvez donc adapter votre éditeur facilement
GCC: Il est compilé pour SH3, version 4.8 pour windows, 4.9 pour linux
Le SDK est compatible windows et linux sans modifier les projets, utile si vous utilisez un PC linux et un windows
Quel est la différence avec un prog' pour le sdk classique ?
- Tout les includes sont regroupés dans un fichiers qui permet de ne pas avoir de #ifdef dans chaque fichier
- Les fonctions type printf sont utilisable quand compiler pour PC et sont retirée automatique à la compilation, jamais besoins de changer le code pour changer de cible
- Aucune éditeur ne permet de définir quel fichiers sont compilés et avec quelle option, pour cela il est necessaire de changer le makefile, tout les fichiers .c .cpp et .s dans le dossier src du projet sont automatiquement compilés
- Sous linux, il est necessaire d'installer wine, sauf si vous recompilez le wrapper de la communautée pour linux, il vous suffira de modifier le makefile !
- Possiblitée d'utiliser le wrapper G1A de casio ou celui de la communauteé
- Il est necessaire de copier le projet template pour crée un nouveau projet, faire un nouveau projet dans un éditeur ne fonctionnera pas
- Certaines fonctions, principalement mathématiques font crasher la calculatrice quand éxécutée (ou crée des erreurs dans la mémoire), ce n'est pas un problème de mon SDK, c'est commun quand on utlise GCC
- Monochrome lib est déja inclu, il est ncessaire d'utiliser la version du sdk !
Pour commencez, inspirez vous du template ou de 3DGine3, ses deux projets des exemples fonctionnels de la démarche à suivre
Pour upload votre G1A sur la calculatrice, je vous recommande UsbConnector (je l'ai crée pour ça), il permet d'aller plus vite qu'avec FA-124, et fonctionne sous linux.
Téléchargement:
Attention, l'archive fait 300 mo, le dossier décompressée fait 1.3Go !
https://www.dropbox.com/s/f9j0y3xfzuvre4l/GCCSHCBSDK110.tar.xz?dl=0
Changelog:
-1.1 Correction de bugs, découplement de la compilation et du lancement sur linux, support complet de sublime text 2 et support "manuel" de tout les IDEs avec l'utilisation de .bat et .sh
-1.0 première release
Citer : Posté le 24/05/2015 18:47 | #
Tu tente de concurrencer le fxSDK de Lephe ?
Je te préviens, le sien me parait bien mieux, même si le gros avantage du tien est la possibilité d'exécuter les addins sur PC
Citer : Posté le 24/05/2015 18:48 | #
Oh purée ! Tu nous postes un moteur 3D, un SDK amélioré et un logiciel de transfert pour Linux ! Mais... Mais... Bravo et merci !
Ajouté le 24/05/2015 à 18:48 :
Quel nom barbare par contre.
Pong400
PierrePaCiseaux (CP400)
Les Triangles
Menu
ASCII
Nombres premiers
Citer : Posté le 24/05/2015 18:49 | #
Tu tente de concurrencer le fxSDK de Lephe ?
Je te préviens, le sien me parait bien mieux, même si le gros avantage du tien est la possibilité d'exécuter les addins sur PC
Le mien dispose d'une interface graphique
Nan, sérieusement, il n'y a aucune concurrence entre nous, à moins qu'il ne le veule
Par contre si ça ne te dérange pas, je me ferai une joie d'intégrer les concepts intéressant de ton sdk au fxSDK !
Merci pour toutes ces contributions
Citer : Posté le 24/05/2015 18:51 | #
@Ds: je ne concurence pas le fxSDK, mon SDK est fait pour ceux qui aime codeblocks et ses plugins, codeblocks possède une communautée entière et plein de modifs possible pour le rendre le plus agréable possible
@Lego, j'ai commencer ce SDK et le moteur 3D en même temps, il y a 10 mois, le transfère pour linux, ça fait 2 mois que c'est pret et que j'ai la flème d'y toucher
De rien
Voici Spassus2, mon jeu de combat spatial procédural abandonné, le NESSCASDK, mon SDK 'barebones' fait maison (C'est pour les maso uniquement) et CasioUsb, mon utilitaire de transfert d'addin pour Linux.
Citer : Posté le 24/05/2015 18:54 | #
Je plaisantais, bien sur
En tout cas c'est du beau boulot. Je dois reconnaitre que l'idée du code compilé pour l'ordi (et donc permettre de l'exécuter sans émulateur) est un concept à creuser. Le truc c'est que du coup, si je ne me trompe, tu ne gère pas les syscalls ?
Citer : Posté le 24/05/2015 18:55 | #
Je gère suffisament de syscall pour être utilisable, j'ai le ticks, le 3pin, mais pas grand chôse d'autre, j'utilise une version modifiée de monochromelib aussi
Voici Spassus2, mon jeu de combat spatial procédural abandonné, le NESSCASDK, mon SDK 'barebones' fait maison (C'est pour les maso uniquement) et CasioUsb, mon utilitaire de transfert d'addin pour Linux.
Citer : Posté le 24/05/2015 18:56 | #
Ah, great ça !
Citer : Posté le 24/05/2015 19:02 | #
... J'ai fait quoi du serveur pour le 3 pin ? *fail* ... je trouverai ça plus tard, faut voir si j'ai une save de la SD de mon RPI x)
Voici Spassus2, mon jeu de combat spatial procédural abandonné, le NESSCASDK, mon SDK 'barebones' fait maison (C'est pour les maso uniquement) et CasioUsb, mon utilitaire de transfert d'addin pour Linux.
Citer : Posté le 25/05/2015 09:35 | #
Tu tente de concurrencer le fxSDK de Lephe ?
Je te préviens, le sien me parait bien mieux, même si le gros avantage du tien est la possibilité d'exécuter les addins sur PC
Le mien dispose d'une interface graphique
Nan, sérieusement, il n'y a aucune concurrence entre nous, à moins qu'il ne le veule
Par contre si ça ne te dérange pas, je me ferai une joie d'intégrer les concepts intéressant de ton sdk au fxSDK !
Merci pour toutes ces contributions
Idem
- Tout les includes sont regroupés dans un fichiers qui permet de ne pas avoir de #ifdef dans chaque fichier
Je comprends pas bien là, tu veux dire que on ne devra inclure qu'un fichier?
Ajouté le 25/05/2015 à 09:40 :
Citer : Posté le 25/05/2015 10:15 | #
- Tout les includes sont regroupés dans un fichiers qui permet de ne pas avoir de #ifdef dans chaque fichier
Euh... j'ai un doute sur la propreté de cette solution là...
Je gère suffisament de syscall pour être utilisable, j'ai le ticks, le 3pin, mais pas grand chôse d'autre, j'utilise une version modifiée de monochromelib aussi
Le problème je pense, de ces versions compilées pour PC, c'est qu'on ne peut pas jouer profondément avec le système : comment gères-tu les appels de syscall à partir d'un tableau (puisqu'il n'y a pas besoin de modifier le code pour passer d'une version à l'autre) ?
Et puis, je ne pense pas qu'on puisse écrire de l'assembleur pour les deux plateformes à la fois, donc impossible de linker une bibliothèque.
ça me fait d'ailleurs pensé à une super idée
Non.
Non
Citer : Posté le 25/05/2015 10:19 | #
ça me fait d'ailleurs pensé à une super idée
Non.
Non
Si.
Si
Citer : Posté le 25/05/2015 15:58 | #
@Lephe, c'est vrai que c'est pas propre
Pour les syscalls, il existe deux fichiers, un contenant les syscalls normaux pour la calculatrice, et l'autre est un morceau ce calculib, il faut donc implémenter à la main les syscalls dans calculib et les nommer comme les syscalls calto
Pour linker une lib, il te faut les sources, si tu les ajoutes dans ton dossier src, elles seront compilées, si tu veut les laisser dans un fichier différent, il faut que tu les ajoutes dans le makefile de ton projet
Voici Spassus2, mon jeu de combat spatial procédural abandonné, le NESSCASDK, mon SDK 'barebones' fait maison (C'est pour les maso uniquement) et CasioUsb, mon utilitaire de transfert d'addin pour Linux.
Citer : Posté le 25/05/2015 17:25 | #
@Lephe, c'est vrai que c'est pas propre
Je me doute bien que c'est plus simple, mais ce n'est pas comme ça que ça fonctionne.
Pour les syscalls, il existe deux fichiers, un contenant les syscalls normaux pour la calculatrice, et l'autre est un morceau ce calculib, il faut donc implémenter à la main les syscalls dans calculib et les nommer comme les syscalls calto
Du coup tu modifies les sources...
Pour linker une lib, il te faut les sources, si tu les ajoutes dans ton dossier src, elles seront compilées, si tu veut les laisser dans un fichier différent, il faut que tu les ajoutes dans le makefile de ton projet
Ouais, donc on peut pas linker de bibliothèque quoi. xD
Il me semble que ça soulève un léger problème dans le fonctionnement de ton sdk.
Citer : Posté le 25/05/2015 17:41 | #
Pour les colisition de définitions, normalement, ça passe, pourquoi y aurait'il deux fonction/objets nommé pareil ?
après, si tu veut vraiment laisser les includes dans chaque fichier d'un projet avec tout les ifdefs, t'a plus d'expérience, donc je le ferais
Je modifie les sources de calculib une fois, et ensuite je peut utiliser le syscall dans tout les projets, c'est déja pas mal
On ne peut pas linker non, mais, c'est de toute manière impossible
J'ai sûrement oublier de préciser que çe SDK n'a pas été concu pour être distribué à la base, ce système rempli bien sa fonction je trouve
Voici Spassus2, mon jeu de combat spatial procédural abandonné, le NESSCASDK, mon SDK 'barebones' fait maison (C'est pour les maso uniquement) et CasioUsb, mon utilitaire de transfert d'addin pour Linux.
Citer : Posté le 25/05/2015 17:47 | #
Pour les colisition de définitions, normalement, ça passe, pourquoi y aurait'il deux fonction/objets nommé pareil ?
après, si tu veut vraiment laisser les includes dans chaque fichier d'un projet avec tout les ifdefs, t'a plus d'expérience, donc je le ferais
Parce qu'un define peut changer d'un header à l'autre, ou qu'un fichier peut être pensé pour être compilé sans lib standard et redéfinir autrement ses fonctions, ou des définitions statiques qui se mélangent, y'a plein de cas possibles !
Je modifie les sources de calculib une fois, et ensuite je peut utiliser le syscall dans tout les projets, c'est déja pas mal
Oui, mais du coup c'est inexact de dire que les sources n'ont pas à être modifiées
On ne peut pas linker non, mais, c'est de toute manière impossible
Non, ce n'est pas de toute manière impossible. La bonne réponse aurait été de me dire que tu avais une version compilée pour le PC et une pour la calto
Et, non, tu n'as pas toujours les sources sous la main. Ça par contre ce n'est pas vrai !
J'ai sûrement oublier de préciser que çe SDK n'a pas été concu pour être distribué à la base, ce système rempli bien sa fonction je trouve
Certes, mais tu l'as quand même distribué
Par contre, on peut faire tout ça avec le fx-9860G SDK et je ne sais pas si tu dirais qu'il a fait ses preuves pour autant