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:
The value of a telemetry source (source) should be assigned to the variable sourceVal, but this did not work. Obviously, the source was not created (error message "..nil value (local 'source)").
Let's see what name the sensor had at that moment. For this, we add to the code and use the print command to output some "debug infos":
The simulator now outputs:
The name of a telemetry sensor is "5," which is certainly wrong, so we ensure the correct sensor name (e.g., "RSSI") in the coding, and the error is fixed.
In the debug window of the Sim, such information is easily provided.
But how do I get debug info directly from the transmitter?
One possibility has just been described: via Suite and the dev-tools. There is a terminal window that displays the information.
What alternative is there?
It is important to know that this information is sent as a kind of "serial text transmission" via USB. The technique of serial transmission has existed since the early days of computer technology. One hardware standard for serial transmission was the RS232 interface, which can still be emulated via USB. To display the information, we certainly do not use an antique text terminal (unless someone still owns, for example, DEC VT510 devices), but we leave this to a software app.
A very common and free program is "Putty": Download Putty
This app visualizes the text data coming from the transmitter via USB. The data is sent at a certain speed and "lands" on a specific "virtual" interface through emulation. Once Putty is installed, this communication interface needs to be set up first.
It is generally possible for multiple devices to communicate serially with a computer at the same time. Each device must use its own interface. The former physical RS232 or "Com" (Communication) interfaces were therefore present on the host multiple times and numbered (Com1: to Com32: and more).
The USB interface now emulates a specific port, depending on which USB port the transmitter is connected to, which OS version, which driver, etc. We need to find out which port the transmitter is assigned to via the Device Manager. To do this, the transmitter is connected to the computer and put into serial mode. We then open the Device Manager and check which so-called COM interface the transmitter is connected to.
In Putty, we define a session with exactly this COM interface and the parameters 115kB (speed).
We save the session under a unique name (e.g., "ethos11") and can now start a terminal window by clicking "Open," which will display information from the transmitter.