ESP8266 KNX mit ETS

[jayem0]

Das Sortieren wäre doch kein Problem, einmal zur Instanziierung müsste doch reichen. Je nach Algorithmus bräuchte man halt noch genug freien Speicher zum Rumschieben. Sobald ich mal etwas Zeit habe ist eines der Projekte, die ich mir unbedingt genauer anschauen möchte, dieses Stack. Echt tolle Arbeit!

[mumpf]

Ah, das kann natürlich sein, dass ich auch auf einen Branch gegangen bin. Wie gesagt, ist schon 1,5 Jahre her...

Wird über den Stack noch an andere Stelle diskutiert?

Nicht dass ich wüsste.

Sehr viel gewinnen kann man hier wenn man binär sucht, dafür muss die Liste halt sortiert vorliegen.

Klar, ich muss aber erstmal sicher sein, dass es daran liegt.

Gruß, Waldemar

[Ing-Dom]

ahhh, jetzt. Ich hab die ganze History der samd_plattform.h durchsucht, aber kein Hinweise auf NVMemory gefunden.
Aber es gibt zwei branches, die sich des Themas angenommen haben, die es aber wohl bisher nicht in den master geschafft haben.

Es wäre interessant, warum.. ich seh schon, ich muss ich durch die 20 Seiten quälen
Wird über den Stack noch an andere Stelle diskutiert?

[mumpf]

Sicher?! Ganz sicher ?

Ja, meine samd_platform.h sieht so aus: https://github.com/mumpf/knx/blob/43832c0957d65dd1d434a4ee53ecce2edd39ad6d/src/samd_platform.h#L1

Wie gesagt, ich hab das nicht verfolgt (leider), empfinde es aber als Rückschritt.

Gruß, Waldemar

[Ing-Dom]

und es funktioniert bei mir, ich hab die FlashAsEEPROM Lib gar nicht auf meinem Rechner drauf.

Sicher?! Ganz sicher ?

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

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

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

[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

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

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

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

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

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

[jeff25]

Ja du hast natürlich recht...

[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