ESP8266 KNX mit ETS

[SebastianObi]

Ja, habe ich um einiges erhöht. Hat aber nichts gebracht.
Die Frage ist ob es an deiner KNX-Library oder an der FlashStorage-Library liegt.

[mumpf]

Hi Thomas,

ich hab mal wieder zwei Fragen... ich komm erstmal nicht weiter:

Die (etwas längere Vorgeschichte): Ich habe mal einen Machbarkeitstest gemacht und die Linux-Variante mit 80 Kanälen / 240 KO getestet. Läuft. Die ETS braucht recht lange für die Applikation, mit IP geht das noch (ca. 60 Sekunden), mit TP kann ich noch nicht testen, erwarte aber wesentlich längere Zeiten. Mein Parameterblock sollte 8812 Bytes umfassen (80*110 Bytes + 12 Bytes), wenn ich aber die ganzen Memory-Zugriffe der ETS betrachte, dann kommt er auf fast das doppelte (Address liegt bei 3D08, wenn ich mich richtig erinnere).

Frage 1: Verstehst Du das? Ist es irgendwie erklärbar, dass die ETS viel mehr Daten überträgt als Parameter vorhanden sind?

Dann habe ich mir noch überlegt, dass man bei 80 gleichartigen Kanälen den Parameterspeicher partitionieren könnte und dann könnte die ETS ja beim partiellen Programmieren nur die geänderten Kanäle übertragen. Dann wären das ja nur n*110 Bytes und meistens nicht alle.

In der knxprod habe ich dafür statt

        <ApplicationProgram Id="M-00FA_A-0001-01-0000" ApplicationNumber="1" ApplicationVersion="1" ...>
          <Static>
            <Code>
              <RelativeSegment Id="M-00FA_A-0001-01-0000_RS-04-00000" Name="Parameters" Offset="0" Size="1002" LoadStateMachine="4" />
            </Code>
            ...

so was gemacht:

        <ApplicationProgram Id="M-00FA_A-0001-01-0000" ApplicationNumber="1" ApplicationVersion="1" ...>
          <Static>
            <Code>
              <RelativeSegment Id="M-00FA_A-0001-01-0000_RS-04-00000" Name="Parameters" Offset="0" Size="12" LoadStateMachine="4" />
              <RelativeSegment Id="M-00FA_A-0001-01-0000_RS-04-00001" Name="K1" Offset="12" Size="110" LoadStateMachine="4" />
              <RelativeSegment Id="M-00FA_A-0001-01-0000_RS-04-00002" Name="K2" Offset="122" Size="110" LoadStateMachine="4" />
              <RelativeSegment Id="M-00FA_A-0001-01-0000_RS-04-00003" Name="K3" Offset="232" Size="110" LoadStateMachine="4" />
              <RelativeSegment Id="M-00FA_A-0001-01-0000_RS-04-00004" Name="K4" Offset="342" Size="110" LoadStateMachine="4" />
              <RelativeSegment Id="M-00FA_A-0001-01-0000_RS-04-00005" Name="K5" Offset="452" Size="110" LoadStateMachine="4" />
              <RelativeSegment Id="M-00FA_A-0001-01-0000_RS-04-00006" Name="K6" Offset="562" Size="110" LoadStateMachine="4" />
              <RelativeSegment Id="M-00FA_A-0001-01-0000_RS-04-00007" Name="K7" Offset="672" Size="110" LoadStateMachine="4" />
              <RelativeSegment Id="M-00FA_A-0001-01-0000_RS-04-00008" Name="K8" Offset="782" Size="110" LoadStateMachine="4" />
              <RelativeSegment Id="M-00FA_A-0001-01-0000_RS-04-00009" Name="K9" Offset="892" Size="110" LoadStateMachine="4" />
            </Code>

Die 1002 Bytes kommen daher, dass ich es nur mit 9 Kanälen versuch habe. Die Parameter für jeden Kanal haben dann eine passende Memory-Definition (Hier als Beispiel ein Parameter für Kanal 7):

    <Parameter Id="M-00FA_A-0001-01-0000_P-7047" Name="f7E2Repeat" ParameterType="M-00FA_A-0001-01-0000_PT-DelaySeconds" Text="Eingang 2 wird alle n Sekunden gelesen (0 = nicht zyklisch lesen)" Value="0">
      <Memory CodeSegment="M-00FA_A-0001-01-0000_RS-04-00007" Offset="35" BitOffset="0" />
    </Parameter>

Obwohl ich das alles nur als "Schuss ins Blaue" ausprobiert habe, funktioniert es, die Programmierung klappt und nach dem Download stehen die Daten auch an der richtigen Stelle (zumindest funktionierte Kanal 1 und Kanal 9 genau so, wie zuvor). Insofern Hut Ab vor Deiner Leistung, hier die Spec zu implementieren, denn ich gehe mal davon aus, dass Du so was nicht ausprobiert hast!

Meine Hoffnung, dass die ETS bei einer Änderung nur das Segment verwendet, dass sich geändert hat, hat sich aber nicht erfüllt.

