ESP8266 KNX mit ETS

[mumpf]

Mach ich... Reverse Engineering ist doch was tolles.

Gruß, Waldemar

[thesing]

Das gleiche habe ich mich auch gefragt. Ich habe bisher immer nur die alte Version rein geschrieben. Sag bescheid, falls du heraus findest wie es geht.

[mumpf]

Ok, habe jetzt gesehen, dass bei mir im XML das Attribut ReplacesVersions fehlte. Da ich ja das XML manuell editiere und CreateKnxProd nur zum umwandeln in knxprod nutze, hatte ich nicht die neueste Version hier und konnte nicht die passenden Sachen "abgucken". In der Doku steht, dass da eine Liste von alten Versionen stehen kann (und der Name lässt das auch vermuten), allerdings ist es nur ein String. Weißt Du, wie die Liste notiert wird? Durch Leerzeichen getrennt? Durch Komma? Wahrscheinlich werde ich sowieso nur von der vorherigen auf die nächste müssen, aber mich würde das Format interessieren.

Ich werde mal mein XML an die ganzen Neuerungen anpassen, die ich in dem Output vom aktuellen CreateKnxProd gesehen habe und dann weiter testen...

Danke und Gruß,
Waldemar

[mumpf]

Für ein Update der knxprod eines Gerätes muss du übrigens wie folgt vorgehen.

Hi Thomas, danke! Werde ich gleich morgen ausprobieren...

Gruß, Waldemar

[thesing]

Ich glaube bei Konnekting gibt es auch noch eine FlashAsEeprom-Variante. Vielleicht ist die besser?

[thesing]

mumpf Für ein Update der knxprod eines Gerätes muss du übrigens wie folgt vorgehen.
- In neuer knxprod: Version erhöhen. "Replaces Versions" auf alte Version setzen.
- ETS-Projekt sichern (Backup)
- neue knxprod in ETS importieren.
- neues Gerät mit neuer knxprod zum Projekt hinzufügen.
- Eigenschaften von zu updatendem Geräte aufrufen und bei Informationen->Applikationsprogramm unten auf "Aktualisieren" drücken. Wenn du im Dropdown nur die neue Applikations auswählst, wird die vorhandene Konfiguration verworfen.
- neu hinzugefügtes Gerät entfernen. (Kann man wahrscheinlich auch gleich nach dem hinzufügen machen.)

[thesing]

