1.6 die Arbeitsumgebung
Ich weiß, Ihr wollt endlich loslegen. Trotzdem möchte ich noch ein paar einführende Worte dazu verlieren, wie man sich für die Lua-Entwicklung eine „Arbeitsumgebung“ schafft, die die Vorteile vorhandener Tools nutzt, insbesondere zu den Themen Editoren und dem Ethos Simulator.
Wer sowieso bereits programmiert, wird seinen „Lieblingseditor“ weiter nutzen wollen. Wer eher am Anfang steht und sich fragt, welchen Editor er nutzen sollte, dem möchte ich zwei (Windows) Empfehlungen geben:
Ein Open-Source/Free-Software-Projekt, das weit verbreitet ist. Vorteile sind einfache Anwendung, „Lua“-Unterstützung (farbliche Markierungen/Hervorhebungen des Codes), portable, etliche Zusatz-AddOns etc. Definitiv weit verbreitet und willkommen, wenn schnelle Einarbeitung und einfache Anwendung über der Anzahl der Features steht.
Wie der Name vermuten lässt, stammt Visual Studio Code aus dem Hause Microsoft. VS Code ist ebenfalls kostenlos und funktional noch umfangreicher als Notepad++. Wer seine Projekte auf GitHub veröffentlichen möchte, ist bei VS Code erst recht gut aufgehoben, da hier Add-Ons existieren, um Dateien direkt mit Git abzugleichen (push/pull/commit etc.).
VS Code lässt sich extrem individualisieren, was allerdings eine entsprechende Einarbeitung in die Config-Dateien erfordert. Die Lua-Code-Unterstützung „out of the box“ ist noch umfangreicher als bei Notepad++, zum Beispiel sieht man bereits farblich, ob definierte Variablen oder Funktionen im Code überhaupt genutzt werden (farblich ausgegraut).
VS Code besitzt mehr Funktionalitäten als Notepad++, erfordert jedoch auch mehr Einarbeitungszeit. VS Code ist für diverse Betriebssysteme verfügbar (Windows, Linux, macOS).
[VS Code Webseite](https://code.visualstudio.com/) 
Der Ethos Simulator ist ein hervorragendes Tool, um seine Scripts während der Entwicklungsphase zu testen, ohne den Sender zu benötigen. Zum einen besitzt der PC, das Notebook oder der Mac deutlich mehr Performance, was insgesamt zu einem flüssigeren Arbeitsablauf führt. Die „Coden > Testen > Analysieren > Coden“-Zyklen sind am Simulator einfach schneller. Zudem nutzt sich der Sender nicht so schnell ab.
Zum anderen hat man natürlich die Einschränkung, dass nicht restlos alle Funktionen (z.B. Trimmbedienung, bestimmte Telemetrie-Situationen) nachgestellt werden können (Stand Ethos 1.5.x). Ich persönlich nutze zu rund 90% der Entwicklungsaufwendungen den Simulator.
Der aktuellste Simulator ist im jeweils aktuellen Ethos Release (latest) auf GitHub zu finden. Bedient wird der Simulator hauptsächlich via Maus. Bedienelemente wie Schalter, Sticks etc. werden über die Tastatur emuliert.
Um am Simulator die Telemetrie nachstellen zu können (nur Fixwerte), muss am Simulator das RF-Modul eingeschaltet sein. Sollte der Modellspeicher noch keine Telemetriesensoren besitzen, dann können diese im Telemetriemenü per Suche definiert werden. Es werden alle typischen Sensoren gefunden.
Ab Version 1.5.12 wurde die Verwendung von Ordnern bzw. die Pfade erheblich umgestaltet. Zuvor wurden Modellfiles zentral in der Benutzerumgebung abgelegt, und der Simulator selbst lief mit allen weiteren Ordnern (audio, bitmaps, scripts, usw.) in seinem Installationspfad. Für jede „Umgebung“, wie z.B. spezifische Sim-Releases, Betas, Arbeits- und Entwicklungsumgebungen, war eine eigene Installation notwendig, die sich ein Modellverzeichnis teilten.
Dies führte bei gleichzeitiger Verwendung von Simulatoren unterschiedlicher Releasestände zu Problemen. Nun, ab Version 1.5.12, wird eine hardware-spezifische „Userumgebung“ unter dem Ordner .ethos im Windows-Benutzerpfad angelegt.
Sie enthält die Ordner logs, models und scripts, sowie die radio.bin-Datei inkl. Sendersettings. Alle restlichen Ordner befinden sich im Installationspfad.
Ab Version 1.5.12 kann beim Start eines Simulators über Parameter bestimmt werden, welcher spezielle Ordner für welchen speziellen Zweck (audio, system, scripts, usw.) verwendet werden soll (Re-Routing).
-
--system-directory: System-Verzeichnis (z.B. i18n, bitmaps) -
--user-directory: Die typischen User-Verzeichnisse (logs, models, usw.) -
--scripts-directory: Ordner für Scripts -
--radio-settings: Legt dedizierteradio.bin-Datei fest
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"
Der Ordner „0 environment A“ sollte dann so aussehen:
- **soundfiles**: Eigene Sounddateien - **modelfiles**: Modelldateien - **scripts**: Lua-Scripts - **radio.bin**: Die dedizierte `radio.bin`-Datei
Eine weitere Arbeitsumgebung ließe sich einfach und ohne zusätzliche Simulator-Installation durch eine angepasste Batch-Datei und einen weiteren „Umgebungs-Ordner“, z.B. „0 environment B“, erstellen.
**SEHR WICHTIG!!!**
Der Simulator kann ein Debug-Fenster zur Verfügung stellen, in dem alle Systemmeldungen inklusive Lua-Debug-Code und Fehler präsentiert werden. (Lua-Debug-Code ist nichts anderes als ein print-Befehl in bestimmten Codezeilen, um Statusinfos und Werte im Ablauf auszugeben.)
Um das Debug-Fenster im Simulator zu erhalten, muss der Simulator über die Command-Shell gestartet werden:
Beispiel:
- Command-Shell öffnen (
cmd.exe) - In das Verzeichnis des Simulators navigieren
- Eingabe:
simulator.exe
Alternativ kann ein Batch-File generiert und gestartet werden, z.B. für einen Simulator, der unter D:\Programme\Ethos\X18 installiert wurde:
d:
cd "D:\Programme\Ethos\X18"
"D:\Programme\Ethos\X18\simulator.exe"Links erscheint das Debug-Fenster zum gestarteten Simulator (rechts, Teilausschnitt).
Die Ethos Suite kann ebenfalls während der Lua-Script-Entwicklung genutzt werden.
Sie wird meistens „on top“ zum Simulator angewendet. Der Simulator stellt z.B. ausschließlich konstante Telemetriewerte zur Verfügung, kann derzeit Trimmereingaben nicht entsprechend verarbeiten und zeigt ein anderes Performanceverhalten auf. Ab dem Moment, wo ein „Real-World“-Testing notwendig ist, kommt die Suite zum Einsatz.
Dabei wird der Sender (z.B. im Suite-Modus) mit dem Rechner verbunden und die Suite gestartet. Durch Verwendung der Suite im „Dev-Tool-Menü“ kann der Sender durch die Suite gesteuert zwischen Betriebsmodus und Entwicklermodus umgeschaltet werden.
Der „Entwicklermodus“ ist quasi der Suite-Modus mit gemounteten Laufwerken, sodass die Lua-Files einem Editor zur Verfügung stehen. Ist ein Lua-File des Senders im Editor geöffnet, sollte der Editor in der Lage sein, das File im Speicher zu halten, auch wenn die Datei im Betriebsmodus des Senders gerade nicht zur Verfügung steht.
Durch diese Art der Umschaltung lassen sich schnell Anpassungen im Code vornehmen und praktisch testen. Es muss kein Kabel umgesteckt werden, und der Sender muss nicht manuell in den Suite-/Seriell-Modus versetzt werden.
Der besondere und wesentliche Vorteil liegt darin, dass einem direkt ein Terminalfenster zur Verfügung steht, in dem Debug-Informationen des Senders in Echtzeit dargestellt werden können. Diese Debug-Infos sind außerordentlich hilfreich bei der Suche nach Fehlern und deren Ursachen.
Wenn im Testmodus auch das Modell eingeschaltet werden sollte: Um beim Umschalten Schäden durch versehentliches Anlaufen von Antriebsmotoren etc. zu verhindern, müssen Propeller demontiert werden und ggf., je nach Modellkonfiguration, weitere Sicherheitsmaßnahmen getroffen werden.
Gerade wurde von Debug-Informationen gesprochen. Was versteht man darunter?
Allgemein gesagt, ist Debug-Information alles an (textlicher) Information des Senders oder des Simulators, was dem Entwickler hilft, Fehler und deren Ursachen aufzuspüren.
Beispiel:
Der Simulator zeigt im Script einen Fehler an:
die Zeile 2507 im main.lua konnte also nicht ausgeführt werden.
Schauen wir uns den Codebereich an:
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.