LUA Scripting sur V2.1.x

Heisenberg a écrit:... Dans un autre langage de prog, ce serait cellValue[1], cellValue[2] etc... mais pas en Lua. ...

Si, si, c'est bien la syntaxe LUA pour ça.

Heisenberg a écrit:... [Edit] pour connaître le nombre d'élément, je viens de réagir que je l'ai sous les yeux, c'est tout simplement "i" une fois sorti de ce bout de code. ...[/Edit]

Ou encore plus simple #cellResult qui te donne le nombre d'élément de la table cellResult.

Pour ta série de test, tu dois pouvoir la remplacer par assert(loadstring(...))
Par ailleurs, fait attention a déclarer tes variables locales (excepté lorsque tu veux artager tes variables entre plusieurs scripts.
Au final, j'écrirais un code comme ceci, plus concis mais peut-être pas plus rapide.

Code:

local batt_sum, batttype = 0, 0
local cellValue = "telemetry not available"
local cell01, cell02, cell03, cell04, cell05, cell06 = 0, 0, 0, 0, 0 ,0
local cellResult = getValue("Cels")
if type(cellResult) == "table" then
  cellValue = ""
  batttype = #cellResult
  for i, v in pairs(cellResult) do
    cellValue = cellValue .. i .. ": " .. v .. " "
    batt_sum = batt_sum + v
    assert(loadstring("cell0" .. i .. " = v"))
  end
end


J'avais bien déclaré mes variables mais ne les avais pas recopiées dans mon message, je le fais tout le temps sur tes conseils d'il y-a quelques semaines, ça m'évite des erreurs intempestives. 1000 merci pour ton bout de code.

Je ne savais même pas qu'on pouvait déclarer les variables à la chaine comme dans ton exemple ci-dessus d'ailleurs.
A chaque message échangé j'avance et je t'avoue que je m'éclate avec le Lua  

Assert, je ne connaissais pas non-plus, j'ai trouvé quelques lignes relatant de cette fonction mais pas très documentées. Ceci dit, je comprends parfaitement ce qu'assert(loadstring("cell0" .. i .. " = v")) est censé faire dans une boucle for.
Ça condense sérieusement le code, c'est bien plus lisible aussi.

J'ai bien déclaré local cell01, cell02, cell03, cell04, cell05, cell06 = 0, 0, 0, 0, 0 ,0 mais j'ai quand-même un retour d'erreur comme si ces variables n'existaient pas : attempt to call global 'loadstring' (a nil value)

[Edit] loadstring ne semble plus être d'actu. A la place, la fonction load devrait faire l'affaire et je n'ai plus d'erreur avec load mais mes cellules restent à zéro. [/Edit]

Heisenberg a écrit:...A chaque message échangé j'avance et je t'avoue que je m'éclate avec le Lua   ...

C'est vrai qe c'est un langage sympa, il est concis, rapide et peut tourner sur des environnements très léger avec peu de mémoire et peu de puissance. La bible LUA est ici : http://www.lua.org/manual/5.2/

Heisenberg a écrit:... J'ai bien déclaré local cell01, cell02, cell03, cell04, cell05, cell06 = 0, 0, 0, 0, 0 ,0 mais j'ai quand-même un retour d'erreur comme si ces variables n'existaient pas : attempt to call global 'loadstring' (a nil value)

De ce que j'ai compris, loadstring n'a pas à être déclaré en tant que variable (?)

En fait, c'est "load" qu'il faut utiliser, "loadstring" n'est là que pour assurer la compatibilité avec d'ancienne version et ce n'est pas mis en oeuvre dans OpenTx, je ne savais pas, je n'avais pas testé.

Load est un peu contraignant pour deux raisons :
- il retourne une fonction qu'il faut executer
- son environnement d'exécution et l'environnement global

Pour que ça marche, il faudrait :
- que cell01, ... , cell06 soient globales
- transmettre i et v à la fonction créée par load et les récupérer dans la chaine

Il faudrait écrire le code ainsi, c'est concis mais ce n'est pas ce qu'il y a de plus simple :

Code:

local batt_sum, batttype = 0, 0
local cellValue = "telemetry not available"
cell01, cell02, cell03, cell04, cell05, cell06 = 0, 0, 0, 0, 0 ,0  -->> variable globale (pas bon)
local cellResult = getValue("Cels")
if type(cellResult) == "table" then
  cellValue = ""
  batttype = #cellResult
  for i, v in pairs(cellResult) do
    cellValue = cellValue .. i .. ": " .. v .. " "
    batt_sum = batt_sum + v
    load("i, v = ...; cell0" .. i .. " =  v")(i, v)  -->> i, v = ... récupère les deux paramètres passés à la fonction (ça fallait le savoir)
  end
end

Tu auras noté que l'on peut mettre plusieurs instructions sur une ligne mais il faut les séparer par un ;

Le plus simple quand même, c'est d'avoir une table au lieu de ces 6 variables et d'utiliser les éléments de la table par ailleurs.

Code:

local batt_sum, batttype = 0, 0
local cellValue = "telemetry not available"
local cells = {0, 0, 0, 0, 0 ,0} -->> table de 6 éléments initialisé à 0
local cellResult = getValue("Cels")
if type(cellResult) == "table" then
  cellValue = ""
  for i = 1, #cells do cells[i] = 0 end -->> on reinitialise les 6 élément à 0
  batttype = #cellResult
  for i, v in pairs(cellResult) do
    cellValue = cellValue .. i .. ": " .. v .. " "
    batt_sum = batt_sum + v
    cells[i] = v --> on renseigne l'élément correspondant
  end
end

Heisenberg a écrit:... tu approcherais la perfection si tu pouvais ajouter encore 4 à 6 cellules de plus de batteries pour couvrir 95% des besoins du modelisme ...

J'ai bataillé avec VC++ 2015 et le net un certain temps avant de trouver comment envoyer dans un tableaux des valeurs de cellules séparées par des ";" depuis un champ retourné par Form.
Cette ligne de C++ à la sauce Microsoft Windows Forms applications est un vrai petit trophée personnel, spécialement le type de la variable split avec l'opérateur carret (ou hat) [^] pour définir un handle vers un objet managé qui est en fait une référence vers cet objet managé.  handle:



L'outil peut maintenant gérer jusqu'à 6 cellules, dans l'exemple j'ai saisi : 1,1;2,2;3,3;4,4;5,5;6,6

Code:

local cellValue = "unknown"
local cellResult = nil
local cellID = nil

local function getTelemetryId(name)
    field = getFieldInfo(name)
    if field then
      return field.id
    else
      return -1
    end
end

local function init()
  cellId = getTelemetryId("Cels")
end

local function background()
  cellResult = getValue(cellId)
  if (type(cellResult) == "table") then
    cellValue = ""
    for i, v in ipairs(cellResult) do
      cellValue = cellValue .. i .. ": " .. v .. " "
    end
  else
    cellValue = "telemetry not available"
  end
end

local function run(e)
  lcd.clear()
  lcd.drawText(1,11,"Cels:", 0)
  lcd.drawText(lcd.getLastPos()+2,11,cellValue,0)
end

return{init=init,run=run,background=background}

Edit a écrit:Compilation sous MVS2010 pour assurer la compatibilité avec Windows 7

De mon côté, après avoir réinstallé l'environnement sur nouveau portable (l'ancien m'a laché), j'ai développé hier soir un fonction lcd.drawEllipse pour OpenTX. J'ai piqué un algorithme sur net, j'y comprends rien mais ça marche.

Et depuis tout à l'heure, j'ai ajouté la fonction drawFilledEllipse.



S'il y en a qui veulent tester, voici le code à ajouter dans lua_api.cpp. Tout d'abord les deux fonctions à mettre entre luaLcdDrawFilledRectangle et luaLcdDrawGauge par exemple:

Code:


static int luaLcdDrawEllipse(lua_State *L)
{
  if (!luaLcdAllowed) return 0;
  int xc = luaL_checkinteger(L, 1);
  int yc = luaL_checkinteger(L, 2);
  int width = luaL_checkinteger(L, 3);
  int height = luaL_checkinteger(L, 4);
  unsigned int flags = luaL_optunsigned(L, 5, 0);

/* Bresenham's procedure to draw an ellipse in two steps */
  int a2 = width * width;
  int b2 = height * height;
  int fa2 = 4 * a2, fb2 = 4 * b2;
  int x, y, sigma;

/* Plot more horizontal part */
  for (x = 0, y = height, sigma = 2*b2+a2*(1-2*height); b2*x <= a2*y; x++)
  {
    lcd_plot (xc + x, yc + y, flags);
    lcd_plot (xc + x, yc - y, flags);
    if (x > 0)
    {
      lcd_plot (xc - x, yc - y, flags);
      lcd_plot (xc - x, yc + y, flags);
    }
    if (sigma >= 0)
    {
      sigma += fa2 * (1 - y);
      y--;
    }
    sigma += b2 * ((4 * x) + 6);
  }

/* Plot more vertical part */
  for (x = width, y = 0, sigma = 2*a2+b2*(1-2*width); a2*y < b2*x; y++)
  {
    lcd_plot (xc + x, yc + y, flags);
    lcd_plot (xc - x, yc + y, flags);
    if (y > 0)
    {
      lcd_plot (xc + x, yc - y, flags);
      lcd_plot (xc - x, yc - y, flags);
    }
    if (sigma >= 0)
    {
      sigma += fb2 * (1 - x);
      x--;
    }
    sigma += a2 * ((4 * y) + 6);
  }

  return 0;
}

static int luaLcdDrawFilledEllipse(lua_State *L)
{
  if (!luaLcdAllowed) return 0;
  int xc = luaL_checkinteger(L, 1);
  int yc = luaL_checkinteger(L, 2);
  int width = luaL_checkinteger(L, 3);
  int height = luaL_checkinteger(L, 4);
  unsigned int flags = luaL_optunsigned(L, 5, 0);

/* Bresenham's procedure to draw an ellipse in two steps */
  int a2 = width * width;
  int b2 = height * height;
  int fa2 = 4 * a2, fb2 = 4 * b2;
  int x, y, sigma;

/* Plot more horizontal part */
  for (x = 0, y = height, sigma = 2*b2+a2*(1-2*height); b2*x <= a2*y; x++)
  {
    if (sigma >= 0)
    {
      lcd_line(xc - x, yc - y, xc + x, yc - y, SOLID, flags);
      lcd_line(xc - x, yc + y, xc + x, yc + y, SOLID, flags);
      sigma += fa2 * (1 - y);
      y--;
    }
    sigma += b2 * ((4 * x) + 6);
  }

/* Plot more vertical part */
  for (x = width, y = 0, sigma = 2*a2+b2*(1-2*width); a2*y < b2*x; y++)
  {
    lcd_line(xc - x, yc - y, xc + x, yc - y, SOLID, flags);
    if (y > 0)
      lcd_line(xc - x, yc + y, xc + x, yc + y, SOLID, flags);
    if (sigma >= 0)
    {
      sigma += fb2 * (1 - x);
      x--;
    }
    sigma += a2 * ((4 * y) + 6);
  }

  return 0;
}


Et l'ajout des deux fonctions dans celle disponible pour LUA :

Code:

 { "drawFilledRectangle", luaLcdDrawFilledRectangle },
  { "drawEllipse", luaLcdDrawEllipse },
  { "drawFilledEllipse", luaLcdDrawFilledEllipse },
  { "drawGauge", luaLcdDrawGauge },


dev.fred a écrit:J'ai bataillé avec VC++ 2015 et le net un certain temps avant de trouver comment envoyer dans un tableaux des valeurs de cellules séparées par des ";" depuis un champ retourné par Form.

J'attendais ça avec impatience sans être sur que tu t'y colles
...Mais il ne tourne pas sur ma machine Win7 64bits, y compris en mode admin et/ou en mode de compatibilité

Je me suis attelé pour ma part à un script simple, moins compliqué que vos travaux (Et sans aucun BMP !)
J'allais le mettre en partage sauf qu'il rend très bien sous Companion et refuse de tourner sur la radio.

Il va vraiment falloir que je bricole une interface pour logguer la liaison série de la radio ...

Sinon, c'était beau et bien pratique aussi...

Probablement ton script utilise trop la mémoire, il n'y en a pas beaucoup de disponible sur la radio, et aussi surcharge trop le garbage collector. Quelques trucs :
- éviter l'opérateur .. (contaténation de chaine de caractère qui utilise pas mal de mémoire et qui surcharge le garbage collectore)
- éviter trop de variables dans les fonctions (surcharge aussi le garbage collector)

Publie ton script, je vais y jeter un coup d'oeil et si je vois quelque chose, je t'indiquerai ce qu'il est possible de faire.

L'opérateur .. est plutôt fort utilisé dans ce script, je vais changer ça déjà...

Heisenberg a écrit:...Mais il ne tourne pas sur ma machine Win7 64bits, y compris en mode admin et/ou en mode de compatibilité

C'est ballot, j'ai recompilé sous MVS2010 et testé sous W7 et là ça fonctionne.

Je me suis laissé endormir par le marketing, j'ai un peu oublié la dépendance des .exe avec l'OS :

Microsoft a écrit:Visual Studio 2015 est un environnement de développement intégré riche pour créer des applications époustouflantes pour Windows, Android et iOS, ainsi que des applications Web et des services de cloud modernes.

Edit a écrit:En fait il faudrait installer Redistribuable Visual C++ pour Visual Studio 2015; c'est un peu lourd .

Bien pratique ton outil, merci

J'allais le dire, c'est complet à présent.
Du très bon boulot et simple comme bonjour à utiliser.
Merci.

Ravi que cela vous plaise, de mon coté c'était l'occasion d'utiliser cet environnement de programmation en ayant un petit projet utile, c'est bien + motivant.

Sinon, même si ce n'est pas encore au point, je serais intéressé par le code que tu as développé pour LI-PO BattCheck, ton écran est prometteur.

A 1ere vue, il fonctionne, mais l'auteur est plus Marco que moi-même à présent, j'ai bénéficié honteusement de son aide précieuse en loose-day et il m'a donné un peu plus que quelques pistes.

Je compte regarder encore 2 ou 3 choses et le mettre en partage dans la semaine avec un tuto ad'hoc.

Effectivement ma phrase est un peu maladroite étant donné la contribution de Marco qui en connait un rayon sur LUA en autre .
A ma décharge, j'ai déjà partagé mon admiration pour son savoir faire en programmation C++ sur le projet OpenTX Multilingue.

Sinon, j'ai trouvé une option dans Visual Studio 2015 qui permet de lui faire générer du code 2010 donc compatible W7.



L’intérêt c'est que Visual Studio 2015 est un outil complet qui est gratuit pour les particuliers alors qu’auparavant, seule la version express était gratuite.
J'ai pu également compiler directement le projet openTX avec Visual Studio 2015 qui s'est mis automatiquement en mode de compatibilité VS2010.

En tout cas, c'est ton outil qui m'a permit de faire pas mal de choses.

Petite question :
J'ai 2 scripts qui refusent de tourner en même temps, si je les associe tout les 2 à un modèle, l'un des 2 scripts plante.

Alors, lorsqu'un modèle est associé à 2 scripts télémétriques (sur ecran1 et écran2 par exemple)
Si le script1.lua utilise une variable locale mavariable = 10
Et que le script2.lua utilise une variable avec le même nom mavariable sans la déclarer au départ dans le script2.lua, celle-ci peut-elle être récupérée par l'autre script ?

Je crois avoir compris que oui dans les scripts modèle mais quid des scripts télémétriques ??

Si c'est le cas, ça me permettrait d'alléger considérablement le script2.lua qui utilise des routines identiques au script1.lua.

Heisenberg a écrit:...
Petite question :
J'ai 2 scripts qui refusent de tourner en même temps, si je les associe tout les 2 à un modèle, l'un des 2 scripts plante.

Alors, lorsqu'un modèle est associé à 2 scripts télémétriques (sur ecran1 et écran2 par exemple)
Si le script1.lua utilise une variable locale mavariable = 10
Et que le script2.lua utilise une variable avec le même nom mavariable sans la déclarer au départ dans le script2.lua, celle-ci peut-elle être récupérée par l'autre script ?

Je crois avoir compris que oui dans les scripts modèle mais quid des scripts télémétriques ??

Si c'est le cas, ça me permettrait d'alléger considérablement le script2.lua qui utilise des routines identiques au script1.lua.

Oui bien sûr mais il ne faut pas la déclarer "local" ainsi elle est globale pour tous les scripts qui tourne dans l'environnement LUA.

[EDIT]Pour la portée des variables, relis peut-être ce que j'avais écrit là : https://frskytaranis.forumactif.org/t2666p60-lua-scripting-sur-v2-1-x#31872 [/EDIT

J'ai placé en partage le script de testeur de batterie ici : [Script de testeur de batterie LUA]
Je préfère garder ce fil ici plus propice aux questions / réponses généralistes sur le Lua sinon, ça risque de partir dans tout les sens.



Ça devrait servir à pas mal d'entre nous.

Un boulot qui n'aurait jamais vu le jour sans ce fil de discussion, pourvu que d'autres choses en sortent encore.

En programmation, plus on est concis, plus c'est facile de mettre au point le code et plus c'est facile de le maintenir pour autant qu'il lisible.

Un truc que j'utilise souvent c'est l'équivalent LUA de l'opérateur ?: en C :

Code:

<test> and <valeur si vrai> or <valeur si faux>

Ainsi ces lignes :

Code:

 if cellsum > 10 then
   lcd.drawNumber(lcd.getLastPos() - 1, 24, cellsum, PREC1 + LEFT + SMLSIZE)
 else
   lcd.drawNumber(lcd.getLastPos() - 1, 24, cellsum, PREC2 + LEFT + SMLSIZE)
 end

Peuvent s'écrire en une seule :

Code:

lcd.drawNumber(lcd.getLastPos() - 1, 24, cellsum, cellsum > 10 and PREC1 or PREC1) + LEFT + SMLSIZE)

