ESP8266 KNX mit ETS

[mumpf]

Hi,

Du kannst auch einfach den master neu forken

jetzt kommt mein beschränktes Wissen zu github raus... Ich hab schon einen Fork gemacht, wie kann ich das nochmal forken?

Gruß, Waldemar

[Ing-Dom]

neues projekt (leeres repo!) mumpf/knx2 anlegen
thelsing/knx lokal clonen nach C:\Data\knx2
dann origin von C:\Data\knx2 entfnern
origin C:\Data\knx2 auf mumpf/knx2 setzen
pushen

[mumpf]

Danke, mal schauen, ob ich das brauche. Ich hab im Augenblick einen Branch knx-for-pull gemacht, der jetzt auf dem Original steht, mal schauen, ob ich da weiter komme.

Aber ich hab gleich eine Frage an thesing: In group_object.h gibt es jetzt was neues:

#if HAS_FUNCTIONAL
#include <functional>
typedef std::function<void(GroupObject&)> GroupObjectUpdatedHandler;
#else
typedef void (*GroupObjectUpdatedHandler)(GroupObject& go);
#endif

Was ist das denn? Ich hatte ja den GroupObjectUpdatedHandler-Callback statisch gemacht. Wie man das aber auf die andere Methode umsetzt, weiß ich nicht wirklich. Ich könnte höchstens bei meinem Ansatz dann das HAS_FUNCTIONAL wieder auf 0 setzen. Oder ich mach auch die Funktion statisch, ich bin mir nur nicht sicher, ob ich das vernünftig getestet bekomme. Ist aber eher meinen mangelnden C++-Kenntnissen zuzuschreiben.

Gruß, Waldemar

[Ing-Dom]

der "flash" branch ist schon der richtige oder thesing ?
Weil es gibts ja doch noch ein memory_rework ? Was hats damit auf sich?

[thesing]

mumpf : Das sollte für dich irrelevant sein. std::function ist quasi ein Functionpointer als C++ Klasse. Es wird an der Stelle nur der Typ
GroupObjectUpdatedHandler definiert.

Ing-Dom Der flash-branch ist der richtige. Memory-rework ist der Branch in dem Bernator SAMD21-Flashzugriff implementiert hat. (In etwa der Stand auf dem mumpf aufgesetzt hat.) https://github.com/thelsing/knx/blob...samd_flash.cpp sollte da am interessantesten sein. (Dort ist eine Row ein Eraseblock, also der Teil der beim Flash immer zusammen gelöscht wird.)
Jetzt sollte der flash branch auch wieder compilieren.

[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

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

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

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

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

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

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

[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