Erfahrungsberichte

[mode]

So heute Abend habe ich mit einem Pro Micro 5V getestet. Mit noch weniger Ergebnis
Pro Micro ganz nackt ohne Verbindung zum NCN o.ä.
Um sicher zu gehen Bootloder Arduino\hardware\arduino\avr\bootloaders\caterina\ Caterina-Micro.hex per ISP geflasht.
Sketch Konnekting _communication_test per USB draufgespielt. Dabei DebugSerial auf SoftwareSerial debugSerial(7, 10); angepasst da der Pro Micro 11 ja nicht rausführt.
Ergebnis: Eine LED Dauerhaft an, eine LED blinkt.
Auf TX sieht man 10 mal SOH im Sekundentakt und danach nix mehr. Sprich der Watchdog schlägt zu aber der ProMicro resettet nicht sondern hängt. Das Problem wurde im Nachbarforum ja schon besprochen.
ABER
Was ich aber viel Schlimmer finde ist das auf den SoftSerial Ports KEINE Debug Meldung kommt. Garnichts. Hab ich mit dem Scope kontrolliert. Die Ports 7 und 10 sind einfach immer HIGH.

Kann doch nicht sein dass alle meine Arduinos Fritte sind... Das geht ja schon gut los

[Eugenius]

Immer ruhig bleiben. Wenn es alles beim ersten Versuchen gehen würde, wäre es ja zu langweilig

So, jetzt zur Sache:
Wie hast du die Lib heruntergeladen, wie hier beschrieben? https://knx-user-forum.de/forum/proj...-beta-3-ist-da

In der KnxTools.cpp muss man die Pins für Softserial auch anpassen:
https://github.com/KONNEKTING/Konnek...xTools.cpp#L47


P.s. ich habe bei mir überall 10,11 gegen 11,10 getauscht, so ist es mit allen Boards kompatibel.

Mit beta4 wird es einfacher, aber es dauert noch...

[mode]

Kaum macht mans richtig..
Mit dem Pro Micro:

7:44:34.293> Setup KnxTools
7:44:34.293> createProgComObject
7:44:34.293> Manufacturer: DEADhex
7:44:34.354> Device: FFhex
7:44:34.354> Revision: 0hex
7:44:34.354> numberOfCommObjects: 3
7:44:34.417> _deviceFlags: 10001bin
7:44:34.417> Using EEPROM
7:44:34.479> ComObj index=1 Suite-ID=0 HI: 0x0 LO: 0x1 GA: 0x1 Settings: 0x80 Active: 1
7:44:34.542> ComObj index=2 Suite-ID=1 HI: 0x0 LO: 0x2 GA: 0x2 Settings: 0x80 Active: 1
7:44:34.606> IA: 0x11C7
7:44:44.589> KnxDevice startup status: 0x2
7:44:44.651> Knx init ERROR. retry after reboot!!
7:44:45.149> WDT reset NOW

Ohne NCN. Und im WDT hängt er dann. Aber das ist erstmal ein Erfolg.

Mit dem Pro Mini:

