Diskussion Weiterentwicklung der pyMobaLedLib

[hlinke]

Im Stummi-Forum hatten wir eine Diskussion mit Ideen für eine Weiterentwicklung der pyMobaledLib bzw der gesamten MLL angefangen.
Damit diese Ideen nicht verloren gehen, habe ich die Diskussionsbeiträge in diesen Thread als Zitate kopiert.
Ich hoffe, ich habe nichts übersehen.

Harold

[hlinke]

Zitat von GerdR im Stummi-Beitrag #577

pyMLL - Python Version der MobaLedLib - hier Version 5.3.5v

Mal ganz bunt durcheinander was mir so aufgefallen ist, bzw, was mir überhaupt nicht gefällt:

1. Programm- und Patterngenerator nutzen nur einen kleinen Teil des Bildschirms, in dieser Version liegt es wohl daran dass das Display angepasst wurde damit es auf einem Laptop mit kleinem Bildschirm läuft (zwecks Vorführung auf der Messe).

Warum hier die TKInter Bibliothek nicht genutzt wird um das Display dynamisch an die verschiedenen Bildschirmgrössen anzupassen, bzw. warum das Display statisch ist und nicht grössenmässig dynamisch verändert werden kann wird Harold @hlinke uns bestimmt erklären können.

So wie es jetzt im Moment ist, kann man nur 8 Zeilen des Prog-Gen Sheets sehen - manchem wird es reichen, aber wenn man ständig ruf und runterscrollen muss ist es schon lästig.

2. Und damit gleich zum nächsten Punkt - kann man nicht auf die "RiesenButtons" verzichten, die zur Zeit etwa 25% der Displayhöhe in Beschlag nehmen (zum Arduino schicken, Zeile einfügen, etc.)
Daß diese Button aus der "Anfangszeit" der MLL stammen ist jedem klar, aber alles ändert sich, auch die Größe und Darstellung von Button. Etwas kleiner und dezenter wäre doch möglich, die Beschriftung kann ja bleiben,aber warum muß eine riesen Grafik dargestellt werden.

3. Was im Moment nirgendwo erklärt ist, bzw.anscheinend noch nicht implementiert ist - was machen die diversen Einstellmöglichkeiten in Programmeinstellungen, bzw dem Config sheet. Bei einigen Sachen habe ich das Gefühl da ändert sich nix, sie haben keinen Einfluss.

Mir ist klar das die Programmiererei an Harold hängen bleiben wird, ich finde es auch fantastisch was er bisher geleistet hat, aber das die PyMLL keine "One Man" Show ist dürfte jedem klar sein, Vlt. findet sich ja ein weiterer Python Programmierei der mit an der MLL arbeiten möchte.

So-jetzt könnt ihr wieder auf mich einschlagen, vor allen Dingen die Leute die noch nie die Python Version gestart haben, sondern nur sehen dass ich etwas zu "meckern" habe -

Zitat "Dann mach es doch besser" Zitat Ende

GerdR

[hlinke]

Zitat von Eckhart im Stummi-Beitrag #578

Hallo Gerd!

Alle deine Kritikpunkte sind berechtigt! (und ich hätte noch zusätzliche dieser Art)

Vlt. findet sich ja ein weiterer Python Programmierer der mit an der MLL arbeiten möchte.

Das alleine wäre unter Umständen nicht mal so sehr das Problem! Python ist heute sozusagen mandatory/verpflichtend zu können, wenn man auch nur ansatzweise in der IT Fuß fassen möchte. Da wird es schon einige geben, die Python können. In meinem beruflichen Fachgebiet sind zwar die Core-Sprachen Assembler, C, C++, C# dominant, aber alle Entwickler schreiben natürlich Service-Code zum Managen von Modulen und Tests in Python. Das sind aber alles Programme, die über die Kommandozeile zu bedienen sind, oder selber wieder eine kleine "Sprache" implementieren, in der man Konfigurationen textuell vornehmen kann.

Warum hier die TKInter Bibliothek nicht genutzt wird um das Display dynamisch an die verschiedenen Bildschirmgrössen anzupassen, bzw. warum das Display statisch ist und nicht grössenmässig dynamisch verändert werden kann

Das ist leider die Crux! ...es geht nämlich gar nicht um "Python können", sondern sich mit GUI Bibliotheken auszukennen (und sich durch den, oft nicht funktionierenden, Schnittstellencode fremder Leute zu quälen) und auch ein Gespür für Anwendungsdesign zu haben. Tja und das würde niemand aus meinem beruflichen Team können, nicht einmal die frischen Mitte 20 jährigen Uniabsolventen... (die haben allerdings auch alle "hardwarenah" studiert)

Wenn ich so sehe, wie grottig viele angeblich "professionellen Webseiten" im Bezug auf "responsive design" aufgestellt sind, wird es richtig schwierig, jemanden zu finden, der das richtig gut kann, was du kritisierst!

Gruß, Eckhart

[hlinke]

Zitat von hlinke im Stummi-Beitrag #579

pyMLL - Python Version der MobaLedLib - hier Version 5.3.5v
1. Programm- und Patterngenerator nutzen nur einen kleinen Teil des Bildschirms, in dieser Version liegt es wohl daran dass das Display angepasst wurde damit es auf einem Laptop mit kleinem Bildschirm läuft (zwecks Vorführung auf der Messe).
Warum hier die TKInter Bibliothek nicht genutzt wird um das Display dynamisch an die verschiedenen Bildschirmgrössen anzupassen, bzw. warum das Display statisch ist und nicht grössenmässig dynamisch verändert werden kann wird Harold @hlinke uns bestimmt erklären können.
So wie es jetzt im Moment ist, kann man nur 8 Zeilen des Prog-Gen Sheets sehen - manchem wird es reichen, aber wenn man ständig ruf und runterscrollen muss ist es schon lästig.

Hallo Gerd
Du rennst mit Deinen Kritikipunkten bei mir offene Türen ein.
Diese Sachen stören mich auch.
Leider hat die TKInter-GUI so ihre Tücken und verhält sich blöderweise auch noch unter Linux und Mac jeweils ein bißchen anders als unter Windows.
Für die Benutzung der pyMLL auf einem kleinen Bildschirm musste ich einige Dinge anpassen.
In meiner Arbeits-Version wird die Größe der Programmgeneratortabelle beim Start an die Größe des Fensters angepasst.
Da die Programmgeneratortabelle Komponenten nutzt, die ich nicht selbst geschrieben habe, ist eine dynamische Anpassung beim Ändern der Fenstergröße leider nicht möglich, bzw ich habe dafür noch keine Lösung gefunden.

Es ist also Besserung in Sicht. Ich möchte diese Version aber erst freigeben, wenn Jürgen siene neue MLL-Version freigegeben hat, da ich dort schon einige Anpassungen für diese neue Version vorgenommen habe.
Du musst also noch etwas warten.

2. Und damit gleich zum nächsten Punkt - kann man nicht auf die "RiesenButtons" verzichten, die zur Zeit etwa 25% der Displayhöhe in Beschlag nehmen (zum Arduino schicken, Zeile einfügen, etc.)
Daß diese Button aus der "Anfangszeit" der MLL stammen ist jedem klar, aber alles ändert sich, auch die Größe und Darstellung von Button. Etwas kleiner und dezenter wäre doch möglich, die Beschriftung kann ja bleiben,aber warum muß eine riesen Grafik dargestellt werden.

Guter Vorschlag. Werde ich in der neuen Version mal umsetzen.

3. Was im Moment nirgendwo erklärt ist, bzw.anscheinend noch nicht implementiert ist - was machen die diversen Einstellmöglichkeiten in Programmeinstellungen, bzw dem Config sheet. Bei einigen Sachen habe ich das Gefühl da ändert sich nix, sie haben keinen Einfluss.
Mir ist klar das die Programmiererei an Harold hängen bleiben wird, ich finde es auch fantastisch was er bisher geleistet hat, aber das die PyMLL keine "One Man" Show ist dürfte jedem klar sein, Vlt. findet sich ja ein weiterer Python Programmierei der mit an der MLL arbeiten möchte.

Da sind eine Menge Einstellungen drin, die ich für mich zum Testen eingebaut hatte und die keine Funktion mehrhaben.
Da muß ich auch mal aufräumen.

So-jetzt könnt ihr wieder auf mich einschlagen, vor allen Dingen die Leute die noch nie die Python Version gestart haben, sondern nur sehen dass ich etwas zu "meckern" habe -
Zitat "Dann mach es doch besser" Zitat Ende

Ich sehe Deine Anmerkungen nicht als "meckern", sondern als willkommene Anregungen etwas zu verbessern.

Wenn Du noch weitere Ideen hast, was verbessert werden könnte oder Dich stört, immer her damit. Wir können das Tool nur gemeinsam verbessern.

Viele Grüße
Harold

[hlinke]

Zitat von oliwel im Stummi-Beitrag #580

Hallo,

Blöde Idee...wäre es eine Option UI und Backend zu trennen und das ganze Frontend in einen Webbrowser zu verlagern? WebUI Toolkits haben zwar auch ihre Macken und Tücken aber das würde es auch viel einfacher machen zB mit einem Raspi an den ESP zu gehen und dann einfach vom HeimPC per Browser seine MLL zu konfigurieren....

Oli

[hlinke]

Zitat von hlinke im Stummi-Beitrag #581

Blöde Idee...wäre es eine Option UI und Backend zu trennen und das ganze Frontend in einen Webbrowser zu verlagern?

Hallo Oli,

diese blöde Idee hatte ich auch schon.
Würde einiges vereinfachen, würde aber auch ein fast komplettes Neuschreiben der pyMobaLedlIb GUI bedeuten.
Es gibt GUI-Frameworks, mit denen das geht z.B. Remi. Remi hat ähnliche Widgets wie TKinter, aber eben nur ähnlich.
Das wäre eine interessante Herausforderung. Wenn ich mal viel Zeit habe, schaue ich mir das auch mal an.
Kann aber noch etwas dauern ...

Den Zugriff auf den RASPI mache ich mit VNC. Die pymobaledlib läuft auf dem RASPI und mit VNC verbinde ich mich mit einem VNC-Client auf meinen PC. Funktioniert problemlos. Über VNC übertrage ich auch das geänderte Programm. Sonst wären Tests auf dem RASPI immer sehr aufwendig.

Viele Grüße
Harold

[hlinke]

Zitat von oliwel im Stummi-Beitrag #582

Es gibt GUI-Frameworks, mit denen das geht z.B. Remi. Remi hat ähnliche Widgets wie TKinter, aber eben nur ähnlich.

Ich würde eher dazu tendieren eine echte RESTlike API zu bauen und das GUI dann mit einem "echten" Webansatz - Bootstrap mit Angular oder Ember, dann kann man beides getrennt entwickeln und die Arbeit auf mehrere Schultern verteilen - ich weiß nicht wie fest du an den Excel Aufbau gebunden bist durch deine VBA Adaption aber ich finde nicht das wir hier eine 1:1 "Abbildung" brauchen solange die Funktion da ist....würde mich hier auch am API Design und vielleicht sogar am WebUI beteiligen (macht in meiner Firma inzwischen ein anderer Kollege aber ich hab das über 10 Jahre selber gemacht)

Oli

[hlinke]

Zitat von hlinke im Stummi-Beitrag #583

Ich würde eher dazu tendieren eine echte RESTlike API zu bauen und das GUI dann mit einem "echten" Webansatz - Bootstrap mit Angular oder Ember, dann kann man beides getrennt entwickeln und die Arbeit auf mehrere Schultern verteilen

Hallo Oli,

das würde dann eine komplett neue Software bedeuten, mit einer neuen Benutzeroberfläche. Müsste man mal drüber nachdenken. Besonders wenn man die Entwicklung dann auf mehrere Personen aufteilen könnte.
Ich hatte vor 6 Jahren mit einer anderen nit tabellenbasierten Benutzerschnittstelle angefangen.
Ich habe das nach kurzer Zeit aufgegeben, da ich keine Chance hatte die neuen Funktionen und Fehlerkorrekturen von Hardi und Jürgen nachzuvollziehen.
Solange die Excel-Version der Master ist, sehe ich da größere Schwierigkeiten mitzuhalten.
Ich habe den heutigen Ansatz, die Excel-Benutzerschnittstelle nachzubilden und den VBA-Code, wenn immer möglich 1:1 in Pythoncode umzusetzen, gewählt, da ich so die Anleitungen im Wiki 1:1 auch für die Python-Version gelten und ich relativ einfach die Änderungen, die von Version zu Version in der Excelversion gemacht werden, nachvolziehen und übernehmen kann.
Wir können uns aber gerne mal mit Hardi und Jürgen zusammen setzen, um zu sehen, wie wir langfristig mit der Software weitermachen wollen.

Viele Grüße
Harold

[hlinke]

Zitat von Eckhart im Stummi-Beitrag #584

Hallo Oli, hallo Harold!

Ich würde eher dazu tendieren eine echte RESTlike API zu bauen und das GUI dann mit einem "echten" Webansatz - Bootstrap mit Angular oder Ember, dann kann man beides getrennt entwickeln und die Arbeit auf mehrere Schultern verteilen - ich weiß nicht wie fest du an den Excel Aufbau gebunden bist durch deine VBA Adaption aber ich finde nicht das wir hier eine 1:1 "Abbildung" brauchen solange die Funktion da ist....

Sowas würde ich sehr begrüßen!

Da gäbe es sogar die Perpektive, dass man dieses Konstrukt, dass ein größerer Raspi (mit REST API) den Arduino Code für einen ESP32 xcompilieren muss, komplett weglassen kann und der js Code und REST native auf einem mittelgroßen uC laufen. (mit dem ESP32 und nonDMA-RMT wohl nicht, aber mit einem einem DMA fähigen Raspi Pico 2 W vielleicht schon)

Die Herausforderung dafür wäre die Umsetzung des C-Programmcodes aus LED_AutoProg.h in eine gespeicherte Konfiguration außerhalb eines neucompilierens! Hier könnte man, bei der REST Spezifikation natürlich schon Vorarbeit leisten und ein abstrakteres Modell fahren.

Solange die Excel-Version der Master ist, sehe ich da größere Schwierigkeiten mitzuhalten.

Ich weiß nicht, ob mittel- bis langfristig die 100% Orientierung an der Excel MLL "das" Konzept ist?

Sobald man etwas hat, was für den User deutlich smarter erscheint (ohne Installation Browser öffnen und "belebtes Haus" zusammenbauen) darf es auch anfänglich Funktionseinbußen geben! Alles hängt dann an der Smartness des Web-UI!

Gruß, Eckhart

PS: Auch wenn Ember evtl. mehr kann, würde ich Angular als lower hanging fruits bevorzugen, da wir dort vermutlich mehr Chancen haben, noch jemanden in's Boot zu holen.

[hlinke]

Zitat von hlinke im Stummi-Beitrag #585

Hallo Oli, hallo Eckhart,

ich glaube wir kommen jetzt gerade etwas vom Pfad ab.

Was Ihr vorschlagt hört sich nach einer kompletten Neuentwicklung an, die mit der MLL vielleicht noch die Stromnversorgung gemeinsam hat (5V Gleichstrom) ansonsten aber in keinerweise kompatibel zu der heutigen MLL ist.

Die MLL hat fast 10 Jahre von den ersten Ideen, die Hardi hatte, bis zu dem Stand gebraucht, den wir heute haben.

Soviele Zeit habe ich leider nicht mehr.

Ich bevorzuge eine schrittweise Weiterentwicklung,bei der wir die heutigen Anwender mitnehmen können, und die es auch immer wieder ermöglicht, nach einer relative kurzen Entwicklung, Erfolgserlebnisse zu haben.

Viele Grüße
Harold

[hlinke]

Zitat von Eckhart im Stummi-Beitrag #586

Hallo Harold, hallo Oli!

Hallo Oli, hallo Eckhart,
ich glaube wir kommen jetzt gerade etwas vom Pfad ab.

Das Gegenteil ist der Fall!

Tatsächlich hatte ich, als ich vor ungefähr 3 Jahren anfing, mich mit der MLL zu beschäftigen, kurzzeitig die Idee, die Effekte neu zu entwickeln. Das habe ich aber schnell aufgegeben, als ich merkte, dass das nicht mal eben in ein paar Wochen gemacht ist! Insbesondere die Rumprobiererei, ob etwas "gut aussieht" kostet viel Zeit! Daher ist die orginale MLL mit einkompiliert und alle MLL Effekte, die ich noch nicht neu schreiben konnte (und das sind die meisten!) sind in einer Virtualisierung verfügbar. (eigentlich ist alles verfügbar, ich nutze es nur tlw. nicht, weil ich was eigenes, z.B. mein "Feuer", habe)

Nehmen wir mal an, es gäbe so eine MLL Hauptplatine, die die ein Webinterface hat und über dieses HTTP Interface die Konfiguration des MLL-Chunk (die MLL Binärkonfiguration) mit einem "GET" hergeben kann und mit der am eine solche MLL Konfiguration auch wieder mit einem "PUT" auch wieder übernehmen kann. Kein Neukompilieren der Hauptplatinen-Firmware; diese wird nur einmalig auf den uC geschmissen!

@oliwel 's Idee, als Interface für so eine Hauptplatine REST zu verwenden, ist genial, denn sie wäre universell und natürlich wäre eine "weiche Migration" durchaus möglich! Es ist ja durchaus üblich, dass auch ein Python Programm, wie dein pyPG, so ein Backend über REST anspricht! Ein neues Web-basierendes Frontend könnte dazu parallel angefangen werden und würde nur die Funktionen anbieten, wo das alte Konzept (alles "Excel-like" zu machen) nicht mehr opportun ist.

@hlinke, könntest du dir vorstellen, mit dem pyPG eine MLL Hauptplatine über REST anzusprechen? Hast du eigentlich schon mal den Text, den du in MobaLedLib_Configuration als C-Source erzeugst, innerhalb deines Python Programms, in den binären MLL Config[] Chunk übersetzt, der letzten Endes auf einer MLL Hauptplatine als Konfiguration abläuft?

Gruß, Eckhart

PS: haltet euch nicht zurück, alles anzuzweifeln, was so eine neue MLL Hauptplatine dafür können müsste und wie lange es dauern würde, so etwas wirklich zu entwickeln!

[Eckhart]

Hallo Harold, hallo Oli!

Die anhängende Datei illustriert, welcher Art die auszutauschenden Daten über die REST API sein würden. Derzeit als POST/GET HTTP Schnittstelle, um Konfigurationen via Files, von der Hauptplatine mit dem PC, austauschen zu können, aber das in ein übliches JSON Format (sehr gängig bei einer REST API) zu packen ist kein Problem!

Gruß, Eckhart

PS: Bis auf die eingefügten Kommentare ist das Format kein Fake, a la "man könnte das so tun", sondern mein Produktiv-Format um Konfigurationen auf meine Hauptplatinen zu bringen. Nur "kann ich kein GUI" und benutzt diverse Umwege um das vom Excel PG, oder dem pyPG zu generieren.

PPS: Konfiguriert sind in dem Beispiel zwei Heartbeat LEDs auf Kanal 0 und eine Const LED auf Kanal 1 mit DCC Adresse 2000.

Config-IP-Rail-WS2811-Pico1-000400000003.zip

(904 Bytes) 9-mal heruntergeladen

[Eckhart]

Hi all!

Ich habe eben mal geguckt und der REST API Ansatz wäre so universell, dass man sowas auch für den Excel Programm Generator und Pattern Configurator umsetzen könnte:

https://learn.microsoft.com/de-de/share ... s-rest-api

Es gäbe dann eine einheitliche REST Schnittstelle zwischen Hardies MLL Konfigurations Urformat (was Hardi ursprünglich mal optimiert für den Nano entwickelt hat) auf dem Excel-PG/PC, dem pxPG und einem noch zu entwickelnden Web-Interface. Möglich damit anzusprechen und zu konfigurieren wären alle MLL Hauptplatinen, die ein LAN, oder WLAN Interface haben.

Der Haken ist natürlich, dass auch die Excel und die ESP32 (*) Fan-Boys dazu Lust haben müssten...

Gruß, Eckhart

(*) Hier könnte ich jemandem Hilfestellung geben, das Raspi Pico WLAN Konzept auf den ESP32 zu übertragen. (evtl. mit der Einschränkung, dass im Moment des Konfigurierens die WS2811 Stränge suspendiert werden müssen (oder Fehler haben))

[hlinke]

Hallo Harold, hallo Oli!

Die anhängende Datei illustriert, welcher Art die auszutauschenden Daten über die REST API sein würden. Derzeit als POST/GET HTTP Schnittstelle, um Konfigurationen via Files, von der Hauptplatine mit dem PC, austauschen zu können, aber das in ein übliches JSON Format (sehr gängig bei einer REST API) zu packen ist kein Problem!

Gruß, Eckhart

PS: Bis auf die eingefügten Kommentare ist das Format kein Fake, a la "man könnte das so tun", sondern mein Produktiv-Format um Konfigurationen auf meine Hauptplatinen zu bringen. Nur "kann ich kein GUI" und benutzt diverse Umwege um das vom Excel PG, oder dem pyPG zu generieren.

PPS: Konfiguriert sind in dem Beispiel zwei Heartbeat LEDs auf Kanal 0 und eine Const LED auf Kanal 1 mit DCC Adresse 2000.

Config-IP-Rail-WS2811-Pico1-000400000003.zip

@Eckhart
Damit ich das richtig verstehe (Brainstorming ...):
1. Könnte Deine Hauptplatine die MLL Hauplatine ersetzen und alle anderen MLL-Komponenten ansteuern? Ich nehme an daß das geht, da Du ja auch den WS2812 Datenbus verwendest.
2. Deine Hauptplatine (können wir der mal einen Namen geben?) wird über WLAN programmiert. Keine Probleme mit USB-Anschluß etc.
3. Anstatt jedesmal die Firmware neu zu kompilieren und zu übertragen wird nur eine Konfigurationsdatei übertragen
4. Du kannst (wie immer Du das auch geschafft hast) alle Makros der MLL ausführen lassen, so daß die heutige Funktionalität der MLL zur Verfügung steht. Oder gibt es Einschränkungen?
5. Ich könnte also die pyMobaLedLib so erweitern, daß Sie Deine Hauptplatine ansprechen kann und aus der Excelliste automatisch ein JSON Konfigurationsdatei erstellt und diese dann über WLAN und ein REST-API an Deine Hauptplatine schickt. Wie das im Detail funktioniert ist dann noch zu diskutieren.
6. Im nächsten Schritte könnte man dann über eine neue zusätzliche Benutzeroberfläche nachdenken, die inutiver und weniger fehleranfällig ist, als die Excel-Tabelle und die zunächst nur mit der neuen Hauptplatine und dem Rest API läuft.
7. Wenn das läuft, darüber nachdenken, wie man die bisherige HW in die neue GUI einbinden kann, um dann vollständig auf die Excel-Tabelle zu verzichten.

Ist das so sinnvoll, oder bin ich da irgendwo falsch abgebogen und habe etwas nicht richtig verstanden?

Viele Grüße
Harold

[Eckhart]

Hallo Harold!

@Eckhart
Damit ich das richtig verstehe (Brainstorming ...):
1. Könnte Deine Hauptplatine die MLL Hauplatine ersetzen und alle anderen MLL-Komponenten ansteuern? Ich nehme an daß das geht, da Du ja auch den WS2812 Datenbus verwendest.

1. Jein! Für die WS2811 klares "Ja", denn meine Hauptplatine unterstützt 16 WS2811 DMA Busse. Allerdings habe ich auf den ganzen "Tüdelüt", wie PushButtons, DMX, SX und auch einen Hardware DCC Receiver verzichtet. Anbindung an Zentralen via TCP (CS2/3 und ECoS); damit aber auch MM und mfx und natürlich bidirektional und alle Rückmeldekontakte! LocoNet wäre denkbar.

2. Ja, sowohl Firmware-Update, als auch Konfiguration
3. Ja
4. Ja, mit der Einschränkung, dass ich derzeit keine "MLL-Extensions" ohne neue Firmware, die den Code dafür enthält, ausführen kann.
5. Ja

6+7. Mal sehen, denn das hängt ja auch stark von anderen ab!

Gruß, Eckhart

[hlinke]

Hallo Harold!

@Eckhart
Damit ich das richtig verstehe (Brainstorming ...):
1. Könnte Deine Hauptplatine die MLL Hauplatine ersetzen und alle anderen MLL-Komponenten ansteuern? Ich nehme an daß das geht, da Du ja auch den WS2812 Datenbus verwendest.

1. Jein! Für die WS2811 klares "Ja", denn meine Hauptplatine unterstützt 16 WS2811 DMA Busse. Allerdings habe ich auf den ganzen "Tüdelüt", wie PushButtons, DMX, SX und auch einen Hardware DCC Receiver verzichtet. Anbindung an Zentralen via TCP (CS2/3 und ECoS); damit aber auch MM und mfx und natürlich bidirektional und alle Rückmeldekontakte! LocoNet wäre denkbar.

2. Ja, sowohl Firmware-Update, als auch Konfiguration
3. Ja
4. Ja, mit der Einschränkung, dass ich derzeit keine "MLL-Extensions" ohne neue Firmware, die den Code dafür enthält, ausführen kann.
5. Ja

6+7. Mal sehen, denn das hängt ja auch stark von anderen ab!

Gruß, Eckhart

Hallo Eckhart,

das hört sich doch schon mal ganz gut an.
Wir können ja mal versuchen Deine HW in die pyMobaledLib einzubinden und dann kann der Anwender entscheiden, ob er das "Tüdelüt" braucht oder ob ihn die einfachere Anwendung und die 16 WS2811 DMA Busse locken können.

Was hältst Du davon?

Viele Grüße
Harold

[Moba_Nicki]

....

1. Jein! Für die WS2811 klares "Ja", denn meine Hauptplatine unterstützt 16 WS2811 DMA Busse. Allerdings habe ich auf den ganzen "Tüdelüt", wie PushButtons, DMX, SX und auch einen Hardware DCC Receiver verzichtet. Anbindung an Zentralen via TCP (CS2/3 und ECoS); damit aber auch MM und mfx und natürlich bidirektional und alle Rückmeldekontakte! LocoNet wäre denkbar.

Hallo Eckhart

diese ganze "Tüdelüt" ist für mich wichtig. Ich habe keine Digitalzentrale, welche die Befehle aussenden kann und ohne kann ich die Ergenisse nicht auslösen.
Zudem wird die MLL nicht nur bei, nicht auf der MoBa, sondern auch abseits davon verwendet.

Liebe Grüße
Dominik

[Eckhart]

Hallo Harold!

Hallo Harold!

@Eckhart
Damit ich das richtig verstehe (Brainstorming ...):
1. Könnte Deine Hauptplatine die MLL Hauplatine ersetzen und alle anderen MLL-Komponenten ansteuern? Ich nehme an daß das geht, da Du ja auch den WS2812 Datenbus verwendest.

1. Jein! Für die WS2811 klares "Ja", denn meine Hauptplatine unterstützt 16 WS2811 DMA Busse. Allerdings habe ich auf den ganzen "Tüdelüt", wie PushButtons, DMX, SX und auch einen Hardware DCC Receiver verzichtet. Anbindung an Zentralen via TCP (CS2/3 und ECoS); damit aber auch MM und mfx und natürlich bidirektional und alle Rückmeldekontakte! LocoNet wäre denkbar.

2. Ja, sowohl Firmware-Update, als auch Konfiguration
3. Ja
4. Ja, mit der Einschränkung, dass ich derzeit keine "MLL-Extensions" ohne neue Firmware, die den Code dafür enthält, ausführen kann.
5. Ja

6+7. Mal sehen, denn das hängt ja auch stark von anderen ab!

Gruß, Eckhart

Hallo Eckhart,

das hört sich doch schon mal ganz gut an.
Wir können ja mal versuchen Deine HW in die pyMobaledLib einzubinden und dann kann der Anwender entscheiden, ob er das "Tüdelüt" braucht oder ob ihn die einfachere Anwendung und die 16 WS2811 DMA Busse locken können.

Was hältst Du davon?

Viele Grüße
Harold

Dann schlage ich vor, dass du dir einen Raspi Pico W (am besten gleich mit gelöteten Pin-Headern) besorgst und ich dir meinen WLAN Bootloader und die Firmware vorbereite, mit der du starten kannst. Leider habe ich gerade keine Platinen mehr, aber für den Anfang reicht ein Taster und ein WS2811 Anschluß auf einem Breadboard. Alles andere geht ja über WLAN!

Allerdings komme ich nochmal zurück auf folgende Kernfrage:

Hallo Harold, hallo Oli!
Hast du eigentlich schon mal den Text, den du in MobaLedLib_Configuration als C-Source erzeugst, innerhalb deines Python Programms, in den binären MLL Config[] Chunk übersetzt, der letzten Endes auf einer MLL Hauptplatine als Konfiguration abläuft?

Das ist nämlich die Crux! Die Hauptplatinen (nicht nur meine, sondern auch der Nano und der ESP32) verstehen nämlich gar nicht den Text, den du in LED_AutoProg.h schreibst, sondern nur das Format, das sich Hardi mal hoch optimiert (!!!) für den Nano ausgedacht hat! Um von dem Abstrakt Format, das es dem gurkigen Visual Basic nicht zu schwer machen sollte, zum Nano Format zu kommen, ackert aber der C-Präprozessor wie wild

ihmo hast du mit Python zwei Möglichkeiten:

1. Irgendein Tool benutzen, dass in Python C-Sourcen analysieren kann

2. Selber schlau hingucken und viel nachdenken!

Ich würde 2. nehmen denn die Limits von solchen Tools sehen wir ja gerade wieder bei dem tollen responsive design der Excel nach Python bib.

Ach ja, als 3. Möglichkeit könnte man natürlich auch Hardi fragen und ihn nötigen, für sein Binärformat eine Doku zu schreiben

Gruß, Eckhart

PS: Vielleicht hat Oli auch eine Idee, denn für einen Web basierenden Ansatz, müsste er es ja auch können! (und sinnvoller Weise könntet ihr euch vielleicht die Arbeit teilen)

[hlinke]

Hallo Eckhart

diese ganze "Tüdelüt" ist für mich wichtig. Ich habe keine Digitalzentrale, welche die Befehle aussenden kann und ohne kann ich die Ergenisse nicht auslösen.
Zudem wird die MLL nicht nur bei, nicht auf der MoBa, sondern auch abseits davon verwendet.

Liebe Grüße
Dominik

Hallo Dominik,

Du hast vollkommen Recht. Diese "Tüdelüt" ist gar nicht so unwichtig und es gibt bestimmt viele Anwendungen, wo besonders z.B die Taster gebraucht werden.
Aber ich glaube, das Hauptproblem wird erstmal sein, die Platine überhaupt einzubinden. Wenn das dann wirklich gut funktionert, dann werden wir für die Taster, DCC Interface usw. auch eine Lösung finden.
Und die anderen Platinen werden ja nicht verschwinden ...

Viele Grüße
Harold

[hlinke]

Hallo Harold!

Hallo Harold!



1. Jein! Für die WS2811 klares "Ja", denn meine Hauptplatine unterstützt 16 WS2811 DMA Busse. Allerdings habe ich auf den ganzen "Tüdelüt", wie PushButtons, DMX, SX und auch einen Hardware DCC Receiver verzichtet. Anbindung an Zentralen via TCP (CS2/3 und ECoS); damit aber auch MM und mfx und natürlich bidirektional und alle Rückmeldekontakte! LocoNet wäre denkbar.

2. Ja, sowohl Firmware-Update, als auch Konfiguration
3. Ja
4. Ja, mit der Einschränkung, dass ich derzeit keine "MLL-Extensions" ohne neue Firmware, die den Code dafür enthält, ausführen kann.
5. Ja

6+7. Mal sehen, denn das hängt ja auch stark von anderen ab!

Gruß, Eckhart

Hallo Eckhart,

das hört sich doch schon mal ganz gut an.
Wir können ja mal versuchen Deine HW in die pyMobaledLib einzubinden und dann kann der Anwender entscheiden, ob er das "Tüdelüt" braucht oder ob ihn die einfachere Anwendung und die 16 WS2811 DMA Busse locken können.

Was hältst Du davon?

Viele Grüße
Harold

Dann schlage ich vor, dass du dir einen Raspi Pico W (am besten gleich mit gelöteten Pin-Headern) besorgst und ich dir meinen WLAN Bootloader und die Firmware vorbereite, mit der du starten kannst. Leider habe ich gerade keine Platinen mehr, aber für den Anfang reicht ein Taster und ein WS2811 Anschluß auf einem Breadboard. Alles andere geht ja über WLAN!

Allerdings komme ich nochmal zurück auf folgende Kernfrage:

Hallo Harold, hallo Oli!
Hast du eigentlich schon mal den Text, den du in MobaLedLib_Configuration als C-Source erzeugst, innerhalb deines Python Programms, in den binären MLL Config[] Chunk übersetzt, der letzten Endes auf einer MLL Hauptplatine als Konfiguration abläuft?

Das ist nämlich die Crux! Die Hauptplatinen (nicht nur meine, sondern auch der Nano und der ESP32) verstehen nämlich gar nicht den Text, den du in LED_AutoProg.h schreibst, sondern nur das Format, das sich Hardi mal hoch optimiert (!!!) für den Nano ausgedacht hat! Um von dem Abstrakt Format, das es dem gurkigen Visual Basic nicht zu schwer machen sollte, zum Nano Format zu kommen, ackert aber der C-Präprozessor wie wild

ihmo hast du mit Python zwei Möglichkeiten:

1. Irgendein Tool benutzen, dass in Python C-Sourcen analysieren kann

2. Selber schlau hingucken und viel nachdenken!

Ich würde 2. nehmen denn die Limits von solchen Tools sehen wir ja gerade wieder bei dem tollen responsive design der Excel nach Python bib.

Ach ja, als 3. Möglichkeit könnte man natürlich auch Hardi fragen und ihn nötigen, für sein Binärformat eine Doku zu schreiben

Gruß, Eckhart

PS: Vielleicht hat Oli auch eine Idee, denn für einen Web basierenden Ansatz, müsste er es ja auch können! (und sinnvoller Weise könntet ihr euch vielleicht die Arbeit teilen)

Ich würde auch 2. bevorzugen.
Ich werde mal Hardi fragen, was er meint ...

Viele Grüße
Harold

[Eckhart]

Hallo Dominik!

....

1. Jein! Für die WS2811 klares "Ja", denn meine Hauptplatine unterstützt 16 WS2811 DMA Busse. Allerdings habe ich auf den ganzen "Tüdelüt", wie PushButtons, DMX, SX und auch einen Hardware DCC Receiver verzichtet. Anbindung an Zentralen via TCP (CS2/3 und ECoS); damit aber auch MM und mfx und natürlich bidirektional und alle Rückmeldekontakte! LocoNet wäre denkbar.

Hallo Eckhart

diese ganze "Tüdelüt" ist für mich wichtig. Ich habe keine Digitalzentrale, welche die Befehle aussenden kann und ohne kann ich die Ergenisse nicht auslösen.
Zudem wird die MLL nicht nur bei, nicht auf der MoBa, sondern auch abseits davon verwendet.

Liebe Grüße
Dominik

Das ist nicht abwertend gemeint, aber meine Hauptplatine ist eine one man show (es gibt nur eine Person, die sie nutzt!) und um weiterzukommen habe ich erstmal alles rausgeschmissen, was ich selber nicht verwende. Die bisherige Lösung ist ganz sicher für viele Leute wichtig und wird bestimmt noch lange leben!

Um so wichtiger ist es, dass sich endlich mal jemand findet, der sagt:

"Ja, ich habe mich ganz bewußt für den ESP32 entschieden, obwohl ich weiß, dass FastLED und WLAN gleichzeitig schwierig ist, aber ich habe mir trotzdem die Arbeit gemacht, endlich mal eine (oder mehrere) von den unzähligen Webserver-Lösungen für den ESP32 anzuschmeißen und die Koexistenz mit Hardies MobaLedLib Code auszuprobieren"

So eine Person wird gesucht! Kennst du da vielleicht jemanden?

Gruß, Eckhart

PS: Danke für deine Arbeit für das neue Forum und den Wiki!

[hlinke]

@Eckhart
Hardi ist im Urlaub.

Ich schlage vor, daß wir uns nach seinem Urlaub mit Hardi und Jürgen zusammen setzen und besprechen, wie wir weiter vorgehen können.

Viele Grüße
Harold

[oliwel]

"Ja, ich habe mich ganz bewußt für den ESP32 entschieden, obwohl ich weiß, dass FastLED und WLAN gleichzeitig schwierig ist, aber ich habe mir trotzdem die Arbeit gemacht, endlich mal eine (oder mehrere) von den unzähligen Webserver-Lösungen für den ESP32 anzuschmeißen und die Koexistenz mit Hardies MobaLedLib Code auszuprobieren"

Die Koexistenz halte ich für nicht notwendig - ich programmiere ja nicht den ganzen Tag, es wäre IMHO durchaus akzeptabel wenn man den ESP zwischen "Mach Licht" und "Programmier mich" umschaltet. Ob dafür dann ein Hardware-Taster irgendwo klemmt oder eine Art "Wake on WLAN" implementiert müßte man halt mal sehen was geht, ich hab von Fähigkeiten und Ressourcen keine Ahnung.

Und bzgl. dem Tüteldü - ich hatte den Pfad ja damals mit der Neuentwicklung der ESP Platine schonmal beschritten, ich denke aber das Feedback zur 102er gibt den "Urvätern" Recht dass hier durchaus ein UseCase da ist den man weiterhin supporten sollte.

PS: Vielleicht hat Oli auch eine Idee, denn für einen Web basierenden Ansatz, müsste er es ja auch können! (und sinnvoller Weise könntet ihr euch vielleicht die Arbeit teilen)

IMHO wäre der sinnvollste Weg den bestehenden Funktionalen Code der Effekte in eine Lib auf dem ESP zu packen die man dann per Funktionsaufruf ansprechen kann und dann laden wir einfach das bekannte Textformat auf den ESP und lassen den daraus den Programmablauf zusammenbauen. Ich denke nicht das es sinnvoll und auch nicht notwendig ist das Binärformat außerhalb zu erzeugen.

[hlinke]

IMHO wäre der sinnvollste Weg den bestehenden Funktionalen Code der Effekte in eine Lib auf dem ESP zu packen die man dann per Funktionsaufruf ansprechen kann und dann laden wir einfach das bekannte Textformat auf den ESP und lassen den daraus den Programmablauf zusammenbauen. Ich denke nicht das es sinnvoll und auch nicht notwendig ist das Binärformat außerhalb zu erzeugen.

Was ist das bekannte Textformat?
Die Excel-Zeilen als Text?
Heute werden diese Zeilen relativ einfach in ein C-Programm umgewandelt, daß dann kompiliert wird und als Programm auf den ESP geladen wird.
Der Schritt von dem Textformat (egal wie es aussieht) zum Steuerprogramm zur Ansteuerung von Hardis Bibliothek ist das Problem.
Der ESP32 kann sein eigenes Programm nicht kompilieren und dann ausführen.
Wie bekommen wir es hin, daß die Firmware konstant bleibt und nur Konfigurationsdaten ausgetauscht werden müssen und wir trotzdem die gesamte Funktionalität der MLL behalten?
Ich habe darauf keine Antwort.
Vielleicht kann Jürgen @jueff etwas dazu sagen?
Gibt es da eine Chance?

Viele Grüße
Harold

[Eckhart]

Hallo Oli!

"Ja, ich habe mich ganz bewußt für den ESP32 entschieden, obwohl ich weiß, dass FastLED und WLAN gleichzeitig schwierig ist, aber ich habe mir trotzdem die Arbeit gemacht, endlich mal eine (oder mehrere) von den unzähligen Webserver-Lösungen für den ESP32 anzuschmeißen und die Koexistenz mit Hardies MobaLedLib Code auszuprobieren"

Die Koexistenz halte ich für nicht notwendig - ich programmiere ja nicht den ganzen Tag, es wäre IMHO durchaus akzeptabel wenn man den ESP zwischen "Mach Licht" und "Programmier mich" umschaltet. Ob dafür dann ein Hardware-Taster irgendwo klemmt oder eine Art "Wake on WLAN" implementiert müßte man halt mal sehen was geht, ich hab von Fähigkeiten und Ressourcen keine Ahnung.

Das wäre sicher ein gangbarer Weg! Es bleibt allerdings die Fragestellung, wie die Direktbedienung z.B. "Farbtest", etc. zu bewerkstelligen wäre, denn mit einer Telnet-Verbindung nicht das zu können, was mit einer in USB eingebetteten seriellen Verbindung schon mal ging, empfände ich schon als Einschränkung!

Und bzgl. dem Tüteldü - ich hatte den Pfad ja damals mit der Neuentwicklung der ESP Platine schonmal beschritten, ich denke aber das Feedback zur 102er gibt den "Urvätern" Recht dass hier durchaus ein UseCase da ist den man weiterhin supporten sollte.

Zweifellos! Daher auch mein Thread bei der 102!

PS: Vielleicht hat Oli auch eine Idee, denn für einen Web basierenden Ansatz, müsste er es ja auch können! (und sinnvoller Weise könntet ihr euch vielleicht die Arbeit teilen)

IMHO wäre der sinnvollste Weg den bestehenden Funktionalen Code der Effekte in eine Lib auf dem ESP zu packen die man dann per Funktionsaufruf ansprechen kann und dann laden wir einfach das bekannte Textformat auf den ESP und lassen den daraus den Programmablauf zusammenbauen. Ich denke nicht das es sinnvoll und auch nicht notwendig ist das Binärformat außerhalb zu erzeugen.

Die MLL als Library ist ja auch heute schon immer auf dem ESP (oder dem Nano, oder dem Pico)!

Den Textansatz auf dem uC halt ich aber, aus mindestens 3 Gründen, für überhaupt keine gute Idee!

1. Ein interpretativer Ansatz wäre viel zu langsam! Der Cadence/Tensilica und der ARM können zwar schon was, aber um bis zu 8 Stränge mit 800 kHz on the fly aus einer Textbeschreibung synthetisieren zu können würde es ganz sicher nicht reichen!

2. Ein Präcompiler Ansatz wäre ein Monster für so einen uC! Was auf einer typischen PC Frontend Plattform ein leichtes ist, weil man z.B. ein richtiges Filesystem zur Verfügung hat, würde auf dem uC unhandhabar! Hast du dir mal Hardies MobaLedLib.h angeguckt? Parsing und lexikalische Analyse von so etwas, zur Umwandung in die smarte und kompakte Binärform von Hardi, würde alle Möglichkeiten eines uC sprengen.

3. Wir haben nicht nur kein Filesystem, sondern auf dem ESP32 (und dem Pico) nicht mal ein physikalisches EEPROM! Das läuft alles in einer EEPROM Emulation im Flash. Wir haben zwar relativ reichlich Flash, aber das Problem ist der wear count (page erase cycles). Möglichst kompakte Konfigurationsdaten sind hier entscheidend! (sogar normale User haben inzwischen gelernt, dass man SSDs nicht so vollfüllen kann, wie es bei HDs problemlos ging)

Wird das Textformat auf dem uC Ziel des Spiels, würde ich erstmal abwarten, bis du, Harold, Jürgen, oder Hardie das für den ESP32 implementiert habt und dann gucken, wie gut es läuft und je nachdem auch bei mir adaptieren (oder selber auf den ESP32 zurückgehen, wenn die WLAN/FastLED Koexistenzprobleme vielleicht gar nicht so schlimm sind, oder gelöst werden konnten)

Gruß, Eckhart