Idée de projet - add-in pour debug
Posté le 28/05/2018 20:01
salut;
Je sais pas si vous programmez sur Casio mais si c’est le cas vous devez savoir à quel point programmer dessus c’est pratique: on programme un jeu, on le compile, on vérifie sur l’Émulateur si tout fonctionne, si tout fonctionne on le transfère sur la calto puis on peut transporter son jeu de partout.
Problématique
Si vous programmez un gros jeu il est possible que des petits bugs apparaissent APRÈS avoir compilé qui font planter la Casio.
Et pourtant le jeu fonctionnait sur l’Émulateur sauf que l’Émulateur ne sera jamais comme la console.
Et c’est là que ça devient méga chiant parce que, modifier un octet, compiler, connecter la calto et voir que ça ne fonctionne pas...on vient de perdre 5 minutes de notre vie à brasser de l’aire.
De plus si vos faites des jeux en multijoueur on ne peut pas vérifier via l’Émulateur, il faut donc tout se taper et c’est...long, trop long.
Idée
C’est pourquoi une idée m’est venue alors que j’écrivais la librairie “mySerail.h”.
Pourquoi ne pas créer un add-in qui récupère les données via le port USB puis exécute le jeu à la fin du transfère ?
Pour résumer éviter d’aller dans “LINK”, et attendre que la calto se connecte à l’ordi, attendre que l’add-in soit transféré.
En gros avoir un add-in de debug qui nous permet de ne pas avoir à toucher à la console pour tester ses programmes.
Théorie
Pour ça il nous faut une connexion directe entre la Casio et le PC...bon ya un port USB donc c’est rapide.
L’add-in se met directement en ‘Receive’ (elle attend un fichier).
Ensuite on vérifie s'il y a assez de place dans la RAM.
Si ya assez de place, on met tout le programme dans la RAM, puis on l’exécute.
(c’est tellement simple à dire^^)
Pourquoi la RAM ?
C’est un add-in de debug je vous rappelle donc on s’en fout que le programme soit stocké dans la ROM.
De plus la RAM est rapide à écrire, bien plus rapide que le ROM.
Possible ?
Oui MAIS seulement des petits programmes car la ‘vrai’ RAM disponible sur SH4 est de 12 ko (d’après
la doc de
Lephenixoir) OU 64 ko (d’après le
wiki).
Donc bon...
Oublions 2 secondes la taille de la RAM et le fait qu’il y en est pas autant sur les SH3 que sur le SH4.
1.On sait communiquer via le port USB (exemple :
P7 de
Cakeisalie5), du moins on sait communiquer PC->Casio par contre il me semble pas avoir entendu parler de syscall permettant de jouer avec le port USB (j’ai chercher mais je n'ai rien comprit
).
2.On sait exécuter du code Assembleur depuis la RAM (#sysCall) (
gint fait ça merveilleusement bien aussi <3).
3.On sait faire des interfaces par dégueux.
Donc oui c’est possible !
Es-ce que j’ai commencer a faire un truc ?
Non, déjà parce que j'ai pas beaucoup de temps en ce moment et j’ai déjà plusieurs projets à finir.
C’est juste pour signaler que c’est théoriquement possible donc s'il y a des personnes intéressées par ce projet...bah allez-y ça pourrait être sympa et il y a sûrement beaucoup de choses à apprendre
.
Citer : Posté le 28/05/2018 20:36 | #
Ton analyse de la taille de la RAM est juste : mais les chiffres sont malencontreux. Il y exactement 8k de RAM statique sur SH3, c'est ça que tu devrais compter. La zone dans laquelle gint s'installe est une zone de non-droit que l'on occupe sans demander son avis au système. Ça marche, mais il n'y a pas de raison. Ne l'utilisez pas !
Il y donc, je disais, 8k de RAM statique sur SH3, et, depuis récemment (car personne n'avait étudié le TLB avant il me semble) que je m'en suis rendu compte, 64k de RAM statique sur SH4.
Tu commets quelques autres petites erreurs : on ne peut pas facilement invoquer l'OS depuis l'add-in et être sûr de récupérer la main ensuite ; on ne peut pas exécuter de code depuis la RAM statique, c'est bien pour ça que gint s'installe dans une zone à part ; et surtout, surtout, surtout, exécuter un add-in c'est plus compliqué que le copier dans la RAM et sauter au bon endroit.
Oublions ces menus détails. Ta théorie est juste : on peut faire tout ça en mettant suffisamment les mains dedans. Moi je fais déjà assez de gint pour oser me lancer (désolé) ; le principal souci est que peu de gens ont les connaissances bas niveau nécessaires pour faire ça. Si ça te tente d'en faire un peu, même juste le début, je pourrai te filer les infos nécessaires pour attaquer le problème.
En fait, on peut faire mieux que ça. Tu sais comment marche un debugger ? Breakpoints tout ça. Je ne sais pas ce qu'il en est sur SH4, mais le SH3 possède un UBC (User Break Controller) comme module périphérique, qui permet de faire plusieurs choses du genre. Kristaba, un illustre et éminent membre d'il y a déjà quelques bonnes années, avait conçu un programme capable de s'auto-debugger en utilisant l'UBC. Mes premiers travaux sur gint sont partis de son code, et c'est d'ailleurs là que j'ai appris à écrire un linker script.
Tout ça pour te dire que dans le monde merveilleux du debug, on peut faire vraiment pas mal de choses. Faudrait quand même voir à bien définir ce que ton programme permet ou ne permet pas facilement de debugger pour calculer l'utilité pratique de la chose !
Citer : Posté le 29/05/2018 09:25 | #
Il y donc, je disais, 8k de RAM statique sur SH3, et, depuis récemment (car personne n'avait étudié le TLB avant il me semble) que je m'en suis rendu compte, 64k de RAM statique sur SH4.
Il me semblait bien que les SH3 avaient peu de RAM static.
Par contre je savais pas que les SH4 en avaient autant x)
Ton analyse de la taille de la RAM est juste : mais les chiffres sont malencontreux. Il y exactement 8k de RAM statique sur SH3, c'est ça que tu devrais compter
[...]
on ne peut pas exécuter de code depuis la RAM statique
Pourquoi on ne peut pas exécuter du code depuis la RAM static alors que Pierrotll déclare son SysCallCode en static ?
(J'ai lu des docs sur la RAM static, mais a part me dire que c'est plus rapide que la RAM rien de bien intéressant :/ )
on ne peut pas facilement invoquer l'OS depuis l'add-in et être sûr de récupérer la main ensuite
[...]
et surtout, surtout, surtout, exécuter un add-in c'est plus compliqué que le copier dans la RAM et sauter au bon endroit.
Je sais bien, c'est juste que j'avais aucune solution "théorique" à donner donc je me suis contenté d'être naïf
Si ça te tente d'en faire un peu, même juste le début, je pourrai te filer les infos nécessaires pour attaquer le problème.
haaaaaa mais ça l'air trop intéressant ... je finis 15 secondes ninja et roulette Knight puis je commencerais sans doute
En fait, on peut faire mieux que ça. Tu sais comment marche un debugger ? Breakpoints tout ça. Je ne sais pas ce qu'il en est sur SH4, mais le SH3 possède un UBC (User Break Controller) comme module périphérique, qui permet de faire plusieurs choses du genre.
Kristaba, un illustre et éminent membre d'il y a déjà quelques bonnes années, avait conçu un programme capable de s'auto-debugger en utilisant l'UBC. Mes premiers travaux sur gint sont partis de son code, et c'est d'ailleurs là que j'ai appris à écrire un linker script.
J'ai sait au moins ou commencer...
Le truc c'est qu'il me manque cruellement de connaissance sur les composants, les thermes techniques et surtout l'assembleur (parce que à part déassembler quelque fonction...et pas comprendre grand-chose, je ne suis pas allé plus loin
De plus je pensais me mettre à fond dans l'assembleur seulement je reprends le 30 juillet
Citer : Posté le 29/05/2018 09:35 | #
Ne confonds pas RAM statique et static. Le terme de RAM statique est un terme informel qu'on utilise parce que la zone de RAM concernée est toujours allouée de la même manière. C'est par opposition à une mémoire « dynamique », en un mot : le tas (malloc(), free(), tout ça). Dans la RAM statique, on trouve grosso modo toutes les variables du programme qui sont accessibles en lecture-écriture. Cela peut inclure ou ne pas inclure des variables déclarées static.
Quel est, maintenant, le rôle de static ? Selon le contexte, ce mot-clé change de sens :
- À l'intérieur d'une fonction, il signifie que la variable déclarée doit survivre à la fonction (sa valeur doit rester la même jusqu'au prochain appel). Il est donc impossible d'allouer la variable sur la pile, et elle part dans la section de données. Si elle est accessible en écriture (et en pratique elle l'est toujours car le cas contraire ne présente aucun intérêt), elle va dans la RAM statique.
- Dans le scope principal du fichier, appliqué à une fonction ou une variable, static signifie juste que la fonction ou la variable déclarée ne sera pas visible par les autres fichiers, sans changer la méthode d'allocation. Ainsi donc, les fonctions static vont toujours dans le segment de code (ROM), les variables en lecture-écriture vont toujours dans la RAM statique, et les variables en lecture seule vont... où, d'ailleurs ?
C'est là que tout se joue : le syscall déclaré par PLL est const static donc il est en lecture seule. Le compilateur n'a pas d'intérêt particulier à lui réserver de la RAM puisqu'on ne va jamais aller changer se valeur : il décide donc de la placer dans un segment qui va en ROM : ce code ne va pas dans la RAM statique. Le segment assigné est celui des données en lecture seule, même si l'idéal aurait été le segment de code : après tout, c'est bien du code qu'il y a dans ce tableau.
Deux derniers points :
- Sous GCC on peut faire beaucoup plus joli que ça.
- Si les variables en lecture-écriture vont dans ces 8k de mémoire-là, c'est parce que le linker script dit à ld de faire comme ça. On pourrait les mettre dans la RAM spéciale utilisée par gint si on en avait envie. Comprends : ce n'est pas parce que c'est la RAM statique que les variables vont là ; c'est parce que les variables vont là qu'on l'appelle RAM statique.
J'en dis pas plus sur le reste de ton message, poppe un coup si tu as un moment, je te fournirai de quoi démarrer !
Ajouté le 29/05/2018 à 20:12 :
Side idea, ou peut-être pas : tu aurais pu parler de simuler le client et le serveur en même temps avec ta lib'. Pour tester le multijoueur sur émulateur, par exemple.
(Ou, de façon plus accessible : communiquer entre la vraie calto et un émulateur sur l'ordinateur.)
Citer : Posté le 29/05/2018 22:36 | #
Merci beaucoup pour ton explication
Donc si j'ai bien pigé, (désoler si ce n'est pas le cas) tous les bouts de code ainsi que les variables qui sont en lecture seule vont se mettre dans le ROM ? (ou dans un segment qui lui va en ROM et dans ce cas-là je n'ai pas pigé la nuance :/ )
Du coup faudrait "trier" tout le code au moment de l'envoi du PC à la Casio ? wooooaaaa... comment ça part mal x)
Sous GCC on peut faire beaucoup plus joli que ça.
GCC...en C++, ça tombe bien je sais pas programmer en C++ x) (Ça s'apprend mais l'assembleur reste le langage que je veux apprendre à tout prix)
Si les variables en lecture-écriture vont dans ces 8k de mémoire-là, c'est parce que le linker script dit à ld de faire comme ça. On pourrait les mettre dans la RAM spéciale utilisée par gint si on en avait envie. Comprends : ce n'est pas parce que c'est la RAM statique que les variables vont là ; c'est parce que les variables vont là qu'on l'appelle RAM statique.
Hooooooooooo
J'ai aucune connaissance en linker script (il me manque tellement de connaissances de partout).
Donc question de débutant: c'est de l'assembleur .
Je me suis rapidement renseigné sur le site le plus fiable d'Europe... Ca permet donc de reprogrammer le GPU ? (je dit surement une bêtise).
L'endroit ou gint est placé est grand en taille ? (je suppose que non, il me semble que tu avais eu des problèmes de place à un moment au cours du développement)
Side idea, ou peut-être pas : tu aurais pu parler de simuler le client et le serveur en même temps avec ta lib'. Pour tester le multijoueur sur émulateur, par exemple.
Possible après est-ce que les fonctions utilisées dans le programme (Serial_Open(), Serial_WriteByte(), etc.) fonctionne pour le port USB ?
Si ce n'est pas le cas, on peut toujours s'inspirer des travaux de Dark storm sur sont Serial DLFiles et faire: Transfère PC -> ATMEGA328 -> port 3-PIN mais du coup ça risque d'être super lent et pas stable du tout (déjà que le multi ce n'est pas stable :/ ).
déjà ce qui est rassurant c'est qu'on sait qu'il est possible de communiquer Casio -> PC via USB donc ce n'est pas impossible.
Citer : Posté le 29/05/2018 23:02 | #
Concernant la stabilité du multi, je pense qu'il faut revoir ton protocole pour le rendre plus résilient. Un truc à base de paquets et de checksums renvoyés peut être intéressant. Par exemple C envoie à H un paquet, H valide en renvoyant le checksum. Ensuite faut trouver comment gérer la file des paquets, mais déjà ça peut aider à gagner en stabilité
Citer : Posté le 30/05/2018 09:51 | #
On a envie de les y mettre, oui. Le compilateur les met automatiquement dans une section dont le nom ressemble à .rodata (read-only data) et ensuite le linker script (nous) décide de mettre cette section dans la ROM.
Aha, nooon ! xD
Pause. Il n'y a du code et des données que pendant que l'add-in s'exécute. Quand la calculatrice est éteinte tout est dans la ROM dans les fichiers g1a. Point.
Ensuite quand on démarre l'add-in, le système nous donne accès aux contenus du fichier g1a à l'adresse 0x0300000. Et c'est là que crt0.s entre en scène pour nettoyer la RAM, initialiser les variables globales, bref copier dans la RAM tout ce qui a besoin de l'être.
Et une fois que l'add-in se termine la RAM est utilisée par quelqu'un d'autre. Jamais, jamais, jamais on n'envoie de trucs dans la RAM pendant le transfert. Sache de plus que cette histoire d'assigner des sections en RAM ou en ROM et de les charger comme il faut c'est quelque chose qu'on sait déjà faire, et que je twiste tous les jours un peu plus avec gint. Ce n'est pas un problème du tout.
Non, en C. On n'est pas encore prêts pour le C++.
Hein ? Le GPU ? Rien à avoir avec le GPU.
Le linker script c'est le script qui contrôle le l'éditeur de liens, ld. Il lui dit comment la mémoire de la calculatrice est agencée, quelles sections sont présentes dans les fichiers objets en entrée, comment répartir ces sections dans les zones mémoire, comment leur attribuer des adresses, et au passage il définit quelques variables utiles pour que crt0.s (ou son équivalent de gint) puisse faire son job.
L'endroit où gint se place étant une occupation illégale, j'ai tendance à dire que sa taille est 0. Ou alors, la taille de gint - 1 octet (pour me forcer à en réduire la taille). Actuellement j'utilise 12k qui sont à la fin d'une zone de 32k utilisée par Kristaba, mais dont le début coïncide avec des données du système sur SH4. C'est vraiment n'importe quoi la façon dont on s'installe ici.
Non, il faut utiliser les syscalls Comm_*() pour ça. Mais ta lib peut cacher les deux derrière une même fonction et :
- pendant le debuggage, utiliser Comm_*()
- une fois compilé pour de bon, utiliser Serial_*()
+1
Citer : Posté le 30/05/2018 12:40 | #
On a envie de les y mettre, oui. Le compilateur les met automatiquement dans une section dont le nom ressemble à .rodata (read-only data) et ensuite le linker script (nous) décide de mettre cette section dans la ROM.
[...]
Haaaaa... du coup le linker script sert juste a dire quoi vas ou ? c'est un "chef d’orchestre" ?
Mais du coup c'est over puissant le truc
Il n'y a du code et des données que pendant que l'add-in s'exécute. Quand la calculatrice est éteinte tout est dans la ROM dans les fichiers g1a.
Je pense bien, ça m'aurais choqué si le contenu la RAM reste même quand la calto est éteinte x)
Ensuite quand on démarre l'add-in, le système nous donne accès aux contenus du fichier g1a à l'adresse 0x0300000. Et c'est là que crt0.s entre en scène pour nettoyer la RAM, initialiser les variables globales, bref copier dans la RAM tout ce qui a besoin de l'être.
Mmmmm... du coup ça va poser problème vu qu'on va passer par un add-in pour débuger... À moins de faire un truc suffisamment optimiser pour aller ce placer-là où va gint et ne rien utiliser du 0x03000000 (du moins juste écrire qu'une fois l'add-in (qu'ont veut débugué) est fini c'est l'add in de debug qui reprend la main)
Faut vraiment que je me renseigne... j'ai tellement envie de commencer le truc, mais je n'ai tellement pas le temps c'est incroyable
Le linker script c'est le script qui contrôle le l'éditeur de liens, ld. Il lui dit comment la mémoire de la calculatrice est agencée, quelles sections sont présentes dans les fichiers objets en entrée, comment répartir ces sections dans les zones mémoire, comment leur attribuer des adresses, et au passage il définit quelques variables utiles pour que crt0.s (ou son équivalent de gint) puisse faire son job.
Donc théoriquement je n'aurais pas à toucher au crt0.s (?) "juste" à écrire deux linker script .
Un pour "placer" l'add-in de débug et un autre pour "placer" l'add-in de test .
Je vais surement faire une supposition fausse et débile mais: le linker script se trouve dans le g1a au tout début du fichier ? du coup, il "suffit" que je choppe le linker script, que je le remplace (juste le moment on il explique ou se met l'add-in) puis c'est bon . (J'aurai fait une grosse partie du moins).
Un autre truc qui me pose soucis c'est qu'il faudrait trouver un endroit ou stocker temporairement l'add-in (envoyer du PC) pour ensuite réécrire le linker puis déplacer tout le programme là où il faut.
(je pense vraiment avoir mal compris le rôle du linker et du crt0.s désoler
Non, il faut utiliser les syscalls Comm_*() pour ça. Mais ta lib peut cacher les deux derrière une même fonction et :
- pendant le debuggage, utiliser Comm_*()
- une fois compilé pour de bon, utiliser Serial_*()
Pas faux du tout
Concernant la stabilité du multi, je pense qu'il faut revoir ton protocole pour le rendre plus résilient. Un truc à base de paquets et de checksums renvoyés peut être intéressant. Par exemple C envoie à H un paquet, H valide en renvoyant le checksum. Ensuite faut trouver comment gérer la file des paquets, mais déjà ça peut aider à gagner en stabilité
Le problème ne vient pas du transfère de données qui est super-fiable (je n'ai vraiment jamais eu de problème à ce niveau-là j'ai toujours eu les bonnes valeurs a chaque fois).
Le problème vient du code.
En gros pour la récupération des données je fais une boucle qui glande jusqu'à qu'il y ait une donnée qui arrive dans le buffer de réception, le problème c'est que si le câble n'est pas branché ou l'autre calot n'envoie pas la donnée qu'il attend bah elle va se bloquer à l'infini. (il faut juste que j'update les fonctions avec la détection du câble (c'est possible) une fonction d'essai de resynchroniser les caltos, sinon on exit de l'add-in).
Citer : Posté le 30/05/2018 18:47 | #
Oui, le linker script c'est le chef d'orchestre du processus de la compilation. ld est très puissant...
Eh oui, d'où la haute voltige quand je parle de charger un add-in avec un add-in : si tu le faisais naïvement, l'add-in chargeur s'écraserait lui-même pendant qu'il chargerait l'autre !
Bonne intuition cependant, la façon de faire pour ce genre de double chargement c'est de se placer en RAM. Mais ce n'est pas l'objectif de ton add-in de debug, n'est-ce-pas ? Ou est-ce une bibliothèque ? Et qu'est-ce que ça permet de faire, au juste ?
Tu peux faire ça oui. Le truc c'est qu'à la fin de la fin le système saute à 0x00300200 pour démarrer l'exécution de ton add-in. Donc tu peux pas le faire charger dans la RAM : c'est à lui de se déplacer dans la RAM une fois qu'il a été chargé par le système.
Tu te trompes sur le linker script : le seul à le lire c'est le linker à la fin de la compilation. Le linker produit un fichier ELF qui contient des sections auxquelles des adresses ont été une fois pour toutes assignées. Ensuite crt0.s ne fait que lire les adresses laissées par le linker dans le fichier pour charger l'add-in. Et comme avant de passer en g1a on supprimer toutes les propriétés ELF pour ne garder que le binaire brut... tu ne trouveras aucune trace de l'arrangement mémoire de l'add-in juste en relisant le g1a. Il faut re-linker si tu veux le modifier !
Tu n'as jamais été aussi près
Citer : Posté le 30/05/2018 18:50 | #
Charger un addin avec un addin, on peut pas déjà le faire avec un syscall ? Ou c'est que les applis systèmes ?
Ecrivez vos programmes basic sur PC avec BIDE
Citer : Posté le 30/05/2018 18:57 | #
Non, on peut le faire avec un syscall, mais ça éliminerait définitivement l'add-in « lanceur », et du coup ça casse tout l'intérêt de faire un chain-load. Le but c'est de continuer à faire des choses avec l'add-in lanceur (le debugger !) pendant que l'autre tourne.
Citer : Posté le 30/05/2018 19:05 | #
Si c'est le même fonctionnement qu'avec les applis système, on peut faire comme PRGM2 et débugger avec les timers.
Ecrivez vos programmes basic sur PC avec BIDE
Citer : Posté le 30/05/2018 19:11 | #
Quelle horreur. Et puis pas du tout assez poussé pour être franc.
Citer : Posté le 31/05/2018 12:47 | #
Mais ce n'est pas l'objectif de ton add-in de debug, n'est-ce-pas ? Ou est-ce une bibliothèque ? Et qu'est-ce que ça permet de faire, au juste ?
À la base je voulais juste "rajouter" un bouton dans le SDK pour envoyer le g1a dans la calto pour le tester rapidement (sans forcement qu'il reste en mémoire).
Visiblement on peut aller bien plus loin que ça avec les (le?) UBC (User Break Controller) (je me suis pas encore renseigné j'aimerais déjà mettre toute la théorie/possibiliter sur papier pour voir un peu ou je vais).
Seulement pour utiliser les (le?) UBC je suppose que je n'ai pas le choix que d’écrire une librairie ( et non un add-in)).
De plus, il est théoriquement possible de pouvoir tester un add-in "axer multijoueur" avec un PC donc ça ajoute encore plus d'intérêt au truc
Ce que je j'imaginais au début: le rôle de l'add-in sera d'attendre qu'on lui envoie un g1a , il le place """"""""en RAM"""""" (il de débrouille pour pas qu'il se mette dans la ROM pour la simple et bonne raison c'est que l'add-in de test va être transféré souvent (ça évite de faire une optimisation (dans le menu MEMORY))) et une fois qu'on a fini avec l'add-in (de test) l'add-in (de debug) reprend la main et re-glande le temps qu'on lui envoie un autre g1a.
Voilà une vidéo qui résume bien ce que je voulais faire à la base;
(donc ce n'est pas une bibliothèque) (je pense que j'ai une une connerie a appeller le topic 'add-in de debug'')
Ou alors le bouton (que je veux rajouter dans le sdk) génère un linker script, recompile le g1a, puis...heuuu...nan mais c'est débile...bon, j'avoue je me suis perdu là....
Tu te trompes sur le linker script : le seul à le lire c'est le linker à la fin de la compilation. Le linker produit un fichier ELF qui contient des sections auxquelles des adresses ont été une fois pour toutes assignées. Ensuite crt0.s ne fait que lire les adresses laissées par le linker dans le fichier pour charger l'add-in. Et comme avant de passer en g1a on supprimer toutes les propriétés ELF pour ne garder que le binaire brut... tu ne trouveras aucune trace de l'arrangement mémoire de l'add-in juste en relisant le g1a. Il faut re-linker si tu veux le modifier !
Hé bien, je suis bloqué
Non, on peut le faire avec un syscall, mais ça éliminerait définitivement l'add-in « lanceur », et du coup ça casse tout l'intérêt de faire un chain-load. Le but c'est de continuer à faire des choses avec l'add-in lanceur (le debugger !) pendant que l'autre tourne.
Le mieux serait de pouvoir vraiment debugger avec l'add-in lanceur, seulement je n'y connais rien en debugg donc il faut que je me renseigne, de plus, a part moi, à quel intérêt aura l'add-in à part pour ce qui développe (en C il n'y en a pas des masses) et qui font de l'assembleur (il a yen encore moins x) ) ?
Mais il y a tellement de choses à découvrir et a appris que je pense quand même me lancer dedans
Tu peux faire ça oui. Le truc c'est qu'à la fin de la fin le système saute à 0x00300200 pour démarrer l'exécution de ton add-in. Donc tu peux pas le faire charger dans la RAM : c'est à lui de se déplacer dans la RAM une fois qu'il a été chargé par le système.
Faut absolument que je lise la doc
Le système le charge ou alors ?
http://furrtek.free.fr/index.php?p=crea&a=smsram
Citer : Posté le 31/05/2018 18:12 | #
À la base je voulais juste "rajouter" un bouton dans le SDK pour envoyer le g1a dans la calto pour le tester rapidement (sans forcement qu'il reste en mémoire).
Ah mais ça ce nest "pas possible", sauf si tu as les sources du SDK... ou alors c'est un programme externe que tu appelles avec un raccourci clavier à la limite.
Un add-in et une bibliothèque c'est la même chose : du code. Tant que tu peux exécuter une fonction pour configurer l'UBC, et répondre aux signaux qu'il t'envoie, tu fais bien ce que tu veux.
Mais c'est un add-in de transfert ça. Si tu n'exécutes pas l'add-in que tu as transféré, ça ne sert à rien !
Remarque supplémetaire : ce n'est pas le debugger qui doit être en ROM et l'add-in testé en RAM, mais l'inverse.
Il faut que je précise plusieurs choses :
- Re-linker un add-in pour le mettre intégralement dans la RAM sans toucher aux sources, c'est dur.
- Le linker script ça ne se génère pas vraiment à la volée, ça s'écrit comme un programme.
- Seul GNU ld utilise les super linker scripts de la destruction. Pas le linker du SDK.
- Pour utiliser l'UBC il faut contrôler le gestionnaire d'interruptions.
Ce que tu veux n'est pas encore clair pour moi. Je refuse d'en dire plus pour éviter de t'envoyer dans la mauvaise direction.
Tu sais le risque principal c'est que tu puisses pas debugger un add-in qui n'ait pas
1. été compilé avec plusieurs choses spécifiques à ton système de debuggage, voire
2. (si tu veux utiliser l'UBC et que tu n'est pas trop habile) été compilé avec un gestionnaire d'interruptions moddable.
Cela va de soi que tu ne veux pas tomber dans la deuxième catégorie...
Dans la ROM... à 0x00300000. Parce qu'à l'origine ton add-in est certes déjà présent dans la mémoire Flash, mais il est dans le système de fichiers. À côté d'autres fichiers et dossiers. Et potentiellement en morceaux fragmentés... avant de pouvoir lancer l'add-in il faut bien commencer par le mapper de façon continue dans la mémoire.
Citer : Posté le 31/05/2018 18:57 | #
Quelle horreur. Et puis pas du tout assez poussé pour être franc.
Pourquoi ça ? On peut mettre le code qu'on veut dans les timers, non ? Du coup on aurait éventuellement accès à un menu "debug" qui montrerait des infos sur l'addin en cours d'exécution. Vu la puissance de PRGM2 ça m'étonnerait qu'on ne puisse pas faire ça.
Si tu parles de calto physique, ça va être assez chaud
Ecrivez vos programmes basic sur PC avec BIDE
Citer : Posté le 31/05/2018 19:07 | #
De puissance, PRGM2 n'a que la vitesse d'exécution du langage. Non, dans un debugger, on aimerait...
- Tracer les appels de syscalls effectuées
- Utiliser le User Break Controller
- Rattraper les exceptions pour lancer une console de débogage
- Générer des dumps quand une segfault se produit
- ...
On ne peut pas faire ça avec un timer. Pour débugger, il faut être dans le programme, et au bon moment. Et le debugger ne doit pas mettre 10 ms à se rendre compte que la segfault a eu lieu : ce sera trop tard. La calculatrice aura déjà crashé depuis longtemps.
Citer : Posté le 02/06/2018 21:55 | #
Ah mais ça ce nest "pas possible", sauf si tu as les sources du SDK... ou alors c'est un programme externe que tu appelles avec un raccourci clavier à la limite.
Ouais c'est ça juste un programme qui envoie (mais du coup ça n'a pas beaucoup d'intérêt a part d’être un poil plus rapide que FA-124) mais si par la suite il y a moyen de communiquer Laptop->Casio ça aiderait les "débutants" (je suis encore un débutant) pour tester leurs jeux / programme.
Un add-in et une bibliothèque c'est la même chose : du code. Tant que tu peux exécuter une fonction pour configurer l'UBC, et répondre aux signaux qu'il t'envoie, tu fais bien ce que tu veux.
Mmmmm...j'ai fait des recherche et impossible de trouver la moindre info sur les UBC (même en cherchant sur la doc (j'ai lu en diagonale donc c'est surement moi qui l'ai loupé)).
Je sais donc pas à quoi m'attendre ni même ce que c'est :/
Mais c'est un add-in de transfert ça. Si tu n'exécutes pas l'add-in que tu as transféré, ça ne sert à rien !
Remarque supplémetaire : ce n'est pas le debugger qui doit être en ROM et l'add-in testé en RAM, mais l'inverse.
Du coup c'est inutile au possible, reprogrammer le menu LINK c'est débile (même si c'est surement super-intéressant^^ ).
Donc au final mon projet d'add-in sert pas à grand-chose
Ce que tu veux n'est pas encore clair pour moi. Je refuse d'en dire plus pour éviter de t'envoyer dans la mauvaise direction.
Ce que j'aimerais avoir c'est un projet qui me permette de toucher vraiment a l'assembleur (et plus si affinité) mais la...je n'ai pas d'idée de projet... (déjà finir tous les trucs que j'ai commencés).
Tu sais le risque principal c'est que tu puisses pas debugger un add-in qui n'ait pas
1. été compilé avec plusieurs choses spécifiques à ton système de debuggage, voire
2. (si tu veux utiliser l'UBC et que tu n'est pas trop habile) été compilé avec un gestionnaire d'interruptions moddable
J'ai déjà peu de connaissances...donc bon x)
Dans la ROM... à 0x00300000. Parce qu'à l'origine ton add-in est certes déjà présent dans la mémoire Flash, mais il est dans le système de fichiers. À côté d'autres fichiers et dossiers. Et potentiellement en morceaux fragmentés... avant de pouvoir lancer l'add-in il faut bien commencer par le mapper de façon continue dans la mémoire.
Haaa du coup ça fait appel au MMU, chose que tu refuses de toucher ? (au passage je n'ai toujours pas compris pourquoi tu veux toucher au MMU avec gint ?
(je suis désolé si je pose beaucoup de questions).
Pourquoi ça ? On peut mettre le code qu'on veut dans les timers, non ? Du coup on aurait éventuellement accès à un menu "debug" qui montrerait des infos sur l'addin en cours d'exécution. Vu la puissance de PRGM2 ça m'étonnerait qu'on ne puisse pas faire ça.
Si je me souviens bien gint plantait au début parce que les timers étaient trop lends (ou gint était trop lend) (absolument pas sûr de ce que je dis) du coup debugger ? en moins d' 1 ms .
De puissance, PRGM2 n'a que la vitesse d'exécution du langage. Non, dans un debugger, on aimerait...
- Tracer les appels de syscalls effectuées
- Utiliser le User Break Controller
- Rattraper les exceptions pour lancer une console de débogage
- Générer des dumps quand une segfault se produit
- ...
J'aimerais juste rappeler que je sais pas programmer en assembleur et que je peine à le comprendre
Peut-être dans quelques années
Du coup je pense essayer de comprendre les timers et essayer de voir si je peux aller les "titiller" de près. (pour un débutant ça me semble pas impossible), donc théoriquement je dois:
Citer : Posté le 02/06/2018 22:13 | #
Tu as lu la documentation du processeur mais l'UBC est sur le microcontrôleur, à côté du processeur. Regarde doc/mpu/sh7705.pdf dans la bible de TeamFX ( https://mega.nz/#F!HMFy1S6J!R5YKtsPOSPNzrJxvewRB2g ) section 23, et doc/mpu/sh7724.pdf section 49. C'est pas dit qu'il existe sur SH4, alors teste bien si tu veux l'utiliser !
Tu peux faire un debugger, c'est un super projet ça !
Oui, le MMU est responsable des mappings mémoire. Et moi je ne veux pas y toucher dans gint, parce que c'est un truc trop crucial, et si je le dérègle par erreur, le système risque de ne jamais retrouver où il en est... et si le système déraille, il ne peut plus exécuter d'add-ins, donc je ne peux plus corriger mes erreurs. Helder7 a brické une Prizm comme ça
Si je me souviens bien gint plantait au début parce que les timers étaient trop lends (ou gint était trop lend) (absolument pas sûr de ce que je dis) du coup debugger ? en moins d' 1 ms .
Le but d'un timer c'est d'exécuter du code de façon périodique. Donc oui, on peut mettre du code ; à vrai dire si on n'en mettait pas ça ne servirait à rien. Un timer ce n'est pas une simple horloge !
Quant à gint, je ne vois vraiment pas à quoi tu fais référence. Je n'ai jamais eu de problème de vitesse et je n'ai manipulé les timers qu'assez tard. Si tu pouvais retrouver le passage qui t'a fait penser ça, il faudrait le clarifier !
J'en ai fait un tutoriel, de ce désassemblage de syscall, si jamais :
https://www.planet-casio.com/Fr/forums/topic14544-1-[Tutoriel]_Desassembler_des_syscalls_avec_une_seule_main.html
L'adresse des timers, comme tout le reste, est dans la doc de SimLo. C'est là que tu dois chercher en premier. Il te manque une info ? Réflexe numéro 1, la doc de SimLo. Réflexe numéro 2, la doc du MPU. Réflexe numéro 3, la doc de SimLo.
Citer : Posté le 03/06/2018 00:59 | #
Réflexe numéro 4, oublier la Bible hébergée sur Mega pour celle de Planète Casio : https://bible.planet-casio.com/hardware/mpu/sh7705.pdf
Celle-ci est tenue à jour, c'est pas le cas de la vieille
Citer : Posté le 06/06/2018 11:52 | #
Tu as lu la documentation du processeur mais l'UBC est sur le microcontrôleur, à côté du processeur.
C'est pas faux
C'est pas dit qu'il existe sur SH4, alors teste bien si tu veux l'utiliser !
D’après la doc sur SH-4A section 10: l'UBC existe sur SH4
Tu peux faire un debugger, c'est un super projet ça !
C'est vrai mais il me manque trop de connaissances, déjà faut que je trouve l'address de UBC, comprendre les signaux qu'il m'envoie et du coup faudra que je fasse une librairie je sais pas en quel langage ni comment la faire
Oui, le MMU est responsable des mappings mémoire
Mais quel intérêt a gint d'y toucher ?
Quant à gint, je ne vois vraiment pas à quoi tu fais référence. Je n'ai jamais eu de problème de vitesse et je n'ai manipulé les timers qu'assez tard. Si tu pouvais retrouver le passage qui t'a fait penser ça, il faudrait le clarifier !
Je me suis trompé, tu avais un problème d'handler et vu que quelqu'un avais évoqué GetKey() qui ennuie les timers j'ai tout confondu
J'en ai fait un tutoriel, de ce désassemblage de syscall, si jamais :
Je l'ai déjà lu plusieurs fois, mais j'ai envie d'essayer tout seul pour voir si je tombe sur ce que tu as dit dans ton tuto
L'adresse des timers, comme tout le reste, est dans la doc de SimLo.
Ha bon ?! Faut vraiment que je me mette à lire correctement les docs
Le but d'un timer c'est d'exécuter du code de façon périodique. Donc oui, on peut mettre du code ; à vrai dire si on n'en mettait pas ça ne servirait à rien. Un timer ce n'est pas une simple horloge !
Mais ya un truc que je comprends pas, si on met du code dans un timer faut aller vérifier si le timer a fini pour exécuter le code ? du coup autant utiliser la RTC... Sauf si le timer et indépendant du code et dans ce cas-là c'est génial (même si je croyais qu'il était impossible de faire 2 choses à la fois, "faire 2 actions en parallèle"...)