ESP8266 KNX mit ETS

[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

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

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.

[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 Platform ist eine Abstraktion für Hardware/Betriebssystem (Linux vs. Esp8266 vs. Samd21). KnxFacade implementiert das Facade-Patter (https://de.wikipedia.org/wiki/Fassade_(Entwurfsmuster)) Damit soll die Nutzung für den Anwender vereinfacht werden.

[Bernator]

Hab auch noch eine Methode ergänzt mit welcher die default Uart Schnittstelle (Serial1) geändert werden kann, schau dir das mal an ob das so in deinem Sinne ist. Hab nämlich das Konzept hinter platform und knx_facade ehrlich gesagt noch nicht ganz verstanden....

[Bernator]

Hab den Übeltäter gefunden , die print Funktion im plattform Konstruktor wird aufgerufen bevor Serial initialisiert wird. Im Pull request hab ich die einfach mal entfernt.
Zusätzlich hab ich für den TPUART Reset ein Timeout eingebaut damit der Code nicht ewig dort hängen bleibt, man kann jetzt nach knx.start() abfragen ob erfolgreich oder nicht:

    // start the framework.
    knx.start();
    if(knx.enabled())
        SerialDBG.print("TPUART OK");
    else
        SerialDBG.print("TPUART NOK");

[thesing]

Die Reihenfolge der Commits wird im Screenshot falsch herum angezeigt. Siehe https://github.com/thelsing/knx/commits/master. c5bf61a sollte eigentlich gehen. Der Rest sind nur Formatierungen, Erhöhung der MAX_PDU_SIZE und Änderungen in den Projekt-Dateien. Durch das konsequente initialisieren der Zeiger auf 0 wird es wahrscheinlich zu einem Fehler durch Dereferenzierung von einem Nullzeiger kommen. Dass sollte aber auch schon unter Linux passieren.

[Bernator]

13b1cff geht bei mir auch schon nicht, muss also doch schon vor den oben genannten commits was passiert sein, hab gestern aber nicht mehr weiter zurück getestet....
Debugger hab ich von Segger den j-link edu mini, und als IDE eine spezielle Eclipse Konfiguration für Arduino namens sloeber

[mumpf]

Ok, das gibt mir die Hoffnung, dass ich mich nicht zu duselig anstelle...

Für mich hört sich das so an, als ob Du den SAMD debuggen könntest? Wie geht so was?

Ich schau bei mir mal, ob ich auf die 13b1cff zurück gehe und ob es dann zumindest prinzipiell läuft...

Danke und Gruß, Waldemar

[Bernator]

hmm hab grad meinen fork auf Stand gebracht und jetzt geht auch bei mir nix mehr, er hängt schon bei __libc_init_array(); im main() des Arduino cores.... lt. erster schneller Recherche kann das was mit dem initialisieren der Konstrukoren zu tun haben...
muss bei einem der folgenden commits passiert sein:
git.jpg

[thesing]

Den Tipp mit 2xReset kannte ich auch noch gar nicht. Danke dafür.

[mumpf]

Wenn man kurz hintereinander den Reset-Button 2x drückt startet der Recovery-Boot-Modus (Status-LED faded hin und her)

Hey, das ist klasse!

Das hat schon mal geklappt, ich konnte wieder einen Standard-Example-Sketch flashen und der Arduino macht es. Also schon mal wiederbelebt.

Ich vermute stark das was an der Verbindung SAMD21 zu BCU nicht stimmt, der Stack schickt nämlich beim Start ein "Reset" an die BCU und wartet dann auf die "richtige" Antwort, wenn die nicht kommt wartet er hier ewig. Ich weiß jetzt nicht wie der USB darauf reagiert aber könnte mir gut vorstellen das der dann auch "tot" ist.

Das ist ein prima Hinweis... Ich werde das mal unter diesem Gesichtspunkt nochmal testen. Wie ich schon sagte, ich bin ja noch nicht einmal zu meinem eigentlichen Projekt gekommen, da ich noch nicht mal die knx-demo zum laufen bekommen habe.

Danke euch für die tollen Tipps!

Gruß, Waldemar

[SebastianObi]

Nachdem ich mir auf diese Weise jetzt 2 SAMD's "zerschossen" habe

Ich hatte auch mal das Problem, dass die SAMD's nicht mehr per USB erkannt wurden. Wenn man kurz hintereinander den Reset-Button 2x drückt startet der Recovery-Boot-Modus (Status-LED faded hin und her). Hier wird dann ein anderer COM-Port am PC erkannt und lässt sich wieder flashen.