7:49:14.563> Setup KnxTools
7:49:14.626> createProgComObject
7:49:14.626> PROGBUTTON toggle
7:49:14.626> PROGBUTTON 1
7:49:14.688> Manufacturer: DEADhex
7:49:14.688> Device: FFhex
7:49:14.688> Revision: 0hex
7:49:14.688> numberOfCommObjects: 3
7:49:14.751> _deviceFlags: 10001bin
7:49:14.751> Using EEPROM
7:49:14.815> ComObj index=1 Suite-ID=0 HI: 0x0 LO: 0x1 GA: 0x1 Settings: 0x80 Active: 1
7:49:14.938> ComObj index=2 Suite-ID=1 HI: 0x0 LO: 0x2 GA: 0x2 Settings: 0x80 Active: 1
7:49:14.938> IA: 0x11C7
7:49:25.046> KnxDevice startup status: 0x2
7:49:25.046> Knx init ERROR. retry after reboot!!
7:49:25.609> software reset NOW
7:49:26.108> Setup KnxTools
7:49:26.108> createProgComObject
7:49:26.170> Manufacturer: DEADhex
7:49:26.170> Device: FFhex
7:49:26.170> Revision: 0hex
7:49:26.170> numberOfCommObjects: 3
7:49:26.232> _deviceFlags: 10001bin
7:49:26.232> Using EEPROM
7:49:26.357> ComObj index=1 Suite-ID=0 HI: 0x0 LO: 0x1 GA: 0x1 Settings: 0x80 Active: 1
7:49:26.419> ComObj index=2 Suite-ID=1 HI: 0x0 LO: 0x2 GA: 0x2 Settings: 0x80 Active: 1
7:49:26.419> IA: 0x11C7
7:49:36.531> KnxDevice startup status: 0x2
7:49:36.531> Knx init ERROR. retry after reboot!!
7:49:37.090> software reset NOW
....

Hier wird Statt WDT der Softwarereset verwendet, was auch funktioniert.


Ich hatte mir einfach den Master Branch gepullt. Warum nutzt ihr nicht den Dev Branch und Merged bei jedem Release in den Master? So kenne ich das von anderen Projekten.

Und das in der KnxTools.cpp die DebugPins angepasst werden müssten hatte ich auch übersehen. Ich war der Meinung das wäre ich globale #defines abgefrühtstückt. Jetzt wo das läuft muss ich leider feststellen, dass ich die nächsten Tage weniger Zeit für dieses Projekt haben werde. Melde mich dann aber sobald es weitergeht.
Der ProMini der heute bei Eugenius ankommen wird, wird also ganz normal funktionieren wenn man ihn mit der Beta 3 und der richtigen Debugport Config flasht.

VG

Mode

[tuxedo]

Bzgl. Master&Dev Branch:

Da gibt's halt unterschiedliche Ansätze. Ganz generell gilt aber: Nur Releases sind getestet und für "funktionierend" befunden. Und das ist bei allen Projekten die ich kennen so. Der Code im Versionierungssystem (außer in Tags) erhebt nie den Anspruch auf "funktioniert und ist tauglich für jedermann". Dafür gibt's auf Github extra die Sparte "Releases", die genau hierfür gedacht ist und nicht umsonst so heisst. Dass es manche oder viele Projekte gibt in denen der Master-Branch dem letzten&stabilen Release entspricht... Mehr oder weniger Zufall, aber nicht im Sinne des Versionierungssystems (egal ob Git, Subversion, CVS, Mercurial oder sonstwas).

Wer selbst Code auschecked muss halt selbst schauen wie's läuft. Ergänzend muss gesagt werden, dass es so oder so keine gute Idee ist als Nicht-Entwickler direkt den Code auszuchecken. Wenn du einen Fehler berichtest, aber nicht im Stande bist die Ursache selbst zu suchen: Welche Version nennst du uns dann? "irgendwas zwischen dem releasten Beta3 und und dem noch nicht releasten beta4"? Das ist für uns nicht hilfreich. Deshalb gibt's definierte Releases mit definirten Versionsnummern und Softwareständen.
Zusammen mit der nächsten, anstehenden Arduino IDE Version (1.6.9 von arduino.cc) ist das "runterladen bei Github" sowieso hinfällig, da unsere Lib im Arduino Library Manager auftauchen solle.

Zum Thema #define:
Da scheinst du in die gleiche "Annahme-Falle" getappt zu sein wie ich (dachte bis vor kurzem auh das sowas geht):
Ein #define ist nur dann global, wenn es in einer all-übergreifenden Header-File definiert wurde. Man bräuchte eine sagen wir "Debug.h" in der das steht und die sowohl vom Sketch als auch von allein der Lib genutzten Klassen/Header-Files genutzt wird.
Das hat aber zur Folge, dass die File von der Lib selbst mitgeliefert werden müsse (sonst ist sie ja in sich nicht vollständig). Und das hätte dann zur Folge, dass man z.B. in Projekt A einen Nano und in Projekt B einen Micro nutzt, beide ggf. unterschiedliche Debug-Einstellungen brauchen, wir aber nur eine Lib mit nur einer Debug.h haben und man zwischen Projekt A und B die Debug.h jeweils anpassen müsste.

