ESP8266 KNX mit ETS

[thesing]

Hi Waldemar,

die Versionen, die ich meine habe nichts direkt mit der knxprod zu tun. Man kann im Sketch festlegen, welchen Hardwaretyp, welchen Hersteller, welche Firmwareversion usw. der Sketch hat. Ich würde nur prüfen, ob die Werte im Flash mit dehnen im Sketch übereinstimmen.

Die ApplicationVersion in der knxprod wird (AFAIK) nur von ETS genutzt. Man könnte zusätzlich noch in der knxprod einstellen, dass beim Programmieren via ETS geprüft wird, ob der HardwareType des Sketches zum HardwareType der knxprod passt. Andere Prüfungen gehen sicher auch. Standartmäßig prüft ETS zumindest ob der Manufacturer der richtige ist.

VG
Thomas

[mumpf]

Hi Thomas,

die Versionen, die ich meine habe nichts direkt mit der knxprod zu tun. Man kann im Sketch festlegen, welchen Hardwaretyp, welchen Hersteller, welche Firmwareversion usw. der Sketch hat. Ich würde nur prüfen, ob die Werte im Flash mit dehnen im Sketch übereinstimmen.

da spricht natürlich nichts gegen - solange Du uns (zumindest mir) verrätst, wie man die Werte im Sketch festlegt... ich denke, das wird man dann ich der knx-demo finden.

Man könnte zusätzlich noch in der knxprod einstellen, dass beim Programmieren via ETS geprüft wird, ob der HardwareType des Sketches zum HardwareType der knxprod passt.

Ich bin da "indifferent", meinen check hab ich ja selber implementiert, und das auch nur als Selbstschutz, damit ich nicht versehentlich die falsche knxprod mit einer bestimmten Firmware nutze und mich dann wundere, dass nicht läuft (ist mir bereits passiert).

Gruß, Waldemar

[mumpf]

Hi,

ich konnte jetzt erfolgreich den Segger JLink mit PlatformIO in Betrieb nehmen. Programmieren klappt, auch ohne den gesamten Flash zu löschen (die ETS-Daten bleiben also erhalten), Debugging geht auch - super.

Was ich noch vermisse: Der Output über SerialUSB ist nicht wie erwartet im VSCode zu sehen. Kann mir hier jemand einen Tipp geben, was ich machen muss oder wo ich das nachlesen kann? Meine bisherigen Recherchen haben da nichts hervorgebracht...

Danke und Gruß,
Waldemar

[mumpf]

Hallo Thomas,

ich wollte am WE jetzt mal wieder aufräumen und alles zusammen bringen, u.a. auch mit Deinem Stack "mergen" - da hab ich festgestellt, dass Du den memory-rework branch noch nicht im master hast. Derzeit gäbe es also entweder knx-rf oder flash. Gibt es dafür einen Grund? Planst Du, das noch zusammen zu bringen? Ist nicht eilig, ich hab je eine lauffähige Version, ich wollte nur wissen, ob sich da was auseinanderentwickelt...

Gruß, Waldemar

[thesing]

Hallo Waldemar,

der Code von Bernhard wird nicht einfach so übernommen, sondern extra eingearbeitet. Im ersten Schritt wird geändert, dass die ganzen TableObjects ihre Daten im nicht nochmal puffern, sondern die Daten direkt aus dem Flash bzw. aus dem Flashbuffer nutzen. Dabei wird erst mal das alte Interface zur Platform (getEepromBuffer()) genutzt. Einen Buffer im Ram in der Größe eines Eraseblocks (also die Größe die man im Flash auf einmal löschen muss. Das heißt je nach MCU mal Sector, oder Block, oder sonstwie.) braucht man eh. Die Eeprom-Emulationen nehmen davon aktuell (höchstwahrscheinlich) genau einen.
Im nächsten Schritt wird dann die Memory-Klasse so erweitert, dass sie mit Eraseblocks und Flashpages usw. klar kommt. Das ist bei Bernhards Lösung alles in der SamdFlash-Klasse drin. Ich möchte das einmal im Stack drin haben, damit man das nicht für jede Platform neu implementieren muss. Dann gibt es in der Platform etwa:

