Implementation STL Graph 90+E / fx-CG50
Posté le 09/11/2021 15:58
Hello,
je commence de regarder comment programmer la Graph 90+E / fx-CG50 et j'aimerais à terme rendre compatible mon GUI Toolkit NF développé à la base pour la TI nSpire sur cette machine.
Pour ceux qui ne connaitrait pas, si si, j'en vois
, vous trouverez des infos ici :
GUI Toolkit NF (sur TI-Planet).
C'est un projet offrant un Widget Toolkit pour programmer des outils/logiciels avec des composants standards (boutons, cases à cocher, zone d'entrée de texte ...). Le projet est "multi-cible", à ce stade il fonctionne sur nSpire et PC (ce qui permet de tester debugger plus facilement). Et j'aimerai bien ajouter une cible Casio Graph 90.
Problème : le projet est C++ avec usage massif de la STL ( vector / list / string / iterators ).
Question : y-a-t-il une implémentation "toute faite de la STL pour la Graph 90 que je pourrais utiliser directement ?
J'avoue que j'ai un peu galéré pour avoir une toolchain fonctionnelle (mais c'est OK, j'ai compilé avec succès mon premier Add-Ins) et je voudrais éviter de tout bousiller en faisant "portnawak"
Si rien de dispo, y a t il un tuto qq part pour faire la compilation ? Et vaut il mieux partir sur la vraie STL ou un port du genre uSTL ou STL_port ?
Merci par avance
Sly
Citer : Posté le 09/11/2021 16:18 | #
C'est compliqué ; de disponible immédiatement tu n'en as pas non.
Il faut savoir que tu as deux options pour programmer sur la Graph 90+E ; utiliser le Prizm SDK (l'option historique issue du seul SDK officiel de Casio pour les Graph mono), ou utiliser gint).
Avec l'approche PrizmSDK, il y a une libc dont le port semble perdu depuis longtemps et qui est distribuée sous forme d'achive (je crois que c'est une newlib), peut-être que tu peux compiler uSTL avec.
Avec l'approche gint, on utilise une libc maison (à tort ou à raison) et lal lib standard C++ fournie avec GCC, sobrement appelée libstdc++-v3. J'ai déjà réussi à compiler le subset free-standing qui permet de faire du C++ tout court, mais pas encore la STL complète.
Par rapport aux archis bien établies côté Nspire, c'est sûr que c'est pas le même délire. x)
Pour info, le SDK officiel avait un support discutable de la STL, donc à ma connaissance il n'y a jamais eu de vrai support C++ bien complet ni bien moderne encore.
Citer : Posté le 09/11/2021 17:56 | #
OK Merci Lephe,
je suis parti sur l'option gint.
A priori j'ai pas besoin de beaucoup de choses de la STL. A vérifier, mais je pense me débrouiller avec un support de :
- std::list
- std::vector
- std::iterator
- std::string
- plus problématique certainement std::fstream
Bon donc faut que je regarde cela de plus près, mais je risque de galérer un peu si je résume
A plus
Sly
Citer : Posté le 09/11/2021 18:47 | #
Les structures de données tu y arriveras certainement, std::fstream certainement pas. On n'a pas de support de fopen() et compagnie, le système de fichiers n'en étant jusqu'à un moment simplement pas capable, et actuellement peut-être mais je ne parie pas dessus. En général on ne touche pas au fs sauf de loin pour faire des sauvegardes etc.
Citer : Posté le 09/11/2021 19:31 | #
- plus problématique certainement std::fstream
Je pense avoir déjà essayé d'utiliser une partie de uSTL qui contient fstream:
https://github.com/pavel-demin/fxcg-notes/tree/master/ustl/src
Il utilise les fonctions de read/write que j'ai implémenté dans la partie de musl que j'ai porté sur Graph 90+E:
https://github.com/pavel-demin/fxcg-notes/blob/master/musl/unistd/read.c
https://github.com/pavel-demin/fxcg-notes/blob/master/musl/unistd/write.c
Pour le moment, je n'ai pas eu besoin de C++ dans mes petits projets, donc je n'ai pas beaucoup testé fstream sur Graph 90+E.
KhiCAS (http://www-fourier.univ-grenoble-alpes.fr/~parisse/casio/) est écrit en C++ et utilise uSTL, fstream, etc., et mon idée était de construire un environnement de développement basé sur musl pour pouvoir compiler KhiCAS mais je n'ai pas encore terminé ce projet.
Si ça t’intéresse je pourrais mieux tester et compléter la partie C++/uSTL de mon environnement de développement.
Citer : Posté le 09/11/2021 19:49 | #
Ce serait bien si ça pouvait marcher directement ; les anciennes versions du fs sont si immondes qu'il est purement impossible d'implémenter la libc dessus (eg. les fichiers doivent avoir une taille fixée à la création).
Notez juste qu'avec gint on ne peut pas utiliser Bfile à loisir il faut faire un world switch.
Citer : Posté le 09/11/2021 19:56 | #
Merci Pavel et Lephe,
donc y'a un peu de taf.
Si déjà je peux avoir le support des containers, ce sera un gros plus.
Le fstream n'est pas beaucoup utilisé, par contre le fopen c'est pas cool, car actuellement il me sert pour loader les ressources (icones/fond ecrans/themes).
Faudra que je me penche sacrément dessus.
Bon d'une manière globale, la structure du projet est pas trop dégueu dans le sens où tout ce qui est vraiment "architecture-dependant" est contenu dans des classes spécifiques.
Par contre, je pensais que le système de fichier avait de base fopen/fwrite/fclose.
Bon je pense que je risque donc de poser pas mal de questions.
Merci pour ces éléments qui m'intéressent beaucoup.
Je vous tiens au jus de mes avancées, et je reviens avec des questions...
Sly