ESP8266 KNX mit ETS

[Bernator]

Ok aber warum sind in der Facade dann Plattformspezifische Dinge wie zb. "pinMode(_ledPin, OUTPUT)" ect. sollte sowas nicht in die Platform und Facade nutzt dann nur die Methoden aus der jeweils ausgewählten Plattform? Wie implementiert man Plattformspezifischen Methoden die nicht in allen Plattformvarianten implementiert werden aber trotzdem über Facade dem User zugänglich gemacht werden sollen?

[thesing]

Die Facade war ursprünglich nur für Arduino. Eigentlich müsste die Platformklasse Abstraktionen für Pinmode usw. erhalten. Wenn man dann dabei ist, dann z.B. delay und millis aus der Platform-Klasse raus und ähnlich wie print* umgesetzt werden. Platformspezifische Methoden werden gar nicht über die Facade zugänglich gemacht.
Die Facade sollte gar keine platformspezifischen Methoden haben. Besser wäre es das globale FacadeObjekt abzuschaffen und im setup() erst ein Platform-Objekt zu erzeugen, dann ein BauSystemB-Objekt und schließlich ein KnxFacadeObjekt (wenn man will).

Oder man lässt sich das BauSystemB-Objekt über eine Methode geben und holt sich von dem dann wieder die Platform über eine Methode, castet die zur richtigen Platform und ruft die spezifischen Methoden auf. Oder man mach die globalen Variablen bau und platform aus knx_facade.cpp über knx_facade.h sichtbar (wie die knx-Variable). Dann kann man platfomspezifische Methoden mit platform.foobar() aufrufen. Das ist wohl das einfachste.

[mumpf]

Hi Thomas,

ich bin mir nicht sicher, ob ich Deine Abstraktionsvorhaben richtig verstehe, aber ich würde mir das nicht nur aus technischer Sicht betrachtet wünschen.

Vielleicht bin ich ja der einzige, aber ich sehe den großen Vorteil in Deinem Stack unter anderem darin, dass man alles unter Linux implementieren und testen kann und anschließend auf einer anderen Plattform (SAMD, ESP) laufen lassen kann. Wenn man sich das Ganze anschaut, dann gibt es bei den Arduinos die setup() und loop() Funktionen, beim Linux die main(), die dann selbst das setup() und loop() pattern implementiert.

Ich habe letztendlich bei mir ein Logikmodul.h und Logikmodul.cpp implementiert, die ihrerseits ein appSetup() und ein appLoop() exponieren, die passend von den setup()/loop() methoden aufgerufen werden. Alle Plattformspezifischen funktionen (bei mir nur millis()) habe ich im .ino-File bzw. im main.c gekapselt und als externe Funktion exponiert (ich weiß, das geht auch schöner) und kann so das SELBE Logikmodul.cpp coding auf allen 3 von Dir unterstützten Plattformen compilieren.

Warum schreibe ich das? Ich glaube, Dein letzter Absatz geht in die Richtung (bin mir aber nicht sicher), und das würde ich begrüßen. Ich kann ja mal heute Nachmittag versuchen, die knx-demo so umzubauen, dass sie auch mit allen 3 Plattformen identisch läuft, um zu zeigen, wie ich mir das vorstelle, dann kannst Du bzw. Leute, die besser c/c++ können, eine saubere Abstraktion und Kapselung vorschlagen . Jetzt muss ich aber leider erst zur Krankengymnastik und zum Arzt...

Gruß, Waldemar

[thesing]

Hallo Waldemar,

Ich glaube die Spaltung eines Sketches in verschiedene Dateien ist gerade für Arduino-Einsteiger zu komplex. (Zumindest kriege ich den Eindruck wenn ich mir die Sketche so anschaue.) Die einfachen Beispiele möchte ich daher auch in einer Datei behalten. Ich glaube das Logikmodul ist auch ein Sonderfall, da du dort wenig mit richtiger Hardware kommunizieren musst. Die millis(), delay() usw. will ich demnächst auch als externe Funktionen in die linux_platform.cpp packen.

Eine main mit setup()/loop() sollte jeder, der auf Linux programmiert hin bekommen. Ich bin aber für Vorschläge offen.
Zuerst ist aber DPT9 auf ESP8266 dran.

Grüße,
Thomas

[mumpf]

Hi Thomas,

Ich glaube die Spaltung eines Sketches in verschiedene Dateien ist gerade für Arduino-Einsteiger zu komplex.

