ESP8266 KNX mit ETS

[thesing]

Hallo Waldemar,

ich finde dein Vorhaben sehr löblich Ich würde bei der SaveRestore-Klasse und der Memory-Klasse anfangen, da Flash blockweise geschrieben werden muss, und möglichste jedes InterfaceObjekt getrennt voneinander geschrieben werden muss. Daher musst du ggf. Padding einführen. Da weiterhin partielle Programmierung möglich sein sollte, musst du dann damit klar kommen, dass sie die Größe von einzelnen InterfaceObjekten verändern könnte wenn z.B. neue GAs zu den KOs hinzugefügt werden.

• TableObject wird so umgebaut, dass es nur mit einer Speicherreferenz auf den Anfang eines Speicherblocks arbeiten kann und kein einziger Wert ins RAM kopiert wird.
• Damit könnte man für die Parameter und die GA-Zuordnungen direkt auf den Flash referenzieren, da sich diese Tabellen ja zur Laufzeit nicht ändern (nur beim Programmieren -> kommt noch). Damit könnte man für diese Tabellen auf ein malloc verzichten.
• Nach dem Programmieren werden die Daten ins Flash geschrieben und dann der SAMD neu gestartet, dann bekommt die Firmware ja ihr RAM wieder.

Passt soweit.

• KO und deren Werte werden weiterhin im RAM belassen. Dazu muss hier ein malloc passieren, das müsste dann "außerhalb" der TableObject-Klasse passieren (oder über einen alternativen Konstruktor, das kann man ja noch sehen)

Hier muss nichts geändert werden, da die GroupObjekt-Objekte eh in der GroupObjektTable erzeugt werden.

• Beim Programmieren gehe ich davon aus, dass die eigentliche Firmware (also das, was den Stack nutzt) gestoppt ist. Sollte diese RAM brauchen, dann wird dieser während der Programmierung nicht gebraucht und kann "missbraucht" werden - für die zu programmierenden TableObject (Parameter, KO und GA).

Da solltest du ein zusätzliches Callback an der Facade oder der Bau-Klasse vorsehen. Durch dieses Callback kann die eigentliche Anwendung dann vor der Programmierung Speicher freigeben.

• Ich muss nochmal untersuchen, was beim partiellen Programmieren abgeht, das blicke ich noch nicht ganz, obiges würde nur (falls überhaupt) für das Programmieren der gesamten Applikation funktionieren.

Das Hauptproblem bei der partiellen Programmierung besteht, ist dass du dann damit klar kommen musst, dass sich die Größe von einzelnen InterfaceObjekten verändern könnte wenn z.B. neue GAs zu den KOs hinzugefügt werden.

Bsp.:
Ist AdressTable 100 Byte startet an Offset 0, AssoziationTable 100 Byte startet and Offset 100, GoT 100 Byte startet an Offset 200, Paramter 100 Byte startet an Offset 300.
Nun soll nur die AssoziationTable geändert werden. (da eine GA auch an ein anderes KO zugewiesen wurde). Diese wird jetzt größer. Also ändern sich die Offsets von Got und Parameter. Du kannst dann entweder für die einzelnen InterfaceObjekte feste Größen vorsehen, oder du schreibst die abwechselnd auf zwei Bereiche im Flash, oder du lädst alle in den Ram und schreibst sie neu in den Flash. (ggf. pro Block prüfen ob man neu schreiben muss). Oder dir fällt noch etwas neues ein.

Die Hauptarbeit wird am Zusammenspiel der Klassen Memory, SaveRestore und TableObject sein. Die Platform muss wahrscheinlich auch mehr Operationen für das blockweise Speichern bekommen. Das ist insgesamt sicher keine ganze einfache Aufgabe.
Ich würde wahrscheinlich damit anfangen, dass die Memory-Klasse die Platform fragt wie groß die Blockgröße zum Speichern sein soll. Dann fragt die MemoryKlasse der Reihe nach alle registrierten SaveRestore Objekte nach den Blöcken und speichert diese. Den letzen Block sollte man am besten auffüllen damit ein neues SaveRestore immer an einem Block beginnt. Zusätzlich muss du dir irgendwo merken wie viele Blöcke jedes SaveRestore hat (vielleicht in den ersten zwei Blöcken?)
Dies nur als schnell heruntergeschriebene Idee.

Ich wünsche jedenfalls viel Spaß

VG
Thomas

[mumpf]

Hi,

das ist jetzt echt strange - ich mach mir ein paar Gedanken und Du hast gleich eine Lösung! Und auch noch eine wesentlich bessere als ich es mir hätte ausdenken können!