virtual size_t flashEraseBlockSize(); // in pages
virtual size_t flashPageSize();       // in bytes
virtual uint8_t* userFlashStart();   // start of user flash aligned to start of an erase block
virtual size_t userFlashSizeEraseBlocks(); // in eraseBlocks
virtual void flashErase(uint16_t eraseBlockNum); //relativ to userFlashStart
virtual void flashWritePage(uint16_t pageNumber, uint8_t* data); //write a single page to flash (pageNumber relative to userFashStart

Ich bin mir noch nicht sicher, ob das dann eine FlashMemory-Klasse wird, oder es bei einer Memory-Klasse bleibt.
Ebenso bin ich mir noch nicht sicher, ob ich Speicher wie EEPROM in der Platform in dem Ram laden will, oder ob die Memory-Klasse das machen soll. (Evtl. eine spezielle Memory-Klasse). Dazu kommt noch, dass bei ESP8266 der Flash z.B. nicht über den Speicherbus sondern per SPI angebunden ist. Da kann der Flash also nicht einfach über einen Zeiger gelesen werden, sonder muss auch byteweise geholt werden. Beim ESP32 ist es genau so, aber man kann den Speicher in den Adressraum mappen.

Dann gibt es auch noch Leute, die gern den Flash aus dem Eeprom initialisieren wollen

Kurz: Ich will das Thema nichtflüchtiger Speicher jetzt einmal richtig anfassen und dann möglichst eine Weile nicht anfassen müssen. Und dafür lasse ich mir auch die nötige Zeit.

VG Thomas

[mumpf]

Hallo Thomas,

vielen Dank für die wie immer informative und erschöpfende Antwort. Ich freue mich, dass die Entwicklung von Bernhard auch den Weg in den Stack finden wird. Und ich verstehe auch, dass es seine Zeit dauern wird, ich wollte nicht drängeln, sondern nur verstehen.

Dann gibt es auch noch Leute, die gern den Flash aus dem Eeprom initialisieren wollen

Bei meiner letzten Zählung war das nur einer. Und der (also ich) ist gar nicht mehr so "scharf" drauf...

Ich sehe das mit der Speicherverwaltung sehr pragmatisch von der praktischen Seite her:

1. Ich brauche viel RAM
2. Ich möchte möglichst kurze "roundtrips" beim entwickeln (also möglichst nicht nach jedem flashen der Firmware mit der ETS programmieren müssen. Eben so komfortabel, wie das unter Linux ist)

Punkt 1 wurde von Bernhards Ansatz unterstützt/verbessert, Punkt 2 nicht, weil ich nicht zuverlässig die Firmware flashen konnte, ohne den gesamten Flash vorher zu löschen. Und da meine Hardware sowieso ein 32kByte EEPROM hat, dachte ich, ich könnte bein Startup von da aus die Daten in den Flash schreiben.
Inzwischen habe ich den Segger J-Link und kann damit zuverlässig Firmware flashen ohne den gesamten Flash zu löschen, somit bleiben die ETS-Daten im Flash und ich hab meine schnellen Roundtrips (und kann Debuggen). Deswegen kannst Du meinen obigen Wunsch vergessen...

So wie ich Deine Erklärung verstanden habe, wird

Im ersten Schritt wird geändert, dass die ganzen TableObjects ihre Daten im nicht nochmal puffern, sondern die Daten direkt aus dem Flash bzw. aus dem Flashbuffer nutzen.

der erste Schritt noch nicht den obigen Punkt 2 unterstützen können. Was ja auch OK ist. Aber hast Du auf Deiner Liste, dass der finale Ausbau so was ermöglicht (z.B. indem man - wie Bernhard - mit den ETS-Daten den Flash von hinten nach vorne schreibt)? Es wäre schade, wenn das verloren geht...

Danke und Gruß,
Waldemar

[jeff25]

Bei meiner letzten Zählung war das nur einer. Und der (also ich) ist gar nicht mehr so "scharf" drauf...

