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 » SDK gcc pour addin 35e2/portage KhiCAS
Parisse Hors ligne Membre Points: 457 Défis: 0 Message

SDK gcc pour addin 35e2/portage KhiCAS

Posté le 16/04/2019 20:58

Souhaitant porter KhiCAS sur la nouvelle casio 35, j'ouvre le sujet d'un SDK pour la Graph 35e2. La branche liberation du code source d'Eigenmaths (https://git.planet-casio.com/Nemh/Eigenmath/tree/liberation) contient une version gcc qui suffit pour compiler Eigenmaths, elle convient aussi pour tommath (entiers longs utilisables avec giac) mais pas pour porter la uSTL, la libc est incomplete, il manque par exemple printf, fprintf, errno, etc. Et cette libc est fournie sans code source (c'est probablement la libc du SDK de Casio?).
Je pense qu'il doit etre possible de porter la libc que j'utilise pour KhiCAS (https://www-fourier.ujf-grenoble.fr/~parisse/casio/libfxcg.tar.gz), en remplacant principalement dans stdio.c les appels fxcg vers libfx. Mais Lephenixnoir me suggere d'utiliser le portage de newlib par Memallox https://git.planet-casio.com/Memallox/libc
Question: est-ce que ce portage est compatible avec la 35e2?
Existe-t-il une version compilee (libc.a et fichiers headers) quelque part?



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

Citer : Posté le 20/04/2019 16:32 | #


Bien joué !

Que fait aplatir_plus_only d'exotique ? Arrête-moi si je me trompe, mais ça ressemble juste à une fonction pour normaliser la forme des termes ?

Comment appelle-t-on un syscall (le syscall 135 pour GetVRAMAddress)?

Comme ceci.

.global _GetVRAMAddress

_GetVRAMAddress:
    mov.l   syscall_table, r2
    mov.l   1f, r0
    jmp     @r2
    nop
1:  .long   0x135

syscall_table:
    .long   0x80010070

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 20/04/2019 20:58 | #


aplatir_plus_only supprime les + imbriques provenant du parser pour eviter un stack overflow lors d'une evaluation (ca ne devrait pas se produire pour une expression entree a la calculatrice, ce n'est pas la qu'on va rentrer des polynomes sommes de plusieurs milliers de monomes). Je n'ai pas encore determine pourquoi ca crashait, il n'y a effectivement rien d'extraordinaire dans ce code. J'ai pour le moment desactive aplatir_plus a l'issue du parser et dans la commande regroup. Je le reactiverai quand j'aurai compris la raison du crash, mais c'est assez fastidieux parce que je suis oblige de tester a l'aveugle en ajoutant des return prematures pour voir quelle instruction cause le crash, je n'ai pas de debugger, a chaque changement il faut recharger l'addin sur la Casio pour tester. Ma premiere priorite c'est d'avoir un addin relativement fonctionnel, et la il me semble qu'il y a deja pas mal de calculs qui passent.

Merci pour le syscall, je suppose que je peux m'inspirer d'un fichier qui fait deja ce genre de trucs.

Ajouté le 21/04/2019 à 08:53 :
Le probleme de aplatir_plus_only vient de l'appel a reverse de la uSTL. J'ai ecrit une version specifique pour les vecteurs de gen, mais je ne vois pas pourquoi la version generique de ualgo.h plante.
Quelques crash en moins, mais il en reste encore pas mal si on fait des trucs un peu evolues.
Lephenixnoir En ligne Administrateur Points: 24145 Défis: 170 Message

Citer : Posté le 21/04/2019 17:51 | #


Tu progresses super vite, je suis impressionné en vrai. :o
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 21/04/2019 18:49 | #


Bon, ma version de reverse avait un bug, une fois celui-ci corrige, ca semble aller mieux! J'ai mis a jour le tout.

Ajouté le 22/04/2019 à 15:32 :
Nouvelle mise a jour, les menus ont ete modifies, et il y a de l'aide en ligne pour les commandes du menu alg (F1), accessible en mettant en surbrillance le nom de la commande dans le menu puis en tapant curseur vers la droite, quand l'aide est affichee on peut alors recopier l'exemple en tapant Entree, ce qui permet de le modifier. Les autres commandes suivront...
Je pense que je ne vais pas utiliser l'afficheur tex pour le pretty print, car il faudrait que je reimporte la traduction latex de giac que j'avais enlevee, c'est probablement plus simple de porter l'editeur d'expression de la 90.
Lephenixnoir En ligne Administrateur Points: 24145 Défis: 170 Message

Citer : Posté le 22/04/2019 16:07 | #


Parisse a écrit :
Je pense que je ne vais pas utiliser l'afficheur tex pour le pretty print, car il faudrait que je reimporte la traduction latex de giac que j'avais enlevee, c'est probablement plus simple de porter l'editeur d'expression de la 90.

Tu pourrais exposer les fonctions pour créer directement des noeuds, mais je ne dis ça vraiment que pour le principe.
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 22/04/2019 22:24 | #


Je n'ai pas compris?
Lephenixnoir En ligne Administrateur Points: 24145 Défis: 170 Message

Citer : Posté le 22/04/2019 22:42 | #


Même si l'API de ce fichier prend du latex en entrée, il a quand même une structure arborescente. Comme tu as déjà ça dans giac, tu pourrais générer directement l'arbre en contournant le pseudo-parser (qui est tout nul d'ailleurs).

Mais bon, même avec ça, le module reste trop pauvre donc ça n'en vaut pas vraiment la peine. Je n'ai simplement pas pu m'empêcher de répondre sur le plan technique à "il faudrait que je réimporte la traduction latex".
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/04/2019 08:05 | #


Je vois dans l'afficheur tex

void Txt_Pixel(int x, int y, int v)
{
  if(x&~127 || y&~63) return;
  if(v) *(Txt_VRAM+(y<<4)+(x>>3)) |=  (128>>(x&7));
  else  *(Txt_VRAM+(y<<4)+(x>>3)) &= ~(128>>(x&7));
}

qui j'imagine allume ou eteint le pixel x,y, a condition que Txt_VRAM soit bien positionne. Il y a aussi setPixel dans disp.src (dont la syntaxe n'est pas celle de gcc, correct?). Quelle est la difference avec Bdisp_SetPoint_DD/ Bdisp_SetPoint_VRAM/ Bdisp_SetPoint_DDVRAM? Est-ce pour une question d'efficacite?
Lephenixnoir En ligne Administrateur Points: 24145 Défis: 170 Message

Citer : Posté le 23/04/2019 13:09 | #


Pour cette fonction-là le gain de vitesse est discutable, mais oui dans l'essentiel c'est la vitesse. Il n'y a pas de différence d'effet avec Bdisp_SetPoint_VRAM(). Pour les fonctions plus élaborées MonochromeLib a démontré qu'on pouvait gagner une énorme marge (notamment sur le tracé d'images), et j'arrive encore à gagner des facteurs significatifs (type 8 ou 10).