Alles in allem nicht wirklich praktisch. Mit dem Beta4-Release wird das anders. Da definierst du im Sketch selbst welches Serial du zum debuggen nutzt und gibst eine Referenz darauf der Lib, welche dann das gleiche Serial zum debuggen (bzw. loggen) nutzt.

Zuguter letzt freut es mich aber dass das Problem auf so etwas banales zurückzuführen war.

Gruß
Alex

[mode]

Hi,
mit dem Auschecken hast du natürlich recht. Ich bin eigentlich auch Programmierer nur meine aktiven C und erstecht C++ Zeiten sind schon etwas her. Daher war das auschecken des letzen Master Branches für mich ganz intuitiv der erste Schritt.
Da ich dann aber noch am Hardwarebasteln war habe ich den Fehler zunächst dort gesucht. Aber gut dass es nun läuft. Jetzt muss ich mir noch ein C++ auffrisch Kurs antun, dann sollte ich den Code verstehen können

Der WDT Reboot lässt sich doch sicher auch durch eine andere Art von Reboot ersetzen, oder? Oder gibt es hier https://knx-user-forum.de/forum/%C3%...-problem/page5 schon Neuigkeiten?
Komisch ist, das ihr das Reboot Problem meist bei Pro Minis hattet. Bei mir tritt es nicht beim Pro Mini sondern nur beim Pro Micro auf...

VG

[tuxedo]

Das WDT Problem tritt nur beim Bootloader des 328P auf, nicht jedoch beim 32u4 (würde mich doch sehr wundern wenn der Testsketch aus dem anderen Thread bei dir mit dem 32u4 Probleme macht. Bitte nichts durcheinander werfen...). So zumindest die Erkenntnis nach Rücksprache mit den Arduino-Entwicklern. Es gibt bereits ein Ticket für den BL des 328P dass das mal korrigiert wird. Aber bis man einen 328p angetriebenen Arduino kaufen kann der diesen Fix im BL drin hat, vergehen wohl noch 1-2 Jahre (gefühlt, mindestens).


