Module externe Xcas: Python + calcul formel (giac) sur 83PCE

[zardam]

Il faut être sadique ou extrêmement zen pour compiler un projet aussi conséquent sur une target aussi sous-dimensionnée pour la tâche...

Ou ignorant

Il faudrait plutôt cross-compiler à partir d'un ordinateur hôte plus puissant.

Oui, mais jamais fait ça pour un paquet debian encore.

Concernant le backport, Debian buster n'est-il pas en freeze et pour ainsi dire en pratique stable sans officiellement l'être? Pourquoi s'embêter avec un backport alors?

Je n'ai pas trouvé d'image pour le PI Zero. C'est du "raspbian" (arm v6 + hard float), pas du debian "standard" sur ce modèle, et la mise à jour semble prendre autant de temps que la compilation. J'ai fini par craquer avant la fin.

[parisse]

Pour en faire un paquet debian je ne sais pas, par contre on peut cross-compiler giac en utilisant ./configure --host=...
Ceci dit avec un build natif, on est sur que ca marche. Pour aller plus vite en phase de tests, on peut faire export CXXFLAGS=-g, ce qui evite les optimisations par defaut en -O2 qui prennent beaucoup de temps (et de memoire).

[Lionel Debroux]

Les distros Linux préfèrent habituellement la compilation native, car beaucoup de logiciels ne sont pas correctement cross-compilables.

[zardam]

Bon, j'ai fini par me rabattre sur un chroot avec qemu sur mon laptop. Le temps de compilation passe à environ 3h en ayant désactivé les tests (j'ai laissé les autres options par défaut). La procédure est plus ou moins décrite ici : https://wiki.debian.org/RaspberryPi/qemu-user-static

Ci-joint les binaires générés :

giac_rpi0.zip

Pour giacpy, je l'ai fait directement sur le Raspberry (installé avec pip). Il faut prévoir du swap pour que le build passe.

[Lionel Debroux]

Bon, j'ai fini par me rabattre sur un chroot avec qemu sur mon laptop. Le temps de compilation passe à environ 3h en ayant désactivé les tests (j'ai laissé les autres options par défaut).

Ah, "seulement" 3h ? Au boulot, j'utilise de temps à autre des chroots Debian 8 et 9 armel, armhf, arm64 et à une époque mips avec qemu-user-static, mais j'avais éliminé d'office cette méthode, sans en parler ici, car la performance n'est pas bonne... C'est passable pour de petits builds, mais tu parlais de 12h sur une RPi Zero, donc on n'est plus dans ce cadre-là.
Il y a des années, sur la compilation de la glibc, un i.MX51 (EfikaMX) single core avait un facteur de mérite bien meilleur que celui d'un Core i5 mobile qui, lui, utilisait plusieurs coeurs dans un build multi-jobs.

[Lionel Debroux]

@zardam, dès que tu arrives à compiler le tout comme tu veux avec giac, n'hésite pas à partager le firmware.
Je sens que je vais remplacer ma Trinket M0 par une Feather M0...

Ou éventuellement une ItsyBitsy M0 Express, plus petite et moins chère (12 USD), qui dispose comme la Feather M0 (20 USD) d'un chip de Flash externe SPI 2 MB.

Avec un meilleur rapport puissance-prix, pour se libérer des contraintes de place de la famille M0, il y a les ItsyBitsy M4 Express (15 USD) et Feather M4 Express (23 USD), équipées d'un ATSAMD51 plus rapide et surtout de 512 KB de Flash + 192 KB de RAM, plus le chip de Flash QSPI 2 MB. Assez de Flash interne pour stocker non seulement une implémentation plus complète de CircuitPython sans devoir la faire rentrer au chausse-pieds dans 184 KB, mais aussi une image de firmware TI-Python Adapter pour tromper PyAdaptr (<= 184 KB, mais on pourrait même stocker les 256 KB complets), tout en gardant le filesystem sur la Flash externe
La Trinket M4 n'existe pas, c'est marrant. J'imagine qu'ils partent du principe que quand on utilise un µC plus puissant, on a besoin des I/O supplémentaires qu'il offre.

Mais au fait... sur les photos d'Adafruit pour la Feather M4 Express, on voit un ATSAMD51J19, qui a clairement la capacité XIP sur l'interface QSPI ( https://www.microchip.com/wwwproducts/en/ATSAMD51J19A ). Sur l'ItsyBitsy M4 Express, est-ce que quelqu'un arrive à voir quelque chose ?
Sur les Metro M4 (dimensions beaucoup plus élevées, mais même famille de matériel), l'utilisation de XIP semble réaliste, même si comme sur les NumWorks, le bootloader ne peut pas flasher la Flash externe: https://forums.adafruit.com/viewtopic.p ... IP#p739304


zardam: quelle taille faisait ton binaire de firmware NumWorks + giac situé sur la Flash externe de la NumWorks ?
Dans viewtopic.php?f=97&t=20557&p=224136&hilit=giac+NumWorks#p224185 , je vois des tailles très supérieures à 2 MB, mais on sait que des builds plus restreints, pour le SH-4 des Graph 90+E, font 2 MB parce que c'est la limite de taille pour une application utilisateur sur cette plate-forme: https://www-fourier.ujf-grenoble.fr/~parisse/casio/ .
Si on peut produire un build de KhiCAS pour Cortex-M4F qui pèse moins de 2 MB, CircuitPython + KhiCAS (mais peut-être pas un giacpy très complet, à moins qu'il ne fasse que quelques dizaines de KBs ?) ne serait pas forcément techniquement impossible sur des ItsyBitsy / Feather / etc. M4.

[zardam]

Ah oui, ces cartes ont l'air très intéressantes !

Pour l'ItsyBitsy M4 Expres le schéma est disponible : https://learn.adafruit.com/assets/55481

Je n'ai pas noté la taille du firmware "giac" avec la Numworks. Je vais le recompiler un coup pour vérifier. C'était moins de 4 Mo, mais moins de 2... pas certain.

[parisse]

Je ne pense pas que ca ait pu etre moins de 2Mo, car j'ai du faire un gros travail pour atteindre 2Mo sur la Casio (suppressions de commandes, optimisations diverses...)

[zardam]

Effectivement, giac & libtommath font environ 3.6 Mo

[Lionel Debroux]

Hmm... moins d'un facteur 2 à gagner, il faudrait donc faire comme Bernard l'a fait pour KhiCAS Graph 90+E, de sérieuses tailles dans la fonctionnalité, pour s'approcher des 2 MB...

GigaDevices fait d'autres chips de Flash de capacité supérieure dans la famille GD25, mais s'il y en a qui utilisent le même boîtier que sur les * M4 Express sus-mentionnées, dessouder et ressouder un chip aussi petit que celui-là nécessite de l'équipement et de l'habitude, contrairement aux chips beaucoup plus gros des NumWorks et de ta manip avec l'Arduino Zero.
Même si Adafruit connaît le TI-Python Adapter et ce qu'on fait avec leurs boards à base d'ATSAMD21 pour fournir un firmware alternatif amélioré, puis plus récemment cloner le TI-Python Adapter, ça serait probablement gonflé de les contacter pour leur suggérer de faire - moyennant finances - quelques exemplaires d'une version custom de l'ItsyBitsy M4 Express ou Feather M4 Express sur laquelle ils souderaient un chip compatible de 32 ou 64 Mbits (encore une fois, si ça existe)