addin en 2 parties
Posté le 19/12/2021 18:34
J'ai bien avance sur la creation d'un addin en 2 parties.
Voici un fichier testv.cc qui cree un vecteur (avec la uSTL) puis appelle une fonction declaree dans le fichier r8c2.h ci-dessous
#define std ustl
#include <vector>
void r8c2_print_vector(const std::vector<int> & v);
La fonction r8c2_print_vector affiche le vecteur, elle est implementee dans r82c.cc ci-dessous et sera ulterieurement stockee en RAM.
#include <fxcg/keyboard.h>
#include <fxcg/display.h>
#include <fxcg/file.h>
#include <fxcg/keyboard.h>
#include <fxcg/system.h>
#include <fxcg/misc.h>
#include <fxcg/app.h>
#include <fxcg/serial.h>
#include <string.h>
#include <stdio.h>
#include <stdlib.h>
#define std ustl
#include <vector>
#include <string>
using namespace ustl;
void r8c2_print_vector(const vector<int> & v){
for (int j=0;j<v.size();++j){
printf("%d\n",v[j]);
}
}
Et le fichier testv.cc avec le code de chargement de la fonction en ram et avec les commandes de compilation (a modifier selon installation)
// -*- compile-command: "sh3eb-elf-g++ -g -mb -m4a-nofpu -mhitachi -std=c++11 -fpermissive -fno-use-cxa-atexit -fno-strict-aliasing -fno-rtti -fno-exceptions -I. -I/home/parisse/casiolocal/include/ustl -c r8c2.cc -o r8c2.o && sh3eb-elf-g++ -g -mb -m4a-nofpu -mhitachi -std=c++11 -fpermissive -fno-use-cxa-atexit -fno-strict-aliasing -fno-rtti -fno-exceptions -I. -I/home/parisse/casiolocal/include/ustl -c testv.cc -o testv.o && sh3eb-elf-g++ testv.o r8c2.o -g -static -nostdlib -Taddinram.ld -Wl,--gc-sections,--print-memory-usage -L. -L/home/parisse/casiolocal/lib -Wl,--start-group -ltommath -lustl -lm -lc -lgcc -Wl,--end-group -o testv.elf && sh3eb-elf-objdump -C -t testv.elf | sort > dump && sh3eb-elf-objcopy -R .comment -R .bss -R .rominram -O binary testv.elf testv.bin && sh3eb-elf-objcopy -j .rominram -O binary testv.elf testv.8c2 && mkg3a -n basic:Testv -n internal:TESTV -V 0.0.0 testv.bin testv.g3a && /bin/cp testv.g3a testv.8c2 ~/.wine/drive_c" -*-
// debug with sh3eb-elf-gdb -i=mi -ex "target remote localhost:31188" testv.elf
#include <fxcg/keyboard.h>
#include <fxcg/display.h>
#include <fxcg/file.h>
#include <fxcg/keyboard.h>
#include <fxcg/system.h>
#include <fxcg/misc.h>
#include <fxcg/app.h>
#include <fxcg/serial.h>
#include <string.h>
#include <stdio.h>
#include <stdlib.h>
#define std ustl
#include <vector>
#include <string>
#include "r8c2.h"
using namespace ustl;
unsigned ram2Msize=0;
char ram_filename[]="\\\\fls0\\testv.8c2";
bool chk_ram2M(const char * filename,bool reload){
unsigned ram2Maddr=0x8c200000, ram2Mendaddr=ram2Maddr+ram2Msize;
unsigned * ram2M=(unsigned *) ram2Maddr,*ram2Mend=(unsigned *) ram2Mendaddr;
const unsigned chkinit=0x12345678;
unsigned chk=chkinit,*ptr;
const unsigned inc=1;
if (ram2Msize){
// if it's too slow, modify incr
for (ptr=ram2M;ptr<ram2Mend;ptr+=inc){
chk ^= (*ptr);
}
if (chk==*ptr)
return true; // proba to return true with corruption is tiny, about 1/4e9
if (!reload)
return false;
}
// load khicas overlay
int nchar=strlen(filename);
unsigned short pFile[nchar+1];
Bfile_StrToName_ncpy(pFile, (const unsigned char *)filename, strlen(filename)+1);
int hf = Bfile_OpenFile_OS(pFile, READWRITE); // Get handle
if (hf < 0)
return false; // nothing to load
int size=Bfile_GetFileSize_OS(hf);
if (size>2*1024*1024-4 || Bfile_ReadFile_OS(hf,ram2M,size,0)!=size){
Bfile_CloseFile_OS(hf);
return false;
}
ram2Msize=size;
ram2Mendaddr=ram2Maddr+ram2Msize;
ram2Mend=(unsigned *) ram2Mendaddr;
Bfile_CloseFile_OS(hf);
// compute chksum
chk=chkinit;
for (ptr=ram2M;ptr<ram2Mend;ptr+=inc){
chk ^= (*ptr);
}
*ptr=chk; // save chksum
return true;
}
int main(){
if (!chk_ram2M(ram_filename,true)){
printf("%s%s\n","Unable to load ",ram_filename);
int key;
for(;;)
GetKey(&key);
return 0;
}
if (!chk_ram2M(ram_filename,false)){
printf("%s\n"," ",ram_filename);
int key;
for(;;)
GetKey(&key);
return 0;
}
int i=4321;
string s("Coucou");
//int * jptr=new int;
char * buf=(char *)malloc(256);
char * buf2=new char[256];
printf("Hello\n");
// printf("malloc %d\n new %d\nstack %d",unsigned(buf)-0x88100000,unsigned(buf2)-0x8100000,unsigned(&buf)-0x88100000);
strcpy(buf,"!!Hello abcdefghijklmnopqrstuvwxyz 123456789");
strcpy(buf2,"!!Hello2 abcdefghijklmnopqrstuvwxyz 123456789");
printf("%s\n",buf);
printf("%s\n",buf2);
// char buf[]="!!Hello abcdefghijklmnopqrstuvwxyz 123456789";
if (1){
std::vector<int> v(3);
for (int j=0;j<v.size();++j){
v[j]=j*j;
}
r8c2_print_vector(v);
i=unsigned (&v[2])-0x08100000;
// v.clear();
}
int key;
for(;;)
GetKey(&key);
return 0;
}
Voici le fichier loader addinram.ld pour stocker en RAM le contenu du fichier objet r8c2.o, en creant un fichier elf qu'on divisera ensuite en 2 fichiers, le fichier d'addin g3a et un fichier d'extension 8c2 qui sera charge par l'addin.
OUTPUT_FORMAT(elf32-sh)
OUTPUT_ARCH(sh3)
ENTRY(initialize)
MEMORY
{
rom : o = 0x00300000, l = 2M
ram : o = 0x08100000, l = 64k /* pretty safe guess */
r8c2 (rx) : o = 0x8c200000, l = 3M-4
}
SECTIONS
{
/* 2nd part of code at 0x8c20000 */
.rominram : {
r8c2.o(.text)
r8c2.o (.text.*)
r8c2.o (.rodata)
r8c2.o (.rodata.*)
} > r8c2
/* Code, in ROM */
.text : {
*(.pretext) /* init stuff */
*(.text)
*(.text.*)
} > rom
/* Read-only data, in ROM */
.rodata : {
*(.rodata)
*(.rodata.*)
} > rom
/* RW initialized data, VMA in RAM but LMA in ROM */
.data : ALIGN(4) {
_datald = LOADADDR(.data) ;
_sdata = . ;
*(.data)
*(.data.*);
_edata = . ;
} >ram AT>rom
/* Uninitialized data (fill with 0), in RAM */
.bss ALIGN(4) : ALIGN(4) {
_bbss = . ;
*(.bss)
*(.bss*)
*(COMMON)
_ebss = . ;
/* Extra unused static space */
_sextra = ALIGN(32);
_eextra = ORIGIN(ram) + LENGTH(ram);
} >ram
}
J'ai fait ce petit test en preparation d'une mise a jour majeure de KhiCAS qui pourrait utiliser beaucoup plus d'espace, pour recueillir l'avis des experts sur le meilleur modele a choisir (ceux qui ont lu jusqu'ici sont probablement des experts...).
Mais d'abord j'ai un gros probleme avec l'emulateur, impossible d'ecrire dans la zone memoire 0x8c20000, est-ce qu'il y a une autre adresse a tester? Ou peut-etre que la zone de RAM n'est pas supportee par l'emulateur, ce qui me compliquerait le travail de mise au point, mais pas que, ca rendrait impossible l'execution a l'emulateur pour une demo dans un but pedagogique,
Ensuite, mon idee serait d'avoir le moteur de calcul de giac en RAM jusqu'a une taille de 3M (ca gagne 1M par rapport aux 2M actuels) et de garder toute l'UI (ainsi bien sur que le chargeur en RAM) dans la partie addin en ROM. On peut meme envisager a moyen terme de rajouter mon implementation de MicroPython avec ma collection de modules pour avoir la meme chose que sur Numworks/Nspire.
J'en profite pour signaler que j'ai mis a jour la section developpement de la doc de KhiCAS avec une description assez detaillee je pense de
comment utiliser le debugger mis au point par redoste, (cf.
ce fil)
Citer : Posté le 21/12/2021 10:24 | #
On est d'accord que pour la corruption mémoire on n'a pas encore d'explication solide right? J'ai testé encore de mon côté, la mémoire on-chip (XRAM/YRAM/ILRAM) n'est pas toujours préservée durant une extinction (même dans le menu principal), la RAM utilisateur si. J'aimerais bien creuser encore...
Citer : Posté le 21/12/2021 13:14 | #
Je n'ai aucune explication, faute de comprendre comment le processus qui affiche le main menu et gere getkey et off/on fonctionne. Je n'arrive pas a faire fonctionner la simulation d'appui sur MENU correctement, quand ca le declenche une fois, ca le declenche ensuite a nouveau, comme si le timeout n'etait pas remis a zero par la fonction de lecture clavier. Donc, en cas de timeout, je vais afficher un message pour lancer une autre application avant de relancer khicas, eteindre et bloquer l'addin.
Il n'y aurait pas par hasard un syscall qui met fin a un addin comme si on avait tape la touche MENU puis lance une autre appli?
Citer : Posté le 21/12/2021 13:27 | #
Attends une seconde, ça je connais il me semble. Comment est-ce que tu as programmé la chose ? Je suis pas sûr de comprendre de quel timeout tu parles. Ça devrait marcher en tous cas, ce n'est pas une astuce très courante mais elle est supposée fonctionner (et pas que dans gint où comme je change de driver clavier en plein milieu c'est un peu plus subtil).
Il y a des syscalls pour lancer directement des applis (mais sans revenir au menu principal) ; si tu veux quitter l'add-in définitivement et revenir au menu principal il suffit de exit() ou de sortir de retourner du main() ; sinon si tu veux retourner au menu principal de façon temporaire et sans utiliser GetKey() alors c'es le trick ci-dessus. Je ne connais pas d'autre astuce. (Je soupçonne que le syscall SpecialMatrixCodeProcessing() puisse le faire directement mais quand je teste dans gint ça crashe.)
Citer : Posté le 21/12/2021 13:32 | #
Si je fais exit ou return 0; et que je relance ensuite KhiCAS depuis le menu, est-ce que ca relance completement l'addin?
Le code:
static volatile int menutimer=0;
void clear_menu_timer(){
if (menutimer > 0) {
menutimer=0;
// menu row 9 col 4
Timer_Stop(menutimer);
Timer_Deinstall(menutimer);
}
}
void send_menu_key(){
if (menutimer > 0) {
clear_menu_timer();
OS_InnerWait_ms(50);
// menu row 9 col 4
// Keyboard_PutKeycode(4,9,KEY_CTRL_MENU);
Keyboard_PutKeycode(4,9,0);
}
}
void set_menu_timer(){
if (!menutimer) return;
menutimer = Timer_Install(0,send_menu_key, 200);
if (menutimer > 0) {
Timer_Start(menutimer);
}
}
int ck_getkey(int * keyptr){
int col, row;
unsigned short keycode=0;
shiftstate=false;alphastate=false;alphalock=false;alphamaj=true;
int keyflag=GetSetupSetting( (unsigned int)0x14);
// Keyboard input mode. 0 for standard, 0x01 for Shift, 0x04 for Alpha, 0x08 for lower-case Alpha, 0x84 for Alpha-lock, 0x88 for lower-case Alpha-Lock.
if ( (keyflag&4) | (keyflag &8))
alphastate=true;
if (keyflag&0x80)
alphalock=true;
if (keyflag==0x88)
alphamaj=false;
if (keyflag & 1)
shiftstate=true;
while (1){
casiostatus();
DisplayStatusArea();
Bdisp_PutDisp_DD ();
SetSetupSetting(0x14,0); // disable OFF
int ret=GetKeyWait_OS(&col,&row, 2 /* KEYWAIT_HALTON_TIMERON*/, 300 /*timeout_period*/, 0 /* handle menu key*/, &keycode) ;
if (ret==2 /* timeout */ ){
//printf("timeout shutdown \n");
#if 1
if (lang)
print_msg12("Pour relancer KhiCAS, tapez les touches","MENU tan MENU");
else
print_msg12("To restart KhiCAS, type keys","MENU tan MENU");
Bdisp_PutDisp_DD ();
PowerOff(1);
for (;;){
GetKey(keyptr);
}
#endif
print_msg12("Auto shutdown","MENU");
Bdisp_PutDisp_DD ();
set_menu_timer();
GetKey(keyptr);
*keyptr=KEY_SHUTDOWN;
return 1;
// continue;
}
...
Ajouté le 21/12/2021 à 13:36 :
Je viens de tester avec exit(0) mais ca fait crasher la calculatrice.
Citer : Posté le 21/12/2021 13:51 | #
L'application ne peut pas être relancée directement si tu quittes comme ça (soit il ne se passe rien soit tu vois le dernier écran une fraction de seconde et tu restes sur le menu, je t'invite à tester pour voir).
Il y a un flag caché plus ou moins connu sur mono (vois la description de 0x049A), mais c'est pas déployable comme ça sur Graph 90+E.
C'est chiant oui, mais c'est des questions avec lesquelles personne ne s'embête normalement. Cela dit c'est pas rare que des add-ins retournent de cette façon, les utilisateurs ont plutôt l'habitude. Ça gênerait moins qu'une corruption si c'est ça le compromis à faire...
Il doit bien y avoir un truc cassé/anormal dans l'add-in... tu as un SetQuitHandler() quelque part ? Ton exit() c'est le syscall ou la version fournie par la libc du PrizmSDK (laquelle fait pas mal de choses compliquées dont GetKey()) ?
// menu row 9 col 4
Timer_Stop(menutimer);
Timer_Deinstall(menutimer);
Les appels sont clairement faux ici, tu détruis ton identifiant de timer alors qu'il te reste des appels à l'API à faire !
Le OS_InnerWait_ms() ne devrait pas exister puisque le délai est déjà géré par le timer. Attendre dans un timer handler est une mauvaise idée de façon générale. La façon dont tu gères ta variable menutimer a aussi des problèmes ; par exemple ici :
if (!menutimer) return;
Tu ne démarres pas de timer tant que menutimer vaut 0, mais menutimer est initialisé à 0 et aucune autre fonction ne lui donne une valeur non-nulle. Tu vas juste rester en permanence à 0 et ne jamais utiliser de timer.
Citer : Posté le 21/12/2021 13:56 | #
C'est juste, j'avais rajoute des trucs faux parce que ca ne marchait pas comme prevu. Ca devrait plutot etre
static volatile int menutimer=0;
void clear_menu_timer(){
if (menutimer > 0) {
// menu row 9 col 4
Timer_Stop(menutimer);
Timer_Deinstall(menutimer);
menutimer=0;
}
}
void send_menu_key(){
if (menutimer > 0) {
clear_menu_timer();
OS_InnerWait_ms(50);
// menu row 9 col 4
// Keyboard_PutKeycode(4,9,KEY_CTRL_MENU);
Keyboard_PutKeycode(4,9,0);
}
}
void set_menu_timer(){
if (menutimer) return;
menutimer = Timer_Install(0,send_menu_key, 200);
if (menutimer > 0) {
Timer_Start(menutimer);
}
}
Ajouté le 21/12/2021 à 14:01 :
j'ai rajoute un petit delai pour etre sur que le timer n'est pas declenche avant que GetKey ne soit pas appele. Il est inutile si on est sur que le timer n'est pas declenche des qu'il est installe.
Et effectivement, mon addin a un handler qui gere la sortie. Il faudrait l'enlever avant?
Citer : Posté le 21/12/2021 14:03 | #
Le timer ne risque pas de se déclencher avant GetKey(), tu as quand même laissé 200 ms ! C'est super large. GetKey() aura été appelé depuis longtemps à ce stade.
Au passage tu as vu le ClearKeyBuffer() dans le code de gint ? Je suis prêt à parier que c'est ça pour éviter le double-retour au menu. Si tu veux bien je t'invite à essayer ça, si ça marche pas je teste de mon côté.
Essaie d'enlever ton SetQuitHandler() uniquement pour le test exit(), ça pourrait jouer avec le crash.
Citer : Posté le 21/12/2021 14:07 | #
Bon, avec le timer, ca crashe, ca m'enerve de passer tout ce temps sur des stupidites.
Je reste donc avec un timeout, probablement regle sur 5 minutes, qui necessitera de changer un autre addin pour pouvoir relancer KhiCAS (avec un message demandant de taper MENU tan MENU pour relancer l'addin). C'est pas parfait, mais si ca evite la corruption memoire (il faut que je verifie en faisant beaucoup de tests), ca sera deja bien.
Ajouté le 21/12/2021 à 14:10 :
Comment on fait pour enlever le handler?
Citer : Posté le 21/12/2021 14:12 | # |
Fichier joint
Le code de ce message marche tout seul dans mon add-in de test. Je te joins le code source et le g3a ; le test mémoire est là pour décorer, mais si tu appuies sur 7 tu te fais renvoyer au menu et tu peux revenir.
Comme d'habitude, c'est quasiment impossible de faire des choses précises sans pouvoir tester, surtout avec un add-in aussi gros que KhiCAS... sans vouloir juger, le fait que tu sois le seul à pouvoir créer des builds ça ne nous aide vraiment pas.
Ajouté le 21/12/2021 à 14:12 :
S'il est installé avec SetQuitHandler() tu peux faire SetQuitHandler(NULL). Mais regarde d'abord quel exit() tu utilises...
Citer : Posté le 21/12/2021 14:22 | #
En effet le exit est celui de la libc qui crashe. Il faut mettre quoi a la place de
void exit(int status) {
fprintf(stderr, "TERMINATED (%i)", status);
// We don't have a clean way to exit (right now), so just crash it.
((void (*)())1)(); // Unaligned instruction
}
Sinon, tu devrais pouvoir faire des builds de KhiCAS, il suffit d'installer ma toolchain, comme explique ici https://www-fourier.univ-grenoble-alpes.fr/~parisse/casio/khicasio.html#sec30
J'aimerais bien utiliser quelque chose de plus standard, mais ma tentative recente d'utiliser un gcc plus recent par exemple, s'est soldee par un echec, et je n'ai pas envie de passer encore plus de temps sur les outils.
Ajouté le 21/12/2021 à 14:30 :
Je n'ai sans doute pas besoin du exit(), j'ai mis ca pour le moment
if (lang)
print_msg12("Pour relancer KhiCAS, tapez les touches","MENU tan MENU");
else
print_msg12("To restart KhiCAS, type keys","MENU tan MENU");
Bdisp_PutDisp_DD ();
set_menu_timer();
GetKey(keyptr);
// save_session();
// SetQuitHandler(0);
// PowerOff(1);
for (;;){
GetKey(keyptr);
}
Ajouté le 21/12/2021 à 14:36 :
Nouvel essai, avec juste
if (ret==2 /* timeout */ ){
//printf("timeout shutdown \n");
#if 1
set_menu_timer();
GetKey(keyptr);
*keyptr=KEY_SHUTDOWN;
return 1;
#endif
ca n'a plus l'air de crasher et la plus besoin de relancer l'addin. Reste a tester ...
Merci pour ta patience!!!
Citer : Posté le 21/12/2021 14:50 | #
Bon, si on a un juste milieu c'est pas mal... ça me frustre juste pas mal que tu te retrouves avec des problèmes ridicules comme ça.
Je me compile la toolchain à côté ça pourrait m'être utile plus tard.
Ajouté le 21/12/2021 à 15:34 :
Où est-ce que tu prends ta libc ? J'en ai une du PrizmSDK mais je veux être sûr d'avoir absolument la même que toi, ce serait pas le moment d'introduire des divergences à la con...
Citer : Posté le 21/12/2021 15:53 | #
La libc est incluse dans l'archive libfxcg90.tgz. C'etait le cas quand j'ai telecharge libfxcg, ensuite j'ai du faire des modifs dedans (par exemple printf ne supportait pas les doubles, j'ai ecrit vite fait un workaround qui n'est pas du tout elegant)
Citer : Posté le 21/12/2021 15:55 | #
Mais oui je suis bête, désolé. C'est une histoire d'install en fait, je vois qu'il y a quelques chemins d'install/include hardcodés ("casiolocal"). Heureusement ça devrait être facile à grep/remplacer, merci.
Citer : Posté le 22/12/2021 12:37 | #
J'ai une bonne nouvelle pour nous deux: kmalloc ne pose plus de problemes des l'instant ou OFF/ON est lance depuis le main menu. Du coup je vais pouvoir l'utiliser dans KhiCAS.
Citer : Posté le 22/12/2021 13:17 | #
C'est pas mal ça déjà. Ça paraît naturel que le problème de corruption soit à l'origine de divers effets secondaires avec kmalloc() et ton allocateur. En tous cas si tu trouves d'autres problèmes avec kmalloc() n'hésite pas à les rapporter aussi, on n'est jamais à l'abri d'un vrai bug.