Posté le 09/05/2018 17:27
sûrement les trucs GPIO, mais quoi d'autre ?
Planète Casio v4.3 © créé par Neuronix et Muelsaco 2004 - 2024 | Il y a 197 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
Citer : Posté le 09/05/2018 17:42 | #
J'ai regardé un peu... je n'ai pas trouvé d'informations directes sur où commencer pour créer le port. Ce n'est pas gagné.
Si tu es assez motivé pour faire lancer ce projet, alors tu gagnerais beaucoup à commencer par t'installer un Linux ; je doute que tu ailles loin sinon. Et comme à l'accoutumée, c'est seulement en démarrant bien que les gens vont se sentir impliqués...
Citer : Posté le 09/05/2018 18:00 | #
Je soutiens LePhé, je pense que si tu ne commences pas sur Linux, c'est le genre de truc où tu vas passer beaucoup (trop) de temps à te débattre pour faire marcher des trucs alors que c'est pas là que devrais passer ton temps…
Après je pense qu'il faut commencer par étudier un peu comment est fichu MicroPython pour voir comment bien commencer.
Citer : Posté le 25/05/2018 12:09 | #
Par une magie divine il y a un sh3eb-elf-gcc ainsi qu'un g1a-wrapper installés sur mon système
Du coup je commence à faire le port, toute aide est la bienvenue
Ajouté le 25/05/2018 à 13:02 :
Pour éviter de compiler micropython à chaque fois, il me faudrait deux commandes :
- une pour compiler micropython en fichier .o
- une autre pour compiler mes fichiers .c (l'éditeur + shell) et les joindre au .o pour former un .elf final
Pour l'instant j'ai que la commande du tuto de lephé : sh3eb-elf-gcc -m3 -mb -ffreestanding -nostdlib -T addin.ld crt0.s addin.c -o addin.elf -I include -lgcc -L . -lfx -O2, je fais comment ?
Ecrivez vos programmes basic sur PC avec BIDE
Citer : Posté le 25/05/2018 13:14 | #
On dirait que tout n'est pas clair pour toi : tu ne compileras pas MicroPython avec une seule commande. Il faudra au moins une commande par fichier source de MicroPython, plus une commande pour linker, au minimum. De toute façon MicroPython arrive déjà avec un script de compilation.
Le Makefile dans le répertoire du port minimal par exemple, est déjà là pour compiler tout MicroPython. Tu dois le lire, remarquer qu'en fait il compile pour ARM, et que la cross-compilation est paramétrée par un paramètre CROSS. Tu veux activer ce paramètre, mais dans les sections guardées par ifeq ($(CROSS), 1), tu veux changer les paramètres, par exemple remplacer arm-none-eabi par sh3eb-elf- et remplacer FLAGS_CORTEX_M4 par un FLAGS_SUPERH avec les bonnes options de compilation pour la calculatrice, virer les histoires de DFU...
Tu ferais bien de commencer par le compiler pour PC. Ça me paraît déjà suffisamment compliqué comme ça.
Bref, le tutoriel de compilation de GCC indique quelles options sont pour la compilation, quelles options sont pour le linkage, et quelles options sont pour les deux :
Compilation
-m3 et -mb (SuperH-3, big endian)
-ffreestanding (pas de lib standard ni rien en-dessous de l'add-in)
-nostdlib (impliqué par -ffreestanding, il me semble)
-I include (où trouver les headers) (*)
-O2 (optimisations)
Et bien sûr -c qui indique de ne pas faire le linkage...
Édition des liens
-T addin.ld (instructions de linkage dans addin.ld)
-lgcc (compiler avec libgcc)
-L. -lfx (compiler avec fxlib, et chercher fxlib dans le répertoire courant)
+ toutes les options de compilation parce que quand on utilise libgcc on doit les remettre à l'édition des liens
Si tu essaies de compiler MicroPython avec -I include... alors ce n'est peut-être pas par ce projet-là que tu devrais attaquer ton usage de la toolchain GNU. Porter MicroPython est bien assez ambitieux.
Citer : Posté le 25/05/2018 14:34 | #
Bon, avant de faire la compilation en .o j'aimerais déjà réussir à compiler tout micropython.
Déjà ça commence bien : les dossiers dans les #include sont en bordel, par exemple le fichier extmod/vfs.c inclut py/runtime.h au lieu de ../py/runtime.h, donc y'a plein de "fichier non trouvé". Bon, encore ça se règle avec un petit script.
Par contre le fichier py/qstr.h essaie d'inclure le fichier genhdr/qstrdefs.generated.h qui n'est pas là du tout. En regardant d'autres ports de micropython apparemment il est autogénéré avec le script makeqstrdata.py, mais évidemment il marche pas, en me disant de regarder des erreurs inexistantes :
J'ai bien essayé de virer les qstr en ajoutant un #define NO_QSTR dans addin.c (qui est compilé en premier) mais ça fait rien du tout.
Des idées ?
Ecrivez vos programmes basic sur PC avec BIDE
Citer : Posté le 25/05/2018 20:07 | # |
Fichier joint
Tu t'es pas mal planté on dirait. Ta toolchain est probablement en cause pour l'erreur liée au préprocesseur - t'as un gcc pour ton système pour commencer ?
Du reste, l'histoire des includes ne tient pas debout ; les mecs de MicroPython n'auraient pas laissé passer ça. Tu as pu lancer le mauvaise Makefile.
J'ai compilé le port Unix de MicroPython en suivant les instructions, ça m'a pris 15-20 minutes et aucun effort. Je joins une copie de mon terminal pour que tu puisses voir les commandes, si jamais (tout ce qui commence par λ c'est mon prompt, le λ est toujours suivi du nom du dossier courant et parfois de master quand je suis dans un dépôt git).
Citer : Posté le 25/05/2018 20:14 | #
Ouaip, j'ai un sh3eb-elf-gcc (5.2.0 d'ailleurs, mais micropython ne précise pas de version minimum), et le g1a-wrapper. Aucune idée de comment ils se sont retrouvés sur mon système, j'ai un dossier avec ça où les .exe datent du 30/11/2015.
Pour les makefile je les lance pas (j'ai pas make d'installé), je fais juste les commandes dans ton tuto en mettant tous les fichiers sources de micropython. Du coup mon .bat c'est ça :
sh3eb-elf-objcopy -R .comment -R .bss -O binary addin.elf addin.bin
g1a-wrapper addin.bin -o micropy.g1a -i icon.bmp
python g1a-wrapper-fix.py micropy.g1a
Ecrivez vos programmes basic sur PC avec BIDE
Citer : Posté le 25/05/2018 20:24 | #
Bon, Zezombye... je vais mettre le plus de tact possible dans ce message.
Quand je disais que compiler la version Unix de MicroPython est déjà assez compliqué, je le pense vraiment. Tu ne devrais pas compiler une version SH3 direct ; tu n'as aucune chance.
Je t'ai demandé si tu avais un gcc pour ton système. Ton ordinateur n'est pas basé sur un SuperH. Il est certainement basé sur un x86. Le sh3eb-elf-gcc est donc un gcc pour ta calculatrice mais certainement pas pour ton système. Ce sont des notions que tu devrais maîtriser sans sourciller avant de penser porter un programme aussi compliqué.
Si tu penses que tu peux compiler un projet complet en ignorant les Makefile et en invoquant toi-même le compilateur sur tous les fichiers simultanément avec des options que tu as piquées ailleurs et sans lire le README du projet... alors c'est trop tôt pour toi pour compiler MicroPython. Tu as besoin de progresser en C, tu as besoin d'expérience dans la compilation de projets, et tu as besoin d'expérience d'Unix.
Les mecs d'OSDev qui développent leurs propres kernels et leurs propres systèmes ont un tutoriel de portage de Python, qui n'a rien à voir avec ce que tu veux faire et que tu ne dois pas lire. Tu dois juste remarquer qu'il est vieux (il compile Python 2.5), qu'il utilise a priori les sources du Python mainstream et pas de MicroPython, et qu'il est noté de difficulté Master.
Porting Python - OSDev Wiki
Soit le niveau 4/4. À côté, la compilation de GCC sur laquelle tu as significativement galéré avant - si ma mémoire est bonne - de reprendre des exécutables précompilés, c'est le niveau Beginner, soit 1/4 :
GCC Cross-Compiler - OSDev Wiki
Leurs méthodes à eux sont plus compliquées mais la tâche que tu essaies d'accomplir n'est pas quelque chose qu'on peut réussir par hasard. Tel que je te vois parti, tu n'es pas prêt d'obtenir juste un fichier ELF pour SH3.
Voilà, j'ai fait de mon mieux pour le tact, comme tu peux le voir ce n'est pas génialissime, mais je pense que le message est passé.
Citer : Posté le 25/05/2018 20:34 | #
Inutile d'utiliser du tact, je sais très bien que je suis une merde en C
Par contre je comprends pas pourquoi je dois avoir un GCC qui compile pour mon système, moi je compile pour la calto, pas pour mon système. (et j'ai un GCC d'installé, aucune idée de pour quoi il compile par contre)
Après je pense bien que j'ai un make au final, j'ai le make.exe de cygwin, suffit que je l'ajoute à mon PATH et normalement je peux compiler des makefiles. (reste à comprendre le makefile, parce que moi j'y comprends que dalle
Ajouté le 25/05/2018 à 20:49 :
Le make marche, mais ça risque d'être compliqué de compiler parce que le makefile utilise des commandes spécifiques à linux x)
Ecrivez vos programmes basic sur PC avec BIDE
Citer : Posté le 25/05/2018 20:51 | #
Au risque d'insister, tu n'as aucune chance de faire une cross-compilation propre. Commence par compiler la version Unix pour essayer de comprendre quoi que ce soit au processus.
Le Makefile ne se compile pas ; il indique quelles sont les commandes à exécuter pour compiler le projet. Sans être expert, savoir comprendre la structure d'un Makefile et y trouver les paramètres, surtout dans le cas du Makefile du port minimal qui est très facile à lire, est indispensable. Tu es vraiment parti porter MicroPython sans aucune connaissance en compilation ? '-'
C'est pas faute de t'avoir dit, premier message du topic, de te configurer un Linux.
Citer : Posté le 25/05/2018 21:16 | #
Est ce que tu arrives à compiler la version minimale ? Moi ça me fait des erreurs :
Pour la version unix, y'a des trucs chelous à faire avec git, du coup je m'emmerde pas
Ecrivez vos programmes basic sur PC avec BIDE
Citer : Posté le 25/05/2018 22:18 | #
Je crois qu'il faut d'abord que tu passes sous Linux avant de faire quoique ce soit avec GCC, c'est tellement plus simple et si tu suis le tuto de Lephé, y'a jamais de soucis !
Citer : Posté le 26/05/2018 08:10 | #
Nope, je vais pas installer un OS juste pour un projet x)
Je suis assez proche de la compilation, y'a juste un truc chelou avec le nlr.c (et nlrx86.c), dans ce code :
// When not using setjmp, nlr_push_tail is called from inline asm so needs special care
#if MICROPY_NLR_X86 && MICROPY_NLR_OS_WINDOWS
// On these 32-bit platforms make sure nlr_push_tail doesn't have a leading underscore
unsigned int nlr_push_tail(nlr_buf_t *nlr) asm("nlr_push_tail");
#else
// LTO can't see inside inline asm functions so explicitly mark nlr_push_tail as used
__attribute__((used)) unsigned int nlr_push_tail(nlr_buf_t *nlr);
#endif
#endif
La ligne "unsigned int nlr_push_tail(nlr_buf_t *nlr) asm("nlr_push_tail");" semble poser problème, du coup je l'ai commentée et j'ai mis le #else (pareil pour nlrx86.c). Là ça compile, mais il y a un problème lors du linkage :
build/py/nlrx86.o:nlrx86.c:(.text$nlr_push+0x1e) : référence indéfinie vers « nlr_push_tail »
C'est bizarre, je vois pas pourquoi MICROPY_NLR_OS_WINDOWS est défini alors que le makefile pour le port minimal ne compile pas pour windows...
(sinon, si vous voulez compiler micropython vous-même, je veux bien
Ecrivez vos programmes basic sur PC avec BIDE
Citer : Posté le 26/05/2018 09:19 | #
Ben c'est surtout que ça sera beaucoup plus propre pour ceux qui récupèreront ton code x)
Au passage, les machines virtuelles ça te parle ?
Citer : Posté le 26/05/2018 09:34 | #
Puis on te demande pas de l'installer pour un projet. Ça simplifie le boulot dans l'informatique, que ce soit pour le dev ou l'adminsys.
Et quand bien même ce serait que pour un projet, ça va plus vite d'installer Linux que d'essayer de faire marcher la compilation sous Windows
Citer : Posté le 26/05/2018 09:38 | #
Putain Zezombye.
On ne commente pas des fonctions sous prétexte qu'on n'arrive pas à les compiler. N'importe quel programmeur sait ça ! Tu as commenté la fonction puis tu t'es pris un message d'erreur qui indique, oh quelle surprise, que la fonction est supposée être utilisée mais qu'elle n'existe plus !
Commençons par les bases.
- Avoir un environnement de compilation correct (surtout si on est inexpérimenté, n'est-ce-pas...)
- Lire les README et les INSTALL
- Utiliser les Makefile et pas une sauce maison
- Ne pas modifier les sources sauf en utilisant des patchs testés
- Comprendre ?
Tu sais ce que tu compiles là, le truc qui s'appelle firmware.elf ? Ça t'inspire un exécutable de MicroPython ?
Écoute, si tu ignores tous les conseils qu'on te donne, ce que tu as fait jusqu'à présent excepté pour l'utilisation de make au lieu d'invoquer le compilateur manuellement, on va finir par te répondre « tu n'est manifestement pas assez expérimenté pour ce projet, reviens dans deux ans ». (Ce que j'ai d'abord essayé de te dire, et que tu as ignoré royalement. Sans même demander ce qui pouvait te manquer ni rien...)
Citer : Posté le 26/05/2018 09:47 | #
Binwi je teste, à tout hasard peut être que le bug était là (mais il l'est pas)
- Avoir un environnement de compilation correct (surtout si on est inexpérimenté, n'est-ce-pas...)
- Lire les README et les INSTALL
- Utiliser les Makefile et pas une sauce maison
- Ne pas modifier les sources sauf en utilisant des patchs testés
- Comprendre ?
L'environnement de compilation est correct (cygwin), j'ai lu le readme, j'utilise les makefiles qui sont déjà là (de toute façon je comprends rien aux makefiles donc je les modifie pas), et y'a déjà des erreurs avec la source de base.
Ben le firmware.elf c'est le micropython mais en binaire ? (avec les trucs pour le pyboard)
Je suis pas assez expérimenté, mais faut bien que quelqu'un le fasse ce projet x)
Ecrivez vos programmes basic sur PC avec BIDE
Citer : Posté le 26/05/2018 10:41 | #
Cygwin mais il y a deux jours tu n'avais pas make. Tu ne comprends rien au Makefile, cela contredit mon cinquième point.
C'est extrêmement prétentieux de ta part de dire qu'il y a des erreurs avec la source de base. Tu es en train de qualifier le mainteneur du port minimal de programmeur incompétent au mieux, sur la seule base que tu n'arrives pas à compiler son travail alors que tu n'as aucune expérience dans le domaine. Car oui, le mec qui maintient le port minimal, il le compile probablement à chaque commit. Les gens sérieux font ça.
Si le monde de Java est un monde où tout programme qui compile avec une certaine version du compilateur sous une certaine archi avec une certaine combinaison d'options compile avec toutes les autres versions du compilateur sous toutes les autres archis et avec toutes les autres combinaison d'options, alors je vais casser ton rêve : le C n'est pas comme ça.
Le monde n'est pas divisé entre des programmes qui compilent peu importe les paramètres et des programmes qui ne compilent pas peu importe les paramètres. Apprendre à diagnostiquer les erreurs, à reconnaître des problèmes typiques qui se posent avec d'anciennes versions des compilateurs et ceux qui sont liés à un environnement de compilation incomplet (bibliothèques manquantes, etc), apprendre à distinguer quand l'erreur est dans notre côté et quand les sources peuvent avoir un défaut, c'est un art. Personne ne sait faire ça de façon innée.
Moi je crois qu'il y a des erreurs avec ton setup. Dans tous les cas, la ligne qui est accusée d'une erreur est parfaitement valide en vertu de la documentation. Il y a donc soit une erreur avant, soit un problème de version ou d'options dans la ligne de commande utilisée. Tu es supposé chercher là.
Citer : Posté le 26/05/2018 11:21 | #
je peux me tromper, mais de nombreuse modification me semble néccéssaire dans le fichier stm32f405.ld afin de le faire correspondre à l'architecture de nos cher calculatrice Casio
Citer : Posté le 26/05/2018 11:24 | #
Et tu ne te trompes pas. Tout n'est pas bon à jeter mais presque. Il est assez clair également, au vu du linker script, qu'une partie du programme (certainement le firmware que Zezombye est en train de compiler) fait un travail redondant par rapport à fxlib. Un travail que gint fait par exemple au démarrage de l'add-in.