Ici on peut optimiser x&~127 en (unsigned)x > 127 et y&~63 en (unsigned)y > 63.

De toute façon le véritable constat est ailleurs : sur monochrome, tout système de dessin qui fait des appels répétés à une fonction qui change la couleur d'un seul pixel est lent.
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/04/2019 16:51 | #


Bon, j'ai a peu pres porte l'affichage des graphes dans KhiCAS (ainsi que les commandes Xcas draw_pixel, draw_rectangle, draw_circle, draw_polygon, etc), et ca va suffisamment vite avec les fonctions de trace de Casio. J'ai supprime l'entree lin du menu pour la remplacer par une entree plot. A terme je pense utiliser la touche Matr pour gerer les matrices et les commandes d'algebre lineaire (List pour les listes et PRGM pour les programmes).
L'addin et le source sont a jour sur mon site.
Je vais maintenant regarder l'editeur/afficheur d'expression. J'ai vu dans les syscalls l'equivalent Setup_GetEntry de GetSetupSetting sur la 90, mais je n'ai pas vu d'equivalent de la commande inverse SetSetupSetting, ca existe ?
Lephenixnoir En ligne Administrateur Points: 24145 Défis: 170 Message

Citer : Posté le 23/04/2019 18:42 | #


Bien sûr ; c'est même le numéro 0x4dd juste après Setup_GetEntry().

