ESP8266 KNX mit ETS

[Alloc]

Ich denke aber, ich weiß auch warum der 8192 nicht geht, denn in der FlashStorage wird ja default-mäßig mit 1024 gearbeitet!
Ich dreh hier mal auf 8192 hoch und schau was passiert.

Das war zumindest vor einem halben Jahr auch mein Problem. Ich hatte dann glaub irgendwo die Include-Order geändert, so dass der FlashStorage den Wert aus der Config vom KNX-Stack bekommt und somit an einer Stelle anpassbar bleibt. Hatte auch eine Ergänzung in den fatalError-Code gebaut, dass die LED erst einen Fehlercode ausgibt, und glaub noch irgendwas ... wollte mal einen Merge-Request machen, aber mit GitHub noch nie gearbeitet (nur direktem Git-Zugriff)

[Ing-Dom]

Und leider ist es dabei geblieben.

schade!

Ja, alles dynamisch. Es gibt eine Klasse GroupObject (in group_object.h), jedes Kommunikationsobjekt ist eine Instanz davon. Für die Parameter gibt es passende Parameter-Getter, technisch übergibt die ETS alle Parameter als ein Speicherblock.

sowas dachte ich mir dann schon.
Hat natürlich seine Vorteile - aber auch Nachteile. Es ist wohl ne ganze Menge Flash notwendig.
Ist das auch alles parallel im RAM ? Der ist ja nicht ganz so üppig...

Es gab hier vor kurzem jemanden, der hat als eine Art Studienarbeit eine (kleine) Alternative zur ETS geschrieben. Mit der konnte man auch programmieren. Allerdings fehlte im UI noch einiges. Mir fällt der Username nicht ein, ich stell das noch rein, wenn ich das wiederfinde. Wäre eine Alternative, Du hast Recht.

Ich hab in ganzen alten Threads gewühlt von 2014, da gings um die Konfig von DIY-Geräte. Robert (der mit dem HM-KNX Hörmann Modul) hatte da eine schöne Variante, der hat die Geräte über eibd programmiert - propwrite etc... sowas könnte man machen. Sind wir ehrlich... keiner wird das nutzen

Das ist eine Idee, allerdings dachte ich, das Standardmäßig inzwischen in den Flash vom SAMD geschrieben wird und FlashStorage gar nicht mehr gebraucht wird? Aber da bin ich leider nicht mehr Up-To-Date, sorry.

doch doch, siehe hier:

https://github.com/thelsing/knx/blob...latform.cpp#L7


Leider hat beides auf 2048 oder beids auf 8192 ebenfalls nicht funktioniert. Muss ich mal debuggen...

Wieviel byte brauche ich pro KO und pro Parameter?

[mumpf]

Hi,

wieso wird in diesem Zusammenhang immer von

legal

gesprochen und damit illegal impliziert? Es passiert nicht illegales, weder eine Schlüsselextraktion noch eine illegale Kopie noch irgendein anderes geheimes Ding. Es wird nur eine ETS-Funktion aufgerufen (deswegen muss die ETS auf dem jeweiligen Rechner installiert sein). Dieser Funktion gibt man ein XML-File und sie spuckt ein knxprod raus. Ich sehe daran nichts illegales, nur was nicht direkt unterstütztes. Die installierte ETS muss noch nicht mal lizensiert sein, es reicht vollkommen die ETS-Demo. Nur die ETS, in die später importiert wird, muss lizensiert sein (zumindest wenn man mehr als 5 Geräte nutzen will). Im Prinzip macht man nichts anderes als jeder Hersteller während seiner internen Entwicklungs- und Testphase.

Dass die resultierende knxprod nicht weiterzugeben ist, liegt daran, dass man als Privatmensch keine Herstellerkennung hat. Aber solange man sich das Ding für den Privatgebrauch zusammenbastelt, ist es nicht illegal.

Ich wehre mich schon entschieden dagegen, dass hier was illegales gemacht wird.

Gruß, Waldemar

[mumpf]

Hi,

Ich hab in ganzen alten Threads gewühlt von 2014, da gings um die Konfig von DIY-Geräte.

ich meinte das hier: https://knx-user-forum.de/forum/%C3%...chnikerprojekt. Guter Ansatz :-)

Es ist wohl ne ganze Menge Flash notwendig.

