ESP8266 KNX mit ETS

[mumpf]

Hi Thomas et al,

dadurch, dass ich auf dem SAMD immer an die RAM-Grenzen komme, schaue ich mir ab und zu verschiedene Sachen an, derzeit eben GroupObject. Ich hab mal den Speicherverbrauch von einem KO angeschaut (Bytes in Klammern):

       size_t asapValueSize(uint8_t code);
(4)    GroupObjectUpdatedHandler _updateHandler;
       size_t goSize();
(2)    uint16_t _asap = 0;
(1)    ComFlag _commFlag = Ok;
(4)    uint8_t* _data = 0;
(1)    uint8_t _dataLength = 0;
(4)    GroupObjectTableObject* _table = 0;
(4)    Dpt _datapointType;

Das wären 20 Bytes für ein KO an Verwaltungsdaten (ohne Nutzdaten), und da ein DPT auch noch 6 Byte groß ist und pro KO eine Instanz erzeugt wird, sind es sogar 26 Bytes, denke ich zumindest (ich bin nicht so fit in C/C++, korrigiert mich bitte, wenn ich hier falsch liege). Bei 256 KO sind das alleine schon 6656 Byte... das ist schon was.

Könnte man nicht   GroupObjectTableObject _table = 0;  zu einer Klassenvariablen machen? Schließlich sind alle KO definitiv in der selben Table drin. Ich würde dann in meiner Logik nur noch für unterschiedliche DPT eine Instanz erzeugen (Factory) und so mit wenigen DPT-Instanzen auskommen. Das sind dann für die meisten KO schon 10 Byte ersparnis, man hätte dann nur 256 * 16 + n * 6 = 4096 + 6n (n ist die Anzahl unterschiedlicher DPT), also rund 2.5k gespart, was immerhin rund 7% des verfügbaren RAM ausmacht.

Liege ich da komplett falsch oder ist der Gedanke gar nicht soooo blöd? Ich sage auch nicht, dass Du das machen sollst, ich würde mal wieder - bevor ich so was anfange - gerne die Sinn-Frage stellen .

Gruß, Waldemar

[henfri]

Ja, ich bin auch beeindruckt!

[mumpf]

Hi Nanosonde,

auch von mir vielen Dank. Zwar denke ich derzeit noch nicht an KNX-RF, aber wer weiß, was die Zukunft noch bringt. Und ich finde es einfach irre, was hier alles implementiert wird...

Gruß, Waldemar

[thesing]

Es hat sich übrigens ein Pull-Request dazwischen geschummelt. Nanosonde hat uns KNX-RF als neuen Mediumstyp spendiert. Siehe dazu das Readme unter: https://github.com/thelsing/knx/blob...nx_rf_notes.md

Vielen Dank an Nanosonde!

[mumpf]

Hi Thomas,

danke für die Info - das hatte ich mir schon gedacht. Und die Versuche haben darauf hin gedeutet. Das ist schade, da das XML eigentlich was anderes impliziert. Dann werde ich mich mal darum kümmern, dass die KO möglichst "dicht" beieinander liegen.

Danke und Gruß,
Waldemar

[thesing]

Kurz: Ja.

ETS gibt keine KO-Nummern mit. Die KO-Nummer ist implizit der Index des KO im übergebenen Array.

[mumpf]

Hi,

ich hab mal ne Frage, weil ich nirgendwo nähere Infos dazu gefunden habe (außer im Coding): Wenn ich nur die KO 1 und 1000 habe, wird dann eine GroupObjectTable mit 1000 Einträgen oder mit 2 angelegt? Wenn ich das Coding richtig verstehe, ist das ein Array, somit müssten dann 1000 GroupObjects angelegt werden, richig?
Ich wollte nämlich meine KO mal in sinnvolle Blöcke zusammenfassen, mit ein bisschen Platz für Erweiterungen und bin wieder auf Speicherplatzprobleme gelaufen, obwohl sich funktional im XML und in der Firmware nichts geändert hat - außer dass die KO bis 1000 gingen.

Wenn das stimmt, dann sollte man Lücken in der KO-Nummerierung vermeiden oder möglichst klein halten, richtig?

Gruß, Waldemar

[mumpf]

Hi,

danke für den Tipp, wo ich schauen muss. Ich gehe dann mal auf den neuesten Stand und versuche mich mal mit einer Erweiterung fürs EEPROM. Ich muss mal wieder auf einen stabilen Stand kommen, ich hab derzeit das Gefühl, dass auf allen Ebenen Änderungen stattfinden und ich verliere den Überblick, welcher Fehler welcher Ebene zuzuordnen ist. Was auch daran liegt, dass ich an zu vielen Ebenen unterwegs bin

