Page 7 sur 14

Re: Challenge NumWorks++ | Flash chip hardware mod

Message non luPosté: 08 Nov 2017, 13:06
de parisse
Voir le 1er post de https://tiplanet.org/forum/viewtopic.php?f=102&t=20445
Apres les fractions, il faudrait tester des calculs intermediaires avec entiers longs, par exemple 200!/199!, des calculs avec entiers longs (par ex. 99!), ensuite une variable symbolique par exemple x, puis des expressions symboliques, par exemple sin(x), puis des calculs symboliques, par exemple factor(x^4-1)

Re: Challenge NumWorks++ | Flash chip hardware mod

Message non luPosté: 08 Nov 2017, 13:17
de Adriweb
Ah oui, j'avais oublié que ça gérait le bon formatage (fraction etc.) directement, apparemment - très bien.

Re: Challenge NumWorks++ | Flash chip hardware mod

Message non luPosté: 09 Nov 2017, 00:14
de zardam
Effectivement, pour la video, j'ai eu droit à un "strike" de youtube car son contenu est "inapproprié" d'après eux :?

Pour la compilation de Giac, j'ai récupéré un config.h généré par le script configure de la 1.4.9 avec --enable-tommath. Je n'ai pas réussi à linker cette version avec epsilon, du coup je me suis replié sur la 1.2.0. Je vais de toute façon mettre tout ça sur github, une fois que j'aurais fait un peu de ménage (c'est parti un peu dans tous les sens pour faire fonctionner tout ça)

Pour les tests :
    - Les fractions fonctionnent très bien.
    - 200!/199! -> fail (SIGSEGV)
    - 99! -> fail (SIGSEGV)
    - x -> Ok
    - sin(x) -> fail (SIGSEGV)
    - factor(x^4-1) -> un popup "syntax error". epsilon doit filtrer le mot clé

Dans le cas SIGSEGV, je n'ai pas vraiment d'info utile, car pas de stacktrace dans gdb (la pile semble corrompue). Je supposais un problème de mémoire, mais il devrait y avoir de l'ordre de 100Ko de heap disponible. C'est étrange que des trucs tout simples comme 2! ne passent pas. Il y a certainement un problème autre. Je n'ai pas eu le temps de creuser, et gdb ne me permet pas de mettre des points d'arrêt dans le code de la flash externe. Bref à suivre...

Re: Challenge NumWorks++ | Flash chip hardware mod

Message non luPosté: 09 Nov 2017, 08:00
de parisse
Ce sont les operateurs et commandes qui ne passent pas peut-etre parce que vos flags de compilation ne sont pas adaptes. Je conseillerais d'imiter ceux que j'utilise pour khicas
Code: Tout sélectionner
-DHAVE_CONFIG_H -I. -I..  -DIN_GIAC -DTIMEOUT  -DNO_PHYSICAL_CONSTANTS -DNO_STDEXCEPT -DSTATIC_BUILTIN_LEXER_FUNCTIONS -DGIAC_BINARY_ARCHIVE -DNO_UNARY_FUNCTION_COMPOSE -DTIMEOUT

eventuellement aussi -DNSPIRE_NEWLIB

Re: Challenge NumWorks++ | Flash chip hardware mod

Message non luPosté: 09 Nov 2017, 23:12
de zardam
Je suis repassé sur le simulateur finalement.

Pour les factorielles, il y avait un conflit entre micropython et libtommath (sur les fonctions du mp_...). Pour l'instant j'ai enlevé la partie python d'epsilon et ça fonctionne très bien.

Pour le reste, en fait ça coince dans unary.h sur cette ligne
Code: Tout sélectionner
81       gen operator () (const gen & arg,const context * context_ptr) const { return op(arg,context_ptr); };


"op" ne semble pas initialisé correctement. D'ailleurs, avec -Os à la compilation, elle se fait "optimiser". J'ai bien essayé de désactiver toutes les optimisation et plusieurs combinaisons de define mais sans succès. C'est étrange, car avec giac 1.4.9 sur le simulateur, je n'ai pas le problème... Le code est identique, mais je n'ai pas encore comparé la ligne de commande de gcc.

Pour info, j'ai tout mis sur github ici : https://github.com/zardam/libtommath-0.39 et ici https://github.com/zardam/giac-1.2.0

J'ai corrigé un problème de compilation ici, mais pas certain que ce soit ok.

