Debugging an app real-time, on the transmitter - almost there
- abief
- Offline Autor
- Premium Mitglied
- I'm here, there and elsewhere!
- Beiträge: 95
- Dank erhalten: 19
Debugging an app real-time, on the transmitter - almost there wurde erstellt von abief
Posted 10 Mai 2020 20:37 #1only to let you know that I'm writing a small library, to be installed on the radio during LUA development, with the ability to generate a log file on the SD card and, now, using the telemetry screens to be able to watch internal variables and conditions of the code.
during LUA development, the library will need to be required within your code, and some calls to the log system are needed to properly work, but it should be useful to debug our LUAs.
Keep tuned for the library and explanations on what needs to be done.
Field ready: Taborca (3.4m), Ocelot (1.6m), Alula (0.6m).
Factory line: FVT-3 (1m), A6M Zero (1.6m), Tiger Moth (2.2m), Grumann Goose (2m) and Beechcraft D18 (1.5m).
Design phase: Szd-20x Wampir II (7.5m), Rutan Quickie (1.6m), both parked.
Dreaming: Weird push-pull called Double Trouble (2.4m)
Factory line: FVT-3 (1m), A6M Zero (1.6m), Tiger Moth (2.2m), Grumann Goose (2m) and Beechcraft D18 (1.5m).
Design phase: Szd-20x Wampir II (7.5m), Rutan Quickie (1.6m), both parked.
Dreaming: Weird push-pull called Double Trouble (2.4m)
von abief
Folgende Benutzer bedankten sich: NicoS, Thorn, FuniCapi
Bitte Anmelden oder Registrieren um der Konversation beizutreten.
- abief
- Offline Autor
- Premium Mitglied
- I'm here, there and elsewhere!
- Beiträge: 95
- Dank erhalten: 19
abief antwortete auf Debugging an app real-time, on the transmitter - almost there
Posted 11 Mai 2020 14:38 #2
Hello,
here you have my logger library,
please find, within the zip file, the logger, a sample app containing the documentation, and a working example of a log
the logger helps the coder to determine what's happening with your code, on the transmitter.
It works by providing the coder with two entry points:
log() --> this is the main function to be used in your code, with a list of parameters that will drive the log actions
events --> this is the list of supported events; these are:
configure --> used to configure, should be used at the very first lines of the code.
configureTelemetry --> this is a special configuration for the variable watches. It can only be used within the "init" function or afterwards. It's meant to be used after the log activation.
activate --> used to activate the logger. This is done in order to quickly activate or deactivate the logger, without the need to replace all the log lines.
key --> this is a special event, used to log a key event.
open and close --> these two events are to log when a function starts or stops, or when a specific event needs to be grouped.
any other events are logged but no special action is available.
the location of the log file is determined during configuration and is stored in a subfolder called Debug
the log file structure is XML-like, and if you process the log file with an XML beautifier, you should be able to see the nested calls.
the logger and this sample are provided WITHOUT WARRANTY, and on a best effort base. No responsibility is derived.
here you have my logger library,
please find, within the zip file, the logger, a sample app containing the documentation, and a working example of a log
the logger helps the coder to determine what's happening with your code, on the transmitter.
It works by providing the coder with two entry points:
log() --> this is the main function to be used in your code, with a list of parameters that will drive the log actions
events --> this is the list of supported events; these are:
configure --> used to configure, should be used at the very first lines of the code.
configureTelemetry --> this is a special configuration for the variable watches. It can only be used within the "init" function or afterwards. It's meant to be used after the log activation.
activate --> used to activate the logger. This is done in order to quickly activate or deactivate the logger, without the need to replace all the log lines.
key --> this is a special event, used to log a key event.
open and close --> these two events are to log when a function starts or stops, or when a specific event needs to be grouped.
any other events are logged but no special action is available.
the location of the log file is determined during configuration and is stored in a subfolder called Debug
the log file structure is XML-like, and if you process the log file with an XML beautifier, you should be able to see the nested calls.
the logger and this sample are provided WITHOUT WARRANTY, and on a best effort base. No responsibility is derived.
Field ready: Taborca (3.4m), Ocelot (1.6m), Alula (0.6m).
Factory line: FVT-3 (1m), A6M Zero (1.6m), Tiger Moth (2.2m), Grumann Goose (2m) and Beechcraft D18 (1.5m).
Design phase: Szd-20x Wampir II (7.5m), Rutan Quickie (1.6m), both parked.
Dreaming: Weird push-pull called Double Trouble (2.4m)
Factory line: FVT-3 (1m), A6M Zero (1.6m), Tiger Moth (2.2m), Grumann Goose (2m) and Beechcraft D18 (1.5m).
Design phase: Szd-20x Wampir II (7.5m), Rutan Quickie (1.6m), both parked.
Dreaming: Weird push-pull called Double Trouble (2.4m)
von abief
Bitte Anmelden oder Registrieren um der Konversation beizutreten.
- NicoS
- Offline
- Platinum Mitglied
- Beiträge: 489
- Dank erhalten: 146
NicoS antwortete auf Debugging an app real-time, on the transmitter - almost there
Posted 12 Mai 2020 12:30 #3
If I load the sample.lua file in the Jeti simulator I get the error "Error in sample: ?:-1: attempt to call a nil value (field 'mkdir')"
Nico
Nico
von NicoS
Folgende Benutzer bedankten sich: abief
Bitte Anmelden oder Registrieren um der Konversation beizutreten.
- abief
- Offline Autor
- Premium Mitglied
- I'm here, there and elsewhere!
- Beiträge: 95
- Dank erhalten: 19
abief antwortete auf Debugging an app real-time, on the transmitter - almost there
Posted 12 Mai 2020 14:23 #4
you are probably missing the "Sample" folder in Apps. The Sample.lua file is more as a guideline on how to use the library than a real application
Field ready: Taborca (3.4m), Ocelot (1.6m), Alula (0.6m).
Factory line: FVT-3 (1m), A6M Zero (1.6m), Tiger Moth (2.2m), Grumann Goose (2m) and Beechcraft D18 (1.5m).
Design phase: Szd-20x Wampir II (7.5m), Rutan Quickie (1.6m), both parked.
Dreaming: Weird push-pull called Double Trouble (2.4m)
Factory line: FVT-3 (1m), A6M Zero (1.6m), Tiger Moth (2.2m), Grumann Goose (2m) and Beechcraft D18 (1.5m).
Design phase: Szd-20x Wampir II (7.5m), Rutan Quickie (1.6m), both parked.
Dreaming: Weird push-pull called Double Trouble (2.4m)
Last Edit:12 Mai 2020 14:26
von abief
Letzte Änderung: 12 Mai 2020 14:26 von abief.
Bitte Anmelden oder Registrieren um der Konversation beizutreten.
- NicoS
- Offline
- Platinum Mitglied
- Beiträge: 489
- Dank erhalten: 146
NicoS antwortete auf Debugging an app real-time, on the transmitter - almost there
Posted 12 Mai 2020 15:43 #5
In Apps a map Sample created. Error remains...
Nico
Nico
von NicoS
Bitte Anmelden oder Registrieren um der Konversation beizutreten.
- abief
- Offline Autor
- Premium Mitglied
- I'm here, there and elsewhere!
- Beiträge: 95
- Dank erhalten: 19
abief antwortete auf Debugging an app real-time, on the transmitter - almost there
Posted 12 Mai 2020 16:34 #6
By any chance, did you reinstall the Sample.lua app, or thru the console, reset the the app?
Given the nature of lua apps, the code that initializes the Logger library is part of the preinit part of the code: that is, the code that is not included in any of the functions within your app.
This code is not reinstated until you actually reload the lua app. In my case, I placed the configuration and initialization of the Logger library in this section, because I wanted to monitor also the code within init.
After the lua app is loaded, the firmware will manage the functions defined from within the return sentence, that is:
If you decide to place the configuration and initalization events within the init function, please remember to place them first in this function, if you want to monitor code from within init.
Actually, one of the reasons why telemetry needs to be part of the init code, is because the lua app is not properly active for the firmware, until the hook to loop and init is properly established.
In fact, the
that really drives the watch screen, it's in reality informing the firmware to use the
function I defined from within the Logger app.
And, BTW, one of the reasons that I give the possibility to use one Telemetry Screen or the other, is because two apps cannot use the same telemetry screen at the same time. My assumption is that you could use one telemetry screen for your own app, and the second for the watch screen.
The Display app by Thorn will not be able to use one telemetry screen for watching, as it uses both screens natively, and would probably have to rely on a modified version in case of need, or not use this feature of the library.
Don't forget that the Logger library is that, a library, a set of tools to be used by other apps. Sample.lua is only a simple use of this library, but as with any tool, it's up to the user on how to consume it, as long as you follow certain rules (configure before initialize, initialize before use, telemetry setup from within init, or after your app is properly initialized.
regards,
Given the nature of lua apps, the code that initializes the Logger library is part of the preinit part of the code: that is, the code that is not included in any of the functions within your app.
This code is not reinstated until you actually reload the lua app. In my case, I placed the configuration and initialization of the Logger library in this section, because I wanted to monitor also the code within init.
After the lua app is loaded, the firmware will manage the functions defined from within the return sentence, that is:
If you decide to place the configuration and initalization events within the init function, please remember to place them first in this function, if you want to monitor code from within init.
Actually, one of the reasons why telemetry needs to be part of the init code, is because the lua app is not properly active for the firmware, until the hook to loop and init is properly established.
In fact, the
Code:
system.registerTelemetry(1, "Watch Screen 1", 4, telemetryLoop1)
Code:
telemetryLoop()
And, BTW, one of the reasons that I give the possibility to use one Telemetry Screen or the other, is because two apps cannot use the same telemetry screen at the same time. My assumption is that you could use one telemetry screen for your own app, and the second for the watch screen.
The Display app by Thorn will not be able to use one telemetry screen for watching, as it uses both screens natively, and would probably have to rely on a modified version in case of need, or not use this feature of the library.
Don't forget that the Logger library is that, a library, a set of tools to be used by other apps. Sample.lua is only a simple use of this library, but as with any tool, it's up to the user on how to consume it, as long as you follow certain rules (configure before initialize, initialize before use, telemetry setup from within init, or after your app is properly initialized.
regards,
Field ready: Taborca (3.4m), Ocelot (1.6m), Alula (0.6m).
Factory line: FVT-3 (1m), A6M Zero (1.6m), Tiger Moth (2.2m), Grumann Goose (2m) and Beechcraft D18 (1.5m).
Design phase: Szd-20x Wampir II (7.5m), Rutan Quickie (1.6m), both parked.
Dreaming: Weird push-pull called Double Trouble (2.4m)
Factory line: FVT-3 (1m), A6M Zero (1.6m), Tiger Moth (2.2m), Grumann Goose (2m) and Beechcraft D18 (1.5m).
Design phase: Szd-20x Wampir II (7.5m), Rutan Quickie (1.6m), both parked.
Dreaming: Weird push-pull called Double Trouble (2.4m)
Last Edit:12 Mai 2020 16:48
von abief
Letzte Änderung: 12 Mai 2020 16:48 von abief.
Folgende Benutzer bedankten sich: Thorn
Bitte Anmelden oder Registrieren um der Konversation beizutreten.
Moderatoren: Thorn, IG-Modellbau
Ladezeit der Seite: 1.026 Sekunden