Das ist nicht sooo schlimm, der Stack selber ist groß, die Parameter etc. brauchen eben so viel, wie sie in Binärdarstellung brauchen. Die KO haben aber eine Speicherrepräsentation im RAM (geht auch nicht anders) und die war damals recht groß. Wenn ich mich recht erinnere, 21 Byte + der eigentliche Payload. Also 22 bis 35 Byte pro KO. Das ist eine der Änderungen bei mir in meinem Fork, ich komme mit 5+Payload aus, allerdings ist der Zugriff dann umständlicher (man muss z.B. immer den richtigen DPT mitgeben usw.). Das war es mir aber wert.

Das Maximum, was ich mal versucht habe, waren 350 KO, das hat noch (mit meiner Lösung) problemlos funktioniert.

Wieviel byte brauche ich pro KO und pro Parameter?

Wie gesagt, Parameter brauchen exakt so viel, wie sie physikalisch als Bitrepräsentation brauchen, KO 21+Bitrepräsentation, wobei sich das in der Zwischenzeit geändert haben kann - in beide Richtungen.

Gruß, Waldemar

[jeff25]

Hi,

wieso wird in diesem Zusammenhang immer von

mumpf so meinte ich es auch nicht, aber über die generierte VD1 müsste man zumindest nicht mal mehr die DLL selbst aufrufen daher kann es garnicht evtl gegen was verstossen.

[mumpf]

Hi,

ich kenne zwar VD1 nicht, muss vor meiner Zeit gewesen sein, aber das Problem dürfte doch das Gleiche sein: Wenn Du kein Hersteller bist, hast Du keine Hersteller-ID und kannst damit keine gültige Applikation veröffentlichen. Du müsstest, genau so wie bei unserem xml, eine Herstellerkennung "missbrauchen". Dass bei einer VD1 keine Signierung erfolgt und die ETS so was ohne weiteres importiert macht es nicht besser als eine knxprod, die von dem Tool hier generiert wird, oder?

Gruß, Waldemar

[jeff25]

Ja du hast natürlich recht...

[Ing-Dom]

, 21 Byte + der eigentliche Payload. Also 22 bis 35 Byte pro KO.

uff, das ist ne Menge !
da sind ja 5k ram nur für die KOs bei 200 Stück. Gut, man hat 32k, aber trotzdem...

ich komme mit 5+Payload aus, allerdings ist der Zugriff dann umständlicher (man muss z.B. immer den richtigen DPT mitgeben usw.). Das war es mir aber wert.

das hört sich schon besser an.
Wäre echt toll wenn deine Optimierungen den Weg in den Stack finden.

Das Maximum, was ich mal versucht habe, waren 350 KO, das hat noch (mit meiner Lösung) problemlos funktioniert.

350KO mit einer entsprechenden Anzahl an GA erfordert ja auch eine relativ lange Suche, ob eine eintreffende GA geACKd wird oder nicht. Das haut hin?

Ich wehre mich schon entschieden dagegen, dass hier was illegales gemacht wird.

Im strafrechtlichen Sinne bin ich mir realtiv sicher, dass es nicht strafbar ist.

Dass bei einer VD1 keine Signierung erfolgt und die ETS so was ohne weiteres importiert macht es nicht besser als eine knxprod, die von dem Tool hier generiert wird, oder?

hmnaja, eine vd1 kannst du einfach mit einem editor und einem zipper erstellen.
Für eine importierbare knxprod brauchst du die dll aus der ets. Die Nutzung auf diese Weise wird wahrscheinlich die Nutzungsvereinbarung zwischen dem ETS Benutzer (Lizenznehmer) und der KNX-Association (Lizenzgeber) verletzen.
Ich halte das aber für eine akademische Diskussion. Denn solange keiner signierte prods verteilt und Geräte damit verkauft, wird die KNX A nichts tun..

[mumpf]

Hi,

uff, das ist ne Menge !

ich hab nochmal nachgeschaut. Wenn ich hier https://github.com/thelsing/knx/blob..._object.h#L213 richtig gerechnet habe, braucht ein KO 19 Byte + payload.

Mein Ansatz hier https://github.com/mumpf/knx/blob/43..._object.h#L225 braucht 8 Byte + payload.

Sorry für die falschen Angaben oben, war nur aus dem Kopf und es ist schon lange her, dass ich das programmiert habe.

350KO mit einer entsprechenden Anzahl an GA erfordert ja auch eine relativ lange Suche, ob eine eintreffende GA geACKd wird oder nicht. Das haut hin?

