1.6 dev environment
I know you all want to get started.
However, here are a few introductory words on how to create a 'work environment' for lua development that takes advantage of existing tools, especially on the topics of editors and the Ethos simulator.
Anyone who is already programming will want to continue using their 'favorite editor.'
Those who are just starting and wondering which editor to use, I would like to give two recommendations:
An open-source/free software project that is widely used. Advantages are easy application, 'lua' enabled (color coding/highlighting of coding), it is portable, has several additional add-ons, etc.
Definitely widely used and welcome if quick familiarization and easy application are more important than the number of features.
As the name suggests, from Microsoft. VS Code is also free, functionally even more extensive than Notepad++. If you want to publish your projects on GitHub, VS Code is especially suitable because there are add-ons to synchronize files directly with git (push/pull/commit, etc.).
VS Code can be extremely customized, but it requires corresponding familiarization with the config files. The lua code support 'out of the box' is even more extensive than with Notepad++, e.g., you can already see in color whether defined variables or functions are actually used in the coding (colored gray, etc.). VS Code has more functionality than Notepad++, but it also requires more familiarization time.
[VS Code Webseite](https://code.visualstudio.com/) 
The Ethos simulator is an excellent tool to test your scripts during the development phase without needing the transmitter. It is currently only available for Windows and Linux. It is possible to run it in under Windows in a virtual machine on a Mac.
Firstly, the PC/notebook/Mac has significantly more performance overall, and you can work somewhat more smoothly than directly on the transmitter. 'Coding > Testing > Analyzing > Coding' cycles are simply faster on the simulator.
Additionally, the transmitter does not wear out as quickly. On the other hand, there are of course limitations, as not all functions (e.g., trim operation, certain telemetry situations) can be replicated (as of Ethos 1.5.x). Personally, I use the simulator for around 90% of development efforts.
The latest simulator can be found in the latest Ethos release (latest) on GitHub.
The simulator is mainly operated via mouse.
Control elements such as switches, sticks, etc., are emulated via the keyboard. (If you do not have a numeric keypad, you can use the Windows On-Screen Keyboard ( Go to Start , then select Settings > Accessibility > Keyboard, and turn on the On-Screen Keyboard toggle. )
To replicate telemetry on the simulator (only fixed values), the RF module must be turned on in the simulator. If the model memory does not yet have telemetry sensors, then define them in the telemetry menu via the 'Discover new sensors’. All typical sensors will be found.
**Starting from version 1.5.12, the use of folders and paths has been significantly redesigned. **
Previously, model files were centrally stored in the user environment, while the simulator itself ran with all other folders (audio, bitmaps, scripts, etc.) in its installation path.
For each "environment," such as specific simulator releases, betas, work environments, development environments, etc., a separate installation was necessary, sharing a model directory.
This led to problems when using simulators of different release versions simultaneously.
Now (version 1.5.12), a hardware-specific "user environment" is created under the ".ethos" folder in the Windows user path.
It contains the folders logs, models, and scripts, as well as the radio.bin file including transmitter settings. All other folders are located in the installation path:
Starting from version 1.5.12, parameters can be used to specify which specific folder is used for which specific purpose (audio, system, scripts, etc.) when starting a simulator (re-routing).
-
--system-directory: System directory (e.g., i18n, bitmaps) -
--user-directory: Typical user directories (logs, models, etc.) -
--scripts-directory: Folder for scripts -
--radio-settings: Specifies a dedicated "radio.bin" file
set SIMEXE=D:\Programme_U\Ethos\x18.12
set SIM=0 environment A
d:
cd %SIMEXE%
simulator.exe --system-directory "D:\Programme_U\Ethos\x18 n\%SIM%\system" --user-directory "D:\Programme_U\Ethos\x18 n\%SIM%" --scripts-directory "D:\Programme_U\Ethos\x18 n\%SIM%\scripts"
The folder of the work environment "0 environment A" should then look like this: ("own" sound files, model files, scripts, radio.bin)
Another work environment could be easily created without additional simulator installation by using another customized batch file and another "environment folder," e.g.: ** „0 environment B“**
very important !!!
The simulator can be run with a command shell debug window.
All system messages, including lua debug code and errors, are presented there. (Lua debug code is nothing more than a print command in certain code lines to output status info and values during the process)
To get the debug window in the simulator, it must be started via command shell
example:
- open a command shell (cmd.exe)
- Enter "C:\Program Files (x86)\FrSky\Ethos\X20S\simulator.exe"
Alternatively, generate and start a batch file, e.g., for a simulator installed under
"C:\Program Files (x86)\FrSky\Ethos\X20S"
d:
cd "D:\Programme\Ethos\X18"
"D:\Programme\Ethos\X18\simulator.exe"Left the debug window , right the started simulator
The Ethos Suite can also be used during lua script development.
It is mostly applied 'on top' of the simulator.
The simulator provides only constant telemetry values, cannot currently process trimmer inputs accordingly, and exhibits different performance behavior.
From the moment 'real world' testing is necessary, the suite is used.
The transmitter (e.g., in suite mode) is connected to the computer and the suite is started.
By using the suite in the 'dev-tool menu,' the transmitter can be switched between operating mode and development mode.
The "developer mode" is essentially the suite mode with mounted drives, so that the Lua files are available to an editor.
If a lua file of the transmitter is open in the editor, the editor should be able to keep the file in memory, even if the file is not currently available in the operating mode of the transmitter.
This type of switching allows quick adjustments to the code and practical testing.
No cable needs to be replugged, nor does the transmitter need to be manually switched to suite/serial mode, etc.
The special and essential advantage is that a terminal window is directly available, in which debug information from the transmitter can be displayed in real-time.
These debug infos are extremely helpful in finding errors and their causes.
If the model should also be switched on in test mode:
To prevent damage from accidental starting of drive motors, etc., propellers must be removed, and depending on the model configuration, additional safety measures must be taken
Debug information was just mentioned.
What is meant by this? Generally speaking, debug information is any (textual) information from the transmitter/simulator that helps to detect errors and their causes.
**Example: ** The simulator shows an error in the script: Line 2507 in main.lua could not be executed.
Line 2507 in main.lua could not be executed.
Let's look at the code area:
Es sollte der Wert einer Telemetriequelle (source) der Variablen sourceVal zugewiesen werden, das funktionierte nicht. Offensichtlich ist die Quelle nicht angelegt angelegt worden (Fehlermeldung „..nil value (local‘source`)“
Schauen wir uns an, welchen Namen der Sensor in dem Moment hatte. Dazu ergänzen wir den Code und lassen uns via print Befehl etwas „debug Infos“ ausgeben:
Der Sim gibt nun aus:
Als Name eines Telemetriesensors ist „5“ bestimmt falsch, sorgen wir im Coding also für den richtigen Sensornamen (z.B. „RSSI“), ist der Fehler behoben.
Im debug Fenster des Sims werden solche Infos einfach ermöglicht.
Wie aber erhalte ich debug Infos direkt vom Sender ? Eine Möglichkeit wurde gerade beschrieben: via Suite und den dev-tools. Dort existiert ein Terminalfenster, was die Informationen darstellt.
Welche Alternative gibt es?
Dazu muss man wissen, dass diese Infos als eine Art „serielle Textübertragung“ via USB gesendet werden.
Die Technik der seriellen Übertragung gibt es fast seit Anfang der Computertechnik, ein HW Standard der seriellen Übertragung war einmal die RS232 Schnittstelle, die immer noch via USB emuliert werden kann.
Zur Darstellung verwenden wir mit Sicherheit kein antikes Textterminal (es sei denn jemand besitzt z.B. noch DEC VT510 Geräte..) sondern wir überlassen das einer Software App.
Eine sehr geläufige und kostenlose Anwendung ist das Programm „Putty“:
Download Putty
Diese App visualisiert die Daten (Textnachrichten), die aus dem Sender kommen.
Die Daten werden in einer bestimmten Geschwindigkeit gesendet und „landen“ auf einer bestimmten „virtuellen“ Schnittstelle per Emulation. Ist das Programm Putty installiert, muss zunächst diese Kommunikationsschnittstelle eingerichtet werden.
Prinzipiell ist es möglich, dass mehrere Geräte zeitgleich seriell mit einem Rechner kommunizieren wollen. Jedes Endgerät muss dazu eine eigene Schnittstelle „bedienen“. Die früheren physikalischen RS232- bzw. „Com“- (Communication-) Schnittstellen waren am Host daher mehrfach vorhanden und durchnummeriert (Com1: bis Com32: und mehr). Die USB-Schnittstelle emuliert nun einen bestimmten Port, je nachdem auf welchem USB-Port der Sender verbunden wurde, welche OS-Version genutzt wird, und welcher Treiber installiert ist.
Wir müssen via Gerätemanager herausfinden, auf welchem Port der Sender zugewiesen wurde. Dazu wird der Sender mit dem Rechner verbunden und in den seriellen Modus versetzt.
Öffne den Gerätemanager und überprüfe, auf welche sogenannte COM-Schnittstelle der Sender verbunden wurde.
Unter Putty definieren wir nun eine Sitzung mit genau dieser COM-Schnittstelle und den Parametern 115000 Baud (Geschwindigkeit). Diese Angaben sind im Bild rot markiert:
Wir speichern die Sitzung unter einen eindeutigen Namen (z.B. „ethos 11“) und drücken „Save/Speichern“ (blau)
Jetzt kann man per „öffnen/open“ ein Terminalenster starten, das uns Infos vom Sender ausgibt.