Diskussionen zum WDT Problem bitte in den anderen Thread (https://knx-user-forum.de/forum/%C3%...-problem/page5).

[Eugenius]

Mode's ProMini ist heute angekommen und ... *trommelwirbel*... läuft Sowohl mit HW1.2 3.3V als auch mit HW1.1 5V

[wintermute]

Ich muss mal was einwerfen, sorry, aber das fuehlt sich grad so an als muesste ich wirklich:
Ich fummel auch schon laenger mit Arduinos rum, hab auch am Anfang zusammen mit Thorsten an der KNX-Lib mitgefrickelt, bin also nicht wirklich unbefleckt.
Aber diese ganze Bootloader/Bestueckungs/3.3V/5V/1.0/Beta Geschichte macht mich mehr und mehr unsicher. Ich habe hier bereits laenger (also seit Jahren) einige Arduino/Siemens-BCU Projekte am Laufen, aber der Umstieg auf Konnekting schreckt mich ehrlich gesagt massiv ab. Ich hab zwar Saetze bestellt, aber fuers Erste werde ich bei der "guten alten" KNX-Lib bleiben und auch die alten Schaltungen verwenden.
Daran ist bestimmt nicht das Projekt an sich sondern vielleicht nur die Kommunikation (oder die Art derselben) Schuld, aber ich kann das grad alles nicht mehr wirklich nachvollziehen (was natuerlich an mir liegen mag)

Um das fuer den Wochenend-Bastler tauglich zu machen fehlt da noch einiges... kein Genoergel, nur meine 2¢

gruesse :: Michael

[tuxedo]

Hey Michael,

ich kann dir nur zustimmen. Was die Kommunikation angeht müssen wir noch an uns arbeiten. Ich drösel das mal auf, bzw. versuche es:

Bootloader:
Das ist und war ein eigenes Problem, das nix mit KONNEKTING zu tun hatte, aber im Rahmen von KONNEKTING aufgefallen ist. Wenn du mit der "guten alten" KNX Lib einen Reset hättest machen wollen und da auch den WDT benutzen hättest, wärst du auf selbiges Problem gestoßen. Dass der Bug er hierfür verantwortlich ist im Bootloader steckt... Shit happens. Damit müssen wir aber erstmal leben.

HW-Platinen/Sammelbestellung/Bestückung:
Da gebe ich dir recht. Als Neueinsteiger und nicht "ständig mitleser" muss man sich hier sicher "überfahren" vorkommen. Viele Möglichkeiten und kein durchgehend roter Faden: Hier müssen wir noch nacharbeiten und besser werden.
Bis jetzt sind das ja alles Bastelplatinen wo man quasi alles draus machen kann. Ich sag mal "Expertenplatinen" dazu.
Mein Ziel ist es, quasi fertig geplante Geräte in Bausatzmanier zu haben, und diese so zu gestalten, dass man sie unter Umständen mit unterschiedlichen Sketches für unterschiedliche Zwecke nutzen kann. Ein Beispiel:
Eugen bastelt an der bereits kurz vorgestellten "Universal UP Schnittstelle". Dafür wird es sicher 2 oder mehr Sketches geben, je nach Anwendungszweck. z.B. "4-fach Binäreingang, Fensterkontakttauglich". Man pickt sich also für seinen Anwendungsweck eine passende Anwendung, nimmt die zugehörige Hardware (bestellt die entsprechende Platine und gemäß vorgefertigtem Warenkorb die dafür benötigten Teile) und kann dann alles an einem WE zusammenbauen und die Software aufspielen. Fertig.
So wie dieses Gerät wird es noch weitere geben. Die kann man dann, wenn es soweit ist, einfach nachbauen.

KONNEKTING ist nix was man mal eben in 1-2h voll erfassen und Prototypenhaft umsetzen kann. Es ist kein "mal eben schnell am Wochenende was damit anstellen"-Projekt. Dafür gibt es "die gute alte KNX Lib". KONNEKTING zielt also nicht auf die individuelle Lösung für den einzelnen ab (der einzelne will für seine individuelle Lösung nicht erst ein Konfigurations-XML basteln, sondern die Einstellung/Adressen direkt in den Code schreiben), sondern auf reproduzierbare (individuelle) Lösungen für viele (Hardware nach Anleitung zusammenbauen und fertigen Sketch aufspielen und diesen ggf. selbst feintunen/anpassen).

1.0/Beta Geschichte:
Wie ich ja eben schon versucht habe zu erläutern: KONNEKTING ist umfangreich. Es ist - vereinfacht gesagt - KNX mit ETS und Co, nur eben im kleinen Stil. Das Projekt ist erst ein gutes halbes Jahr alt, und umfasst bereits 6480 Zeilen Java-Code und 392 Zeilen XML Code. Und das ist nur die Suite-Anwendung direkt. Da fehlen noch die ganzen Hilfsbibliotheken und der Umbau von Franck Marini's KNX Lib.
Was erwartest du also in so kurzer Zeit? Ein fertiges, ausgereiftes, wohl dokumentiertes System? Das wäre selbst dann schier unmöglich, wenn wir Vollzeit daran arbeiten würden. Wir haben das aber nebenher, in unserer Freizeit. Von daher braucht es eben eine Beta-Phase die dann irgendwann zum ersten Stable-Release führt. Oder woran hängt's genau bei "1.0/Beta --> macht mich unsicher"? Vielleicht bin ich ja gerade auf dem Holzweg und du meinst eine ganz andere Problemrichtung? Klär mich bitte auf (nein, nicht die bienchen&blümchen nummer:-) ).


aber der Umstieg auf Konnekting schreckt mich ehrlich gesagt massiv ab
Die erste Frage die ich dir stellen muss: Welches Problem versuchst du mit dem Umstieg zu lösen? Deine bisherige Bastelei läuft doch, oder? Lass sie laufen.
Was aber toll wäre, wenn du Zeit findest deine bisherige Lösung nochmal mit KONNEKTING zu machen, damit andere auch etwas davon haben bzw sie einfach nachbauen können. Du hast in erster Linie erstmal nix davon (deine bisherige Lösung läuft ja), außer weniger Freizeit da die Neuentwicklung mit KONNEKTING eben Zeit kostet. Aber uns geht's genau so. Wir glauben aber daran, dass sich eine Community bilden kann die eine gemeinsame, flexible Basis hat.

aber ich kann das grad alles nicht mehr wirklich nachvollziehen (was natuerlich an mir liegen mag)
Muss ich dir zustimmen. AKTUELL ist das noch etwas Kraut und Rüben. Ich denke einer der Gründe ist, weil wir noch kein "Produkt" anbieten können (außer das Software-Framework). Es fehlt ein erstes, praxistaugliches Gerät. Da sind wir aber auf dem besten Weg. Eugen's Universal-Schnittstelle ist da ein erster Schritt für UP Geräte. Und für die Hutschiene bin ich nach wie vor dran eine gemeinsame Basis zu schaffen. Wenn die fertig ist, kannst du locker in einem Wochenende (auch auf Lochraster wenns nix kompliziertes ist) einen neuen Aktor für die Hutschiene basteln.

Um das fuer den Wochenend-Bastler tauglich zu machen fehlt da noch einiges... kein Genoergel, nur meine 2¢
Ich denke was hier noch fehlt ist eine schöne, bebilderte (oder Video?) Schritt-für-Schritt-Anleitung wie man mit KONNEKTING den Fuß in die Tür bekommt:
* Was brauch ich alles dazu?
* Wie verbinde ich die Einzelteile?
* Wie sieht ein erster Sketch aus?
* Wie muss ich die Konfigurations-XML dafür basteln damit ich das auch mal testen/nutzen kann
* Wie geht's weiter?

Steht schon seit längerem auf meiner ToDo Liste. Aber dem gegenüber steht eine Software-Entwicklung die noch in der Beta-Phase steckt, und deren Weiterentwicklung die Anleitung schnell invalidieren würde. Aber deine 2¢ rücken dies nun mehr und mehr in den Vordergrund. Ich muss nur noch Zeit finden...

So, ich hoffe du hast KONNEKTING noch nicht ganz den Rücken gekehrt und schaffst es durch weitere 2¢ dem Projekt ein wenig Feedback zu verschaffen. Denn von dem lebt ein Projekt. Feedback. Ohne läuft es schnell in die falsche Richtung.
Von daher, an dieser Stelle nochmal ein DANKE für deine Rückmeldung und Meinung. Ich hoffe auf mehr ...

Gruß
Alex

[tuxedo]

So, als erste Reaktion auf das Feedback:

* Der "Wichtig" Bereich im Forum ist aufgeräumt.
* Es gibt eine neue Einführung/Zusammenfassung (ähnlich zu der von Mat, die dann aber als Sammelbestellung-Thread benutzt wurde)
* Es gibt in dieser Einführung auch eine FAQ für die ersten Schritte

[wintermute]

Hi Alex,

bei der Software bin ich ja noch gar nicht angekommen
Konkret geht es mir darum, dass ich hier einen speziellen Fall habe, wo die "gute alte" KnxLib nicht mehr so gut und alt funktioniert - die schmiert mir naemlich in unregelmaessigen Abstaenden den Bus mit ACKs bis zum Anschlag zu. Ausserdem ist der Aufbau nicht so wirklich vorbildlich und an die Software muesste ich sowieso auch noch mal und und und. Also schiebt man das ewig vor sich her, sieht dabei wie KONNEKTING entsteht und denkt sich: dann mach ich das gleich damit - quasi als Pilotprojekt. Dann kommt die Sammelbestellung und man denkt sich "So, der Zeitpunkt ist gekommen"
Cool auch, dass ich da keine BCU brauche, die Platine ist huebsch kompakt und sehr offen von den Schnittstellen - alles voll toll.

Dann kommt mein erster Liebling dazwischen: 3.3V was ich (aus irgendwelchen voellig irrationalen Gruenden) im Arduino-Umfeld nicht mag. Weil ich nicht wirklich sicher bin ob meine Bestandshardware der jetzigen Lösung (2 IR-LEDs ueber FETs, 2 LEDs ueber PWM, 5 oder 6 1wire Fuehler) mit 3V3 arbeitet muss ich also bei 5V bleiben und dann brauch ich doch wieder ne BCU.
Und weil ich sowieso vermutlich mehr Strom brauche (oder aber das Dingen wegen ewiger 1wire Probleme hart abschalten moechte) muss da eh noch nen Regler zwischen und dann hab ich sowieso wieder fliegende Verdrahtung, also ist es wohl vielleicht doch besser ne eigene Platine fuer nen paar Euro fertigen zu lassen...
Dann bin ich auch wieder der Pechvogel bei dem was bei der Sammelbestellung schief laeuft weswegen ich jetzt Platinen hier liegen habe mit denen ich nicht wirklich was anfangen kann (zumindest momentan noch nicht). Zwischendurch liest man dann noch, dass irgendwelche Bestueckungen flasch sind und man ist sich garnicht sicher ob einen das jetzt betrifft oder nicht und ob die Platinen die ich nun habe nicht nur falsch, sondern auch noch falsch sind
Das ist dann aber wohl doch alles in Ordnung (glaube ich), dann liest man noch die Bootloader Sache (zunaechst nur den Betreff, den Rest wollte ich dann gar nicht mehr wissen)...
Und dann denkt man sich irgendwann: sei's drum, ich mach das so wie vorher auch.
Das ist auch nicht die Schuld von irgendwem, liegt auch nicht daran dass das Projekt nix taucht, das ist einfach so eine "Bauch-Entscheidung"...

Und nein, mich schreckt das nicht ab, dass da Beta drauf steht - alle meine selbstgebauten Sachen sind irgendwie und irgendwo Beta.

Ich find das bemerkenswert was Ihr da (in der kurzen Zeit) auf die Beine gestellt habt, aber irgendwie ist mir die Lernkurve zu steil - deutlich steiler als bei einem Arduino-"Selbstbau"-Projekt. Nicht dass es das Projekt nicht wert waere da Zeit rein zu stecken, keinesfalls. Aber irgendwie muss ich da an Ecken lernen die mich garnicht so wirklich interessieren - ich denke im Endeffekt sollte es um den Sketch und um die (meist triviale) Anbindung der Peripherie gehen. Mir ist auch klar dass an der Front sehr viel Arbeit wartet die dann auch eigentlich garnicht so viel Spass macht...

Kurzum: ich dachte mit KONNEKTING koennte ich meine bisherigen Loesungen irgendwie unter einen Hut bringen und - vor allem - vereinfachen, aber bisher kommt mir das alles endlos viel komplizierter vor, sorry.

Die oben angesprochene Loesung werde ich sicherlich nochmal in KONNEKTING umsetzen und ich habe auch (wie geschrieben) mehrere Saetze an Platinen hier liegen, aber ich weiss nicht ob ich nochmal was mit Arduino/KNX bauen werde - nicht wegen KONNKETING, sondern schlicht weil ich - wo es geht - auf I2C "vernetzte" Arduinos umsteigen werde. Daher kann ich nicht versprechen ob ich ueberhaupt jemals was konstruktives zum Thema werde beitragen koennen, aber wenn ich etwas umsetze dann ja - versprochen

Und danke fuer die ausfuehrliche Reaktion!

gruesse :: Michael

[tuxedo]

Hey Michael,

bzgl. 3.3V ... Ja da hatte ich Anfangs auch berührungsängste. 5V klingt erstmal irgendwie sinnvoller. Und vieles was man an fetigen Arduino-Komponenten/Shields findet, arbeitet tatsächlich mit 5V statt mit 3.3V (zumindest ist das mein Eindruck).

Wenn du deine bisherige 5V Peripherie nutzen willst, dann kannst du auch Eugen's DevBoard HW1.1 nutzen (--> https://knx-user-forum.de/forum/proj...einsteiger-faq). Da hast du neben 3.3V auch 5V. Ist genauso kompakt.

Das mit dem Strombedarf ist an sich eh so ne Sache. Vom Bus kann man leider nicht allzuviel ziehen, weswegen mein 4TE Controller, der dank ESP8266 prinzipiell auch WLAN beherrscht, optional 24V von der gelb/weißen Klemme bezieht und da eine potente 3.3V Versorgung daraus macht. Allerdings landest du dann gleich wieder bei der galvanischen Trennung, die alles wieder ein wenig komplizierter macht.

Bzgl. etwaiger Fehler bei der Sammelbestellung: Hast du die Jungs schon kontaktiert um das Problem zu klären?

Das mit der Bestückung hat bei mir auch für viel verwirrung gesorgt. Dachte erst noch "mensch, das kann doch nicht sein". Aber als Software'ler passieren mir auch ab und zu mal vergleichbare fauxpas, weswegen ich da niemand an den Karren fahren will oder kann. Ich hab mir nur notiert: Alles in Zukunft dreifach prüfen.

Der Bootloader betrifft dich nicht (und auch niemanden sonst, wir haben das für diesen Fall anders gelöst). Da hast du dich allein vom Betreff in die Irre leiten lassen.

Ich hab Anfangs ja auch mit der KnxTpUart Lib gebastelt und da viel umgestellt/verbessert. Als ich das erste mal die andere Lib gesehen hab dachte ich nur: baaah... viel zu kompliziert. In der Tat wirkt das aber nur auf den ersten Blick so. "Leider" sind unsere Sample-Sketches noch überfrachtet mit hässlichen Debug-Zeilen die das ganze optisch nur verkomplizieren. Faktisch ist es eigentlich sehr einfach. Das einzig "komplizierte" ist, dass du dir mit KONNEKTING überlegen musst was du für konfigurierbare Parameter haben willst/brauchst und welche Kommunikationsobjekte (im Stil von ETS) das Gerät anbieten soll. Der Rest ist dann wirklich trivial.

Wenn man also das Unnötige ausblendet und sich auf das Wesentliche konzentriert, ist das Erstellen des Sketches weder ein Hexenwerk, noch braucht man Tage um da durchzusteigen. Das "komplizierte" ist das Erstellen der XML Datei. Die ist sofern möglich einfach aufgebaut und folgt einfachen Regeln. Aber man muss halt XML schreiben bzw. copy&pasten. Sobald mal alles stabil in Version 1.0 läuft, werde ich ein Hilfswerkzeug bauen, mit dem man sich seine XML Wizard-Artig zusammenklicken kann. Aber bis dahin sind noch ganz andere Dinge zu bewältigen. Aber so ist das halt bei jungen Projekten die noch in der Beta stecken: Es ist noch viel zu tun.

An der Verbesserung, vor allem an dem vielen Debug-Code arbeite ich. Das muss besser werden und ist mir schon länger ein Dorn im Auge.

Das mit den I2C vernetzten Arduinos musst du mir mal erklären (gerne separater Thread oder PM, weil gehört hier nicht rein), weil I2C nicht für "längere Strecken" ausgelegt ist.

Alles in allem, mein Vorschlag: Leg die Konnekting-Sache mal 3 Monate beiseite, schau dann nochmal rein und lass dich (hoffentlich) positiv überraschen.

Und bei Fragen oder Problemen sind wir wie immer gern zur Stelle.

Gruß
Alex

[wintermute]

Alles in allem, mein Vorschlag: Leg die Konnekting-Sache mal 3 Monate beiseite, schau dann nochmal rein und lass dich (hoffentlich) positiv überraschen.

Genau so sah mein jetziger Plan aus
Und ja, ich glaube das mit der Bestellung ist in Arbeit...

gruesse :: Michael

[mode]

So meine Ausgabe Verbunden mit dem NCN

20:00:20.093> Setup KnxTools
20:00:20.156> createProgComObject
20:00:20.156> Manufacturer: DEADhex
20:00:20.156> Device: FFhex
20:00:20.219> Revision: 0hex
20:00:20.219> numberOfCommObjects: 3
20:00:20.281> _deviceFlags: 10001bin
20:00:20.281> Using EEPROM
20:00:20.343> ComObj index=1 Suite-ID=0 HI: 0x0 LO: 0x1 GA: 0x1 Settings: 0x80 Active: 1
20:00:20.469> ComObj index=2 Suite-ID=1 HI: 0x0 LO: 0x2 GA: 0x2 Settings: 0x80 Active: 1
20:00:20.469> IA: 0x11C7
20:00:30.517> KnxDevice startup status: 0x2
20:00:30.578> Knx init ERROR. retry after reboot!!
20:00:31.076> software reset NOW
20:00:31.575> Setup KnxTools

Auf dem Uart zum NCN sehe ich ein 0x01 vom ProMini was mit einem 0x03 vom NCN beantwortet wird. Eigentlich korrekt, oder?

Ich würde gerne das Debugging in KNXDevice und KnxTpUart aktivieren. Leider ist das mit einem Define nicht getan. Es sieht so aus, als ob da am Logging gerade Massiv umgebaut wird.
Was z.B macht in der KnxTpUart der _debugStrPtr der von der Methode DebugInfo gesetzt wird? Ich hätte diese Debugausgaben gerne auf dem Softwareuart..

Edit:
Problem stark eingerenzt:
In byte KnxTpUart::Reset(void)
ist _serial.available() niemals >0 auch wenn gerade ein 0x03 vom NCN am RX Pin eingegangen ist.. (Mit dem Scope gemessen)

Edit2: Habs gefunden. Der Uart wird wie folgt definiert:

_serial.begin(19200, SERIAL_8E1);

Der NCN schickt aber kein Paritätsbit mit seiner Antwort mit. Daher wird das 0x03 verworfen.
initialisiere ich den uart mit

_serial.begin(19200, SERIAL_8N1);

funktioniert der Stack

Setup KnxTools
createProgComObject
Manufacturer: DEADhex
Device: FFhex
Revision: 0hex
numberOfCommObjects: 3
_deviceFlags: 10001bin
Using EEPROM
ComObj index=1 Suite-ID=0 HI: 0x0 LO: 0x1 GA: 0x1 Settings: 0x80 Active: 1
ComObj index=2 Suite-ID=1 HI: 0x0 LO: 0x2 GA: 0x2 Settings: 0x80 Active: 1
IA: 0x11C7
Reset successful
AttachComObjectsList successful
Init : Normal mode started
KnxDevice startup status: 0x0
getParamValue: index=0 _paramTableStartindex=19 skipBytes=0 paramLen=2
 val[0]@19 --> 0xFF
 val[1]@20 --> 0xFF
Toggle every 4294967295 ms
Setup is ready. go to loop...
Rx: State Indication Received
Rx: State Indication Received

VG

Mode

[tuxedo]

OHA, das ist seltsam. Ich schau mir das morgen früh gleich an.