Das wäre eine Frage an Thomas (thesing). Ich habe damals nur geschaut, ob ich meine angedachten 446 KO (und nicht 350, wie ich schrieb) überhaupt ins RAM bekomme. Ich hab die nicht alle mit GA belegt und programmiert. Letztendlich hab ich immer noch nicht den Vollausbau erreicht, den ich damals geplant hatte. Hab übrigens gerade noch meine Aufzeichnung von damals gefunden:

446 * 8 Byte (pro KO) + 34 Byte (Lücken) + (2178 + 192 + 34 + 24) Byte payload = 6030 Byte max.

Aber grundsätzlich hast Du Recht, ich hab bei meinem Modul Probleme mit ACKs, ich hab das nur nicht weiterverfolgt, weil mir Ideen fehlten, was der Grund sein könnte. Du hast jetzt schon mal einen geliefert. Ist auch einer der Punkte auf der Liste, die noch untersucht werden müssen. Da ich zu Hause alles von meinem Linienkoppler ACKen lasse, ist das aber derzeit unkritisch.

Gut, man hat 32k, aber trotzdem...

Rechne nicht mit den 32k. Eher mit der Hälfte. Ich hab das nie vermessen, aber früher, als die Parameter auch noch alle im RAM lagen, war bei Parameter + KO von insgesamt ca. 18k Schluß, es brach schon beim Programmieren ab. Seitdem versuche ich immer, meinen Speicherverbrauch unter 16k zu halten. Ich sag damit nicht, dass der Stack alles andere verbraucht, aber man hat ja noch eine eigene Laufzeit...

So, das war's jetzt für heute Nacht,
Gruß, Waldemar

[h1as]

Hallo zusammen,

ich hab mir mal das Thema mit der KNX_FLASH_SIZE angesehen.

In der read_memory() wird das emulierte Eeprom mit der KNX_FLASH_SIZE ausgelesen:

uint16_t flashSize = KNX_FLASH_SIZE;
_data = _platform.getEepromBuffer(flashSize);

In der Flashstorage lib ist aber in FlashAsEEPROM.h die emulierte Eepromgröße mit 1024 angegeben.

#define EEPROM_EMULATION_SIZE 1024

Ich denke wenn man hier entsprechen die Eepromgröße anpasst sollte es passen? Ich kann akutell leider selber nicht testen,

Viele Grüße
H!as

[mumpf]

Hi,

da gab es schon dieses Statement dazu:

Leider hat beides auf 2048 oder beids auf 8192 ebenfalls nicht funktioniert. Muss ich mal debuggen...

Ansonsten weiß ich nicht, was da im Laufe der Zeit am Stack passiert ist. Als ich mit dem Stack anfing, spielte die FlashAsEEPROM.h eine Rolle und man musste immer wieder den Parameter EEPROM_EMULATION_SIZE anpassen, wenn mehr und mehr Parameter hatte. Damals wurden auch zur Laufzeit am Anfang alle Parameter ins RAM geladen und von da geholt. Was natürlich das verwendbare RAM drastisch reduziert hat.

Dann hat Bernator eine geniale Erweiterung implementiert, die alle Parameter in den Flash schreibt und auch zur Laufzeit daraus liest. Da wurde die FlashAsEEPROM.h überflüssig. Damals hab ich auch meinen Fork gemacht und es funktioniert bei mir, ich hab die FlashAsEEPROM Lib gar nicht auf meinem Rechner drauf.

Weiß vielleicht jemand, der das die ganze Zeit verfolgt hat, warum die FlashAsEEPROM Lib wieder dabei ist? Für mich ist das auch einer der Punkte, warum ich nicht von meinem Fork wegkomme.

Gruß, Waldemar

[mumpf]

Hi Ing-Dom,

ich hab noch meine Fragen zum ACK wiedergefunden. Das fängt hier https://knx-user-forum.de/forum/öffentlicher-bereich/knx-eib-forum/diy-do-it-yourself/1216828-esp8266-knx-mit-ets?p=1453137#post1453137 an. Ich hab dann irgendwann aufgegeben, weil ich wie gesagt den LK alle Telegramme ACKen lasse.

Gruß, Waldemar

[mumpf]

... und noch eine Frage an C++ (performace) Freaks:

Ich hab beim GA-Suchen (prüfen auf Existenz) folgende Stelle gefunden:

