Ankündigung

Einklappen
Keine Ankündigung bisher.

ESP8266 KNX mit ETS

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

    Hallo,
    bei dem "SAMD21" handelt es sich da um den Arduino Zero und Arduino MKR? Oder welche Boards sind damit gemeint.
    Gruß
    Thomas

    Kommentar


      Zitat von blaubaer Beitrag anzeigen
      arbeitest Du an der seriellen Kommunikation für Linux?
      Hi Thomas,

      ja, aber das kann länger dauern, Wochen oder Monate. Auch wenn es nicht so ein großes Thema ist, aber ich nutze es auch um den Code zu verstehen und habe leider immer nur kurz Zeit.

      Gruß
      Werner

      Kommentar


        Hi Bernhard,

        Zitat von Bernator Beitrag anzeigen
        Ich könnte mir vorstellen das es ein timing Problem gibt und der Stack nicht schnell genug aufgerufen wird und somit das Zeitfenster für den Ack_Req verpasst...



        ich schau auf jeden Fall mal nach, ich hatte mir zwar eingebildet, dass ich im Callback nichts lang laufendes mache, aber der Teufel steckt wie immer im Detail, ich mach mal ein paar Zeitausgaben. Jetzt wo ich die Stelle weiß, kann ich es besser analysieren.

        Aber der Vollständigkeit halber: Ich verwende den NCN5130, ich habe gesehen, Du hast ein #define für den NCN5120, wodurch ich vermute, dass Du das für den NCN5120 implementiert hast. Siehst (oder kennst) Du irgendwelche Unterschiede zwischen den beiden, die hier eine Rolle spielen könnten?

        Im NCN5130 Datasheet habe ich was gesehen, dass nach einem Frame wohl 2.6ms Pause gemacht werden und in der Zeit der IACK kommen muss. Ich bin mir aber nicht sicher, ob ich das richtig interpretiert habe. Ist das die Zeit, die Du meinst, die maximal vergehen darf?

        Danke nochmal für die Info, ich werde berichten, was ich rausgefunden habe!

        Gruß, Waldemar

        Kommentar


          Bei mir sind zuhause alle krank. Daher nur kurz:
          - der aktuelle git-Stand funktioniert unter Linux. Daher sollte das Problem bei den anderen Platformen nicht allzu groß sein.
          - Das ACK gibt es nur bei Knx-TP. Bei Knx-IP nicht. Das sollte dein TP<->IP-Router schicken.
          - Der TPUART kann das ACK nur bei direkt adressierter Kommunikation senden. Bei Gruppenkommunikation nicht, da er dann die Gruppen-Adressen-Tabelle kennen müsste. Das Ack sollte hier https://github.com/thelsing/knx/blob...layer.cpp#L257 gemacht werden.
          - welches SAMD21 Board es genau ist spielt keine Rolle. Ich hab ein "WeMos D1 SAMD21 M0 Mini" von ebay.

          VG
          Thomas

          Kommentar


            Gute Besserung, wir kämpfen auch

            Nein mir sind keine Unterschiede diesbezüglich zwischen tpuart und ncn bekannt.
            Man hat 17bit Zeit nachdem der Addresstype an den Host gesendet wurde, bei den 9600baud sind das ca. 1,7ms, aber Achtung die Zeit beginnt logischerweise zu laufen sobald das Byte durch den Interrupt im Arduino rx buffer landent und nicht erst wenn das Byte dann tatächlich vom Stack an o.g. Stelle ausgewertet wird.

            ack.JPG

            Alternativ kann man im tpuart oder ncn mit U_SetAddress die physikalische Adresse bekannt geben und damit die auto-ack Funktion aktivieren, dann sendet der Chip automatisch ein ACK bei allen Gruppenadressen (auch jene die im Device gar nicht vorkommen) und wenn die Zieladresse die eigene physikalische ist.

            Kommentar


              Hallo Bernhard,

              vielen Dank für die ausführliche Erklärung. Und kaum weiß ich, was abgeht, habe ich schon gesehen, dass ich für das KO, bei dem das Problem festgestellt wurde, im Callback zu viel mache (ca. 1-5 ms). Ich hätte aber noch 2 eher konzeptionelle Fragen:
              1. Da so ein ACK nun mal zeitkritisch ist, wäre es nicht sinnvoller, das Telegramm zu empfangen, den GA-Lookup zu machen, den ACK zu senden und dann erst den Callback aufzurufen? Wobei ich nicht wirklich weiß, ob das technisch geht, bin immer noch unterwegs und kann nicht testen.
              2. Wenn ein Telegramm X empfangen wurde und "nur" der ACK zu spät gesendet wurde, sollte dann nicht der Stack die Wiederholungen X1, X2, X3 ignorieren, selbst wenn sie verschickt werde bzw. dann nach der X1 nochmal (zeitnah) einen ACK schicken anstatt die Wiederholung wieder zum Callback durchzureichen?
              Wie gesagt, ich werde mit der vorhandenen Info hoffentlich die Probleme lösen können, aber so wie es implementiert ist, kann es bei zukünftigen Erweiterungen/Änderungen wieder zu Verzögerungen und erneut zu ACK-Ausfällen kommen. Andersrum würde der Stack zuverlässig für einen ACK sorgen und dann erst die Kontrolle abgeben...

              Gruß, Waldemar

              Kommentar


                Du hast einen Denkfehler, der Callback wird auch jetzt erst aufgerufen nachdem das Telegramm vollständig empfangen wurde, das Problem ist aber das ein langsamer Callback bzw. main Loop, den Empfang des nächsten Telegramms verzögert.
                Natürlich könnte man hergehen und immer ganze Telegramme empfangen und erst dann zurück in die Main Loop springen, dann wäre die Warscheinlichkeit ein ACK zu verpassen geringer (nicht ausgeschlossen).
                Allerdings kostet das einiges, es wird damit der gesamte Programmablauf in den langsamen 9600baud Takt der Seriellen gezwungen, der Stack blockiert damit bei jedem Telegramm am Bus (auch fremde) zwischen 11ms (8 Byte) und 31ms (23Byte, bei Extended Frames bis zu 356ms).
                Das wäre zwar der klassische Arduino Ansatz, hauptsache ich (Library) funktioniere, alles was nach mir kommt (Kombi mit anderen Libraries) ist mir egal, aber gerade für einen Kommunikationsstack der ja nur neben der eigentlichen Applikation laufen soll finde ich das nicht sonderlich prickelnd

                Folgende Möglichkeiten sehe ich:

                A) gesamte Telegramm in einem Rutsch einlesen, Stack blockiert in der Zeit (je nach Applikation die parallel laufen soll problematisch)
                B) Loop Zeiten durch entsprechende Programmstruktur kurz halten (effizienteste Variante)
                C) Teile des Telegramm empfanges in Interrupt (ISR) auslagern (Zeit GA Tabelle durchsuchen im Auge behalten)
                D) OS verwenden und mit unterschiedlichen Task prioritäten arbeiten (mit OS overhead leben)
                E) Auto ACK beim tpuart aktivieren und damit mehr Spielraum beim Timing gewinnen (darf man pauschal alle GAs mit ACK bestätigen??)

                Kommentar


                  Eine Verbesserung der aktuellen Implementierung ist mir gerade noch eingefallen, man könnte die Kontrolle nicht pauschal nach jedem Byte an die main Loop abgeben sondern zumindest alle Bytes im RX Buffer bearbeiten....

                  Kommentar


                    Hi Bernhard,

                    ich möchte betonen, dass ich bei Dir bin:
                    Zitat von Bernator Beitrag anzeigen
                    B) Loop Zeiten durch entsprechende Programmstruktur kurz halten (effizienteste Variante)
                    Ich halte B) für sinnvoll und werde daran arbeiten, auch hier noch weiter zu optimieren (vor der Fehlermeldung hätte ich gesagt, dass ich schon gut optimiert habe ).

                    Aber diesen Satz verstehe ich nicht:
                    Zitat von Bernator Beitrag anzeigen
                    Du hast einen Denkfehler, der Callback wird auch jetzt erst aufgerufen nachdem das Telegramm vollständig empfangen wurde, das Problem ist aber das ein langsamer Callback bzw. main Loop, den Empfang des nächsten Telegramms verzögert.
                    Was ich meinte bisher verstanden zu haben:
                    • Du arbeitest den rx-Buffer byteweise ab
                    • Wenn ein ganzes Telegramm angekommen ist (in meinem Fall geht es um ein Schreibtelegramm), wird im Stack der GA-Lookup gemacht
                    • Der Stack findet das passende KO und ruft den Callback auf
                    • irgendwann ist man wieder in der loop() und Du sendest ein ACK
                    • Wenn zwischen "Telegramm angekommen" und "ACK" zu viel Zeit vergeht (weil z.B. man im Callback trödelt), kommt das ACK zu spät und es gibt Telegrammwiederholungen.
                    Das zumindest ist das Problem, dass ich habe, dass kein ACK gesendet wird (oder zu spät, das werde ich erst am Wochenende ausprobieren können, insofern ist alles nur theoretisch).

                    Ich habe gar kein Problem mit dem Empfang des nächsten Telegramms, eher umgekehrt, die nächsten Telegramme sind Wiederholungen, die kommen durchaus an und die will ich eigentlich gar nicht haben.

                    Oder meinst Du mit "Empfang des nächsten Telegramms", dass man den Empfang eines ACK verpasst? Darum geht es mir wie gesagt nicht, es geht um das Senden eines ACK nach dem Empfang eines Schreibtelegramms.

                    Aber ich will auch nicht nerven, ich werde mich am WE mal hinsetzen und ein paar Tests machen, dann hoffe ich, dass ich die Materie besser verstanden habe.

                    Gruß, Waldemar

                    Kommentar


                      Ja der rx-Buffer wird byteweise abgearbeitet aber die Reihenfolge ist anderst, das ACK wird nicht am Ende der Telegrammauswertung gesendet sondern sobald das "address type" Byte verarbeitet wurde, die eigentlichen Daten des Telegrammes kommen erst noch danach. Der Callback wird als letztes aufgerufen wenn das Telegramm den Stack durchlaufen hat.
                      Aber im Prinzip ist auch gar nicht so relevant wo blockiert wird, denn um zu keinem Zeitpunkt ein Telegramm ACK zu versäumen muss die Loop immer schneller als diese 1,7ms sein.

                      Kommentar


                        Zitat von Bernator Beitrag anzeigen
                        Aber im Prinzip ist auch gar nicht so relevant wo blockiert wird, denn um zu keinem Zeitpunkt ein Telegramm ACK zu versäumen muss die Loop immer schneller als diese 1,7ms sein.
                        Da hast Du auch wieder recht - nur leider ist dann die Ursache für mein Problem (kein ACK) nicht das, was ich dachte. So wie Du das beschreibst, gäbe es bei meinen 1-5ms nur mal sporadisch fehlende ACK und nicht reproduzierbar bei jedem WriteRequest.

                        Ich werde das am Wochenende mal untersuchen und meine Findings berichten...

                        Danke für die Einblicke,
                        Waldemar

                        Kommentar


                          Zitat von blaubaer Beitrag anzeigen
                          Wird es da bald eine Lösung geben
                          Hallo Thomas,
                          also bisher sieht es schlecht aus, ich warte noch auf die Optokoppler für die galvanische Trennung.

                          Dafür habe ich heute den Weinzierl kBerry bekommen. Dieses läuft jetzt mit knxd und Raspberry 2 (ging ohne Probleme). Jetzt entwickle ich die von mir geplanten Geräte über die IP Schnittstelle.

                          Gruß

                          Werner

                          Kommentar


                            Hallo zusammen,

                            sehr cooles Projekt, Respekt!

                            Nachdem ich mit dem ESP32 und TPUART2 nicht wirklich weiter gekommen bin.
                            Habe ich mich erstmal dazu entschlossen mit der SAMD21 HW zu starten.
                            Nach ein paar seltsamen Fehlern mit meinen Optokopplern (4-fach TLP281)
                            Hat sich rausgestellt, das sich diese in der verlöteten Schaltung viel zu träge für 19200 Baud.
                            Verbesserung ist in der Mache.
                            Verwende jetzt einen USB-UART Wandler mit optokopplern zum debuggen und trenne den TPUART2 vom KNX beim USB-flashen.
                            Um die GPIOs des SAMD nicht zu brutzeln benutze ich jetzt einfache levelshifter.
                            Da das programmieren über ETS immer noch nicht funktioniert hat bin ich auch mal in den Code abgestiegen.
                            Leider musste ich feststellen das der TPUART2 doch nicht so gleich wie der NCN5120 ist :-(
                            Hier meine Interpretation:

                            Code:
                            // services Host -> Controller :
                            // internal commands, device specific
                            #define U_RESET_REQ 0x01 //Same
                            #define U_STATE_REQ 0x02 //Same
                            #define U_SET_BUSY_REQ 0x03 //NCN5120
                            // #define U_SET_BUSY_REQ 0x21 //TPUART2
                            #define U_QUIT_BUSY_REQ 0x04 //NCN5120
                            // #define U_QUIT_BUSY_REQ 0x22 //TPUART2
                            #define U_BUSMON_REQ 0x05 //Same
                            #define U_SET_ADDRESS_REQ 0xF1 // NCN5120 different on TP-UART
                            // #define U_SET_ADDRESS_REQ 0x28 // TPUART2 different on TP-UART
                            
                            #define U_SET_REPETITION_REQ 0xF2 //NCN5120
                            // #define U_SET_REPETITION_REQ 0x24 //TPUART2
                            
                            //knx transmit data commands
                            #define U_L_DATA_START_CONT_REQ 0x80 //-0xBF
                            #define U_L_DATA_END_REQ 0x40 //-0x7F NCN5120
                            // #define U_L_DATA_END_REQ 0x47 //-0x7F TPUART2
                            Doch leider ist es das wohl noch nicht gewesen...
                            Hat jemand noch ne Idee bekomme folgende Nachrichten:
                            Code:
                            frame with invalid crc ignored<\r><\n>
                            got UNEXPECTED: 0xFE<\r><\n>
                            got U_STATE_IND: 0xEF<\r><\n>
                            got U_STATE_IND: 0xFF<\r><\n>
                            got U_STATE_IND: 0xBF<\r><\n>
                            got U_FRAME_STATE_IND: 0xFB<\r><\n>
                            got UNEXPECTED: 0xED<\r><\n>
                            got U_STATE_IND: 0x57<\r><\n>
                            frame with invalid crc ignored<\r><\n>
                            got UNEXPECTED: 0xFE<\r><\n>
                            got U_STATE_IND: 0xEF<\r><\n>
                            got U_STATE_IND: 0xFF<\r><\n>
                            got U_STATE_IND: 0xBF<\r><\n>
                            got U_FRAME_STATE_IND: 0xFB<\r><\n>
                            got UNEXPECTED: 0xED<\r><\n>
                            got U_STATE_IND: 0x77<\r><\n>
                            frame with invalid crc ignored<\r><\n>
                            got UNEXPECTED: 0xFE<\r><\n>
                            got U_STATE_IND: 0xEF<\r><\n>
                            got U_STATE_IND: 0xFF<\r><\n>
                            got U_STATE_IND: 0xBF<\r><\n>
                            got U_FRAME_STATE_IND: 0xFB<\r><\n>
                            got UNEXPECTED: 0xED<\r><\n>
                            got U_STATE_IND: 0x77<\r><\n>
                            frame with invalid crc ignored<\r><\n>
                            got UNEXPECTED: 0xFE<\r><\n>
                            got U_STATE_IND: 0xEF<\r><\n>
                            got U_STATE_IND: 0xFF<\r><\n>
                            got U_STATE_IND: 0xBF<\r><\n>
                            got U_FRAME_STATE_IND: 0xFB<\r><\n>
                            got UNEXPECTED: 0xED<\r><\n>
                            got U_STATE_IND: 0x77<\r><\n>
                            got unexpected L_DATA_CON<\r><\n>
                            L_DATA_CON not received within expected time
                            Zum programmieren verwende ich ETS5 seit Jahren in kombination mit eibf/knxd erfolgreich.

                            Habe ich in der "tpuart_data_link_layer.cpp" noch was vergessen zu ändern?
                            Datenblätter:
                            NCN:
                            https://www.mouser.de/datasheet/2/30...0-D-278521.pdf
                            TPUART2
                            http://www.opternus.com/uploads/medi...t_20130806.pdf

                            Welche HW Kombination mit KNX-TP auf µC (nicht Linux) wurde schon getestet?

                            Kann mir jemand evtl. schon mal paar Tipps geben wie ich die TPUART geschichte auf einem ESP32 zum laufen bekomme?
                            (Meine Idee, in der knx_facade.cpp/.h die ifdef Geschichte des SAMD21 auf die ESP32 platform anzuwenden.)

                            Grüße DanS

                            Kommentar


                              Für mich klingt das nach einem elektronischen Problem. Ich glaube es haben schon Leute den Stack mit einer Siemens BCU genutzt.

                              Kommentar


                                So ich habe den aktuellen git-Stand nun (hoffentlich) repariert.

                                Kommentar

                                Lädt...
                                X