Les membres ayant 30 points peuvent parler sur les canaux annonces, projets et hs du chat.
La shoutbox n'est pas chargée par défaut pour des raisons de performances. Cliquez pour charger.

Forum Casio - Projets de programmation


Index du Forum » Projets de programmation » Implementation STL Graph 90+E / fx-CG50
Slyvtt Hors ligne Maître du Puzzle Points: 2276 Défis: 17 Message

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


Lephenixnoir En ligne Administrateur Points: 24145 Défis: 170 Message

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.
Mon graphe (24 Mars): (gint#27 ; (Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; ...) || (shoutbox v5 ; v5)
Slyvtt Hors ligne Maître du Puzzle Points: 2276 Défis: 17 Message

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
There are only 10 types of people in the world: Those who understand binary, and those who don't ...
Lephenixnoir En ligne Administrateur Points: 24145 Défis: 170 Message

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.
Mon graphe (24 Mars): (gint#27 ; (Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; ...) || (shoutbox v5 ; v5)
Pavel Hors ligne Membre Points: 30 Défis: 0 Message

Citer : Posté le 09/11/2021 19:31 | #


Slyvtt a écrit :

- 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.
Lephenixnoir En ligne Administrateur Points: 24145 Défis: 170 Message

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.
Mon graphe (24 Mars): (gint#27 ; (Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; ...) || (shoutbox v5 ; v5)
Slyvtt Hors ligne Maître du Puzzle Points: 2276 Défis: 17 Message

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
There are only 10 types of people in the world: Those who understand binary, and those who don't ...

LienAjouter une imageAjouter une vidéoAjouter un lien vers un profilAjouter du codeCiterAjouter un spoiler(texte affichable/masquable par un clic)Ajouter une barre de progressionItaliqueGrasSoulignéAfficher du texte barréCentréJustifiéPlus petitPlus grandPlus de smileys !
Cliquez pour épingler Cliquez pour détacher Cliquez pour fermer
Alignement de l'image: Redimensionnement de l'image (en pixel):
Afficher la liste des membres
:bow: :cool: :good: :love: ^^
:omg: :fusil: :aie: :argh: :mdr:
:boulet2: :thx: :champ: :whistle: :bounce:
valider
 :)  ;)  :D  :p
 :lol:  8)  :(  :@
 0_0  :oops:  :grr:  :E
 :O  :sry:  :mmm:  :waza:
 :'(  :here:  ^^  >:)

Σ π θ ± α β γ δ Δ σ λ
Veuillez donner la réponse en chiffre
Vous devez activer le Javascript dans votre navigateur pour pouvoir valider ce formulaire.

Si vous n'avez pas volontairement désactivé cette fonctionnalité de votre navigateur, il s'agit probablement d'un bug : contactez l'équipe de Planète Casio.

Planète Casio v4.3 © créé par Neuronix et Muelsaco 2004 - 2024 | Il y a 108 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