Les détails sont documentés dans fx_legacy_Setup.htm.
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/04/2019 18:16 | #


L'editeur 2d a progresse. Il y a encore pas mal de details a corriger mais ca commence a etre utilisable.

Ajouté le 24/04/2019 à 18:21 :
Par exemple, la gestion de F5 pour passer de majuscule/minuscules dans la ligne de commande qui modifie la selection de l'editeur 2d ne fonctionne pas correctement comme sur la 90, pourtant j'utilise le meme code:

  extern "C" {
    char Setup_GetEntry(unsigned int index);
    char *Setup_SetEntry(unsigned int index, char setting);
  }
#define SetSetupSetting Setup_SetEntry
  
  int handle_f5(){
    int keyflag = Setup_GetEntry(0x14);
    if (keyflag == 0x04 || keyflag == 0x08 || keyflag == 0x84 || keyflag == 0x88) {
      // ^only applies if some sort of alpha (not locked) is already on
      if (keyflag == 0x08 || keyflag == 0x88) { //if lowercase
    SetSetupSetting( (unsigned int)0x14, keyflag-0x04);
    return 1; //do not process the key, because otherwise we will leave alpha status
      } else {
    SetSetupSetting( (unsigned int)0x14, keyflag+0x04);
    return 1; //do not process the key, because otherwise we will leave alpha status
      }
    }
    if (keyflag==0) {
      SetSetupSetting( (unsigned int)0x14, 0x88);    
    }
    return 0;
  }
Lephenixnoir En ligne Administrateur Points: 24145 Défis: 170 Message

Citer : Posté le 24/04/2019 18:35 | #


Je ne sais pas s'il y a un changement de valeur entre la Graph monochrome et la Prizm ; si tu y tiens tu peux toujours espionner la valeur du flag en lançant un timer depuis un add-in sans l'arrêter en partant.
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/04/2019 21:31 | #


La bascule en mode alpha minuscule bloque fonctionne, c'est la bascule maj/min qui ne marche pas.
Je n'arrive pas non plus a faire marcher shift-left et shift-right pour aller directement en debut/fin de ligne.
Lephenixnoir En ligne Administrateur Points: 24145 Défis: 170 Message

Citer : Posté le 24/04/2019 21:32 | #


Shift-Left et Shift-Right sont normalement bindés par GetKey() sur une commande de modification du contraste ; tu ne peux rien y faire à moins de réimplenter une partie de la gestion des entrées.
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/04/2019 09:13 | #


Tant pis. Je vais faire en sorte que le curseur en ligne d'edition reparte a 0 si on fait curseur droite en fin de ligne (et l'inverse).
La touche FRAC va servir a afficher une ligne de l'historique en 2d, ou a editer une nouvelle ligne en 2d.

Ajouté le 25/04/2019 à 16:16 :
J'ai compris le bug du F5 en chassant quelques warnings, c'est parce que ca travaille avec un char signed et pas unsigned...
Je m'attaque a la persistance des donnees, mais je rencontre un probleme avec le syscall 0x494 (void SetQuitHandler( void (*callback)(void) );) de https://bible.planet-casio.com/simlo/chm/v20/fx_legacy_syscalls.htm
J'ai rajoute dans syscalls.s

...
    .global _SetQuitHandler
...
_SetQuitHandler:    
    mov.l    syscall_table, r2
    mov.l    1f, r0
    jmp    @r2
    nop
1:    .long    0x0494
    

puis dans un de mes fichiers sources

void save_session(){
}