Noch ein paar Fragen eines technisch interessierten (hab mir Dein Coding noch nicht angeschaut, kommt am Wochenende):

• internalRam spart die Duplizierung bei den TableObject-Daten, hab ich verstanden -> Also hast Du hier die gleiche Idee wie ich gehabt, die Klassen arbeiten nur mit einem Pointer, deswegen auch 1,1k weniger RAM-Verbrauch, verstehe ich.
• external ist das, was ich eigentlich für meinen i2c-EEPROM-Implementierung gebraucht hätte, wenn ich vorher richtig drüber nachgedacht hätte... auch verstanden.
• internalFlash hört sich vom Speicherverbrauch am interessantesten an, aber hier verstehe ich nicht, wo Du die ca. 4,5k gespart hast? Und was passiert mit den Werten der KO (also die GroupObject-Klasse)? Werden deren Änderungen auch im Flash gespeichert? Das würde ja endlos viele Seiten-Updates erfordern, da man ja häufig KO wegschreibt (zumindest mach ich das, viele davon mit valueNoSend, damit sie für den nächsten ReadRequest verfügbar sind). Macht das den Flash nicht zu schnell kaputt?
• Wie machst Du denn den Firmware-Update, wenn Du sagst, dass bei Dir nicht der ganze Flash gelöscht wird? Ich hab nämlich keine Ahnung, wer den Flash löscht, bisher dachte ich immer, das "gehört" so .

Ansonsten teste ich gerne auch noch die Linux-Version, da kann ich auch beim debuggen mal sehen, wie Deine Sachen funktionieren. Und Deine SAMD-Implementierung werde ich natürlich auch ausprobieren, denn das verspricht mir mehr RAM... Ich berichte mal, auf wie viele Logikkanäle ich dann komme...

Ich habe mit der bisherigen Plattform eine EEPROM_EMULATION_SIZE von 6144 hin bekommen, bei ca. 5500 bytes an ETS-Daten. Das sind entweder 50 meiner Logikkanäle oder der BME280 (mit seiner Lib) mit Temperatur, Luftfeuchte, Luftdruck, Taupunkt, Wohlfühlbereich und 40 Logikkanälen. Oder ein SCD30 mit Temperatur, Luftfeuchte, Co2, Taupunkt, Wohlfühlbereich und 40 Logikkanälen. Ich wollte mich demnächst mal am BME680 versuchen, aber da scheint dessen Lib recht viel Speicher zu verbrauchen. Insofern wäre mehr RAM sehr interessant, dann könnte ich einheitliche Firmware für verschiedene Sensoren haben.

Auf jeden Fall super, dass Du das gemacht hast, ich versuche mich durch Tests zu bedanken...

Gruß, Waldemar

[Bernator]

thesing da hat sich glaub was überschnitten, aber deine erklärte Vorgehensweise entspricht nahezu 1:1 wie ich es angegangen bin, zum Problem mit den wechselnden Table Größen hab ich eben ein kleines dynamisches memory management für den Flash implementiert. Das wiederfinden passiert über eine eindeutige "memoryID" welche in addSaveRestore() vergeben wird.

Zu den 4,5k, gute Frage, eigentlich sollten es ca. 3k weniger sein (2k Emulation +1k ETS Daten), kann ich mir grad auch nicht erklären aber vielleicht ist da bei meiner Messung was schief gegangen (Ram usage zu untersuchen ist ja gar nicht sooo leicht )

Die Werte der KOs bleiben natürlich im RAM die müssen ja nicht über einen Device neustart hinaus gerettet werden....

Firmware-Update mache ich über den Debugger (Jlink) und der löscht nur den Flashbereich für den es auch neue Daten gibt (überschreibt quasi die alten), mehr zu löschen ist ganz einfach nicht notwendig. Ich vermute mal der Arduino Bootloader macht das auch so aber ich weiß es eben nicht. Der Grund warum bei der FlashStorage lib die ETS Daten nach jedem Update verlorgen gehen ist, das die Lib Flash Speicher über ein const Array reserviert und das landet natürlich irgendwo inmitten des text segements welches jedes mal vor dem schreiben der neuen daten gelöscht werden muss. Deshalb bin ich ja einen anderen Weg gegangen und mach es ähnlich wie Stack/Heap mit dem Ram, damit kommen sich die Bereiche so lange nicht in die Quere solange die Summe unter ~99% bleibt.

Nachdem das alles rel. grobe Änderungen mit sich brachte sind ausführliche Tests hier sehr wilkommen

thesing , was hälst du von einem stable/develop branch?

[manu241]

Hallo,

