OpenKNX Firmware-Update

[mumpf]

Cool, das sieht gut aus! Aber kein USB von außen erreichbar, oder? Zumindest, wenn das im Schaltschrank eingebaut ist...

Mal an die Hardware-Experten: Würde es irgendwie Sinn machen, die Programmierung der Firmware über SWT zu erlauben statt über USB? Das erfordert ja nur 3 Pins, man könnte dann einfacher eine 3-Stift-Buchse (oder wie das immer heißt) im Deckel vom Gehäuse verfügbar machen oder bei den anderen (zukünftigen) UP-Geräten.
Als Programmiergerät könnte man das Picotool nehmen, also einen anderen Pico, den man da anschließt. Oder den J-Link, wenn den schon jemand hat.

Ich reden davon, die Geräte so unterzubringen, dass sie ohne Ausgebaut zu werden immer aktualisiert werden könnten. Ich mache das schon lange mit den Sensormodulen. Ich bau die immer mit einer kurzen Leitung mit einem Stecker ein. Zum Update muss ich nur die Abdeckung (vom Schalterprogramm) abnehmen, das Kabel rausziehen, den J-Link anschließen und kurz proggen. War mir sehr wichtig.

Man könnte in OpenKNX das ja zum Standard erheben. Nur so ne Idee. Eine USB-Buchse rauszuführen ist einfach aufwändiger und wahrscheinlich auch teurer, oder?

Gruß, Waldemar

[willisurf]

Wäre ein Update ganz ohne Stecker denkbar? Irgendwie ist das ja immer störend.
WLAN oder IP-Schnittstelle mit gesondertem Windows Programm?

[mumpf]

Verschiedene:

• Über den Bus: Dauert zu lange.
• WLAN: nicht über den Bus versorgt (hat schon mal jemand beim Pico W geschaut?)
• Netzwerk: Braucht man eben ein Netzwerkkabel an der Stelle. Und auch hier wahrscheinlich die Busversorgung fraglich?

Und dann natürlich immer die Frage: Wie macht man so ein Update und wer schreibt das Update-Programm...

Gruß, Waldemar

[willisurf]

Stimmt schon, wahrscheinlich ist das überbewertet. Irgendwann ist ja die Updatehäufigkeit recht gering.

[Ing-Dom]

Die USB-Buchse ist gar nicht so teuer. ich hab grad 30 UP1-Progger bestücken lassen, die Micro-USB kostet 0,486 US-Cent.

Aber man braucht meistens dann einen 5V => 3v3 regler und der braucht auch wieder Platz.
Daher hab ich das beim UP1-Controller ausgelagert, auf den UP1-Progger.

Man könnte jetzt natürlich einfach die USB-Lines (3v3, D+, D-, Gnd) auf 1.27er Stiftleisten rausführen und mit dem UP1-Progger arbeiten.
Aber wenns irgendwie geht würde ich lieber ne USB Buchse vorsehen.

[Ing-Dom]

Über den Bus: Dauert zu lange.

das war mein Favorit, und mit dem RP2040 auch technisch ECHT machbar.
einen prototypen hab ich da mal gebaut
- aber: die FW gehen Richtung 250k, und das dauert einfach ewig über den Bus... so im Bereich Stunden.
und nach 5min fangen die gira rauchmelders an zu pfeifen.

[thilog]

aber: die FW gehen Richtung 250k, und das dauert einfach ewig über den Bus... so im Bereich Stunden.

Heißt das im Umkehrschluss, dass die Firmware z.B. meiner MDT-Geräte im Gegensatz echt kompakt ist? Hab meine Präsenzmelder vor ein paar Wochen via ETS geupdated. Das hat zwar ein bisschen gedauert, aber im Bereich von Stunden war das nicht...

[mumpf]

Heißt das im Umkehrschluss, dass die Firmware z.B. meiner MDT-Geräte im Gegensatz echt kompakt ist?

Nein, das kann man daraus nicht ableiten.

Die größe der (zu übertragenden) Firmware hängt von mehreren Faktoren ab:

• Offensichtlich: Vom Umfang der Funktionalität
• Vom verwendeten Prozessor / Prozessorarchitektur
• Vom Modularisierungskonzept der Gesamtfirmware

Um den letzten Punkt auszuführen: Eine Firmware (auf dem Gerät) wird immer einen KNX-Stack haben, der für die Kommunikation sorgt, einen Anteil "Hardware-Treiber", der die vorhandene Hardware (Sensoren, Led, usw.) abstrahiert und den eigentlichen Funktionsblock, der das Verhalten des Gerätes implementiert.
Wenn man es schafft, dass die compilierte (auf dem Prozessor lauffähige) Firmware in solche Module partitioniert ist, dann kann man nur einzelne davon austauschen und muss wesentlich weniger übertragen. Den KNX-Stack wirst Du quasi nie übertragen müssen, da der über zig verschiedene Geräte gleich ist und deswegen gut und stabil läuft. Die Hardware-Treiber wahrscheinlich auch eher selten, nur wenn dort ein fieser Bug gefunden wird. Üblicherweise überträgt man dann nur den Funktionsblock, weil dort 90% aller Korrekturen und Features landet. Und der ist dann nicht mehr so groß.

Wir müssen derzeit immer die gesamte Firmware (KNX-Stack, Hardware-Treiber und Funktionsblock) übertragen, um eine Modularisierung hat sich noch keiner gekümmert - und ich weiß ehrlich gesagt nicht mal, ob eine möglich wäre. Zusätzlich ist der RP2040-Prozessor scheinbar noch derart, dass dort das Compilat eher groß wird. Dafür ist der Prozessor schnell und sehr leistungsfähig.