dachte ich auch (bin auch noch blutiger Anfänger), aber dann hatte ich in der Hilfe gelesen, dass alle Dateien, die im gleichen Verzeichnis wie die .ino-Datei sind und deren .h-Datei includiert wird, auch mit übersetzt, gelinkt und hochgeladen werden. Und das hat auch auf Anhieb geklappt... Aber OK, ich verstehe Deinen Beweggrund und sicherlich bin ich mit einem reinen KNX-Gerät ohne externe Sensoren ein Exot bei der Nutzung Deines Frameworks. Und sobald Sensoren dazu kommen, ist die Testbarkeit unter Linux sicherlich auch nicht mehr einfach zu erreichen. Ich wollte mit meinem Beitrag oben aber wenigstens das Loswerden, was mich bei Abstraktion/Kapselung antreibt.

Gruß, Waldemar

[Bernator]

Dann kann man platfomspezifische Methoden mit platform.foobar() aufrufen.

Damit geht aber der Zusammenhang mit dem "Stack" verloren, besser wäre aus meiner Sicht in der facade die platform als member anzulegen dann könnte man knx.platform.foobar() aufrufen und man sieht sofort wohin die methode gehört?

[thesing]

Der Aufruf würde ja in etwa:
((SamdPlatform&)knx.platform()).foobar();
sein.
Besser wäre noch KnxFacade zum Template KnxFacade<P, B> zu machen. Dann könnte die Facade in eine parameterlosen Konstruktor die BauSystemB und die Platform auch selbst erzeugen und man würde durch knx.platform() auch den richtigen Typ erhalten. Bei der Gelegenheit kann man auch gleich eine Methode knx.bau() anlegen.

[mumpf]

Hi Thomas und Bernhard,

ihr seid klasse, vielen Dank! Ich konnte mit der letzten Version die KNX-Demo auf meinen SAMD zum laufen bringen, auch wenn der DPT9 hier noch immer 0.00 sendet, aber das stört mich derzeit nicht... ich werde jetzt erstmal versuchen, ob mein Logikmodul zum fliegen kommt.

Vielen Dank erstmal und Grüße,
Waldemar

P.S.: Was mir noch aufgefallen ist: Ich kann über die ETS prüfen, ob die PA programmiert worden ist, aber nicht die Prog-LED zum blinken bringen... sollt das gehen?

[thesing]

Die Led wird aktuell nur in KnxFacade:rogMode geändert. Damit das funktioniert, müsste man das digitalwrite dort rausnehmen und im KnxFacade::loop die Led an oder ausschalten je nachdem ob _bau.deviceObject().progMode() true ist oder nicht.

[mumpf]

Dann werde ich das heute Nachmittag ausprobieren. Ich finde es immer praktisch, wenn man über KNX feststellen kann, ob man das richtige Gerät an der Hand hat, und da ich wahrscheinlich 3 logikmodule haben werde (pro Stockwerk eines), könnte ich das Mal in Zukunft brauchen.

Deine Antwort sagt mir aber, das man den ProgMode per Bus einschalten kann. Ich hatte vermutet, dass das nicht klappt...

Gruß, Waldemar

[thesing]

Ja der ProgMode sollte sich problemlos per ETS setzten lassen. Hat eigentlich jemand einen Geschwindigkeitszuwachs beim programmieren beobachtet? Ich hatte letztens die MAX_APDU_SIZE nach oben gesetzt.

[SebastianObi]

Hallo,

ich habe festgestellt, dass die Anzahl an Gruppenadressen auf 255 beschränkt ist. Im AssociationTableObject steht nur 1 Byte für die GA zur Verfügung. Lässt sich das erweitern? Ich habe das selbst probier, blicke aber im Detail nicht durch, da wohl an diversen Stellen Anpassungen notwendig sind.

[mumpf]

Hi,

ich habe festgestellt, dass die Anzahl an Gruppenadressen auf 255 beschränkt ist

das könnte auch ein Problem bei mir werden. Bei meinem avisierten Ziel von 240 (+2) KO und einem bisherigen Geräteschnitt von ca. 1,3 GA pro KO wird das mit 255 GA knapp. Aber vielleicht komme ich gar nicht auf so viele KO, weil der Speicher im SAMD gar nicht für die ganzen Parameter reicht .

Gruß, Waldemar

[thesing]

Ich kann die Anzahl problemlos erhöhen. Dann wird es aber nicht mehr mit ETS4 gehen. Bin aber am WE unterwegs.

[thesing]

Ich habe die Anzahl der Einträge für AT und GAT im CreateKnxProd auf ushort.MaxValue erhöht und die GAT auf das größere Format umgestellt. Evtl. muss man im AssociationTable::nextAsap und AssociationTable::translateAsap noch operator[](i + 1) mit operator[](i) und umgekehrt tauschen. Ich habe leider heute keine Zeit mehr das zu testen/zu debuggen. Den entsprechenden Verweis auf die Spezifikation hab ich ins commit-Kommentar geschrieben. Ich komme vor Sonntag Abend oder Montag Abend nicht zu mehr.