ESP8266 KNX mit ETS

[Weltenbummler]

Arbeitet eigentlich jemand hier mit einem ESP32 und WIFI, also IP? Ich hatte die Demo nach zahlreichen Versuchen irgendwann mal am Laufen. Dann habe ich darauf aufbauend für meine Applikation die knxprod mit weiteren Parametern und KOs angepasst. Soweit so gut.

Beim Programmieren aus der ETS5 habe ich jetzt folgendes Verhalten: Nur physikalische Adresse funktioniert. Wenn ich anschließend das Applikationsprogramm laden möchte, kommt keine Antwort vom ESP32, ETS bricht mit Timeouts ab. Programmiere ich phys. Addresse und Applikationsprogramm läuft alles fehlerfrei durch. Beim anschließenden Neustart kommt vom ESP32 ein abort() beim Initialisieren der Groupobjects. Ich konnte herausfinden, dass die Variable goCount auf FFFF steht. Dafür reicht der RAM natürlich nicht, daher der abort(). Ich habe in meiner knxprod nur 3 KOs drin. Der Bereich, der beim SAVE gespeichert wird und beim RESTORE zurückgelesen wird ist identisch. Bei mir sind das 130 Bytes. Die letzten 20 stehen allerdings auf FF.
Habt ihr einen Tipp für mich, wo ich bei der Fehlersuche ansetzen kann?
Gruß Stefan

[mumpf]

Das ist perfekt auf den Punkt gebracht .

Gruß, Waldemar

[thesing]

Es ist im Grunde ganz einfach. Die Konfiguration liegt im Flash. Beim SAMD ist der Flash direkt adressierbar. Bei der EEPROM-Emulation wird ein Teil des Flashs in dem RAM kopiert. Da nach der Konfiguration durch ETS diese Daten nicht mehr geändert werden müssen sie nicht im RAM vorliegen. Also verschwendet die EEPROM-Emulation nur RAM.

[Ing-Dom]

sehr sinnvoll für Parameter welche das wiederkehrende (über einen Powercycle hinaus gültige) Abspeichern einzelner Werte zur Laufzeit notwendig machen

korrekt.
Das ist aber nicht das, was wir hier üblicherweise unter Parameter verstehen - wir reden über die "KNX" Parameter, und die werden zur Laufzeit eben nicht wiederkehrend, sondern sehr selten geschrieben.

[Techi]

Hi,
ich glaub wir reden hier aneinander vorbei. Ich weiß sehr wohl (und vor allem sehr hardwarenahe) was Ram, Flash, Eprom bzw. Eeprom ... ist.
Aber egal, aus meiner Sicht ist es jedenfalls sehr sinnvoll für Parameter welche das wiederkehrende (über einen Powercycle hinaus gültige) Abspeichern einzelner Werte zur Laufzeit notwendig machen eine eeprom Simulation zu verwenden, zumindest eben wenn hierfür klassisches Flash (Page Erase) verwendet werden soll. Da bei einer eeprom Simulation das LESEN von Werten teils länger benötigt als das schreiben (es muss beim lesen der jeweils letzte gültige Eintrag gesucht werden) bedingt eine eeprom Simulation meisst ohnehin ein RAM Backup.

VG,
Walter

[mumpf]

Hi,

Aber gibt es nicht auch Fälle wo mal häufig einzelnen Status Infos (z.B. über Schaltzustände) gespeichert werden müssen ?

ich denke, Du meinst nicht Laufzeitzustände, denn die sind natürlich im RAM gespeichert. Wir reden hier über Zustände, die über einen Stromausfall/Busreset hinweg gespeichert werden sollen. Ich habe da z.B. den Wert eines (Eingangs-)KO, der auf Userwunsch erhalten bleibt oder auch irgendwelche Kalibrierungswerte von Sensoren, die sich erst zur Laufzeit ergeben und die nicht immer neu ermittelt werden sollen.

Dafür habe ich bisher immer ein EEPROM (eher klein, so um die 2 KByte) genutzt. Könnte man auch im Flash speichern, da hast Du Recht. Dafür bietet auch der Stack von Thomas Methoden an, wenn ich mich recht erinnere. Nutze ich nur nicht.

Aber wir reden hier sowieso aneinander vorbei...

Technisch wurden schon immer alle Werte, die von der ETS kommen, im Flash gespeichert. Nur ist im aktuellen Stack der Zugriff auf Parameter/KO/GA so gelöst, dass diese Daten beim Modulstart ins RAM geladen werden, bevor sie der Applikation, die den Stack nutzt, zur Verfügung gestellt werden. Das ist aber für Parameter und Assoziationstabellen nicht notwendig, da diese zur Laufzeit nicht verändert werden. Nur die KO müssen im RAM existieren.

Der Fork, den ich nutze, macht genau das: Er kopiert nur die KO ins RAM und blendet den Flashbereich, in dem die anderen Daten stehen, quasi als ReadOnly-Memoryblock in den Linearen Speicher ein, so dass man direkt lesend auf den Flashspeicher zugreifen kann, ohne ihn zu kopieren.

Gruß, Waldemar

[Techi]

Ich meine nicht das direkte Lesen, ich meine z.B. die Info von thesing

