LUA Scripting sur V2.1.x

Pour mettre un peu les choses en clair:
- Le debug est actuellement activé d'office avec l'option CLI, mais c'est pas bien et ça va changer en une option séparée.
- Le but de la CLI n'est pas de débugger des scripts, même si avec le couple CLI / debug c'est une des possibilités.
- Les firmwares avec debug activé ne devraient pas être utiliser pour voler, que... pour débugger devant le PC.

L'hexadécimal de ton post ci-dessus c'est des données de télémétrie smart port brutes, rien à voir ni avec debug ni avec CLI.

L'écho dans ton post de cet après-midi en USB c'est probablement une mauvaise configuration de ton programme terminal (retours à la ligne, caractères spéciaux ou autres). PuTTY marche bien avec les réglages par défaut.

Kilrah a écrit:...
- Le but de la CLI n'est pas de débugger des scripts, même si avec le couple CLI / debug c'est une des possibilités.
...

Ce n'est peut-être pas le but, mais pour avoir bataillé pas mal avec des scripts qui tournent dans le simulateur et pas sur la radio, je peux t'assurer que la chose est bienvenue. Et puis y'a des choses pas du tout testable ou très difficilement testables, alors c'est vraiment un plus que d'avoir ça.

Bien sûr, ce n'est pas pour voler avec, ça ça ne me parait pas une bonne idée mais pour la mise au point de certains script, si j'avais eu ça avant, j'aurais gagné beaucoup de temps.

Kilrah a écrit:L'hexadécimal de ton post ci-dessus c'est des données de télémétrie smart port brutes, rien à voir ni avec debug ni avec CLI.

Ça me permettait de vérifier que le montage est ok, ça n'a rien à voir avec le debug ou CLI ca oui, mais j'ai voulu vérifier que le firmware avec ou sans option CLI agissait de la même façon. Hors, le firmware avec option CLI ne retransmet aucune données télémétrique, j'en déduis qu'il y-a quand même un souci (?)

[quote="Kilrah"]L'écho dans ton post de cet après-midi en USB c'est probablement une mauvaise configuration de ton programme terminal (retours à la ligne, caractères spéciaux ou autres). C'était volontaire, c'est une option que j'ai cochée, quand ça communique, j'ai un écho, quand ça ne communique pas, je n'ai pas d'écho, ça me permet de vérifier aussi, je crois que Putty peut le faire aussi.

Je vais attendre la prochaine version avec un debug qui va bien, j'en profiterais pour réessayer Putty, je l'utilisais avec OpenWRT et je n'ai pas pensé à ce soft pour OpenTX.

Sacre100 a écrit:
Ce n'est peut-être pas le but, mais pour avoir bataillé pas mal avec des scripts qui tournent dans le simulateur et pas sur la radio, je peux t'assurer que la chose est bienvenue. Et puis y'a des choses pas du tout testable ou très difficilement testables, alors c'est vraiment un plus que d'avoir ça.

Il est à noter qu'on tombe un peu dans un cercle vicieux, car le fait de passer en mode debug / CLI inclut un tas de code en plus et augmente l'utilisation mémoire d'OpenTX, en en laissant donc encore moins à disposition pour Lua.
Donc tu peux avoir un script qui marche sur la radio sans debug, mais qui ne marche plus en mode debug. Dans les cas "serrés" ça risque de ne pas être d'une grande aide, par contre du coup ca signifie que si ça tourne en mode debug ça devrait pour sûr tourner sans.

Je confirme, mon gros script qui est à la limite de la limite ne fonctionne pas avec CLI activé.

Kilrah a écrit:Il est à noter qu'on tombe un peu dans un cercle vicieux, car le fait de passer en mode debug / CLI inclut un tas de code en plus et augmente l'utilisation mémoire d'OpenTX, en en laissant donc encore moins à disposition pour Lua.
Donc tu peux avoir un script qui marche sur la radio sans debug, mais qui ne marche plus en mode debug. Dans les cas "serrés" ça risque de ne pas être d'une grande aide, par contre du coup ca signifie que si ça tourne en mode debug ça devrait pour sûr tourner sans.