Ich sehe das mit der Speicherverwaltung sehr pragmatisch von der praktischen Seite her:[LIST=1][*]Ich brauche viel RAM[*]Ich möchte möglichst kurze "roundtrips" beim entwickeln (also möglichst nicht nach jedem flashen der Firmware mit der ETS programmieren müssen. Eben so komfortabel, wie das unter Linux ist)

Ich melde mich hier al zweiter Interessent für die EEPROM Variante, ich habe bei meinem neuen Board extra ein EEPROM mit drauf gebaut da es mich auch nervt immer wieder neu Programmieren zu müssen... :-)

[mumpf]

Hi,

da es mich auch nervt immer wieder neu Programmieren zu müssen...

da kann ich Dir nur empfehlen, die 25€ für einen Segger J-Link mini EDU auszugeben. Funktioniert mit der Flash-Variante von Bernhard ( Bernator ) schon jetzt prima. Ich dachte zuerst, braucht man nicht, aber man kann damit ja auch noch debuggen!

Das EEPROM kannst Du ja immer noch zum zwischenspeichern von Zählerständen, KO-Zuständen oder sonst irgendwelchen Spielereien nutzen.

Gruß, Waldemar

[thesing]

Ich habe übrigens mal mit ETS-Inside getestet. Wenn man die Geräte in ETS hinzufügt und da Geräte zu ETS-Inside sendet, bleiben die Geräte erhalten, und man kann sie auch weiterhin in ETS-Inside nutzen.
Ohne Professional sind also nur 5 Custom-Geräte in der Inside möglich. Man mach ein neues Projekt in ETS(Demo Lizenz), fügt die 5 verschiedenen Geräte hinzu und schickt das Projekt an ETS-Inside und fügt dort die restlichen Geräte hinzu. Nur muss man dann bei jeder Änderung der knxprod das ganze Projekt so neu aufsetzen... Praktikabel ist es also nicht.

[thesing]

Ich habe übrigens im devel Branch schon die Memory-Klasse überarbeitet. Ist aber noch komplett ungetestet.

[mumpf]

Ist aber noch komplett ungetestet.

Hi Thomas, ich teste gerne - sofern es sich um die Flash-Implementierung handelt (ich hab noch nicht nachgeschaut), aber vorher muss ich noch mein aktuelles Teilprojekt fertig bekommen - dazu hab ich noch Fragen:

Erstmal der Hintergrund: Ich möchte für ein paar KO die Werte bei Stromausfall speichern und nach dem Neustart wiederherstellen. Dafür habe ich jetzt die Hardware hier und so um die 500ms Zeit (hoffentlich). Der Speicheralgorithmus ist kein Problem, er muss an folgenden Stellen aufgerufen werden:

1. Bei Stromausfall über ein Interrupt - bekomme ich hin
2. Beim "ResetDevice" über ETS - bekomme ich auch hin, habe eine Stelle gesehen, wo Du auch Deinen Speicherservice aufrufst.
3. Vor dem Programmieren (das kann nämlich das MDT Logikmodul nicht) - da ist mir etwas unklar: Wenn die ETS neue Parameter und/oder KO programmiert und am Ende der Programmierung der Reset kommt, hab ich dann noch die alten KO, deren Werte und die alten Parameter zur Verfügung? Dann könnte nämlich das normale Speichern wie bei Punkt 2 laufen. Wenn aber beim Reset nach der Programmierung schon die neuen Parameter und KO über die Zugriffsmethoden geliefert werden, muss ich ja am Anfang der Programmierung speichern und in diesem Fall beim Reset nicht.

Meine Fragen sind:

• Muss ich vor der Programmierung speichern oder reicht es nach der Programmierung, sprich vor dem Reset?
• Wenn vor der Programmierung: Wie bekomme ich mit, dass Parameter bzw. KO programmiert werden?
• Wird eigentlich   knx.configured()  während der Programmierung über die ETS false (dann könnte ich notfalls die Flanke true->false auwerten)?