int main(int isAppli, unsigned short OptionNum){
...
  // SetQuitHandler(save_session); // automatically save session when exiting
...


Si je decommente la ligne SetQuitHandler, l'addin plante quand on le quitte (par exemple en faisant MENU puis MEMORY).
Avec comme erreur Illegal Code Err TARGET et PC sont a 00000000
Pourtant le callback ne fait rien.
On dirait qu'il attend un autre prototype que celui documente, avec une valeur de retour pour le callback.
Une idee?
Lephenixnoir En ligne Administrateur Points: 24145 Défis: 170 Message

Citer : Posté le 25/04/2019 18:51 | #


J'ai compris le bug du F5 en chassant quelques warnings, c'est parce que ca travaille avec un char signed et pas unsigned...

Depuis le temps que je milite pour qu'on utilise des uint8_t...

Pour ton problème avec SetQuitHandler(), tu n'as pas besoin de déclarer le syscall car fxlib contient déjà la fonction. Cela dit j'ai désassemblé le code et il n'y a rien à voir, ça copie juste l'adresse de ton handler dans la RAM à une subtilité près. Il semble y avoir deux pointeurs prévus pour le callback de fin, et il choisit l'un ou l'autre selon la valeur d'une variable de la RAM. Pas sûr que ça joue un rôle important...

En attendant si tu n'as pas déclaré de prototype pour SetQuitHandler() il se peut que GCC adopte une convention d'appel différente. (Mais c'est bien le prototype que tu connais à un argument, promis.)
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/04/2019 20:54 | #


Ce que j'ai pu constater c'est que le callback etait bien appele (creation des fichiers de sauvegarde), et ca plantait apres.
La declaration est faite dans syscalls.h par void SetQuitHandler( void (*callback)(void) );
Pour le moment, j'abandonne le handler au profit d'une sauvegarde manuelle, en tapant sur la touche -> (STO) puis EXE sur une ligne vide. Ca marche pour les variables, pas encore pour l'historique de calculs. Ce n'est peut-etre pas trop genant pour une session CAS. C'est evidemment different si on edite un script, on n'a pas envie de le perdre a la sortie pour cause d'oubli...

J'ai un autre probleme au lancement, si on efface FMENU.cfg en ayant une sauvegarde lastvar.py, ca plante apparamment au moment de la creation de FMENU.cfg (en utilisant le code de memory.h ou le mien, indifferemment), avec l'erreur
TLB ERROR, TARGET=08100C5C, PC=800853A6, pour le TARGET d'apres sh3eb-elf-nm ca correspond a la variable execution_in_progress qui sert a controler l'interruption utilisateur par un timer, pour le PC je n'ai rien qui correspond.
Il n'y a pas de problemes si les 2 fichiers existent ou si aucun des 2 n'existe.


Ajouté le 25/04/2019 à 20:58 :
Est-ce qu'il y a un numero de timer qu'on peut utiliser sans interaction avec l'OS? J'utilisais le 5.
Lephenixnoir En ligne Administrateur Points: 24145 Défis: 170 Message

Citer : Posté le 25/04/2019 21:21 | #


0x800853a6 est une adresse dans le système, il s'agit du gestionnaire d'interruptions des timers logiciels (ceux lancés par SetTimer()). L'instruction en faute est celle qui appelle le callback.

À mon avis, tu as quitté l'application sans arrêter un timer, et la variable qu'il utilisait (qui est dans la mémoire mappée) a disparu quand l'add-in a été quitté. Mais ton timer tournait encore et ton callback a du coup planté. Ta variable execution_in_progress tu la consultes bien avec un timer ?

Tous les timers lancés par SetTimer() le sont en interaction avec l'OS. Tu devrais utilisers les macros ID_USER_TIMERx pour éviter des problèmes.
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/04/2019 21:22 | #


Je vais essayer en testant tous les timers jusqu'a en trouver un inutilise.
Lephenixnoir En ligne Administrateur Points: 24145 Défis: 170 Message

Citer : Posté le 25/04/2019 21:22 | #


Parisse a écrit :
Je vais essayer en testant tous les timers jusqu'a en trouver un inutilise.

Mauvaise idée, si je peux me permettre.
Mon graphe (24 Mars): (gint#27 ; (Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; ...) || (shoutbox v5 ; v5)

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