Ca reste assez lisible et si tu as quelque chose à changer, tu ne le fais qu'une fois, c'est tout ça de gagné.

Sacre100 a écrit:.../...Peuvent s'écrire en une seule :

Code:

lcd.drawNumber(lcd.getLastPos() - 1, 24, cellsum, cellsum > 10 and PREC1 or PREC1) + LEFT + SMLSIZE)

Ca reste assez lisible et si tu as quelque chose à changer, tu ne le fais qu'une fois, c'est tout ça de gagné.

Je comprends, j'ai essayé de reprendre le même système pour autre chose que pour un argument d'affichage (PRECx ou BLINK etc...), ce n'est pas si évident mais ça va venir.

dev.fred a écrit:La présentation est très chouette, mais malheureusement la courbe de décharge, et donc le % de charge restante d'une Lipo, n'est pas linéaire; tu approcherais la perfection en passant par une table. .../...

Je sais pour le moment, ce n'est qu'une indication plutôt qu'un réel pourcentage.
J'ai fait une extrapolation douce pour obtenir une table de 0 à 100% sur Excel.
Ça devrait ressembler à quelque-chose comme ça dans le début du script :
local tableofpercent = {3.000, 3.053, 3.113, 3.174, 3.237, 3.300, 3.364, 3.427, 3.488, 3.547, 3.600, 3.621, 3.637, 3.649, 3.659, 3.668, 3.676, 3.683, 3.689, 3.695, 3.700, 3.706, 3.712, 3.717, 3.723, 3.728, 3.732, 3.737, 3.741, 3.746, 3.750, 3.754, 3.759, 3.763, 3.767, 3.771, 3.775, 3.779, 3.782, 3.786, 3.790, 3.794, 3.798, 3.802, 3.806, 3.810, 3.814, 3.818, 3.822, 3.826, 3.830, 3.834, 3.838, 3.842, 3.846, 3.850, 3.854, 3.858, 3.862, 3.866, 3.870, 3.875, 3.880, 3.885, 3.890, 3.895, 3.900, 3.905, 3.910, 3.915, 3.920, 3.924, 3.929, 3.933, 3.938, 3.942, 3.947, 3.952, 3.958, 3.963, 3.970, 3.982, 3.994, 4.007, 4.020, 4.033, 4.047, 4.060, 4.074, 4.087, 4.100, 4.111, 4.122, 4.132, 4.143, 4.153, 4.163, 4.173, 4.182, 4.191, 4.200}

