ESP8266 KNX mit ETS

[Ing-Dom]

Mal ne Frage Richtung Firmware-Update.

Ich würde gern ein Binary über KNX an den Controller schicken, der soll das irgendwo in einem freien Flashbereich ablegen.

Hier wurde ja schonmal andiskutiert das über ETS / knxprod abzufahren, irgendwie widerstrebt mir hier aber die Komplexität, ich hätte es gerne etwas flexibler, gerade auch im Entwicklungsprozess.

Ich denke an ein PC-Tool das das Binary einliest und dann über KNX an das Gerät schickt.

Welche Mechanismen sind da im Stack schon vorhanden die man nutzen kann? als Telegramtyp würde sich ja memoryWrite anbieten.

[thesing]

Ich gehe mal von nicht IP-Geräten aus. (Da wäre am Stack vorbei am einfachsten.)
Ich würde sonst ein "properitäres" Interface-Objekt erstellen. Das kann man dann nach einer Adresse fragen, darüber memoryWrite direkt auf Flash umbiegen usw.
Das ist aber nicht wenig Aufwand. Da ist ein USB-Kabel sehr viel einfacher.

So richtig hab ich mich mit dem Thema noch nicht beschäftigt.
Ich würde in jedem Fall mal in die knxprods von Geräten schauen, die das über ETS machen. Dort sollten Kommandos/Telegramme drinstehen. Dann würde ich das ähnlich nachbauen.

[Ing-Dom]

Ich gehe mal von nicht IP-Geräten aus

genau, TP Geräte.

Ich hab gestern etwas im Stack gewühlt um die Umsetzbarkeit meiner Idee mit "magic" memory adressen zu prüfen.
Ich hatte die Hoffnung ich könnte dann memorywrites je nach adresse im memory-backend der plattform unterschiedlich behandeln.
die memory Klasse arbeitet aber mit direktem Zugriff über einen datapointer und memcpy, daher ist das mal nix wenn man nicht in den stack eingreifen will. Da bräuchte man einen RAM-Buffer in der Größe der binary.

Der MemoryWrite ist mit 64k adressbereich eigentlich auch schon zu klein.
UserMemoryWrite wäre angezeigt.


Gerade rausgefunden - Siemens arbeitet mit einem separatem Tool:
https://www.hqs.sbt.siemens.com/cps_...w_tools_de.htm

Leider hab ich kein passendes Gerät um mal ein Update mitzutracen.

[Ing-Dom]

thewhobox Ich würde das auch so sehen. Bei UserMemoryWrite hat man sogar noch ein Bit weniger. Dafür aber mehr Platz für die Adresse.

Es sind 2 Bit weniger. Also nur 15 statt 63 Byte.

Im Stack gibt es schon einen ExtMemoryWrite. Teilweise aber auskommentiert.
Wie ist denn da der Stand?

Ich gehe davon aus, du kennst die AN177. Gibt es eine Entsprechung für UserMemoryWrite mit Long Frame?
Oder ersetzt der beide?

in 03_05_03 findet man ja auch diese Aussage:

"The maximum memory address of 1 Mbyte is addressed via a 20 bit address value. Thus the value of PID_TABLE_REFERENCE shall be limited to 20 bit values only; the higher 12 bits shall be marked as reserved and set to 0.
These bits may later on be specified by the KNX Association to indicate usage of A_Memory_Write and A_UserMemory_Write on different or the same memory.
If these bits are set to 0 A_UserMemory_Write and A_Memory_Write shall address the same memory."

[thesing]

Ing-Dom Aktuell kann der Stack mit Flash nur über EEPROM-Emulation zugreifen. Das müsste also zuerst fertig gemacht werden. Dann würde ich einfache in Firmware-Interface-Objekt erstellen und dort "ganz normal" Speicher reservieren, Adresse holen und dann schreiben. Genau wie es bei den anderen Interface-Objekten wie Adresstabelle, Assoziationstabelle usw. auch beim parametriesieren gemacht wird.

[Ing-Dom]

Aktuell kann der Stack mit Flash nur über EEPROM-Emulation zugreifen. Das müsste also zuerst fertig gemacht werden.

