Die Variante mit EEPROM-Emulation würde ich übrigens rauswerfen wollen, wenn die andere Flash-Variante gemergt ist. Bei meinem Pull-Request der lib tut sich nichts. Dann kann ich auch meinen Fork der Flash-Storage lib endlich löschen. Oder legt da jemand Wert drauf?
-
-
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
Kommentar
-
Okay, leider habe ich keine ETS Pro und nur eine ETS Inside Lizenz.Zitat von thesing Beitrag anzeigen
In dem Fall hat es noch keiner getestet?Kommentar
-
Hi,
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.Zitat von Hauswart Beitrag anzeigen
Gruß, Waldemar
Kommentar
-
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
Kommentar
-
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....Kommentar
-
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ß, WaldemarKommentar
-
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....
Kommentar
-
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ß, WaldemarKommentar
-
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
Kommentar
-
Kurz: Ja.
ETS gibt keine KO-Nummern mit. Die KO-Nummer ist implizit der Index des KO im übergebenen Array.Kommentar
-
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
Kommentar
-
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!Kommentar
-
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
Kommentar
-
Ja, ich bin auch beeindruckt!Kommentar
Kommentar