Il faut que je me documente sur l'équivalence d'un lookup en langage Lua et arriver à faire un truc pas trop lourd en travaillant à 3 décimales et en tenant compte des valeurs qui n'existent pas comme 3.02V par exemple.

Je n'avais pas vu ta réponse.
J'ai ajouté une table à ton script dans ta nouvelle page  [LUA / DOWNLOAD] Un testeur de batterie sur la radio. J'aurai peut-être dû continuer sur ce post pour ne pas la polluer.

Que nenni, ça concerne ce script, alors...

Pas très facile de faire tourner un script qui va bien sur Companion mais qui plante sur la radio...

Sacre100 dans un autre fil a écrit:N'oubliez pas quand même que nos radios n'ont pas des processeurs dual-core qui tourne à plusieurs Ghz, tout comme elles n'ont pas plusieurs Giga de mémoires, alors on peut se retrouver rapidement avec des scripts qui tournent très bien dans le simulateur mais plus du tout sur la radio.../...

J'en sais quelque-chose et c'est ce qui me prend le plus de temps.

Pour comparer différentes méthodes et choisir celle qui est la moins gourmande, il existe collectgarbage, y'a t'il d'autres trucs à connaître permettant d'avoir ce genre d'indication pour avoir une idée de la charge du processeur, de la mémoire etc... ?