Der Flash wird nur beim Start gelesen und vor einem Neustart geschrieben. Man könnte also auch einfach aus dem Flash lesen. Das lesen/speichern holt sich einfach einen Pointer über Platform.getEepromBuffer(), und reicht den nacheinander an die ganzen Objekte weiter. Die schreiben ihren Inhalt rein und geben den entsprechend veränderten Pointer zurück. Wenn alle Objekte fertig sind wird mit Platform.commitToEeprom() gespeichert.
Das ganze Speichern/Laden passiert in der Klasse Memory. (Wer hätte das gedacht? ) Die zu Speichernden Objekte erben alle von der Klasse SaveRestore (https://knx.readthedocs.io/en/latest...e_restore.html) Vielleicht sollte da noch eine Methode hizukommen ob zu fragen wieviel Speicher ein Objekt braucht. Dann könnte man den Buffer gleich entsprechend groß machen. Unter Linux war das egal, da dort alles einfach in eine Datei geschrieben wird.
Ich würde es gut finden, wenn dadurch auch gleich die Abhängigkeit von meiner modifizierten FlashLib wegfallen würde. Der Entwickler der Lib scheint nicht mehr aktiv zu sein.

Mag Gyver Den Pull-Request schau ich mir demnächst an. Danke schonmal.

Bernator Stell einfach den Pullrequest. Dann kann ich Änderungen am einfachsten zusammengefasst sehen.

[Bernator]

Naja das Problem ist ja nicht das der SAMD zu wenig Speicher hat sondern das die EEPROM Emulation so geschrieben ist das alle Daten in den RAM kopiert werden. Das muss aber nicht zwingend so sein weil beim Cortex M die Adressräume von RAM und Flash identisch sind, hier könnte man die Parameter auch direkt aus dem Flash lesen ohne Umweg über eine RAM Kopie.

[SebastianObi]

Ich wede jetzt mal einen I2C EEPROM "24AA256" besorgen und damit testen. Dies sollte das Speicherplatzproblem eim SAMD deutlich entspannen

Wann wird denn der EEPROM verwendet? Nur beim Start/auslesen der Parameter und beim Übertragen der Applikation/Einstellungen oder auch während des normalen Betriebes? Der externe sollte wohl deutlich langsamer sein.

VG Sebastian

[Mag Gyver]

Hallo allerseits,

ich habe einen Pullrequest für DPT9 eingestellt. Vielleicht schaut sich Thomas dort mal darüber, hab es allerdings noch nicht prüfen können.

Grüße

Mag Gyver

[Bernator]

Hallo zusammen,

ich hab jetzt in meinem fork eine asynchrone Version des tpuart_data_link_layers geschrieben den ip_data_link_layer hab ich nur soweit angepasst das er wieder kompatibel mit dem gemeinsamen data_link_layer ist.

knx.loop blockiert damit beim SAMD21 nur noch max. 0,2ms (vorher >100ms)

zusätzlich hab ich einige Timeouts eingebaut um ein festfrieren möglichst zu verhindern, auch die crc prüfsumme der Frames wird ausgewertet (hat vorher gefehlt oder hab ich blos nicht gefunden?)

Vielleicht schaut thesing mal drüber evtl. fällt dir noch was auf, ansonsten würde ich einen pull request machen? Habs mit dem Demo Projekt getestet aber sonst noch nicht wirklich was gemacht....

[ur63]

ich habe hier https://support.knx.org/hc/en-us/cat...ool-User-Guide rumgestöbert.

Danke für den Link, Waldemar!

[mumpf]

Hi,

ich habe hier https://support.knx.org/hc/en-us/cat...ool-User-Guide rumgestöbert.

Gruß, Waldemar

[ur63]

Wo findet man denn die Dokumentation der ETS/Hersteller-Tools?
Die Webseiten scheinen von der KNX ja abgeschaltet...

[mumpf]

SebastianObi: Dann werde ich wohl in das selbe Problem laufen... ich muss mal schauen, ich kann ja mit der Anzahl Kanäle variieren. Bin gespannt, wie viele ich unterbekomme.

Man kann daher nicht nur einen Teile der Parameter übertragen.

Ich weiß natürlich, dass man in der ETS anhand der Haken sieht, ob beim partiellen Programmieren nur die Parameter und/oder KO bzw. GA übertragen werden. Ich hatte nur beim lesen der MT-Doku das so (miss-)verstanden, dass intern nach Speicherbereichen (memory segments) unterschieden und die bei Änderung übertragen werden. Das Standardverhalten (alle Parameter/alle KO/alle GA aktualisieren) liegt eben daran, dass die normalerweise jeweils in eigenen Segmenten liegen.
Deswegen hatte ich überhaupt den Versuch gestartet, aber wie gesagt, ich habe das wohl komplett missverstanden. Ich fand das einleuchtend, deswegen hab ich die Idee verfolgt. Leider weiß ich nicht mehr genau, welche Stelle mich dazu animiert hat, es so zu verstehen.

Siehe dazu in der MT Hilfe:
Reference->Device Configuration Procedures -> Default Load Procedures -> System B Default Load Procedure

Das hatte ich schon gelesen, aber nicht wirklich verstanden. Das ist dann doch eine Nummer zu hoch für mich (bzw. es dauert, bis ich genügend Hintergrundwissen angesammelt habe, bis ich auch das noch verstehe).

Vielen Dank für das Angebot, mir bei weiteren Versuchen Hilfestellung zu geben, aber ich will das erstmal in der Grundkonfiguration zum fliegen bringen. Ich will am Wochenende mal testen, wie weit mich die Speicherprobleme von SebastianObi auch treffen. Und ich will noch immer den DPT9 fixen...

Vielleicht kannst Du mir noch bei einer weiteren Sachen einen Tipp geben: Du hast bei der knxprod für Dein shNG.py Plugin beschrieben, wie man einen neue knxprod in die ETS bekommt, ohne ein neues Gerät anzulegen und alle GA erneut zuzuweisen. Das sollte doch auch für die hier erzeugten knxprod-Files funktionieren, oder? Ich habe es mit einer neuen knxprod (ApplicationVersion ist erhöht und alle IDs im Dokument passend angepasst) versucht, aber in der ETS ist bei Eigenschaften->Applikation keine Möglichkeit, unten die neue Version auszuwählen. Ich kann somit nicht upgraden. Hast Du eine Idee, woran das liegen kann bzw. was ich noch mehr machen muss, damit das geht?

Danke und Gruß, Waldemar