Ansonsten versuche ich gerade, einen   #ifndef SMALL_GROUPOBJECT  im Stack an allen Stellen einzubauen, um zu sehen, wie viel Speicher man wirklich mit statischen DPT sparen kann. Mein Logik- und mein Sensormodul habe ich schon so umgebaut, dass bei jedem value-Zugriff ein DPT (natürlich ein Sigleton) mitgegeben wird. Werde berichten...

Gruß, Waldemar

[thesing]

Hallo Waldemar,
es ist nur die Variante mit der EEPROM-Emulation über den Flash.

Wenn die Parameter oder GroupObjectTable geändert werden, dann wird zuerst der entsprechende Speicher frei gegeben. D.h. die Parameter und KOs sind weg.
Du könntest dich in die beforeStateChange(LoadState& newState) Methode reinhängen. Und da auf den Unload-State reagieren. In 3_5_1 Punkt 4.17 wird die State-Machine beschrieben. Da könnte man problemlos Userhandler registrierbar machen.

knx.configured() sollte auf jeden Fall während der Programmierung false sein.

VG Thomas

[mumpf]

Hallo Thomas,

danke für die Erklärung, dann werde ich mal versuchen, das zu implementieren und dann auch Deine Flash-Memory-Variante testen.

Gruß, Waldemar

[mumpf]

Hi, wie hier versprochen

Werde berichten...

hier mal ein Zwischenergebnis:
Mit SMALL_GROUPOBJECT, also

• die _table-Referenz in jedem KO ist statisch (weil immer gleich)
• KO hat keinen _updateHandler mehr, callbacks werden über eine Klassenmethode dispachted
• KO hat keinen _datapointtype mehr, der wird bei jeder value-Methode mitgegeben

benötigt ein KO jetzt nur noch 5 Byte Verwaltungsdaten, damit konnte ich mein Sensormodul erfolgreich mit 100 Logikkanälen (und den Sensoren natürlich) zum laufen bekommen. Mit dem Flash-basierten Stack von Bernhard. Ohne SMALL_GROUPOBJECT gehen 60 Kanäle, 80 klappen nicht mehr und dazwischen habe ich es nicht probiert. Und ohne Flash gingen gerade mal 40 Logikkanäle. In den letzten 2 Monaten hat sich also so viel getan, dass ich die Kapazität vom gleichen Modul mehr als verdoppeln konnte.

Ich bin echt "GeFLASHed". Nochmal meinen herzlichen Dank an Thomas und Bernhard für die vielen Verbesserungen und Anregungen.

Gruß, Waldemar

P.S.: Ein Pull-Request kommt, wenn ich das mal ne Zeit lang getestet habe...

[mumpf]

Hi,

bei mir haben sich jetzt ein paar Fragen angesammelt, vielleicht hat jemand von euch eine Idee:

• Kann ich bei SAMD irgendwie den Reset abfangen? Ich meine den Hardware-Reset, als das, was ich über den Reset-Button auslöse. Ich würde gerne auch im Reset-Fall noch vorher meine Werte ins EEPROM schreiben... Es geht um ca. 400 ms, die ich den Reset verzögern möchte.
• Ich verwende den NCN5130, der erlaubt es, den 5V-Regler abzuschalten (Analog Control Register 0, Bit 5). Hat jemand ein Stück Coding oder einen Tip, wie ich an dieses Register dran komme? Ich muss bei Stromausfall die 5V abschalten, da mir sonst die Sensoren die Zeit, die ich zum speichern der Werte habe, stark verkürzen, indem sie den Kondensator, der den Strom puffert, leersaugen.
• Der Segger JLink hat den Vorteil, dass er beim download der Firmware nur die Bereiche im Flash überschreibt, die auch die Firmware belegt. So bleiben die ETS-Daten im Flash erhalten. Weiß jemand, ob und wie ich den JLink veranlassen kann, doch den ganzen Flash zu löschen. Ich hatte schon Fälle, bei den durch falsche ETS-Daten die Firmware sich gleich beim Start aufhängt. In solchen Fällen würde ich gerne den Flash löschen können.

Danke und Gruß, Waldemar