C'est dommage qu'il n'y ai pas une instruction LUA qui permette d'envoyer un pulse sur le jack d’écolage de la Taranis, il suffirait de bancher un scope pour avoir une idée du temps de cycle d'un script. Et encore + fort, un nombre de pulses programmable de 1 à 9 par exemple pour pouvoir tracer un programme qui plante.

Je crois déjà qu'en supprimant toutes opérations .. (concaténation), on arrive à résoudre 90% des problèmes. C'était ce qui faisait que le script d'affichage de la tension ne fonctionnait pas sur la radio.

Ensuite, si cela ne suffit pas, éviter de déclarer des variables dans les fonctions, ça évite bien du travail au garbage collector.

On peut aussi 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
- parfois c'est mieux de faire quelques multiplications pour l'affichage que de faire plein de division par 100 dans les calculs, parfois c'est le contraire.
- pour trouver ce genre de chose, on essaie de les repérer visuellement puis on fait des recherches pour se faire une idée de ce qui serait le mieux

Autant que possible, éviter d'avoir la même information dans plusieurs variables :
- on les trouve assez facilement surtout lorsqu'une constante est assignée à plusieurs variables, il suffit de faire des recherches sur les constantes, puis sur les variables les contenant.

Finalement, quelque bonnes pratiques qui ne sont pas spécifiques à LUA :
1) é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)

Et surtout mais ce n'est pas votre cas, éviter certains styles de programmation qui font beau dans le paysage (par exemple, une programmation orientée objet sur des script tellement petits que cela n'en vaut généralement pas la peine).

La grosse différence entre un langage de script comme LUA ou un langage compilé comme le C, c'est que les compilateurs savent optimiser l'objet généré ce qui n'est pas du tout le cas avec un langage de script.

Avec LUA, on doit tout faire soit même alors qu'un compilateur saura détecter par exemple les instructions inutiles ou en fonction des directives qu'on lui donne, saura minimiser l'éspace mémoire utilisé au détriment de la vitesse ou au contraire, optimiser la vitesse d'exécution, ce pour autant qu'on le laisse le faire, ce qui n'est pas toujours le cas selon la manière de programmer (par exemple, le cas de la division par 2)