J'avais pas pensé à ça, effectivement, si cela bouffe trop de mémoire, ça va pas le faire.

Alors on va continuer avec des drawText placés judicieusement qui permettent de s'en sortir plus ou moins aisément et puis maintenant qu'on a les fonctions io de base, on va pouvoir garder une trace des exécutions sur la carte SD, c'est aussi un gros plus pour la mise au point.

Tout ça va dans le bon sens, j'adore comme OpenTx évolue rapidement, c'est le jour et la nuit par rapport aux autres radios.

Hello tous, quelqu'un parmi vous pourrait me filer un petit coup de main ?

Il s'agit d'un script télémétrique.
Une seule page.
Avec une COMBOBOX.

J'aimerai pouvoir récupérer ma sélection que je voudrais loger dans la variable i
Je n'arrive pas à comprendre comment rédiger ma ligne lcd.drawCombobox pour récupérer la valeur et la placer dans i

Je ne parviens pas non-plus à changer ma sélection avec les touches + et -

Je me suis plongé dans le code du wizzard pour m'en inspirer mais il est d'un niveau trop complexe encore pour moi (multipage).
Auriez-vous dans vos scripts un petit bout de code avec un exemple concret qui m'aiderait à avancer ? Je ne sais même pas si c'est faisable pour une page de télémétrie (?)

Ça fait 8h00 que je suis dessus et je deviens fou.

Code:


local i = 0

local table_cellcapa = {1800, 2100, 2200, 2600, 3000, 3300, 3600, 4200, 4800, 5000, 5200, 5800, 6000, 8000}

local function run(event)
lcd.clear()

lcd.drawCombobox(2, 2, 32, table_cellcapa, 5, 1)

lcd.drawText(80, 2, i, BOLD)

end -- local function run(event)
return { run = run }


C'est pas tout simple car il faut tout gérer mais voilà déjà un bout de script qui gère la sélection avec les touches "+" et "-". J'ai ajouté aussi le code qui permet de tester ça comme "one time script" pour la mise au point.

Code:

local i = 0

local table_cellcapa = {1800, 2100, 2200, 2600, 3000, 3300, 3600, 4200, 4800, 5000, 5200, 5800, 6000, 8000}

local function run(event)
  if event == nil then
    error("Cannot be run as a model script!")
    return 1
  elseif event == EVT_EXIT_BREAK then                                           -- exit script
    return 1
  elseif event == EVT_PLUS_BREAK then
    i = (i - 1) % #table_cellcapa
  elseif event == EVT_MINUS_BREAK then
    i = (i + 1) % #table_cellcapa
  end
  lcd.clear()

  lcd.drawCombobox(2, 2, 32, table_cellcapa, i, 1)

  lcd.drawText(80, 2, i, BOLD)
  lcd.drawText(80, 20, table_cellcapa[i+1], BOLD)
  return 0
end -- local function run(event)
return { run = run }

Ohh, ça, c'est du tout pré-mâché !
C'est exactement ce que je recherche, tu as même ajouté l'affichage de la position de la liste.

Tel qu'il est, ça marche bien quand un seul écran de télémétrie est affecté au modèle car les touches + et - ont gardé leur fonction de navigation d'un écran à l'autre.

Il doit exister une instruction à ajouter pour désactiver ça, sinon, c'est top.

Exemple du calcule de nombre de C :

Code:

local i = 5
local amps = 0
local table_cellcapa = {1800, 2100, 2200, 2600, 3000, 3300, 3600, 4200, 4800, 5000, 5200, 5800, 6000, 8000}

local function run(event)
  if event == nil then
    error("Cannot be run as a model script!")
    return 1
  elseif event == EVT_EXIT_BREAK then                                           -- exit script
    return 1
  elseif event == EVT_PLUS_BREAK then
    i = (i - 1) % #table_cellcapa
    --return 0
  elseif event == EVT_MINUS_BREAK then
    i = (i + 1) % #table_cellcapa
    --return 0
  end
  