bool AddressTableObject::contains(uint16_t addr)
{
    uint16_t size = entryCount();
    for (uint16_t i = 1; i <= size; i++)
        if ([COLOR=#c0392b]ntohs(_groupAddresses[i])[/COLOR] == addr)
            return true;
    return false;
}

Da es hier wohl auf jede ms ankommt, würde es nicht so rum schneller sein? Gerade bei vielen GA?
bool AddressTableObject::contains(uint16_t addr)
{
uint16_t size = entryCount();
uint16_t lAddr = ntohs(addr);
for (uint16_t i = 1; i <= size; i++)
if (_groupAddresses[i] == lAddr)
return true;
return false;
}
(kurz gesagt: Anstatt für jede GA Low-/Highbyte vertauschen, macht man das für den Vergleichswert nur einmal).

Zwar ist ntohs ein Makro und keine Funktion, aber die Operationen müssen ja trotzdem n mal (bei n GA) gemacht werden, bei mir nur einmal. Oder irre ich mich da?

Gruß, Waldemar

[Ing-Dom]

bzgl Flash /EEprom Simulation.

Ist KNX_FLASH_Size > 1024, läuft er in den Fatal Error:

https://github.com/thelsing/knx/blob...atform.cpp#L26

Warum? Rätselhaft! Hab ich doch sowohl EEPROM_EMULATION_SIZE in der FlashAsEEPROM.h auf 2048 bzw. 8192 hochgedreht.

Der Debugger enthüllt die Wahrheit: EEPROM_EMULATION_SIZE ist trotz Änderung oben immer noch 1024.
Auch eine Ausgabe mit #pragma beweißt es:

[COLOR=#569cd6]uint8_t[/COLOR][COLOR=#569cd6]*[/COLOR][COLOR=#4ec9b0]SamdPlatform[/COLOR][COLOR=#d4d4d4]::[/COLOR][COLOR=#dcdcaa]getEepromBuffer[/COLOR][COLOR=#d4d4d4]([/COLOR][COLOR=#569cd6]uint16_t[/COLOR][COLOR=#9cdcfe]size[/COLOR][COLOR=#d4d4d4])[/COLOR]
[COLOR=#d4d4d4]{[/COLOR]
[COLOR=#6a9955]//EEPROM.begin(size);[/COLOR]
[COLOR=#c586c0]#pragma[/COLOR][COLOR=#9cdcfe]message[/COLOR][COLOR=#569cd6]([/COLOR][COLOR=#9cdcfe]VAR_NAME_VALUE[/COLOR][COLOR=#569cd6]([/COLOR][COLOR=#9cdcfe]EEPROM_EMULATION_SIZE[/COLOR][COLOR=#569cd6]))[/COLOR]
[COLOR=#c586c0]if[/COLOR][COLOR=#d4d4d4](size [/COLOR][COLOR=#d4d4d4]>[/COLOR][COLOR=#d4d4d4] EEPROM_EMULATION_SIZE)[/COLOR]
[COLOR=#dcdcaa]fatalError[/COLOR][COLOR=#d4d4d4]();[/COLOR]

[COLOR=#c586c0]return[/COLOR][COLOR=#9cdcfe]EEPROM[/COLOR][COLOR=#d4d4d4].[/COLOR][COLOR=#dcdcaa]getDataPtr[/COLOR][COLOR=#d4d4d4]();[/COLOR]
[COLOR=#d4d4d4]}[/COLOR]

D:\Data\Eigene Dokumente\Arduino\libraries\knx\src\samd_platform.cpp:30:54: note: #pragma message: EEPROM_EMULATION_SIZE=1024

und was ist das Problem: Ich Dummbatz hab die FlashAsEEPROM.h in meinem Arbeitsverzeichnis geändert, statt die im ibraries Ordner.
Kaum macht man es richtig, geht es.

[Ing-Dom]

Zwar ist ntohs ein Makro und keine Funktion, aber die Operationen müssen ja trotzdem n mal (bei n GA) gemacht werden, bei mir nur einmal. Oder irre ich mich da?

nein du irrst nicht!
Aber das ist ja einfach nur eine lineare Suche Die langsamste Suche überhaupt.
Das kostet schon Zeit, bei 300GAs. Müsste man mal messen.
Sehr viel gewinnen kann man hier wenn man binär sucht, dafür muss die Liste halt sortiert vorliegen.