[RESOLU] Options de compilation et variation de mémoire disponible.

Hello tous.

Le choix des options de compilation du firmware dans Companion a-t'il une influence sur la mémoire disponible pour faire tourner des scripts Lua ? La question n'est pas de savoir à quoi ces options correspondent mais seulement de connaître leur influence sur la mémoire et/ou la conso du processeur.

Exemple : Si je choisis noheli, en toute logique, j'ai un firmware plus simple, aurais-je plus de mémoire dispo ?

Quid des autres options comme massstorage, sqt5font, nooverridech etc...

La seule manière d'avoir la réponse à ça c'est de flasher les firmwares en question et regarder la mémoire dispo pour lua à chaque fois.
Ca va changer, mais c'est à peu près impossible de deviner de combien.

Connaissant Heisenberg, on va le savoir bientôt.

Sacre100 a écrit:Connaissant Heisenberg, on va le savoir bientôt.

Si je connaissais le code pour afficher la mémoire je m'y collerait mais je ne connais que celui pour afficher le collecteur de déchet

La mémoire dispo est affichée sur la page DEBUG dans la radio (statistiques / +)

Je n'avais jamais fait attention à ça, c'est plus intéressant ça.
Ne fonctionne pas sous Companion malheureusement, mais ça ne m'étonne pas vraiment car la mémoire n'est pas celle de la radio.

Je vous ferais un compte rendu de quelques tests dans la semaine.

Si si ça marche sous companion, ENT long, puis tu sélectionnes "statistique" puis tu appuies sur la touche + pour passer à la page suivante.

...Et tu as toujours 1000b !

Environnement :
- X9DP
- OpenTX 2.1.6
- Modèle d'exemple peu évolué
- 2 scripts de type télémétrie sur écrans 1 & 2 (Battcheck et Memoscreen)

Résultats : Seules les 2 très spécifiques options CLI et MASSSTORAGE consomment de la mémoire.
Sinon, que le fichier soit compilé vierge ou avec les autres options ne change rien sur le plan mémoire.

Ci-dessous, les mesures réalisées.

en ; eu-fr ; faichoice-fr ; faimode-fr ; fr ; internalppm-fr ; lua-fr ; mixersmon-fr ; nogvars-fr ; noheli-fr ; nooverridech-fr ; ppmus-fr ; sqt5font-fr ; timer3-fr = Mémoire dispo de 23152b

cli-fr ; massstorage-fr = Mémoire dispo de 19456b

timer3-lua-cli-mixersmon-ppmus-sqt5font-fr = Mémoire dispo de 19456b

timer3-lua-mixersmon-ppmus-sqt5font-fr = Mémoire dispo de 23152b

Au risque d'être lourd avec ce sujet, si les options de compilation ne changent rien au niveau ressources mémoire, pourquoi avoir certains choix de dispo ?

Pourquoi ne pas avoir Lua, mixermon et timer3 systématiquement inclus ?
Et pourquoi proposer nogvars, noheli, et nooverridech ?

Si ces choix n'existaient pas, ça ne changerait la vie de personne, si demain, il n'y a pas d'option noheli ou si je ne peux pas désactiver le Lua sur ma radio, ça ne changerait rien, de même que le nooverridech, si je ne veux pas l'utiliser, il me suffit de ne pas l'utiliser même si la radio le propose (?)

J'imagine qu'une raison m'échappe mais par pure curiosité, quelle est-elle ?

Salut Heisenberg,

Je peux répondre partiellement !
Par exemple j'ai coché noheli pour ne pas avoir la page de configuration des hélico, même si cela ne change rien en taille mémoire cela allège l'interface et donc moins de pages à faire défiler. C'est un détail mais j'apprécie cette possibilité.

Cela correspond assez bien à l'esprit libre d'optenTX.

Il ne s'agit bien sur que de mon avis personnel !

Il est vrai que cela complique la rédaction d'une documentation universelle mais c'est un autre débat !

Voilà, simplement pour alléger l'interface de trucs dont on ne va de toute façon pas se servir mais sur lesquels il faut passer à chaque changement de réglages.

Avoir lua ou pas ne change rien à l'interface pourtant.

De même qu'avoir une compilation du firmware différente selon qu'on veuille un chrono 3 ou pas... Je ne m'attendais pas à cette réponse.

Le chrono 3 (Et ce n'est qu'un exemple) aurait pu être une simple coche dans les réglages radio et pareil pour les autres options d'ailleurs.

C'est curieux d'avoir opté pour ce choix de plusieurs compilations possibles plutôt que de tout mettre d'un coup avec des choix dans le menu réglages radio.