Gruß, Waldemar

[Ing-Dom]

Zusätzlich ist der RP2040-Prozessor scheinbar noch derart, dass dort das Compilat eher groß wird. Dafür ist der Prozessor schnell und sehr leistungsfähig.

ne, das glaube ich nicht. Der Befehlssatz ist ja für den Core, also Cortex M0, da sollten keine gravierenden Unterschiede zum SAMD21 vorhanden sein.

In der Tat ist aber bereits das blink-sketch für den RP2040 mit dem EarleEPhilhower-Core schon 128k groß, meine ich.

Woran das genau liegt weiß ich nicht, aber da werden halt viele libs verwendet, am Ende landet da wohl mehr im binary als wirklich sein müsste...

[mumpf]

EarleEPhilhower-Core

Stimmt, an dem kann es auch liegen. Und vielleicht gibt es da nochmal eine Optimierung. Aber das Sensormodul mit 1-Wire und Logikmodul braucht auch auf dem SAMD 200k, alles Größen, die keinen Spass beim Download über den Bus machen.

Gruß, Waldemar

[philipp900]

Den RP2040 kenne ich nicht aber meine ESP32 bzw. ESP8266 mit KNX Firmware update ich über ArduinoOTA direkt aus VScode heraus bzw. übertrage das kompilierte Binary mittels Commandline.
Wlan lässt sich über Taster ein-/ausschalten und OTA über passwortgeschütztes Webinterface aktivieren.

[Ing-Dom]

wlan nur fürs FW Update einzubauen wäre schon ziemlich drüber, vom Strombedarf mal ganz abgesehen.

Mein Ziel bei OpenKNX Geräten ist schon ein gewissen Kostenoptimierung (das ist dem Bastler der 3 Stück baut egal) und auch eine weitgehende Standardkonformität.

Ich denk schon drüber nach ob es nicht vielleicht doch Sinn macht FW über BUS updatebar zu machen - ggf. über "Multicast" also über GAs, so dass alle gleichartigen Geräte im Haus gleichzeitig mit der FW versorgt werden können. Dazu müsste man noch ein Protokoll bauen mit dem dann die Geräte einzelne chunks die sie nicht bekommen haben nochmal nachfordern können.

Das muss dann aber auch so langsam gehen dass die Geräte a) weiterlaufen können und b) der Bus nicht überlastet wird.
Aber andererseits kann man das ja mal über Nacht verteilen.

Wokflow:
OPenKNX Update-Tool (GUI) starten.
Es zeigt alle OpenKNX Geräte an, mit allen relevanten Daten und FW-Versionen.
Dann kann ich eine FW-Verteilung starten an vorher ausgewählte Geräte.
nach X Stunden wird dann angezeigt welche Geräte die FW erfolgreich im Bauch haben und man kann das echte Update triggern - vorher haben die Geräte die FW nur im "Schattenspeicher".

[jeff25]

Wie funktionieren eigentlich diese Firmware Update Plugins der Hersteller. Gut es geht nicht pfeilschnell aber es geht gut, habe ich schon öfters bei unetrschiedlichen Devices gemacht... klar wäre es irgendwie cool das über den Bus zu machen aber erst wenn ein Gerät einigermassen ausgereift ist, jeden Tag würde ich es dann doch lieber über usb machen :-)

[Ing-Dom]

Wie funktionieren eigentlich diese Firmware Update Plugins der Hersteller. Gut es geht nicht pfeilschnell aber es geht gut, habe ich schon öfters bei unetrschiedlichen Devices gemacht...

steht in der Spec, die Daten werden über MemoryWrite/ExtMemoryWrite übertragen. die haben wahrscheinlich kleinere binaries.. denn mehr Daten bekommen die auch nicht über den Bus.

[STSC]

Is es eigentlich möglich, dass wenn die Firmware einmal auf dem RP2040 ist, dass zukünftig die Updates über KNX aufgespielt werden können?

[Ing-Dom]

du musst das schon richtig machen.
Im UF2 stecken ca. 50% Overhead, die nicht mit übertragen werden, bzw. bei meinem Ansatz nicht übertragen wurden. Das sind sehr viele 0en.

Ich kanns aktuell nicht testen weil ich keine Test-HW/FW aufgebaut hab. Ich meine es waren so knapp 50-100Byte/s ...

[Masifi]

Gar keinen ich fahre schon seit Jahren so, ohne das ich damit große Probleme hatte.

Meine HW ist aber dafür ausgelegt, zumindest treiben die unterschiedlichen Spannungsversorgungen nicht gegeneinander.
Daher kann ich nur für mich sprechen. USB anstecken zum Updaten oder für Debug-Zwecke ist temporär möglich, aber bitte nicht 24/7.

Es gab aber schon mal das Phänomen(nicht bei mir), dass das parametrisieren über die ETS nicht funktioniert wenn USB angesteckt ist. Da logischerweise USB wieder trennen.

[STSC]

du musst das schon richtig machen.
Im UF2 stecken ca. 50% Overhead, die nicht mit übertragen werden, bzw. bei meinem Ansatz nicht übertragen wurden. Das sind sehr viele 0en.

Ich kanns aktuell nicht testen weil ich keine Test-HW/FW aufgebaut hab. Ich meine es waren so knapp 50-100Byte/s ...

Ich habe heute mal einen Taster von MDT aktualisiert, die schaffen das auf 6-7 Minuten. Kann mir nicht vorstellen, dass die eine Firmware von nur 35KB haben.
Kann es evtl. sein dass man mit Extended Frames noch was rausholen kann? Welche APDU-Länge hast du verwendet, prinzipiell müsste ja 55 gehen.