amps = getValue("Curr")
  
  lcd.clear()

  lcd.drawCombobox(2, 2, 32, table_cellcapa, i, 0)

  lcd.drawText(80, 2, "id CellCapa = ", BOLD); lcd.drawText(160, 2,  i, BOLD); lcd.drawText(lcd.getLastPos(), 2, "(i)", BOLD)
  lcd.drawText(80, 12, "Batt Capa = ", BOLD);  lcd.drawText(160, 12, table_cellcapa[i+1], BOLD); lcd.drawText(lcd.getLastPos(), 12, "mA", BOLD)
  lcd.drawText(80, 30, "Current = ", BOLD);    lcd.drawText(160, 30, amps, BOLD); lcd.drawText(lcd.getLastPos(), 30, "A", BOLD)
  lcd.drawText(80, 40, "Batt drain = ", BOLD); lcd.drawText(160, 40, (amps/(table_cellcapa[i+1]/1000)), BOLD); lcd.drawText(lcd.getLastPos(), 40, "C", BOLD)
  
  
  
  return 0
end -- local function run(event)
return { run = run }

Heisenberg a écrit:...
Tel qu'il est, ça marche bien quand un seul écran de télémétrie est affecté au modèle car les touches + et - ont gardé leur fonction de navigation d'un écran à l'autre.

Il doit exister une instruction à ajouter pour désactiver ça, sinon, c'est top.
...

Oui en ajoutant des killEvents mais ça ne marche plus avec la 2.1 (probablement un bug que tu as trouvé !!!)

Code:

local i, s = 0, 0

--local table_cellcapa = {1800, 2100, 2200, 2600, 3000, 3300, 3600, 4200, 4800, 5000, 5200, 5800, 6000, 8000}
local table_cellcapa = {1800, 2100, 2200, 2600, 3000, 3300}

local function run(event)
  print(event, EVT_PLUS_FIRST, EVT_PLUS_BREAK)
  if event == nil then
    error("Cannot be run as a model script!")
    return 1
  elseif event == EVT_EXIT_BREAK then                                           -- exit script
    s = 0
    return 1
  elseif event == EVT_ENTER_BREAK then
    s = s == 1 and 0 or 1
  elseif event == EVT_PLUS_FIRST then
    if s == 1 then
      i = (i - 1) % #table_cellcapa
      killEvents(EVT_PLUS_FIRST)
      killEvents(EVT_PLUS_BREAK)
    end
  elseif event == EVT_MINUS_FIRST then
    if s == 1 then
      i = (i + 1) % #table_cellcapa
      killEvents(EVT_MINUS_BREAK)
      killEvents(EVT_MINUS_FIRST)
    end
  end
  lcd.clear()

  lcd.drawCombobox(2, 2, 32, table_cellcapa, i, s)

  lcd.drawText(80, 2, i, BOLD)
  lcd.drawText(80, 20, table_cellcapa[i+1], BOLD)
  return 0
end -- local function run(event)
return { run = run }

Hum... Le WIZARD utilise aussi killEvents et se porte bien en 2.1.x
Serait-ce du au fait que ce n'est pas la même famille de scripts ?

EDIT : https://github.com/opentx/opentx/issues/2469
Si je pige bien, ils ne trouvent pas l'idée mauvaise mais c'est resté sans suite...
Peut-être une fonction trop Geek comme la liaison série.

Sacre100 a écrit:En supprimant toutes opérations .. (concaténation), on arrive à résoudre 90% des problèmes.../...
.../...éviter de déclarer des variables dans les fonctions, ça évite bien du travail au garbage collector.
.../...laisser faire OpenTx autant que possible, par exemple les arrondis :

Code:

local n = 0.056
lcd.drawNumber(x, y, n, PREC2)

va être affiché 0.05 par OpenTX.