- Als dringenstens Feature sehe ich noch direktes Flash schreiben für SAMD21. Dafür habe ich im flash-Branch schon den platformunabhängigen Teil geändert. Es müsst nur noch der platformspezifische Teil geschrieben werden. Dann fällt bei SAMD21 die EEPROM-Emulation weg. Das dürfte auch der Hauptgrund für den fork von mumpf gewesen sein.

Aber wenn wirklich nur selten und nur am Block gearbeitet wird (also z.B. ein Page Erase nur bei jedem großen Write aus der ETS) dann könnte man in der Tat wohl darauf verzichten.
Aber gibt es nicht auch Fälle wo mal häufig einzelnen Status Infos (z.B. über Schaltzustände) gespeichert werden müssen ?

[Ing-Dom]

Warum soll denn überhaupt eine direkte Flash speicher Version im Stack unterstützt werden ?

die Daten (Paramter, "Metadaten" der KO) werden im Normalbetrieb ausschließlich gelesen! Nur beim Programmieren (ETS) werden diese geschrieben.
Und da dann ein Vorhalten im SRAM keinen (wenig ?) Vorteil bringt, kann man sich den Platz sparen und direkt aus dem Flash lesen.

[Techi]

Ich beschäftige mich anderweitig sein Jahren mit Flash Speichern in Embedded Systemen, darum hab ich hier mal eine Frage:

Warum soll denn überhaupt eine direkte Flash speicher Version im Stack unterstützt werden ?
Aus Hardware Sicht hat es schon einen Sinn eine Eeprom Emulation zu verwenden, denn damit werden Flash Erase Operationen (Page Erase) auf eine Minimum reduziert. Flash Page Operationen sind es was den üblichen Flash Strukturen in den Controllern auf Dauer zusetzt.

Ich kenne die genauen Anforderungen des Stacks diesbezüglich ja nicht, aber einfach jeweils komplette Pages zu löschen wäre nur sinnvoll wenn diese jeweils auch komplett wieder mit anderen Daten neu beschrieben werden würden. (also z.B. beim einem Page Ping/Pong System)

[jeff25]

Hi Waldemar,

super danke für die Erklärung! Samd21 nutze ich auch genau wegen der Busversorgung. Gibt es eigentlich auch Erfahrung mit dem STM32 wie ist denn da so der Stromverbrauch?

Gruß
RObert

[mumpf]

Hi Robert,

eigentlich ist es einfach. Ich habe mir ein GroupObject (KO) angesehen und festgestellt, dass es pro Instanz 19 Bytes Verwaltungsinformation braucht. Ich hab geschaut, wie viel davon gespart werden kann. Am Ende ist es bei 8 Bytes geblieben. Dadurch kannst Du ungefähr 2,3 mal so viele KO im RAM unterbringen. Zu den Verwaltungsinformationen kommt noch immer der Payload, also die eigentlichen KO-Daten hinzu, also die jeweilige Länge vom DPT in Bytes. z.B. bei DPT1 1 Byte, bei DPT 16 14 Byte. Daran hat sich nichts geändert.

Für kleine Projekte ist meine Erweiterung nicht notwendig. Ich bin bei mir im Vollausbau bei über 400 KO, arbeite mit dem SAMD21, bei dem ja (im aktuellen Stack) auch die Parameter im RAM sind, das hätte alles nicht ins RAM gepasst.

Mit den Parametern im Flash und den kleinen KO ist bei 400 KO auf dem SAMD noch nicht die Grenze des Machbaren erreicht. Und SAMD ist es deswegen, weil der vom Bus versorgt werden kann.

Gruß, Waldemar

[jeff25]

Hi Waldemar,

würde das mit den SMALL_GROUPOBJECT gerne verstehen, das ist nur zur Speicheroptimierung oder das nicht immer der gleichgroße Speicherblock reserviert wird, was bringt das sonst?

Gruß
Robert

[mumpf]

Hi,

habe soeben gelesen, dass Thomas meinen Pull-Request mit SMALL_GROUPOBJECT in den Hauptzweig aufgenommen hat. Danke!

Ing-Dom: Falls Du wirklich was in Richtung SAMD-Flash machst (also der Verzicht auf FlashStorage), dann würde ich auch noch meine anderen Änderungen in den Stack bringen und dann hoffentlich auch wieder in den Hauptzweig einziehen können.

Gruß, Waldemar

[mumpf]

Hi,

habe nach erfolgreichen Tests (allerdings nur mit TP) einen Pull-Request mit meiner Änderung zu SMALL_GROUPOBJECT und einem passenden knx-demo-small-go Beispiel im examples Ordner gemacht. Github sagt, dass die checks durch sind und es keine Konflikte zum master-Branch gibt. Ich hoffe, damit spricht nichts gegen einen Merge.

Falls es Fragen oder offene Punkte gibt, lasst es mich wissen. Ich habe noch nicht so oft pull requests gemacht...

Gruß, Waldemar

[mumpf]

Hi,

nur zur Info: Ich hab jetzt zwar SMALL_GROUPOBJECT in den aktuellen Stand eingebaut, bekomme aber die knx-demo nicht gebaut, um zu testen. Ich hoffe, dass ich das im Laufe des Tages noch hin bekomme, dann würde ich zeitnah einen Pull-Request machen, damit das nicht verloren geht. Ich war nämlich schon mal so weit, und dann hab ich es "verpennt" zu pushen.

Gruß, Waldemar