Ankündigung

Einklappen
Keine Ankündigung bisher.

ESP8266 KNX mit ETS

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

    hmm U_State.ind 0x17 meldet der TPUART bzw NCN zurück wenn das Frame welches vom SAMD kommend auf den Bus gesendet werden soll nicht stimmt (CRC bzw. Protokollfehler)
    Ich glaube hier gibt es keinen Unterschied zwischen TPUART und NCN, sollte also eigentlich passen....
    Eventuell wird knx.loop nicht schnell genug aufgerufen und das übertragen der Bytes dauert dem Chip zu lange?

    Kommentar


      Zitat von Bernator Beitrag anzeigen
      Eventuell wird knx.loop nicht schnell genug aufgerufen und das übertragen der Bytes dauert dem Chip zu lange?
      Bei Konnekting wird bei einem Programmier-Vorgang durch die loop so eingeschränkt, das immer nur die Funktion knx.loop(); aufgerufen wird.

      macht das die Funktion auch:
      Code:
      // only run the application code if the device was configured with ETS
          if (!knx.configured())
      return;
      Wenn das der Fall ist, dann kann ich mir beim besten Willen nicht vorstellen, dass ein SAMD21 zu lange dafür braucht. Außer ihr macht ganz wilde Sachen in knx.loop().

      Und auch die Datenübertragung der Bytes zum Chip geht schnell genug. Man stellt die UART Geschwindigkeit (z.B. 9600 Baud) zwischen SAMD und NCN ja fest ein, dann muss der NCN auch damit klarkommen.
      www.smart-mf.de | KNX-Klingel | GardenControl | OpenKNX-Wiki

      Kommentar


        Hi,

        ich weiß nicht, ob knx.configured() false liefert, während programmiert wird (hoffe es aber). Bei dem obigen log ging es aber um die Erstprogrammierung, wodurch meine Logik sowieso nicht durchlaufen wurde. Und ich mach im loop() normalerweise nur ein for von 1 bis 50 in dem ein if ist... das kann nicht so viel Zeit kosten.

        Ich bin gerne bereit, weiter zu analysieren, aber ich bin heute in den Urlaub los und kann erst in 3 Wochen wieder an meinem Modul weiterarbeiten.

        Danke und Gruß, Waldemar


        OpenKNX www.openknx.de

        Kommentar


          Hallo allerseits,

          mumpf CreateKnxProd erweitere ich immer je nach Bedarf. In der GUI kann man zu ReplacesVersions glaub ich nur eine Zahl zuweisen. Für mich reicht das bisher.
          Die Seriennummer setzt sich aus DeviceObject::manufacturerId und DeviceObject::bauNumber zusammen. Beides kann man auch über die KnxFacade setzen.

          Sisamiwe Ich habe so ein Wemos Board (das in Wirklichkeit gar nicht von Wemos ist). Sollte aber egal sein welches du nimmst.

          Da sich noch niemand beschwert hat, scheint mein letztes Update gut gegangen zu sein.

          Kommentar


            Hi Thomas,

            Zitat von thesing Beitrag anzeigen
            Da sich noch niemand beschwert hat, scheint mein letztes Update gut gegangen zu sein.

            ich habe ehrlich gesagt noch nicht die neueste Version verwendet. Ich wollte noch vor meinem Urlaub alles auf den SAMD bringen und neue Probleme vermeiden, sorry.

            Zitat von thesing Beitrag anzeigen
            In der GUI kann man zu ReplacesVersions glaub ich nur eine Zahl zuweisen
            Ich hatte das nur erwähnt, weil Du mal geschrieben hast, ich sollte Dir bescheid geben, wenn ich herausgefunden habe, wie man mehrere Versionen im XML angibt.

            Bernator ​​​​​: Ich habe in Deinem Coding gesehen, dass es #ifdef für NCN5120 gibt... ich habe den aber gar nicht gesetzt. Könnte es daran liegen?

            Gruß, Waldemar
            OpenKNX www.openknx.de

            Kommentar


              Hi,

              ich habe noch eine Frage, die aus meinen gestrigen Tests resultiert. Ich habe es bei meinem Logikmodul auf 50 Kanäle gebracht, 60 klappen nicht mehr, es bricht entweder beim Programmieren ab oder nach den Restart werden keine GA gesendet. Dazu musste ich sowohl in memory.cpp wie auch in FlashAsEPROM die Speichergröße auf 6k setzen (6144 Bytes). Sprich, ich habe Speicherprobleme. Allerdings kann ich mir das nicht wirklich erklären...

              Rein rechnerisch verbrauche ich pro Kanal:
              • 110 Byte für Parameter
              • 33 Byte zur Laufzeit
              • 3 KO (4 Byte, 4 Byte und 14 Byte = 22 Byte)
              Unabhängig von den Kanälen habe ich
              • 12 Byte für Parameter
              • 20 Byte zur Laufzeit
              • 1 KO (1 Byte)
              Wenn ich (110+33+22)*50+12+20+1 zusammen rechne, komme ich auf 8283 Byte. Selbst mit dem gespiegeltem EPROM im Ram sind das dann 8283+6144 = 14427 Bytes. Dazu kommt dann noch der Speicher für die GA, die den KO zugeordnet werden können, nehmen wir mal an das sind 256*4 Bytes = 1024 Bytes, also ein weiteres KB. Dann komme ich auf 15451 Bytes, das ist noch nicht mal die Hälfte des verfügbaren Ram. Hab ich da was übersehen oder wird der Rest von KNX-Stack verbraucht?

              Ich kann zwar mit 50 Kanälen leben, aber es ist eher die untere Grenze von dem, was ich erreichen wollte, mein Traum sind ja immer noch 80.
              SebastianObi : Du hattest ja auch schon Speicherprobleme, hast Du da Erkenntnisse, wie mal da besser werden kann?

              Gruß, Waldemar
              OpenKNX www.openknx.de

              Kommentar


                das #ifdef für NCN5120 wird nur beim Beenden des Stacks schlagend, hat also hier keinen Einfluss...
                Wenn nur die Schleife durchläuft ist das sicher auch kein Problem und die Ursache muss woanders liegen, hast du mal den Demo Sketch versucht, nur um sicher zu gehen?

                Bzgl Speicher ist es glaube ich so das die Parameter, GAs, Associations sogar 3x vorkommen, 1x Flash, 1x RAM EEPROM Emulation, 1x RAM Stack, aber das kann Thomas bestimmt besser beantworten.

                Kommentar


                  Hi Bernator,

                  danke für das Feedback. Ich mache gerne weitere Tests, ich wollte auch mal die millis() ausgeben, damit man sieht, wie häufig die Meldungen kommen, einige kommen nämlich am Block, dann aber wieder ne Pausen usw. Ich übertrage eben ca. 7k über den Bus beim programmieren, das dauert auch knapp 2 Minuten. Über diese Zeit verteilen sich die Meldungen. Ich hatte schon die EEPROM-Emulation im Verdacht, dass diese zwischendurch mal Seiten weg schreibt und dafür zu lange braucht, aber dann bräuchte man nicht alles im RAM spiegeln...

                  Langer Rede kurzer Sinn: Wegen Urlaub komme ich erst Ende August wieder an meine Hardware und kann erst dann wieder testen.

                  Gruß, Waldemar
                  OpenKNX www.openknx.de

                  Kommentar


                    Zitat von thesing Beitrag anzeigen
                    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.
                    da scheint es tatsächlich noch ein Problem zu geben... in translateAsap läuft die Schleife bis "entries * 2" und in nextAsap nur bis "entries", der operator[] liefert aber bei ">= entryCount()" immer 0

                    Kommentar


                      Hi,

                      weiß jemand, ob es möglich ist, eine knxprod für TP und IP zu erstellen? Also eine für beide Medientypen? Das würde Tests und Versionierung stark vereinfachen, wenn man für beide Medientypen entwickelt...

                      Dass es die ETS grundsätzlich kann, sieht man am GIRA Dummy, aber da eben mit anderer Mask-Version, sonst hätte ich da schon abgeguckt .

                      Gruß, Waldemar


                      OpenKNX www.openknx.de

                      Kommentar


                        Ich denke ich hab das Problem mit dem neuen association table format gefixt, zumindest läufts bei mir so jetzt wieder.
                        Auch einen Bug bzgl. senden von extended frames hab ich im tpuart noch ausgemerzt, jetzt ist die schnellere Programmierung über die ETS auch deutlich merkbar. Mit meinem Testprojekt ist die ETS jetzt in 10 Sekunden fertig, vorher waren es ca. 15 Sekunden.

                        Kommentar


                          Bernator Danke. Hab ich gemergt.

                          mumpf Man könnte in einer kndprod beide Applikationsprogramme rein packen, aber da die Mask-Version schon das Medium festlegt, wird man kein Applikationsprogramm für zwei Medientypen erstellen können.

                          Kommentar


                            Zitat von thesing Beitrag anzeigen
                            aber da die Mask-Version schon das Medium festlegt, wird man kein Applikationsprogramm für zwei Medientypen erstellen können.
                            Doch, geht.

                            Kommentar


                              Hallo Klaus,

                              Zitat von Klaus Gütter Beitrag anzeigen
                              Doch, geht.
                              ...aber Du darfst uns nicht verraten, wie es geht? Falls Du irgendwo eine knxprod kennst, die das macht, schaue ich auch gerne selber nach.

                              Gruß, Waldemar
                              OpenKNX www.openknx.de

                              Kommentar


                                Hi,

                                ich hab mir mal ein paar knxprod von Dummy-Geräten angeschaut, weil ich mich daran erinnert habe, dass der von mir verwendete Dummy für TP und PL verwendet werden kann. Und was soll ich sagen, der Gira-Dummy enthüllt das Geheimnis! Mit   MediumTypes="MT-0 MT-5"  bei Hardware kann man der ETS sagen, dass ein Gerät sowohl in IP- wie auch in TP-Linien sein darf. Ich kann dann auch parametrierte Geräte zwischen IP- und TP-Linien verschieben. Funktioniert auch wunderbar mit meinen knxprod Files.

                                Jetzt die Frage an Thomas thesing: Kann man das irgendwie mit Deinem Stack nutzen? Inwiefern ist die Applikation in dem XML (also die gesamten Parameter und KO) noch abhängig von der Linie? Mir ist natürlich klar, dass die Firmware für Linux komplett anders ist als für nen SAMD, aber kann ich beide mit der selben knxprod parametrieren oder wird das nicht funktionieren?

                                Gruß, Waldemar
                                ​​​​​​​
                                OpenKNX www.openknx.de

                                Kommentar

                                Lädt...
                                X