Alle in der jüngsten Vergangenheit hinzu gekommenen funktionalen Erweiterungen/Optionen mündeten in extra Firmware-Versionen, die sich im JLC als unterschiedliche Geräte darstellen. Warum?
Nun… Für Spezialanwendungen wie “BID” (unterstützt Robbe BID-Chip) und “JTX” (meine Homebrew-Telemetrie) ist das prinzipiell sinnvoll, weil die Beschaltung des Loggers, das Verwenden seiner Optionsanschlüsse und der COM, jeweils spezifisch ist, festgelegt und andere Anwendungen ausschließend. Z.B. wird der Robbe BID-Chip (Battery Identification Device) via I²C-Bus angeschlossen (ein 2-Wire-Bus), was die beiden Optionsanschlüsse grundsätzlich frisst.
Ein anderer Grund ist folgender: Der Speicherplatz im Prozessor des Loggers, FlashROM (für Code) und RAM (für Daten, Variablen) ist limitiert und eigentlich, über das Portfolio der gesamten Funktionalität betrachtet, längst überfüllt. Es ginge nicht, den gesamten Code ständig im Prozessor vorzuhalten, bestimmte Teile davon nur per Konfiguration der Anwendung zuzuführen. Außerdem frisst jede neue Konfigurierbarkeit selbst erheblich Speicher, CONFIG.txt muss ausgewertet, bewertet (Konsistenz und Plausibilität), korrigiert werden, gelernte Parameter muss der Logger in seinen EEPROM einlernen.
Die unterschiedlichen Firmware-Versionen beruhen alle auf derselben Source, nur, dass per Precompiler-Anweisungen, eine Art Makro-Sprache, Teile des Codes hereingenommen werden oder nicht, der Code ist dergestalt modular gestaltet.
Dieses Verfahren wird sich dann auch mit dem Implementieren weiterer Telemetrien fortsetzen müssen, HoTT (inzwischen realisiert), später S-Bus2. Es gilt dann, sinnvolle Kombinationen zu finden, die am ehesten kombinerte Anwenderbedürfnisse treffen können. Zu berücksichtigen ist dann dabei natürlich auch, dass der bestehende Source-Code selbst Teile funktional und damit untrennbar kombiniert, z.B. sind JETI-Telemetrie, Undisplay, Online-Konfigurator “jbJLC” und Alarmleitungen schwer verheiratet miteinander.