Gruß, Waldemar

[Bernator]

Deine Variante könntest du mit meinem aktuellen Interface bereits implementieren, solche Dinge sind und bleiben Platformspezifisch und sollen dort behandelt werden.
In reloadNVMemory(), könntest du beim ersten Aufruf die EEPROM Kopie in den Flash kopieren und in finishNVMemory() umgekehrt eine Flash Kopie im EEPROM erstellen.
Thomas hat in seinem Reopository den memory_rework Branch gemerged....

[mumpf]

Noch etwas - wenn Du und Thomas schon am "verhandeln" seid: Ich sehe die EEPROM-Variante, wie sie Dir vorschwebt, als nicht so relevant an, und so wie ich Thomas verstanden habe, er auch nicht. Unter Linux müsste man eigentlich gar nichts implementieren, da hat man genug Speicher... aber es schadet natürlich auch nichts.

Ich verstehe auch, dass meine EEPROM-Variante (beim Start alles vom EEPROM ins Flash kopieren) euch nicht sinnvoll erscheint, ich habe aber über die Zeit festgestellt, dass das flashen der Firmware ohne --erase zumindest bei meinem Programmer (bossac) bzw. mit PlatformIO (ich weiß noch nicht genau, an wem es liegt) nicht zufriedenstellend ist. Ich muss bei ca. 1 von 3 Firmware-Flash dann doch mit --erase flashen, weil mir bossac ein Verify error bringt (und dann natürlich den ganzen ETS-Prozess mit PA programmieren und dann noch die Applikation). Das macht die Roundtrips zum testen echt lang!

Ich werde mir jetzt ein Amtel-ICE ausleihen und schauen, wie das Debugging läuft und ob ich damit mehr Einfluss aufs Flashen nehmen kann, tendiere aber doch dazu, meine Idee mit dem EEPROM zu realisieren. Ich verstehe, dass das nicht in den Stack soll, würde mich aber freuen, wenn wir uns wenigstens auf callbacks einigen könnten. Ich müsste ja mitbekommen, wann die ETS mit dem programmieren fertig ist (Thomas hatte dann ja die Sachen in den Flash schreiben lassen) und dann würde ich gerne beim Startup nur dann was zurückkopieren, wenn der Flashinhalt wirklich weg ist. Ich hatte im alten Stack die Flash-Lib durch meine eigene ersetzt, am neuen Stack reizt mich, dass man sich auch noch das RAM sparen kann, indem man die relevanten Tabellen ins Flash auslagern kann.

Ich warte erstmal ab, was ihr da austüftelt, würde mir dann anschauen, wie ich meine Sachen mit möglichst wenig Schnittstellen da reinbringen kann und würde mich dann nochmal melden. Ich fände es angenehmer, wenn ich nicht immer auf einem Fork arbeiten müsste...

Gruß, Waldemar

[Bernator]

Alles klar danke, vermutlich wird sich auch nochmal was ändern bzgl. der Strukturierung, sodass mehr Logik in die memory Klasse wandert damit die Platform Implementierung einfacher wird. Bin da mit Thomas in Kontakt, deine Tests diesbezüglich sind aber wertvoll....

[mumpf]

HI Bernator,

ich wollte nur kurz mitteilen, dass ich in der Sache an sich (linux test) gerade nicht weiter komme, weil ich den Stack nicht über IP programmieren kann - keine Ahnung warum. Hat aber nichts mit Deinen Änderungen zu tun, klappt auch mit Thomas Original nicht. Muss also an meinem Netzwerk liegen, ich forsche erstmal.

Gruß, Waldemar

[mumpf]

Hi,

In dem Fall hat es noch keiner getestet?

keine Ahnung... an sich basiert das Projekt hier auf knxprod-Files. Wenn man die nicht importieren kann, wüsste ich nicht, wie sie sonst in die ETS inside kommen sollten.

Gruß, Waldemar

[Hauswart]

Hauswart : Vielleicht geht es, wenn du das Projekt in ETS von der Inside importierst, dort die knxprod hinzu fügst und dann wieder zum Inside-Server zurück synchronisierst. Ich habe das allerdings nie probiert, da ich keine Inside hab.

Okay, leider habe ich keine ETS Pro und nur eine ETS Inside Lizenz.

In dem Fall hat es noch keiner getestet?

[mumpf]

Hi,

wenn das mit dem Flash problemlos funktioniert, kann ich gern auf die lib verzichten. Allerdings hat sich gestern der SAMD mit der Flash-Implementierung aufgehängt. Kann aber auch an meinem Teil der Firmware liegen. Würde ich gerne noch testen, bevor Du die Sachen weglöscht... so 2 Wochen?

Gruß, Waldemar