wäre eventuell jemand so nett und erstellt ein DemoIO-Projekt wie man die I/Os eines Arduino nutzen kann um KNX Befehle per Arduino sendet und auch empfängt?
Ich verstehe aktuell nicht, wie es funktioniert und könnte so eventuell einen besseren Einstieg finden.

Gruß und danke Manuel

[MasterOfPuppets]

Hallo,

wäre eventuell jemand so nett und erstellt ein DemoIO-Projekt wie man die I/Os eines Arduino nutzen kann um KNX Befehle per Arduino sendet und auch empfängt?
Ich verstehe aktuell nicht, wie es funktioniert und könnte so eventuell einen besseren Einstieg finden.

Gruß und danke Manuel

Geht mir genau so! Finde das Thema extrem spannend, Arduinos habe ich auch schon des öfteren programmiert, aber hier steige ich irgendwie nicht durch.

[mumpf]

Hi,

eigentlich macht das knx-demo.ino alles nötige (also keine Abfrage von IO-Pins, aber das kann man in anderen dafür gedachten Projekten abgucken). Ich gehe mal davon aus, dass Du knx-demo.ino auf Deiner Wunschplattform (linux, SAMD, ESP8266 oder ESP32) zum laufen gebracht hast.

In measure_temp gibt es z.B.

    goCurrent.value(currentValue);

das schreibt den aktuellen Temperaturwert auf das Kommunikationsobjekt goCurrent. Du könntest jetzt (erstmal testweise) einen pin auslesen und so was machen wie

if (pinValue != goCurrent.value()) goCurrent.value(pinValue);

Damit würde der Pin-Wert auf den Bus geschrieben werden, wenn er sich ändert.

Ein Beispiel zum Empfangen siehst Du in resetCallback. Der wird immer aufgerufen, wenn das KO goReset einen Wert vom Bus empfängt. Da kannst Du dann so was machen wie

pinValue = go.value();
// hier kommt der Code, um pinValue auf dem Pin auszugeben...

Das ist natürlich sehr "hausbacken", um mit dem aktuellen knxprod auszukommen (der pinValue, der auf den Bus gesendet wird, wird als Temperatur (DPT9.001) gesendet). Um was richtiges zu machen, musst Du mit CreateKnxProd eine knxprod-Datei basteln, dann kannst Du das auch über die ETS parametrisieren. Aber wie gesagt, in der knx-demo.ino sind schon alle Teile zum empfangen und senden drin.

Oder ich hab das Problem nicht verstanden... Vielleicht solltet ihr genauer euer Problem beschreiben, dann kann man euch konkret helfen...

Gruß, Waldemar

[Sonnengruesser]

manu241 und MasterOfPuppets: Für den Einstieg ist sicher erst mal das Projekt Arduino am KNX zu empfehlen. Das ist deutlich einfacher und man muss sich nicht mit der ETS-Integration herumquälen. Später kann man sich schrittweise dann in Richtung dieses Projekts bewegen. Als Zwischenschritt vielleicht noch mal bei KonnektING reinschauen.
Wenn man sich natürlich mit Softwareentwicklung auskennt sollte auch der direkte Einstieg hier möglich sein.

[jeff25]

Ich bin nun auch nicht wirklich der Profi aber du musst dir erst mal überlegen was du überhaupt machen willst, denke als erste Übung wäre ja ein Tasterinterface mit einem Eingang gut, da musst du ja nur den Eingang abfragen und bei Änderung das KNX Objekt ändern bzw die Änderung raussenden, das kann man sich ganz gut ableiten von den existierenden Beispielen (knx-demo).

[mumpf]

und man muss sich nicht mit der ETS-Integration herumquälen.

Ähhhh... Aber das ist doch gerade DER Pluspunkt für dieses Framework! Man kann DIY-Geräte basteln UND sie in die ETS integrieren. Und dann noch über KNX-IP und KNX-TP arbeiten! Ich empfinde eher die anderen Frameworks als "quälend", da ich entweder für jede Änderung eine neue Firmware brauche (bei Arduino am KNX) oder eine alternative Parametrisierungssoftware brauche (bei KONNEKTING).

Aber klar: Jeder soll das nehmen, was für einen am Angenehmsten ist.

Gruß, Waldemar

[jeff25]

kann mumpf nur zustimmen, bin auch erst seit kurzem eingestiegen mit Vorwissen aber schon lange her, gerade KNX-IP in Verbingung mit einem ESP8266 bringt schnelle Erfolge und man kann an den Demo Projekt viel anpassen um zu verstehen wie das alles funktioniert, auch die ETS Integration finde ich klasse und ist mir zum großen Teil klar. Ich rede natürlich nicht von eigenen XML Files erstellen im Editor :-)

[Sonnengruesser]