hab ich mir angeschaut, das ist mir aktuell ne Nummer zu komplex. Ich werde erstmal den Stack anwenden und lernen, bevor ich an die Innereien gehe.

Zum Testen werde ich wohl mal den ExtMemoryWrite umbiegen mit einer Magic Address um das einfach mal auszuprobieren.


Verstehe ich das richtig das mittlerweile https://github.com/mumpf/multiply-channels das Tool der Wahl zum Erstellen der knxprods ist ?

Hab ich die angedachte Verwendung des Tool korrekt verstanden:
1) Gerüst-xml vom Tool erzeugen lassen
2) händisch die Paramter/Objekte etc... in die xml einbauen
3) ggf. xml prüfen
4) knxprod erzeugen

Gibt es einen guten Einstieg in die Struktur der xmls oder führt hier der einzige Weg über anschauenn bestehender xmls und ausprobieren?

[mumpf]

Hi,

Verstehe ich das richtig das mittlerweile https://github.com/mumpf/multiply-channels das Tool der Wahl zum Erstellen der knxprods ist ?

nicht unbedingt. Hängt davon ab, was Du machen willst. Mein Tool kann nur Projekte erzeugen, die Features bis incl. ETS 5.6 unterstützen (xml Schema Version 14). Die ETS 5.7 verwendet Schema Version 20, das kann mein Tool nicht. Natürlich kann 5.7 auch die früheren Schemata lesen. Aber falls man superneue Features der 5.7 nutzen will, könnte es sein, dass man das nicht kann.

Soviel ich weiß, kann das Tool von thesing auch mit Version 20 umgehen. Hab aber schon lange nicht mehr reingeschaut .

Mein Tool hab ich im wesentlichen dafür geschrieben, damit man Kanäle vervielfachen kann, also z.B. einen Schaltkanal in xml definiert und dann daraus 20 Schaltkanäle macht. Beschrieben hab ich die Funktion noch nicht, da ich immer wieder (inkompatible) Änderungen an der Kanalgenerierung gemacht habe. Den einfachen Fall (einfach ein knxprod zu erzeugen) hat das aber nie beeinflusst.

Ansonsten gehe ich wirklich so vor:

anschauenn bestehender xmls und ausprobieren

Gruß, Waldemar

[Ing-Dom]

Mein Tool hab ich im wesentlichen dafür geschrieben, damit man Kanäle vervielfachen kann, also z.B. einen Schaltkanal in xml definiert und dann daraus 20 Schaltkanäle macht.

Ja, das impliziert ja auch der Titel, aber gefunden hab ich das Feature nicht
Wenn du das mal grob beschreibst wäre super, das könnte ich auch brauchen.

[mumpf]

HI,

gefunden hab ich das Feature nicht

hab ich ja auch gut versteckt :-)

Um den Thread hier nicht mit der Beschreibung und Deinen Rückfragen vollzumüllen (und um mich nicht vollkommen zu blamieren, wie amateurhaft ich das realisiert habe), lagern wir das man in den Thread zu multiply-channels aus: https://knx-user-forum.de/forum/%C3%...it-ets-projekt

Bitte beachte auch das, was ich im Thread vorne geschrieben habe: Ist nur als ein Tool zur Vereinfachung der eigentlichen Aufgabe (xml zu erstellen) entstanden, und echt "gewachsene" Software! Mein Kenntnisstand zum xml ist ja auch erst über Zeit gewachsen. Ich bin nicht super stolz drauf, da kaum strukturiert, aber ich hab auch keine Zeit/Lust, es neu zu machen.

Gruß, Waldemar

[mumpf]

Hi Ing-Dom et all,