Si l'on veut arrondir n à l'affichage, il suffit d'écrire ceci :

Code:

local n = 0.051
lcd.drawNumber(x, y, n + 0.005, PREC2)

va être affiché 0.06 par OpenTx, pas besoin de routine d'arrondi, c'est tout ça de gagné.

Par contre si on utilise lcd.drawText pour afficher un nombre, et bien, on doit faire l'arrondi soit même.

NB. on doit utiliser lcd.drawText pour afficher un nombre si l'on veut que 5.0 soit affiché 5 et non 5, 5.0 ou 5.00 en fonction de la précision. C'est aussi nécessaire si l'on a besoin d'afficher plus de 2 décimales.

Essayer de travailler dans l'unité la plus utilisée, par exemple les % : 10% = 0.10
.../...éviter d'avoir la même information dans plusieurs variables
.../...écrire du code concis (p.ex. employer une boucle au lieu d'écrire plusieurs fois la même chose)
      2) éviter un code qui fait des choses inutilement (parfois en contradiction avec 1)
      3) traiter en priorité le cas le plus courant (avec le risque d'avoir le cas le plus rare qui plante)
.../...

Je suis en train de me replonger dans tout le fil pour optimiser au mieux un projet et ce n'est pas si évident.
Rien n'est gravé dans le marbre.

Exemple : Si je veux un arrondi à précision zéro de 100/30, j'utilise math.floor((100/30) + 0.5)
Mais si j'ai besoin d'arrondir 10 chiffres différents, j'utilise ce même calcul dans une fonction que je rappelle.

Bizarrement, d'un script à l'autre, il est préférable de rappeler une fonction ou de recopier plusieurs fois le calcul.
J'imagine que c'est le juste équilibre à trouver entre le GC et la mémoire.

J'ai eu une autre bizarrerie aussi.
Un script qui fonctionnait, et qui une fois nettoyé ne fonctionnait plus.
Quand il fonctionnait, j'avais une fonction déclarée que je n'utilisais pas :

Code:


local function rnd(v,d)
  if d then
    return math.floor((v*10^d)+0.5)/(10^d)
  else
    return math.floor(v+0.5)
  end
end

C'était une erreur de ma part de l'avoir laissée car elle ne me servait à rien.
Quand je l'ai supprimée, mon script ne tournait plus...
J'ai revérifié plusieurs fois et rnd(quelquechose) n'était nulle-part employé dans le script.

Les While et For consomment pas mal aussi on dirait.
Et comme je l'utilisais souvent pour pour du graphique, depuis peu, je ne m'en sort mieux en supprimant tout ce qui crée du graphique statique, comme les échelles et tableaux... Je les mets dans les BMP.

Exemple :
Pour cet écran qui me permet d'adapter la meilleure hélice pour le meilleur rendement / perf, toutes les icônes sont sur 2 1/2 écrans comme sur le script de page de note de Dev.Fred.


J'ai moins d’accès carte que quand j'utilise un fichier par icône comme je le faisais avant et ça me laisse plus de marge d'erreur en matière de consommation tant que le script n'est pas optimisé.

Le firmware 2.1.5 vient de sortir, pas de note concernant le CLI / débug et la liaison série
Par contre on peut lire dans les changements : "Several Lua IO library fixes" Je n'ai pas encore été voir en détail mais à la place d'un écran blanc, on a au moins une info

Sacre100 a écrit:.../...en ajoutant des killEvents mais ça ne marche plus avec la 2.1.../...

On dirait que ça a été entendu
https://github.com/opentx/opentx/pull/3051

J'en ai parlé : https://github.com/opentx/opentx/issues/3041
Mais il y avait déjà un sujet ouvert : https://github.com/opentx/opentx/issues/3041
Mais le fait d'en parler a fait bouger les choses

Un petit peu en avance de phase sur la release 2.1.7 qui est sur le point de sortir : https://github.com/opentx/opentx/releases

Plus besoin de mon outil en 2.1.7, il est en quelque sorte intégré dans la page de simulation de télémétrie qui a été considérablement enrichie    :



Il y a même la possibilité de rejouer un fichier de log de télémétrie ou de reloader un script LUA ce qui évite les manips fastidieuses de recharge de fichier source à chaque modification.

Il y'a du vrai changement par rapport à la 2.1.6
Le reload Lua me plaît bien.

Par contre, toujours pas de gestion des potar à 6 positions. J'espère que ça viendra, car je m'en sert pour mes sécurités moteurs.
Par contre la nouvelle télémétrie est un tuerie !!!! Ils ont, une fois de plus, fait un super boulot.

Salut à tous,
J'ai cherché pas mal d'infos ces derniers temps sur la gestion de la mémoire et sur "l'hygiène" à pratiquer en lua versus OpenTX ... je suis tombé sur votre fil, mais pas uniquement. J'ai repiqué une idée à un certain Ishems qui fraye sur le github concerné. Déjà, et pour avoir testé j'ai pu constater que c'est vrai, il y a des memory leak sur la libération des tables. Depuis, je vérifie toujours ce qu'il vaut mieux utiliser, la libération "naturelle" ou cette petite fonction qui fera le ménage plus proprement, ou plutôt qui permettra au garbagecollector de bien tout collecter.

Code:

function clearTable(t) -- Thank You Mr Ishems !
 if type(t)=="table" then
 for i,v in pairs(t) do
 if type(v) == "table" then clearTable(v) end
 t[i] = nil
 end
 end
 collectgarbage()
end

Ensuite, j'ai été confronté au script "d'a coté" un peu envahissant, et là j'ai encore suivi copain Ishem : le principe est de scinder son script en plusieurs pages (lorsque c'est possible) et d'avoir un "moteur" de pages qui ne pèsera que quelques ko (dans mon cas pratique j'arrive à un peu moins de 7) et qui sera la seule partie du script a demeurer en mémoire quand on s'en va sur l'écran de télémétrie d'a coté. Le principe est tout con en fait et repose sur la capacité des tables à recevoir des fonctions. On a fait bien pire à l'époque du Minitel ...  
L'autre avantage est que quand un script comporte plusieurs pages, une seule est en mémoire, à chaque fois que l'on change, la première sera déchargée de la mémoire, la 2° chargée ... on pourra donc multiplier les pages et même s'économiser des "écrans de télémétrie" en mettant plusieurs scripts sur le même.

Un cas pratique est lorsqu'on a une page principale et des pages annexes de configuration où on va ajuster quelques paramètres. Ishems quant à lui propose carrément un menu ou choisir le script à charger/lancer.

On crée donc un fichier par page, chacun étant structuré ainsi

Code:


-- début du fichier
local tPage={}

tPage.stop = function () -- optionnel pour s'assurer de bien vider les éventuelle tables de la page
  ...
end

tPage.run = function (aEvent)

 if aEvent == EVT_EXIT_BREAK then
 tPage.Stop() -- si on a du ménage à faire avant de partir
 return -1
 end

  ...

end

tPage.init = function () -- optionnel
  ...
end

return tPage
-- fin du fichier

Après on passe au "moteur" qu'on soignera tout particulièrement pour qu'il soit le plus léger possible.
Ce sera un fichier à lui seul, il portera le nom du script à associer à la page de télémétrie.

Quelques variables pour commencer

Code:


local PG_MAIN =1
local PG_1 =2 -- page 1 de mon script
local PG_2 =3 -- page 2 appelée sur la touche menu par exemple

local t_pages = {} -- tableau des pages
local page={} -- page courante
local g_CurrPage = PG_MAIN -- pas de page chargée

p_Tools=nil -- page des routines a partager entre les différentes pages du script


Ensuite, je vais commencer par la fin, je pense que ce sera plus didactique.
Il nous faut une première fonction "pageStop" qui déchargera la page courante, puis une 2° "chargeRun" qui elle commencera par faire un "pageStop" sur la page courante, avant de charger la nouvelle, et l’exécuter pour récupérer le pointeur sur celle-ci

Code:


-- ----------------------------------------------------
local function pageStop()
 page=clearTable(page) -- décharge la page
 gCurrPage = PG_MAIN -- retour sur la page principal
end

-- ----------------------------------------------------
local function pageRun(aEvent,aPageIdx)

 if gCurrPage ~= aPageIdx then -- C'est une autre page

 if page then pageStop() end -- Arrêt de la précédente

 page = loadScript(t_pages[aPageIdx].script)() -- Chargement et récup du pointeur
 if page.init then -- Init prévue ?
 page.init() -- Init !
 page.init = nil -- Init effectué, plus utile, on vire, on soulage
 end

 gCurrPage = aPageIdx
 return page
 end

 if page.run then return page.run(aEvent) end -- ça roule !
 
 return page
end

et on en arrive au "gros" morceau

Code:

local function mainRun(aEvent)
 
 if p_Tools==nil then -- en dehors du moteur rien n'est (encore/plus) chargé

 -- init la table des les modules
 t_pages =
 { [PG_1] ={script="/SCRIPTS/CAFE/p1.lua" },
 [PG_2] ={script="/SCRIPTS/CAFE/p2.lua" },
 [PG_TOOLS] ={script="/SCRIPTS/CAFE/tools.lua" }
 }
 
 p_Tools = pageRun(aEvent,PG_TOOLS) -- charge les routines

 -- fait se charer la page principale
 page = nil
 gCurrPage = PG_MAIN
 end
 
 -- Page annexe de configuraiton des paramètres
 if aEvent==EVT_MENU_BREAK or gCurrPage==PG_CONFIG then
 if pageRun(aEvent,PG_2)==-1 then pageStop() end
 return 0 -- Pas besoin d'exe le reste et puis page config capture [ENT]
 end

 -- Page principale
 if gCurrPage==PG_RACE or gCurrPage==PG_MAIN then
 if pageRun(aEvent,PG_1)==-1 then pageStop() end
 end

 -- Part sur un autre écran de télém
 if aEvent==EVT_PAGE_BREAK and t_pages then
 pageStop() -- décharge la page courrante
 page=p_Tools -- décharge les tools
 p_Tools  = pageStop()
 end
 
 --[[
 if aEvent~=0 then -- pour débug et surveillance mémoire
 collectgarbage()
 print(string.format("mainRun Out : %i",collectgarbage("count")*1024))
 print(string.format("memMax : %i",memMax))
 print("-------------------\n")
 end
 --]]

 return 0

end

return {run=mainRun}

Voilà, il y a certainement des choses qui peuvent être encore améliorées, mais si tant est que cela puisse servir ou donner des idées à qqun, en juste retour pour l'aide indirecte que vous m'avez donnée, et plus particulièrement Sacre100 que je rejoins sur les variables locales et le garbagecollector, mais pas de manière systématique. Perso j'ai tendance à localiser mes variables quand une fonction n'est pas appelée de manière continuelle par le run. Mais toujours un max de test pour voir les effets sur la mémoire, on est tellement à l'étroit !!

Bref, c'est de la dentelle la prog lua sous OpenTX  

Encore une chose, il y a plusieurs moyens de charger le script, Ishems utilise "dofile" mais je n'ai pas compris pourquoi, une fois les lua compilés, je ne parvenais pas a récupérer le pointeur sur la page. J'utilise donc "loadScript()()" et ça passe. De plus avec l'option du firmware "luac" activée, les fichiers annexes sont bien compilés par la radio ce qui n'était pas le cas avec "dofile". (Open TX 2.2)
Pour info, en compilé, de 28Ko, je suis descendu à 20Ko sur une de mes pages, c'est pas rien dans not'monde .

Woaw, chapeau !
Didactique, clair, concis...
Cela donne envie de s'y mettre...

Coyotte