Vielleicht hab ich aufgrund der Wortwahl ein falsches Bild im Kopf, aber Aussagen wie

die I/Os eines Arduino nutzen kann um KNX Befehle per Arduino sendet

und

Arduinos habe ich auch schon des öfteren programmiert

klingen für mich eher nach Arduino copy-paste Programmierung ohne Hintergrundwissen - entschuldigt mich bitte falls dem nicht so ist. Und ich denke um dieses Projekt zu nutzen, sollte man zumindest verstehen wie structs, Klassen, usw. funktionieren.
Allein um die paar Zeilen aus der knx-demo.ino zu verstehen muss man sich schon ein bisschen reinfuchsen können:

 [TABLE]
 	 		[TR]
 			[TD]// print values of parameters if device is already configured[/TD]
 		[/TR]
 		[TR]
 			[TD] [/TD]
 			[TD]if (knx.configured())[/TD]
 		[/TR]
 		[TR]
 			[TD] [/TD]
 			[TD]{[/TD]
 		[/TR]
 		[TR]
 			[TD] [/TD]
 			[TD]// register callback for reset GO[/TD]
 		[/TR]
 		[TR]
 			[TD] [/TD]
 			[TD]goReset.callback(resetCallback);[/TD]
 		[/TR]
 		[TR]
 			[TD] [/TD]
 			[TD]goReset.dataPointType(DPT_Trigger);[/TD]
 		[/TR]
 		[TR]
 			[TD] [/TD]
 			[TD]goCurrent.dataPointType(DPT_Value_Temp);[/TD]
 		[/TR]
 		[TR]
 			[TD] [/TD]
 			[TD]goMin.dataPointType(DPT_Value_Temp);[/TD]
 		[/TR]
 		[TR]
 			[TD] [/TD]
 			[TD]goMax.dataPointType(DPT_Value_Temp);[/TD]
 		[/TR]
 	 [/TABLE]

Das geht dann über wire.begin() und pinMode() ein wenig hinaus - das verstehe ich unter "Arduino schon des öfteren programmiert".

Das Projekt hier selbst finde ich klasse! Nur die Einstiegshürde sollte man auch realistisch sehen.

[mumpf]

Hi,

Sonnengruesser: Sorry, ich fand "mit der ETS integration herumquälen" negativ behaftet und wollte nur klarstellen, dass ich das als wesentlichen Vorteil sehe. Aber natürlich hast Du recht: Damit ist die Einstiegshürde gegenüber den anderen genannten Frameworks hoch! Und man braucht auch recht potente Microcontroller (schnell, viel Flash, viel Speicher), damit alles überhaupt läuft. Wie schon oben geschrieben:

manu241 und MasterOfPuppets: Hier nochmal die Schritte, die es erfordert, um die knx-demo.ino zum laufen zu bringen:

1. Verbindung mit TP herstellen, wenn man damit arbeiten will (Siemens BCU, MicroBCU)
2. Falls notwendig, einen Programmierbutton an einen Pin anschließen
3. knx-demo.ino mit entsprechenden Angaben für die Anschluß-Pins anpassen
4. knx-demo.ino auf einen der unterstützen Microcontroller hochladen
5. Falls es die ESP-Plattform ist, WLAN-Verbindung herstellen (steht weiter vorne im Thread, wie das geht)
6. knxprod für IP oder für TP in die ETS laden
7. Am Microcontroller den Programmierbutton drücken
8. Jetzt sollte die Prog-LED leuchten
9. Von der ETS aus die physikalische Adresse programmieren
10. Jetzt sollte die Prog-LED ausgehen
11. In der ETS der Applikation ein paar GA zuweisen
12. Dann von der ETS aus die Applikation hochladen
13. Jetzt sollte das Device auf den zugewiesenen GA Telegramme schicken (Temp, Temp max, Temp min). Das kann man sich im Gruppenmonitor ansehen.

Erst wenn man das alles erfolgreich durch hat, sollte man über Anpassungen und Änderungen nachdenken.

Gruß, Waldemar

[MasterOfPuppets]

Vielen Dank für die Mühe =).

Jetzt habe ich es geschnaggelt, also doch so einfach wie ich zu Anfang erst dachte

Gruß Pierre

[manu241]

Hallo Waldemar,

danke für deine Hilfe. Die Demo-Version habe ich bereits zum laufen gebracht.

Mein erster Arduino schickt bereits Munter diese Zufallswerte.

Gruß Manuel

[Sonnengruesser]

Na gut, dann war meine Einschätzung wohl doch verkehrt, Glück auf manu241 und MasterOfPuppets .
Vielleicht sollte ich mir den Stack doch mal genauer ansehen...