Page 8 sur 14

Re: Challenge NumWorks++ | Flash chip hardware mod

Message non luPosté: 10 Nov 2017, 23:47
de zardam
Merci :)

Pour le temps de calcul, c'est certainement lié à la lenteur de la flash. Elle est actuellement en mode "SPI normal". Il y a donc une amélioration possible d'un facteur 4 en la passant en "quad SPI", et peut être encore un peu plus en augmentant la fréquence (24 MHz pour le moment).

Re: Challenge NumWorks++ | Flash chip hardware mod

Message non luPosté: 11 Nov 2017, 08:06
de parisse
Oui, c'est certainement le temps d'acces memoire au code source (sur la Prime, il faut moins d'1/100ieme de seconde).

Re: Challenge NumWorks++ | Flash chip hardware mod

Message non luPosté: 11 Nov 2017, 11:05
de darthvader
R15 et Q4 sont la pour envoyer le jus à la carte SD à partir d'un PIN du STM32.
Par contre c'est étonnant qu'ils n'aient pas prévu d'y mettre les 2 condensateurs de découplage (100nF et 10µF tantale) en paralelle entre
VDD et VSS au plus prés du connecteur de la SD.

Re: Challenge NumWorks++ | Flash chip hardware mod

Message non luPosté: 12 Nov 2017, 12:27
de coco33920
Félicitation @zardam :o

Re: Challenge NumWorks++ | Flash chip hardware mod

Message non luPosté: 13 Nov 2017, 22:04
de zardam
Merci !

En poussant la flash à 96 MHz et en utilisant la fonction "Fast Read Quad I/O", c'est vraiment plus rapide. L'intégrale de 1/(x^4-1) sort en moins d'une seconde. Je ne sais pas si la carte est faite pour fonctionner à cette fréquence, mais pour l'instant ça a l'air Ok. Tout est dispo ici : https://github.com/zardam/epsilon/tree/giac

Re: Challenge NumWorks++ | Flash chip hardware mod

Message non luPosté: 14 Nov 2017, 07:59
de parisse
Merci!
Je signale juste pour que les choses soient claires d'un point de vue legal: l'edition de liens vers giac dans ce fork de epsilon par un tiers ne donne aucun droit specifique sur le code source de giac, dont la licence d'utilisation par defaut est la GPL3.
Il me semble qu'il n'y a pas de problemes legaux pour linker avec un logiciel GPL3 tournant sur un OS ferme en tant que simple utilisateur de l'OS. Par contre si d'aventure Numworks (ou une autre societe ayant le droit de commercialiser epsilon) souhaitait utiliser ce fork, il faudrait soit qu'ils publient epsilon sous une licence compatible avec la GPL3, soit qu'ils passent un accord avec les detenteurs du copyright.

Re: Challenge NumWorks++ | Flash chip hardware mod

Message non luPosté: 14 Nov 2017, 08:50
de parisse
Sinon, j'ai une suggestion si ca n'a pas ete fait, compiler giac avec
Code: Tout sélectionner
export CXXFLAGS='-Os'

avant ./configure (ou modifier le Makefile et remplacer -O2 par -Os) afin d'optimiser la taille du code (plutot que la vitesse), puisque le facteur limitant semble etre le temps d'acces a la memoire. Peut-etre que ca peut permettre un gain de temps significatif.

Re: Challenge NumWorks++ | Flash chip hardware mod

Message non luPosté: 14 Nov 2017, 12:23
de coco33920
Merci zardam pour le partage du code, je l'ai lu rapidement et a part quelques petites modifications éventuellement cette version prend t elle en charge l'ADESTO plus ou moins officielle de Numworks ou cela implique des modifications en profondeur ?

Merci,
Colin.

Re: Challenge NumWorks++ | Flash chip hardware mod

Message non luPosté: 14 Nov 2017, 23:06
de zardam
Il me semble qu'il n'y a pas de problemes legaux pour linker avec un logiciel GPL3 tournant sur un OS ferme en tant que simple utilisateur de l'OS.


Oui, tant qu'on est dans le cadre privé (pas de redistribution des binaires), cela ne pose pas de problème il me semble. (Free à longtemps utilisé cet argument pour ne pas redistribuer ses modifications de logiciels GPL sur la freebox)

export CXXFLAGS='-Os'


Oui, j'ai compilé tommath et giac avec cette option.

cette version prend t elle en charge l'ADESTO plus ou moins officielle de Numworks ou cela implique des modifications en profondeur ?


Oui, je l'ai testé avec l'adesto dans ma calculatrice. Pour que ça fonctionne il faut patcher flashrom pour qu'il supporte ce modèle, et j'ai ajouté un script python pour setter le bit QE dans le registre de status (cela permet à la flash de passer en mode QSPI).

Cela devrait fonctionner aussi avec la Windbond, dans ce cas il n'est pas nécessaire de patcher flashrom, ni d'utiliser le script python (le mode QSPI est déjà activé). Il faut par contre passer le padding du binaire de la flash externe à 16Mo pour que flashrom l'accepte (et éventuellement modifier le script du linker et la taille de la flash dans le fichier extflash.cpp pour profiter de l'espace supplémentaire)

Re: Challenge NumWorks++ | Flash chip hardware mod

Message non luPosté: 15 Nov 2017, 04:30
de Ti64CLi++
Encore une fois, bravo pour tout ce travail :bj:
Je pense que tu as des chances de faire beaucoup d'heureux :D