Mais merci pour la réponse.

Heisenberg a écrit:Avoir lua ou pas ne change rien à l'interface pourtant. ...

LUA te rajoute une page, celle qui permet de paramétrer les model-script, page qui n'est disponible que sur la radio, elle n'a pas encore été développée pour Companion.

Voilà. Et elle ne rajoute QUE cette page, pas besoin de cocher lua pour des one-time script ou les scripts de télémétrie.

Heisenberg a écrit:C'est curieux d'avoir opté pour ce choix de plusieurs compilations possibles plutôt que de tout mettre d'un coup avec des choix dans le menu réglages radio.

Après ça te fait des choix "inutiles" dans le menu réglages radio
En l'occurrence c'est plutôt la solution de facilité qui a été choisie, il n'y a actuellement pas de mécanisme dans le firmware qui permette de changer la disponibilité des pages à un autre moment qu'à la compilation, donc il y aurait eu du boulot de développement.

... il n'y a actuellement pas de mécanisme dans le firmware qui permette de changer la disponibilité des pages...

J'imagine qu'implémenter un tel mécanisme prendrait de la place en mémoire (au moins dans la partie code) et il me semble plus intéressant d'économiser celle-ci pour ajouter des fonctionnalités RC plutôt qu'une gestion dynamique de pages et options à afficher.

Mais ce n'est que l'avis du Coyotte :-)

Coyotte Solidaire

Kilrah a écrit:c'est plutôt la solution de facilité qui a été choisie, .../...il y aurait eu du boulot de développement.

Cette réponse est nettement moins frustrante, de même que ton explication Lua est plus claire que ce que j'avais lu auparavant.
Jusqu'à présent que pensais que de décocher l'option désimplémentait une partie du support Lua alors qu'il ne s'agit que d'un affichage de page.
Même si je continue de penser qu'ils ont poussé le bouchon un peu loin (comme pour le simple Timer3), ça me plaît plus, je retiens que ces différentes options, à part CLI et MASSSTORAGE ne jouent que sur des masquages/affichages et que ça demandait plus de boulot pour inclure ces options dans le firmware.

Merci de vos infos.

Et, encore un truc, qui reste dans le sujet, mais c'est le dernier, promis...
Existe-t-il un hack visant à rajouter de la mémoire ?

Çà c'est une excellente question....j'ai mis deux scripts et il me dit not enough memory .... Script syntax error ...
les scripts sont : les excellents Battcheck et pixhawk

Heisenberg a écrit:Jusqu'à présent que pensais que de décocher l'option désimplémentait une partie du support Lua

En fait c'est le cas, vu que ça supprime évidemment la fonctionnalité des model scripts (que cette page permet de configurer).

Heisenberg a écrit:Et, encore un truc, qui reste dans le sujet, mais c'est le dernier, promis...  
Existe-t-il un hack visant à rajouter de la mémoire ?

Non rien de possible, c'est déjà le plus grand de la famille niveau RAM.

CoyotteDundee a écrit:J'imagine qu'implémenter un tel mécanisme prendrait de la place en mémoire (au moins dans la partie code)

Ca c'est pas un souci, y'a des tonnes à dispo et on arrivera jamais à tout remplir.

Je déterre le sujet car je ne comprend pas comment la mémoire est gérée.
Suis en V2.1.7 mais je ne pense pas que cela soit une information.

J'utilise 3 scripts, un affichage perso, batcheck (merci), et un affichage des fonctions (merci), et en fonction de l'ordre, écran de télémétrie 1/2/3 j'ai une erreur de mémoire (sur la radio, pas dans companion), ou pas !!

Que conclure malgré ce contournement ?

... Que la mémoire qu'utilise Companion est celle de l'ordinateur.
Ça passe toujours sur l'ordinateur en réalité. Faire un super-script est finalement abordable, là où ça se complique, c'est de faire en sorte d'utiliser un minimum de ressources, le bon génie Sacre100 qui connaît bien ces techniques est souvent passé derrière moi pour minimiser des demandes de ressources quand nous avons planché sur BattCheck. A force, il y'a 2 ou 3 trucs à bien comprendre et mémoriser pour éviter de saturer trop vite la mémoire ou le GC.

J'ai appris par l'exemple, comparaisons, et en y laissant des nuits.

Mais faire tourner 3 scripts en même temps, même optimisés, ça fera toujours plus de mémoire prise qu'un seul. Tu peux réutiliser les mêmes variables pour les 3 scripts si ils utilisent des données identiques, ça fait gagner de la place.