ESP8266 KNX mit ETS

[jeff25]

fände ich total gut dann muss man nicht 44 Seiten durchsuchen :-)

[thesing]

Soll ich das wiki auf der github-Seite frei schalten? Da könnte man solche Dinge nachhalten.

[mumpf]

Hi,

für die Nachwelt und falls es jemand anders auch braucht (und hier überhaupt findet): So greift man auf die internen Register des NCN5130 zu:

#define U_INT_REG_WR_REQ_WD       0x28
#define U_INT_REG_WR_REQ_ACR0     0x29
#define U_INT_REG_WR_REQ_ACR1     0x2A
#define U_INT_REG_WR_REQ_ASR0     0x2B
#define ACR0_FLAG_V20VEN          0x40
#define ACR0_FLAG_DC2EN           0x20
#define ACR0_FLAG_XCLKEN          0x10
#define ACR0_FLAG_TRIGEN          0x08
#define ACR0_FLAG_V20VCLIMIT      0x04
void savePower() {
    println("savePower: Switching off all energy hungry devices...");
    // turn off 5V rail (CO2-Sensor & Buzzer)
    uint8_t buffer[] = {U_INT_REG_WR_REQ_ACR0, ACR0_FLAG_XCLKEN | ACR0_FLAG_V20VCLIMIT };
    knx.platform().writeUart(buffer, 2);
}

Im obigen Bespiel greife ich auf das Analog Control Register 0 zu und lösche die Bits 5 und 6 (ACR0_FLAG_V20VEN, ACR0_FLAG_DC2EN), die anderen lasse ich so, wie sie sind (default). Die Register sind im datasheet https://www.onsemi.com/pub/Collateral/NCN5130-D.PDF beschrieben.

Gruß, Waldemar

[jeff25]

Hi Waldemar,

ich lese Deine Monologe mit Interesse, bin nur fachlich nicht so weit Antworten zu geben :-)

Gruß
RObert

[mumpf]

Hi,

auch wenn das ein Monolog wird , die erste Frage scheint sich erledigt zu haben, Reset ist Reset... hab ich auch befürchtet, aber was solls, ist ein seltener Fall im Produktivbetrieb, kommt nur oft beim entwickeln vor.

Und nachdem ich mir nochmal das Datasheet vom NCN5130 im Zusammenhang mit der Implementierung vom tpuart_data_link_layer angesehen habe, hab ich zumindest eine Idee, was ich versuchen muss, um den 5V Regler abzuschalten. Falls jemand Beispielcoding hat, wäre das hilfreich, aber ich denke, ich werde es auch so hin bekommen.

Wie der JLink den gesamten Flash löschen kann hab ich aber immer noch nicht in Erfahrung bringen können...

Gruß, Waldemar

[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

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

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

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

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]

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

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

[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

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

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