Mike (thewhobox) hat mich auf ModuleDef der Applikationen mit Schema-Version 20 (ETS 5.7) hingewiesen (Siehe https://knx-user-forum.de/forum/öffentlicher-bereich/knx-eib-forum/diy-do-it-yourself/1672351-kaenx-open-source-inbetriebnahme-software?p=1680458#post1680458). Da wird bereits in der Applikation ein Wiederholteil mit ModulDef EINMAL definiert und mit Module beliebig häufig aufgerufen. Das sieht mir vielversprechend aus.

Ansehen kann man sich das in einer Applikation der KNX Association, die direkt im Online-Kalatog verfügbar ist und zum KNX Virtual Projekt gehört:

0204 - PB, Applikationsprogramm KliX, Version 2.4

An das xml kommt man, wenn man das Produkt normal als knxprod exportiert, dann die Endung in .zip ändert und anschließend entpackt.

Ich will noch damit etwas rumspielen, würde dann mein multipy-channels noch passend erweitern, damit es auch damit umgehen kann. Ich will ja die Headerfile-Generierung und die Berechnung der Parameteradressen und der KO-Nummern nicht missen, aber es würde die knxprod-xml wesentlich kleiner machen.

Das nur mal zur Info, mir was das Thema neu...

Gruß, Waldemar

[thewhobox]

mumpf es erleichtert bestimmt auch wesentlich Anpassungen bei KOs/Parameter und der dynamischen Ansicht, da man sie nur einmal ändern muss und nicht 80 mal^^

Wollte das schon lange implementieren, aber meine aktuelle Importroutine lässt es nicht zu.
Sieht vom Aufbau her aber leicht verständlich aus.

[OutOfSync]

Moin zusammen,

das ModuleDef gehört zu den "Modular Application Programs". Da gibt es in der Hilfe vom Manufacturer Tool ein paar (wenige) Informationen: https://support.knx.org/hc/en-us/art...ation-Programs. Weiter unten auf der Seite ist ein Download für eine MAP Demo, das ist auch ganz interessant. Da kann man reingucken ohne das Manufacturer Tool zu haben, ist ja XML 😉

Viele Grüße, Julius

[mumpf]

Hi Julius,

danke für die Beispiele, das mit Repeat und Allocator kannte ich auch noch nicht. Man kann somit bereits in der Applikation Kanäle gut vervielfachen. Es ist auch schön zu sehen, wie die Zeilenanzahl der knxprod-xml immer weiter sinkt (447 Zeilen beim klassischen Ansatz mit 8 Kanälen, dann 172 wenn man nur Modules nutzt und abschließend 144 mit Modules und Repeat).

Weiß jemand, ob die Moduldefinitionen geschachtelt sein können (also Module in ModuleDef genutzt werden können)?

thewhobox: Rein von der funktionalen Seite hab ich diese Features (Modularisierung und Vervielfachung) mit meinem multiply-channels erfüllt (und noch ein paar mehr), aber die resultierenden xml-Files wurden riesig. Aber Parameter bzw. KO musste ich schon immer nur einmal und nicht 80 mal anpassen .

Gruß, Waldemar

[thewhobox]

Hey,

Repeater und Allocator kannte ich auch noch nicht.
Reapeater ist klar, was er macht.
Beim Allocator steig ich noch nicht ganz durch. Zählt der quasi immer hoch, wenn er abgefragt wird?
Wobei argCH nur 1 hoch zählt, argObj hingegen 10 und argPar 16?

ich schon immer nur einmal und nicht 80 mal anpassen

dann ist nur die Frage wer es zuerst erfunden hat :P

[mumpf]

Beim Allocator steig ich noch nicht ganz durch. Zählt der quasi immer hoch, wenn er abgefragt wird?
Wobei argCH nur 1 hoch zählt, argObj hingegen 10 und argPar 16?

Ja, so verstehe ich das auch. Macht ja auch so Sinn. argCH ist ja die Kanalnummer, die wird immer um 1 hoch gezählt. argObj ist der KO-Offest, jeder Kanal braucht 6, die zählen aber um 10 weiter und argPar ist der Parameter-Offset, die Parameter brauchen 16 Byte pro Kanal. Bleibt also alles in Sync und man weiß genau, wie man auf die Paramter bzw. KO zugreifen kann (wieder mal aus Sicht des Firmware-Schreibers).

dann ist nur die Frage wer es zuerst erfunden hat

Na ich natürlich ...

Gruß, Waldemar