Sinon, la trace gdb, au cas ou :
Code: Tout sélectionner
(gdb) bt
#0  0x00005555556b4e61 in giac::unary_function_eval::operator() (this=0x555555f1e774 <giac::_cos_s+2>, arg=..., context_ptr=0x55555629d380 <caseval::C>) at unary.h:81
#1  0x0000555555955aaa in giac::symbolic::eval (this=0x555556357e68, level=1, contextptr=0x55555629d380 <caseval::C>) at symbolic.cc:1444
#2  0x00005555556538c8 in giac::gen::in_eval (this=0x7fffffffdd00, level=1, evaled=..., contextptr=0x55555629d380 <caseval::C>) at gen.cc:2105
#3  0x00005555556b40b6 in giac::gen::eval (this=0x7fffffffdd00, level=1, contextptr=0x55555629d380 <caseval::C>) at gen.h:677
#4  0x0000555555cd5b40 in giac::protecteval (g=..., level=1, contextptr=0x55555629d380 <caseval::C>) at prog.cc:7399
#5  0x00005555556b25f9 in giac::caseval (s=0x5555563af708 "sin(0)") at gen.cc:15372
#6  0x00005555556331a3 in Calculation::Calculation::setContent (this=this@entry=0x55555629aa08 <container+9800>, c=0x5555563af708 "sin(0)", context=context@entry=0x5555563574b0)
    at apps/calculation/calculation.cpp:58
#7  0x0000555555633208 in Calculation::CalculationStore::push (this=this@entry=0x55555629aa00 <container+9792>, text=<optimized out>, context=context@entry=0x5555563574b0)
    at apps/calculation/calculation_store.cpp:14
#8  0x00005555556338c6 in Calculation::EditExpressionController::textFieldDidFinishEditing (this=0x555556357530, textField=<optimized out>, text=<optimized out>, event=...)
    at apps/calculation/edit_expression_controller.cpp:99
#9  0x000055555562484f in TextField::handleEvent (this=0x5555563af5a8, event=...) at escher/src/text_field.cpp:365
#10 0x000055555561c006 in App::processEvent (this=<optimized out>, event=...) at escher/src/app.cpp:49
#11 0x000055555561d313 in Container::dispatchEvent (this=this@entry=0x5555562983c0 <container>, event=...) at escher/src/container.cpp:39
#12 0x000055555564a24d in AppsContainer::dispatchEvent (this=0x5555562983c0 <container>, event=...) at apps/apps_container.cpp:83
#13 0x000055555561fa8a in RunLoop::step (this=this@entry=0x5555562983c0 <container>) at escher/src/run_loop.cpp:69
#14 0x000055555561faa6 in RunLoop::run (this=this@entry=0x5555562983c0 <container>) at escher/src/run_loop.cpp:24
#15 0x000055555561d27f in Container::run (this=this@entry=0x5555562983c0 <container>) at escher/src/container.cpp:48
#16 0x000055555564a39b in AppsContainer::run (this=0x5555562983c0 <container>) at apps/apps_container.cpp:135
#17 0x00005555556027c5 in main (argc=<optimized out>, argv=<optimized out>) at ion/src/simulator/boot/main.cpp:6
(gdb) p op
$2 = (giac::gen_op_context) 0x736f63615f74615f

Re: Challenge NumWorks++ | Flash chip hardware mod

Message non luPosté: 10 Nov 2017, 02:45
de zardam
Bon, on peut oublier le post précédent :D voir pourquoi ici : https://vimeo.com/242163942 (si ma video ne se fait pas jeter comme sur youtube)

Bref, j'ai fini par réussir à compiler Giac 1.4.9 comme il faut, et ça fonctionne parfaitement ! L'accès à la flash externe n'est pas encore optimal (24MHz en SPI standard) ça doit expliquer en partie la lenteur. J'ai fini par souder directement l'adesto, mais elle ne veut pas passer en QSPI. Et vu cette ligne du datasheet "WARNING : The QE bit should never be set to a 1 during standard SPI or Dual SPI operation if the WP or HOLD pins are tied directly to the power supply or ground.", ça explique peut être pourquoi j'ai cramé le microcontrolleur la fois passée... Je vais faire un peu plus attention...

Le code source va suivre, mais la c'est l'heure d'aller dormir.

Re: Challenge NumWorks++ | Flash chip hardware mod

Message non luPosté: 10 Nov 2017, 08:35
de Lionel Debroux
Bref, j'ai fini par réussir à compiler Giac 1.4.9 comme il faut, et ça fonctionne parfaitement !

Super nouvelle :)

Re: Challenge NumWorks++ | Flash chip hardware mod

Message non luPosté: 10 Nov 2017, 08:45
de Adriweb
Félicitations !

Re: Challenge NumWorks++ | Flash chip hardware mod

Message non luPosté: 10 Nov 2017, 11:14
de parisse
Bravo!
Pour info, avec ce type de caracteristiques materielles, je m'attendais a environ 1 seconde pour calculer l'integrale de 1/(x^4-1)
(time() permet de mesurer le temps d'execution mais ca ne doit pas marcher avec l'UI de l'app Calculs).

Re: Challenge NumWorks++ | Flash chip hardware mod

Message non luPosté: 10 Nov 2017, 12:49
de Ti64CLi++
Bonne nouvelle :)
Bien joue zardam :bj: