Diskussion Weiterentwicklung der pyMobaLedLib

[Eckhart]

Hallo Harold!

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

Ich bin zwar nicht Jürgen, aber ich kenne dennoch die Antwort. In meiner Pico Umgebung ist der Orginal-Soure von Hardi und Jürgen eincompiliert. Ich musste bislang keine einzige Zeile Code verändern, sondern konnte alles über einen Mantel-Wrapper, quasi als Virtualisierung der Arduino Umgebung lösen.

Mein "Haupttrick" ist dabei das Ausnutzen einer historischen Altlast des Atmel Assembler Instruction Sets. Dieses hat zwingend erfordert, dass man "const" Daten, die im Flash gespeichert waren, mit sog. PGM_READ_xxx Zugriffen attributieren musste. Das hat Hardi konsequent genutzt und mir ermöglicht, das mit meinem virtuellen Arduino Wrapper auf eine eigene Konfiguration umzulenken, die über das WLAN/Webinterface ladbar ist.

Es sind wirklich alle MLL Funktionen verfügbar und auch für eine nachträglich eingebrachte LED Konfiguration. (die auch deutlich umfangreicher sein kann)

Gruß, Eckhart

[hlinke]

Hallo Harold!

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

Ich bin zwar nicht Jürgen, aber ich kenne dennoch die Antwort. In meiner Pico Umgebung ist der Orginal-Soure von Hardi und Jürgen eincompiliert. Ich musste bislang keine einzige Zeile Code verändern, sondern konnte alles über einen Mantel-Wrapper, quasi als Virtualisierung der Arduino Umgebung lösen.

Mein "Haupttrick" ist dabei das Ausnutzen einer historischen Altlast des Atmel Assembler Instruction Sets. Dieses hat zwingend erfordert, dass man "const" Daten, die im Flash gespeichert waren, mit sog. PGM_READ_xxx Zugriffen attributieren musste. Das hat Hardi konsequent genutzt und mir ermöglicht, das mit meinem virtuellen Arduino Wrapper auf eine eigene Konfiguration umzulenken, die über das WLAN/Webinterface ladbar ist.

Es sind wirklich alle MLL Funktionen verfügbar und auch für eine nachträglich eingebrachte LED Konfiguration. (die auch deutlich umfangreicher sein kann)

Gruß, Eckhart

Hallo Eckhart,

wenn das bei Dir funktioniert, wo ist dann das Problem?
Vielleicht könntest Du mal in einen Ablaufplan zeigen, was machst Du genau, um von dem Excel-Programm zu Deinen Konfigurationsdaten zu kommen, die dann an den Prozessor gesendet werden?
Leider verstehe ich immer noch nicht so ganz, was Du da machst.

Viele Grüße
Harold

[Eckhart]

Hallo Harold!

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

Ich bin zwar nicht Jürgen, aber ich kenne dennoch die Antwort. In meiner Pico Umgebung ist der Orginal-Soure von Hardi und Jürgen eincompiliert. Ich musste bislang keine einzige Zeile Code verändern, sondern konnte alles über einen Mantel-Wrapper, quasi als Virtualisierung der Arduino Umgebung lösen.

Mein "Haupttrick" ist dabei das Ausnutzen einer historischen Altlast des Atmel Assembler Instruction Sets. Dieses hat zwingend erfordert, dass man "const" Daten, die im Flash gespeichert waren, mit sog. PGM_READ_xxx Zugriffen attributieren musste. Das hat Hardi konsequent genutzt und mir ermöglicht, das mit meinem virtuellen Arduino Wrapper auf eine eigene Konfiguration umzulenken, die über das WLAN/Webinterface ladbar ist.

Es sind wirklich alle MLL Funktionen verfügbar und auch für eine nachträglich eingebrachte LED Konfiguration. (die auch deutlich umfangreicher sein kann)

Gruß, Eckhart

Hallo Eckhart,

wenn das bei Dir funktioniert, wo ist dann das Problem?
Vielleicht könntest Du mal in einen Ablaufplan zeigen, was machst Du genau, um von dem Excel-Programm zu Deinen Konfigurationsdaten zu kommen, die dann an den Prozessor gesendet werden?
Leider verstehe ich immer noch nicht so ganz, was Du da machst.

Viele Grüße
Harold

Hallo Harold!

Ich meine natürlich nicht die Textdaten, sondern das Binärformat! Die MobaLedLib Bibliothek, mit allen MLL Funktionen, ist IMMER (egal, wieviel davon genutzt wird!) auf JEDER MLL-Hauptplatine komplett verfügbar! Die binäre Konfiguration ist also zwischen den Hauptplatinen austascubar und es wandern IMMER ALLE konfigurierten Funktionen mit!

Mein Workflow:

- Ich kreiere mit deinem pyPG eine beliebige LED_AutoProg.h (mit welchen Macros auch immer)
- Dann übersetze ich die MLL nicht für einen Nano, oder ESP32, sondern für meinen Pico und lade es auf ebenjenen (einen Pico on Bench)
- Dieser Pico hat auch eine Webschnittstelle und damit kann man die binäre Konfiguration extrahieren und in dem Fileformat speichern, das ich bereits zeigte. Das ist sehr kompakt und nur wenige Bytes pro Macro!
- Diese Datei lade ich, wieder via Webschnittstelle, als File auf einen beliebigen anderen Pico auf meiner Bahn
- Das aktiviere ich dort und es sind alle Macros transferiert und laufen auf der Zielplatine ab.

Das meinte ich oben mit "Umwege"! Wenn der Programm Generator die paar Byte direkt erzeugen könnte, wäre es einfacher. 99% des Compilates sind ja bereits auf allen Haupplatinen. (und überall gleich!)

Gruß, Eckhart

[hlinke]

Ok. Danke. Jetzt verstehe ichetwas besser, was Du meinst.

Ist diese Binärdatei prozesorunabhängig? Kann man dieselbe Datei auch in einen ARDUINO oder ESP32 laden? Oder hat sie dort ein etwas anderes Format?

Harold

[Eckhart]

Hallo Harold!

Ok. Danke. Jetzt verstehe ichetwas besser, was Du meinst.

Ist diese Binärdatei prozesorunabhängig? Kann man dieselbe Datei auch in einen ARDUINO oder ESP32 laden? Oder hat sie dort ein etwas anderes Format?

Harold

Jein. Die codierte LED Number ist beim Nano ein Byte (da eh' nur 256 LEDs möglich) und beim ESP32 und Pico ein Word (16 Bit little endian). Zwischen dem ESP32 und den Pico wird man also Konfigurationen hin- und herschieben können. (habe ich noch nicht gemacht, aber ich habe bislang noch nichts gegenteiliges gesehen)

Gruß, Eckhart

[hlinke]

So. Ich habe mir jetzt mal zwei Picos (RASPBERRY PI PICO-WH) bestellt.
Sollen Mittwoch nächster Woche ankommen. Dann kann ich mal anfangen ein bißchen zu probieren.

Harold

[oliwel]

Ich versteh aktuell nichtmal die Hälfte von den "Problemen" die ihr seht aber vor ein paar Jahren war eines meiner ersten Arduino Projekte eine Vitrinensteuerung für mein Krokodil im Wohnzimmer - da ist eine DCC "Zentrale" auf Basis des DCC-Ex Codes in Kombination mit einer Mini-Config die einen Tasteneingang mit einer DCC Befehlskette "verlinkt", d.h. ich kann dort per Konsole in das "EEPROM" sowas laden wie "Taste 1: DCC Befehl A, 3 Sekunden warten, DCC Befehl B,..." - das "Programm" steht also einfach in einer Datenstruktur die man nativ aus dem Speicher holen kann, wenn eine Taste gedrückt wird. Die MLL ist sicher um Längen komplexer aber von der Grundidee sollte es doch kein Problem sein das auch hier so zu bauen.

Mein erster Ansatz wäre es gewesen die "Exceltabelle" in der pyMLL eben direkt in ein Zielformat umzubauen das man in Datenstrukturen auf dem ESP schreibt, wenn das mit WLAN aufgrund der Parallelität nicht geht, wäre ein erste Zwischenschritt das weiterhin Seriell zu machen, so ähnlich funktioniert ja AFAIR aktuell auch der Farbtest.

Bevor wir uns also verzetteln wäre es IMHO sinnvoll man die Probleme zu zerlegen, als Gesamtbild würde ich mir sowas vorstellen:

WebBrowser -> HTTP API -> Stück Software auf dem PC -> Link zum ESP -> ESP

Wenn wir eine HW haben die dann den PC ersetzen kann und man direkt das WebUI auf dem Controller hat, wäre das natürlich großartig aber auf dem ESP sehe ich das auch nicht und nochmal eine neue HW ins Spiel bringen ist absolut nicht sinnvoll/leistbar.

Schritt 1 auf der rechten Seite wäre wie schon von Eckhart beschrieben m.E. die Konfiguration ohne Kompilation hinzubekommen indem man ein "Konfigregister" im ESP passend beschreibt - das ist dann wohl das was bisher als "Hardis Binärformat" betitelt wurde - nachdem wir sowohl den Code als auch noch Hardis Hirn im Zugriff haben, kann es ja nicht so schwer sein das zu isolieren. Ob dass dann als C Lib in python hängt oder es "einfach" ist das in python nativ zu implementieren muss man entscheiden wenn wir verstanden haben was da passiert.

Auf der linken Seite - und das war eigentlich die Idee hinter meinem "Urpost" zu dem Thema letzte Woche - ging es mir eigentlich nur darum das bestehende TK Interface durch eine WebUI zu ersetzen die über eine HTTP API mit der pyMLL kommuniziert. So wie ich aber nun Harold verstanden habe sind GUI und Coderstellung über die VBA Bridge verzahnt so dass man wohl beide Seiten gemeinsam angehen muss...