LUA Scripting sur V2.1.x

Il y a peut être un moyen simple d’instrumenter un script LUA sur la Taranis en utilisant la fonction playtone qui envoi des pulses audio que l'on pourrait lire avec un scope connecté sur le jack audio à travers une résistance de charge (30-100 ohms).
On pourrait mesurer une boucle ou faire des marqueurs en utilisant des fréquences différentes pour tracer un script qui plante.



Le problème c'est que je plante mon script LUA dans Companion en essayant ça : playtone (1000,1,0,PLAY_NOW,0)  (et plein d'autres variantes)

P.S: Je n'ai pas de Taranis sous la main pour tester l'idée, je suis en plein déménagement.

Sinon la doc LUA en cours d'écriture par dsbeach vient d'être mise à jour ici, elle est prometteuse

Il faut que "pause" soit > que 0 : playTone (1000,1,1,PLAY_NOW,0)

Super,
merci pour ton aide, je n'étais plus très loin (j'avais aussi essayé avec pause <>0 mais avec un autre paramétrage autour qui plantait aussi ce qui fait que je tournais en rond)   .
Quand j'aurais fini mon déménagement, je mettrais un scope pour voir si c'est utilisable.

Ce qui serait surtout bien, c'est qu'on puisse avoir une option CLI qui renvoie les infos debug comme dans companion lorsqu'on télécharge une compil du firmware pour pouvoir logguer directement via la prise USB.
https://github.com/opentx/opentx/issues/2595

Chez moi, rien ne sort

J'ai pas essayé la liaison série et pour le moment je suis en plein déménagement.

J'ai essayé de mesurer les perfs de ton code en utilisant getTime

Code:

T0=tonumber (getTime())
.
code à chronométrer
.
T1=tonumber (getTime())
.
.lcd.drawNumber (lcd.getLastPos()-1,46, T1-T0, LEFT + SMLSIZE)

Le pb c'est que le nombre de tick de 10 ms  mesuré = 0, la résolution n'est pas suffisante.

C'est pourquoi j'ai pensé mettre un scope pour faire une mesure plus fine en utilisant un pulse généré sur le HP.

J'aime bien les moyens détournés pour arriver à ses fins.
Mais ça rendrait quand-même service à plus d'un si cette liaison série / debug pouvait fonctionner.

Je n'ai pas l'habitude de Github et ne suis pas suffisamment de près les évolutions pour pouvoir laisser une proposition percutante sans être sur que ça n'a pas déjà été abordé. Si un jour tu essaies, ça me plairait d'avoir ton retour.

Sur la prise série dédiée, on peut logguer la télémétrie mais pas d'info de débogage.

Heisenberg a écrit:Ce qui serait surtout bien, c'est qu'on puisse avoir une option CLI qui renvoie les infos debug comme dans companion lorsqu'on télécharge une compil du firmware pour pouvoir logguer directement via la prise USB.
https://github.com/opentx/opentx/issues/2595

Chez moi, rien ne sort  

Tu devrais réessayer de downloader le firmware, il me semble qu'ils ont apporté des modifications aujourd'hui (si je ne me trompe pas, il faut effacer le firmware précédemment downloadé avec l'option cli, sinon tu n'auras pas la mise à jour).

Héhééé, je n'ai pas la radio sous la main mais je viens de faire une comparaison binaire de ce firm avec l'ancien (mêmes options de compilation, seule la date n'est pas la même), et il y'a des différences.

Il changent des choses sans changer le numéro de version, c'est vicieux ça !

Je ferais un feedback demain en essayant sur la radio, si ça marche, ce sera pour moi une grosse avancée.

Edit : L'un fait 362 576, l'autre 366 888 octets

Heisenberg a écrit:... Il changent des choses sans changer le numéro de version, c'est vicieux ça ! ...

Oui et non, en fait, j'ai découvert dernièrement que les firmware sont compilés à la demande au moment du transfert. Il y avait une erreur dans les options de compilation pour l'option CLI, elle a été corrigée dans l'automate de compilation mais les sources n'ont pas changé semble-t-il. C'est pourquoi, je réponds oui et non, c'est quand même un cas très particulier.

Voilà, le souci était simplement que quand tu choisissais l'option cli le firmware était en fait quand même compilé sans. Les sources sont identiques.

Ok, si ce n'est que ça...

Ça se précise : J'ai de l'écho !
J'arrive à communiquer avec la radio, pour l'instant on ne se comprend pas vraiment car à part répéter bêtement ce que je lui dis, elle ne veut pas m'informer de rien.

trace on : elle a l'air d'aimer car elle ne me le renvoie pas.
help : elle me demande des params supplémentaires

Donc, pas de debug automatique de débogage comme avec companion pour l'instant.
Il doit y-avoir quelques ordres à connaître pour les lui envoyer.

En bonus, avec ce firmware, en page 8 des réglages radio, l'option "Debug" est maintenant proposée pour le port série, ça pourrait donc fonctionner par là si je ne parviens pas à lancer le debug par le port USB

Les commandes disponibles ont l'air d'être celles-ci :

Code:

- beep [<frequency>] [<duration>]
- ls <directory>
- play <filename>
- print <address> [<size>] | <what>
- stackinfo <tid>
- trace on | off
- volume <level>
- help <command>


Si tu tapes "help print", il devrait te renvoyer

Code:

print <address> [<size>] | <what>

enfin si ça marche.

On voit quand même que "help" aurait dû te renvoyer quelque chose de semblable à ce que j'ai listé ci-dessus mais que ce n'est pas le cas.

Essaie aussi la commande "beep", tu verras tout de suite si ça, ça fonctionne.

Ce que tu peux essayer, c'est de voir si un print dans un script LUA est renvoyé sur la console lorsque tu es en "trace on", ça permettrait de bien débugger les script directement sur la radio quand on ne s'en sort pas avec le simulateur.

Si jamais, le source qui s'occupe de ça est là : https://github.com/opentx/opentx/blob/master/radio/src/cli.cpp

beep et volume ça fonctionne.
j'ai bien dans le 1er cas un beep, et dans le second, j'entends un léger claquement dans le HP. Donc, c'est tout bon mis à part help qui ne renvoie pas exactement ce que tu envisageais.



Je vais me plonger dans la commande print/Lua que je n'ai jamais utilisée pour faire un test.

Je suis aussi curieux de voir ce qui sort de la prise série en mode debug, je pense me faire l'interface dans la semaine. Si par défaut, ça sort tout ce que la radio fait sans avoir à y envoyer de commande, je logerais dans la radio un OpenLog.

Si un jour il m'arrive un truc incompréhensible comme un reboot par le watchdog ou un autre pépin comme sur ce sujet, alors j'aurais une trace de ce qui a bien pu se produire. Ça ouvre pas mal de possibilité si tout se passe comme prévu.

Print dans LUA envoie simplement les chose sur stdout :
- une chaine -> la chaine
- un nombre -> le nombre
- une table -> l'adresse de la table
- un boolean -> true ou false
- une fonction -> l'adresse de la fonction
- etc...

Tu peux printer plusieurs valeurs, dans ce cas elle sont séparées par des tabs.

C'est très basique mais utile.

Je mets ça de côté pour dans la semaine.
Par contre, je n'ai pas pu attendre pour le port série qui en théorie devrait m'afficher tout ce que fait la radio, y compris les erreurs Lua.

Le problème, c'est que ça reste désespérément muet
TX -> RX
RX -> TX
GND -> GND



Vu la copie écran ci-dessous, faut-il que je fasse un élévateur de signal ?

Tu sembles utiliser un convertisseur usb->série à niveaux TTL, pas RS-232, et les niveaux sont donc inversés.

J'y réfléchissais justement.
Avec cette petite astuce, ça le fera ?

Ca devrait, oui.

Je viens d'essayer avec le RX & TX inversés.
C'est pas encore ça mais il y-a du mieux.
Ne souhaitant que recevoir de la radio sans rien lui envoyer, je n'ai pas fait le montage de la diode.

Debug 115200 ne donne rien
Écolage 115200 ne donne rien
Télémétrie 9600 ne donne rien (Radio non reliée à un RX sous tension)
Recopie S-Port 57600 ne donne rien mais illumine les 2 leds ERR et BREAK


Ma config (Le port est le bon) :

Attention quand j'ai dit oui il ne s'agit évidemment que pour la partie où il s'agit de configurer "inverser RXD" et "inverser TXD" dans le FTDI. Le reste concerne la connection à un smart port, ce qui n'est pas le cas ici, on a un port série tout simple avec TX et RX séparés.

J'avais bien compris Kilrah.
J'ai peut-être une config de parité et autre à trouver.

Hmm en fait une discussion sur github suggère que le debug sur port série ne fonctionnerait pas sur 2.1.3.

J'ai l'impression quand une c..lle disparait, 2 nouvelles surviennent !

Je vais tenter un log de télémétrie avec un RX allumé, ça me donnera une idée si mon montage est bon.

Heisenberg a écrit:J'ai l'impression quand une c..lle disparait, 2 nouvelles surviennent !

Le bug sur le port série n'a rien à voir et a en fait été corrigé il y a 19 jours... https://github.com/opentx/opentx/commit/637d20a66d82d7be39c482c02b3981599e2122df

Il reste un problème avec le firm compilé avec option CLI, même si on oublie le debug.

En remettant le firm sans cette option, je logue bien la réplication S-Port.

Mais avec la même procédure avec l'option CLI, l'écran reste blanc.
C'est un peu à tâtons tout ceci, je ne sais jamais si c'est le firmware qui pose problème ou si c'est une erreur de ma part mais là, je sais  
On va devoir attendre après une V2.1.4 pour ça je crois...
Et pourvu que les infos debug ne soient pas en hexa. si un jour j'arrive à les avoir.