Frage 2: Hast Du eine Idee, in welche Richtung man schauen könnte, um die partielle Übertragung zu ermöglichen? Ich vermute ja, dass es an dem LoadStateMachine="4" liegt, aber ich hab keine Ahnung, was das macht. Ich habe auch versucht, aus der Anleitung vom Manufacturer Tool schlau zu werden, aber da bin ich nicht weiter gekommen...

So, das hier bleibt erstmal liegen, ich komme ja nicht weiter. Als nächstes versuche ich mich an den Applikationsversionen, damit ich in der ETS eine Applikation für ein Gerät wechseln kann, ohne es neu parametrieren zu müssen, bei 80 Kanälen macht das nämlich keinen Spaß...

Dann werde ich mich wieder der Funktionalität und damit dem DPT 9 widmen...

Gruß, Waldemar

[mumpf]

Ja, habe ich um einiges erhöht. Hat aber nichts gebracht.

Hi Sebastian,

ich habe beim rumprobieren noch entdeckt, dass in der FlashAsEEPROM.h noch folgendes steht:

#define EEPROM_EMULATION_SIZE 1024

Ich denke, den wirst Du auch erhöhen müssen, und ich auch, ich bin nur noch nicht so weit. Ich musste in der linux_platform.cpp schon ein

#define MAX_MEM 4096

auf

#define MAX_MEM 32768

ändern, damit meine Applikation per ETS programmiert werden konnte. Wobei bei mir 32768 sicherlich nicht notwendig sind, 16384 aber nicht ausreichen, obwohl ich es erwartet hätte, da ich nur 8812 Bytes Parameter habe... kann ich mir nicht wirklich erklären!

Hab da nicht tiefer rein geschaut, falls Du neue Erkenntnisse gewinnst, kannst Du es ja hier anmerken.

Gruß, Waldemar

[thesing]

mumpf Die Adressen sind inzwischen größer, da ich den Referenzpunkt um 1024 Bytes nach unten verschoben habe. Hierdurch sollte es nicht mehr zu negativen Adressen kommen. ETS überträgt ja nicht nu die Parameter da kommt schon einiges zusammen. Beim Programmieren entläd ETS nacheinander die Adresstabelle, die Associationstabelle, die Gruppenobjekttabelle, die Parameter und füllt sie dann wieder. Partiell heißt hier nur, dass nur die Parameter übertragen werden, wenn sich die anderen Objekte nicht geändert haben. (Siehe auch die Haken in der Geräteübersicht in ETS.) Man kann daher nicht nur einen Teile der Parameter übertragen. Man könnte die Paramter allerdings auf mehrere Parameterobjekte aufteilen. Allerdings wird der Zugriff im Sketch auf die Parameter dadurch komplizierter. Ich bin mir nicht sicher, ob es das wert ist. Man müsste in der knxprod die LoadProcedure anpassen und auf dem Gerät eine weiter Instanz vom ApplicationprogramObjekt erzeugt.
Wenn du das probieren willst, kann ich gern Hilfestellung geben.

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

Evtl. kann man das auch ab ETS 5.6 über Skripte lösen. Siehe Reference -> Skripting Support
Damit habe ich mich alledings noch nie beschäftigt. Damit könnte man wahrscheinlich über einen Button in ETS nur einzelne Parameter oder Gruppen von Paramtern schreiben.

[SebastianObi]

Hallo,

ich habe das einfrieren/hängen Problem nun weiter analysiert bei dem SAMD21.

Es ist quasi Architekturbedingt, dass kein EEPROM vorhanden ist und die FlashStorage Library verwendet werden muss wird die Größe "#define EEPROM_EMULATION_SIZE" auch als RAM belegt. Dies führt dann dazu, dass nicht mehr genügend RAM frei ist für die initialisierung der Gruppenadressen. Wenn allerdings zu wenig EEPROM Size definiert ist reicht der Speicher dort wieder nicht.

Bei folgender Funktion ist ab einer gewissen Anzahl an Gruppenadressen dann kein RAM mehr verfügbar in der For-Schleife.

bool GroupObjectTableObject::initGroupObjects()
{
if (!_tableData)
return false;

freeGroupObjects();

uint16_t goCount = ntohs(_tableData[0]);

_groupObjects = new GroupObject[goCount];
_groupObjectCount = goCount;

for (uint16_t asap = 1; asap <= goCount; asap++)
{
GroupObject& go = _groupObjects[asap - 1];
go._asap = asap;
go._table = this;

go._dataLength = go.goSize();
go._data = new uint8_t[go._dataLength];
memset(go._data, 0, go._dataLength);

if (go.valueReadOnInit())
go.requestObjectRead();
}

return true;
}

Lässt sich das ändern, dass die Daten zwischendrinn ins EEPROM geschrieben werden und wieder mehr RAM frei ist?

[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

[ur63]

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

[mumpf]

Hi,

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

Gruß, Waldemar

[ur63]

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

Danke für den Link, Waldemar!

[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....

[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

[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

[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.

[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.

[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.)