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 » KhiCAS, add-in calcul formel pour Graph 90+e et 35eii
Parisse Hors ligne Membre Points: 457 Défis: 0 Message

KhiCAS, add-in calcul formel pour Graph 90+e et 35eii

Posté le 15/07/2018 12:09

KhiCAS est le portage de Xcas pour Casio Graph 90+e et 35eii. En résumé, il transforme votre calculatrice en calculatrice CAS (ce qui en fait de la 35eii la calculatrice CAS la moins chère du marché!), programmable en Python (soit avec MicroPython, soit en syntaxe Python dans Xcas).
Documentation
Version complète pour Graph 90 Fichier g3a et Fichier complémentaire (attention pour l'émulateur il faut utiliser ces fichiers g3a et complément).
Version courte pour Graph 90 Fichier g3a ou pour Graph 35eii Fichier g1a : certaines fonctions de Xcas ne sont pas disponibles (géométrie, moteur de rendu 3d, tableur, certaines commandes Xcas manquent, pas d'interpréteur MicroPython)
Video sur des exercices niveau lycee


Précédente 1, 2, 3 ··· 5, 6, 7, 8, 9, 10, 11, 12 Suivante
Parisse Hors ligne Membre Points: 457 Défis: 0 Message

Citer : Posté le 18/08/2022 11:46 | #


Les versions alpha ont à nouveau été mises à jour avec une nouvelle fonctionnalité : le tracé de fonction de C dans C, avec au choix par exemple la commande plot((x+i*y)^2) ou pour des fonctions dépendant directement sans complexe sans passer par la partie réelle et imaginaire, plot3d(x^2) (on ne peut pas utiliser directement plot(x^2) car cela est compris comme un graphe de R dans R). Le module du complexe résultat est représenté selon z, l'argument avec une couleur de l'arc en ciel.

En codant cela, j'ai rencontré un problème assez déconcertant: pour avoir les couleurs de l'arc en ciel, j'avais créé un tableau constant déclaré comme suit

  struct int4 {
    int u,d,du,dd;
    int4(int u_,int d_,int du_,int dd_):u(u_),d(d_),du(du_),dd(dd_) {}
  };

  const int4 tabcolorcplx[]={
{63488,47104,30720,14336},
{63489,47105,30720,14336},
{63491,47106,30721,14336},
...

Ca compile correctement mais le tableau n'est pas initialisé correctement par le chargeur. Il ne contient que des 0. J'ai alors essayé de remplacer l'initialisation {} par des int4() mais sans succès.
J'ai finalement du déclarer le tableau sans const et rajouter le code suivant

      if (tabcolorcplx[0].u==0){
    for (int i=0;i<126;i++){
      tabcolorcplx[i].u=arc_en_ciel(i,1);
      tabcolorcplx[i].d=arc_en_ciel(i,.75);
      tabcolorcplx[i].du=arc_en_ciel(i,.5);
      tabcolorcplx[i].dd=arc_en_ciel(i,.25);
    }
      }
Lephenixnoir Hors ligne Administrateur Points: 24145 Défis: 170 Message

Citer : Posté le 22/08/2022 22:18 | #


Intéressant comme bug de chargement. Je soupçonne que la section n'est pas linkée correctement parce que le compilateur C++ a tendance à donner des noms bizarres aux sections et il se pourrait que le linker script ne la repère pas.

Tu peux tester cette théorie très rapidement en utilisant le tableau initialisé normalement et en affichant les sections du fichier ELF avec sh3eb-elf-objdump -h.
Mon graphe (24 Mars): (gint#27 ; (Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; ...) || (shoutbox v5 ; v5)
Parisse Hors ligne Membre Points: 457 Défis: 0 Message

Citer : Posté le 23/08/2022 15:39 | #


Si le tableau est declare en const, sh3eb-elf-objdump -C -t khicas.elf me renvoie
081306ec l     O .bss    000007e0 xcas::tabcolorcplx

Si non déclaré en const,
081306dc g     O .bss    000007e0 xcas::tabcolorcplx
Lephenixnoir Hors ligne Administrateur Points: 24145 Défis: 170 Message

Citer : Posté le 23/08/2022 15:51 | #


Ah ben oui .bss c'est initialisé à 0 par le chargeur. Peux-tu regarder le symbole dans le fichier objet qui contient tabcolorcplx ?
Mon graphe (24 Mars): (gint#27 ; (Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; ...) || (shoutbox v5 ; v5)
Parisse Hors ligne Membre Points: 457 Défis: 0 Message

Citer : Posté le 23/08/2022 19:22 | #


Voila ce que me renvoie

sh3eb-elf-nm zdisplay.o | grep tabcolorcplx
00000004 B __ZN4xcas12tabcolorcplxE
Parisse Hors ligne Membre Points: 457 Défis: 0 Message

Citer : Posté le 23/08/2022 19:24 | #


Oups, c'était la version sans const, la version avec const renvoie

00000014 b __ZN4xcasL12tabcolorcplxE
Lephenixnoir Hors ligne Administrateur Points: 24145 Défis: 170 Message

Citer : Posté le 23/08/2022 19:30 | #


Donc il est déjà dans la section BSS, ie. initialisé à 0.

À bien y réfléchir, si le tableau est static const il devrait être initialisé correctement. S'il n'est pas const il devrait être copié dans la pile au début de la fonction...
Mon graphe (24 Mars): (gint#27 ; (Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; ...) || (shoutbox v5 ; v5)
Parisse Hors ligne Membre Points: 457 Défis: 0 Message

Citer : Posté le 23/08/2022 20:46 | #


C'est une variable globale.
Lephenixnoir Hors ligne Administrateur Points: 24145 Défis: 170 Message

Citer : Posté le 24/08/2022 16:55 | #


Ta structure int4 elle est POD ? Je me demande si un constructeur ne pourrait pas interférer. Sinon je vois pas pourquoi un tableau comme ça serait pas initialisé. Si tu fais un int tabcolorplx[][4] = { ... } sûrement il est initialisé correctement (dans la section .data/.rodata) ?
Mon graphe (24 Mars): (gint#27 ; (Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; ...) || (shoutbox v5 ; v5)
Parisse Hors ligne Membre Points: 457 Défis: 0 Message

Citer : Posté le 24/08/2022 21:10 | #


Il y a juste le constructeur d'initialisation qui est pratique à d'autres endroits (pas indispensable non plus). Le même code ne pose pas de problème avec la Numworks et TI nspire CX.
Lephenixnoir Hors ligne Administrateur Points: 24145 Défis: 170 Message

Citer : Posté le 24/08/2022 22:58 | #


Désolé pour le retour mou. J'ai testé, je pense avoir trouvé. Si on reprend depuis le début :

% cat a.cpp
   struct int4 {
    int u,d,du,dd;
    int4(int u_,int d_,int du_,int dd_):u(u_),d(d_),du(du_),dd(dd_) {}
  };

  const int4 tabcolorcplx[]={
{63488,47104,30720,14336},
{63489,47105,30720,14336},
{63491,47106,30721,14336},
};

Le symbole est bien dans .bss :

% sh-elf-g++ -c a.cpp -o a-sh.o -Wall -Wextra
% sh-elf-objdump -C -t a-sh.o
(...)
00000000 l    df *ABS*    00000000 a.cpp
00000000 l     O .bss    00000030 tabcolorcplx
00000000 l     F .text    000000b0 __static_initialization_and_destruction_0(int, int)
000000b0 l     F .text    00000024 _GLOBAL__sub_I_a.cpp
00000000 l       .group    00000000 ZN4int4C5Eiiii
00000000  w    F .text._ZN4int4C2Eiiii    0000005e int4::int4(int, int, int, int)
00000000  w    F .text._ZN4int4C2Eiiii    0000005e int4::int4(int, int, int, int)

Une symbole dans la section .bss n'est pas initialisé ou initialisé à 0, donc clairement le compilateur ne compte donc pas sur l'initialisation des sections de données pour assigner ta variable.

À la place, l'initialisation se fait via un constructeur (pas au sens C++, juste une fonction lancée au démarrage du programme) qui est révélé par l'existence d'une section .ctors contenant un pointeur de 4 octets :

% sh-elf-objdump -h -j .ctors a-sh.o

a-sh.o:     file format elf32-sh

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  5 .ctors        00000004  00000000  00000000  00000170  2**2
                  CONTENTS, ALLOC, LOAD, RELOC, DATA

À partir de là c'est facile (supposant le code que j'ai trouvé dans la version en ligne de giac90.tgz). Aucun des linker scripts (relativement simples) que tu utilises ne collecte ces constructeurs. Je n'ai pas trouvé le loader dans l'archive, mais l'idée générale c'est que tu veux collecter les constructeurs comme ceci et ensuite les appeler comme ceci, bien sûr après avoir initialisé les sections.
Mon graphe (24 Mars): (gint#27 ; (Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; ...) || (shoutbox v5 ; v5)
Parisse Hors ligne Membre Points: 457 Défis: 0 Message

Citer : Posté le 25/08/2022 10:28 | #


Hum, je crois que pour le moment je vais laisser l'initialisation en RAM, je vais rajouter un commentaire dans le source.
Parisse Hors ligne Membre Points: 457 Défis: 0 Message

Citer : Posté le 31/08/2022 17:19 | #


Je viens de passer les versions en 2 addins en version stable de KhiCAS. La doc a ete mise a jour
https://www-fourier.univ-grenoble-alpes.fr/~parisse/casio/khicasio.html#sec3
et je suis en train de terminer un document sur la nouvelle application de geometrie 2d et 3d de KhiCAS
https://www-fourier.univ-grenoble-alpes.fr/~parisse/irem/geo.html

N.B.: La Graph 90 a sa propre application de geometrie 2d mais elle a enormement moins de fonctionnalites!
Parisse Hors ligne Membre Points: 457 Défis: 0 Message

Citer : Posté le 01/09/2022 18:12 | #


Je suis sur un crash assez inexplicable (sur le calcul de integrate(abs(cos(x)),x,0,pi)), le crash affiche address(R), en df1ed41f (pc=10).
Ca correspond a une adresse en memoire? Merci!
Lephenixnoir Hors ligne Administrateur Points: 24145 Défis: 170 Message

Citer : Posté le 01/09/2022 21:30 | #


Ce n'est pas une adresse mémoire, c'est du code. Spécifiquement si ma mémoire est bonne c'est les 4 octets que tu obtiens si tu lis à NULL.

Cela suggère qu'un pointeur sur fonction a été lu, non pas à sa place, mais à NULL.
Mon graphe (24 Mars): (gint#27 ; (Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; ...) || (shoutbox v5 ; v5)
Parisse Hors ligne Membre Points: 457 Défis: 0 Message

Citer : Posté le 01/09/2022 23:03 | #


Merci! Donc ca ne m'aidera pas a localiser l'erreur, du coup je me lance avec le debugger sur l'emulateur. C'est loin d'etre aussi pratique que le debugger sur PC mais c'est quand meme un progres enorme par rapport a avant, en particulier en l'utilisant en parallele avec le debugger sur PC sur le meme code.
Du coup, je viens de remettre a jour tous les binaires, j'ai corrige 2 ou 3 bugs dans des calculs d'integrale en testant une partie de mes exos pour les L2 physique. Je vais surement en trouver encore dans les prochains jours.
Parisse Hors ligne Membre Points: 457 Défis: 0 Message

Citer : Posté le 02/09/2022 12:07 | #


J'ai toujours un probleme, tres certainement lie a l'allocation memoire, dont je n'arrive pas a determiner l'origine precise. Symptome: si on fait
arclen([3cos(x)-cos(3x),3sin(x)-sin(3x)],x,0,2*pi)
j'ai un crash si j'utilise l'allocateur custom par defaut, et pas de crash si j'utilise le heap systeme par defaut. J'ai essaye de trouver ou le probleme se pose avec le debugger mais la position de l'erreur n'est pas completement stable (ca semble dependre de l'etat de la machine).
Plus precisement, j'ai fait a plusieurs reprises hbreak zseries.cc:2392, puis c 3 fois, au 3eme arret hbreak zseries.cc:2006 puis c, puis hbreak zseries.cc:617 dans la fonction pdiv ou j'ai vu plusieurs fois le crash. Mais il semble aussi s'etre produit dans pcompose et lors de ma derniere tentative,c'etait avant le 2eme hbreak, et l'adresse du PC lors du crash se situait dans le code de kmalloc.
Du coup je change dans main.cc:1196 static_ram.is_default = 0; dans le code d'initialisation de l'arene et la le calcul arrive a son terme sans problemes!
Je vais tester la stabilite dans cette configuration, j'en ai besoin rapidement pour preter les calcs aux etudiants et la recherche de ce genre de bugs est long et hasardeux. Si je comprends bien ca ne change rien en terme de total de memoire accessible, c'est juste l'ordre qui change.
Parisse Hors ligne Membre Points: 457 Défis: 0 Message

Citer : Posté le 02/09/2022 13:38 | #


Voila maintenant qu'il m'arrive le meme probleme sur ma calc que celui signale par un utilisateur de fxcg50, pas possible de lancer khicas90 overclocke alors que j'arrive a lancer khicas50 non overclocke!!!
Lephenixnoir Hors ligne Administrateur Points: 24145 Défis: 170 Message

Citer : Posté le 02/09/2022 13:39 | #


Merci. Ça change beaucoup la mémoire accessible parce que l'arène est invisible pour malloc() ; tu as essentiellement supprimé l'arène, donc malheureusement je pense que ce patch doit te créer des problèmes ailleurs.

C'est vraiment dur de reproduire les problèmes avec KhiCAS pour moi ; j'admets ne pas être sûr d'avoir le temps de faire un test abouti dans les prochaines semaines (thèse + déménagement + etc). Un bug de kmalloc n'est bien sûr pas exclu. Je me permets de noter que l'introduction de kmalloc a révélé par des crashs dans _kfree pas mal de buffer overflows invisibles avant, et à date aucun bug dans l'allocateur lui-même. Il me paraît donc légitime de voir si un buffer overflow peut exister de ton côté ; un petit coup de valgrind, si tu y as accès, devrait tester cette théorie sans nécessiter de gros efforts.
Mon graphe (24 Mars): (gint#27 ; (Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; ...) || (shoutbox v5 ; v5)
Parisse Hors ligne Membre Points: 457 Défis: 0 Message

Citer : Posté le 02/09/2022 14:31 | #


Oui, je suis assez convaincu que l'erreur est quelque part dans khicas, pas dans kmalloc, le fait d'utiliser kmalloc accelere juste un peu le crash vs le malloc sur le heap. Malheureusement, je n'arrive pas a detecter de problemes en utilisant valgrind sur le meme code sur PC. Enfin, ce n'est pas tout a fait le meme code a cause des specificites de la casio, en particulier stl vs ustl et endianness.
Ca fait 6h que je suis en train de faire du parallel debug entre gdb et cross-gdb, tout a l'air de bien fonctionner jusqu'au moment ou ca crash sur l'emulateur. Du coup, peut-etre que tu as des suggestions pour ameliorer ma productivite sur le cross-debugger:
1/ peut-on faire un backtrace sur le cross-gdb avec l'emulateur lorsque la fenetre de crash apparait? Sur PC, je fais bt dans gdb et je peux voir les frames appelant le code qui crashe
2/ peut-on faire un output vers le cross-gdb sh3? Avec le cross-debugger arm et firebird-emu sur nspire, ca marche et c'est tres utile pour visualiser des giac::gen et des giac::vecteur parce que j'ai une fonction membre dbgprint() pour voir les valeurs de maniere comprehensible.
Parisse Hors ligne Membre Points: 457 Défis: 0 Message

Citer : Posté le 02/09/2022 14:34 | #


Sur la question de l'overclock, il y a certainement un probleme avec clock_set_speed(5);
Lorsque je lance ptune et que je fais F5, je peux lancer KhiCAS avec overclock (le code clock_set_speed(5) s'execute sans probleme). Par contre ptune F1 (normal) puis KhiCAS avec overclock crashe. Symptome: l'ecran devient noir puis ca reboote au bout de quelques secondes.
Précédente 1, 2, 3 ··· 5, 6, 7, 8, 9, 10, 11, 12 Suivante

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 71 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