Ankündigung

Einklappen
Keine Ankündigung bisher.

Konnekting Device "verliert" bzw. ignoriert sporadisch Telegramme

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

    Konnekting Device "verliert" bzw. ignoriert sporadisch Telegramme

    Servus,

    mein 12Kanal-Dimmer-Prototyp macht vereinzelt Probleme.
    Und zwr reagiert der weder auf ein eingehendes Dimm-Telegramm, noch wird mit Status geantwortet.
    Das passiert ca. bei 1 von 100.
    Eine wie auch immer geartete gesetzmäßigkeit konnte ich noch nicht feststellen - ein zusammenhang mit hoher Buslast konnte ich nicht feststellen.

    Ich hab nun eine Debug-SW erstellt, die mir ein paar KOs raushaut und damit festgestellt - auch ein ohne jede Bedingung versendetes KO im void knxEvents(byte index) wird nicht versendet. Ich tippe daher darauf, dass die Funktion gar nicht aufgerufen wird.

    Was könnte die Ursache sein? Am wahrscheinlichsten wohl das task zu selten aufgerufen wird - aber wie finde ich das raus?
    Wenn ich das debugging einschalte, verändere ich wieder das zeitverhalten...

    Habt ihr Tipps ?
    OpenKNX www.openknx.de | NanoBCU und OpenKNX-HW verfügbar

    #2
    Ich habe einen Debug eingebaut, das wenn die Task länger als 400us dauert, sich das ding meldet.
    Voraussetzung ist natürlich das sonst nix über die serial ausgegeben wird, sonst ist mal gleich mal über die 400ert

    Kommentar


      #3
      Zitat von ChriD Beitrag anzeigen
      Ich habe einen Debug eingebaut, das wenn die Task länger als 400us dauert, sich das ding meldet.
      Voraussetzung ist natürlich das sonst nix über die serial ausgegeben wird, sonst ist mal gleich mal über die 400ert
      das klingt spannend, wie hast du denn das gemacht?

      Kommentar


        #4
        Nix wirklich aufregendes. Einfach am Anfang vom loop() die zeit gespeichert (micros()) und am Ende des loops dann die die Differenz ausgerechnet..
        Wenns > 400 ist dann hab ich' über die Serial ausgegeben, bzw. eine LED aktiviert.
        So kriegst du zumindest eine Idee ob's das Timing ist oder eher nicht?!

        Kommentar


          #5
          Die Idee ist super. Könnte auch in dem Fall helfen.
          Ing-Dom hast du sourcecode, dass man mal drüber kucken kann?

          Kommentar


            #6
            ja Zeit messen ist ne gute Idee..
            400 micros klingt verdammt schnell, ich dachte mind. alle 5000µs wäre ausreichend.
            Da ich aber sonst eigentlich nichts wirklich zeitaufwändiges mache kann ich es mir gar nicht vorstellen.
            max die onewire oder sensorlib...

            HW ist übrigens Mega2560 + Siemens BCU, galv getrennt mit adum1201

            code kann ich mal online stellen.
            OpenKNX www.openknx.de | NanoBCU und OpenKNX-HW verfügbar

            Kommentar


              #7
              Beta4b ließt Zeichen für Zeichen eines Telegramms vom Bus, mit jedem Knx.task() Aufruf eines.
              Deshalb ist es ja so wichtig dass loop() "frei läuft" und nicht blockiert. 5000µs sind ja schon 5ms. Das ist für einen Microcontroller eine galaktische Ewigkeit.

              Viele Libs (dazu gehören diverse I2C Sensoren) nehmen sich alle Zeit der Welt und schei*en auf 400µs. Da muss man gehörig aufpassen und ggf. die Lib "nachbessern".

              Mit beta5 wird die Situation ein wenig besser, weil wir, wenn wir dann mit -einem- task() Aufruf mal angefangen haben und da gerade ein Telegramm kommt, das Telegramm dann gleich am Stück empfangen. Aber jetzt kommt das dicke ABER:

              Wenn in der loop() ein Sensor gerade mal wieder "blockiert" weil er so blöde durch die Lib angesprochen wird, und just in diesem Moment ein Telegramm eingehen will, dann bekommt man das ggf dennoch nicht mit. Zumindest nicht, wenns blöd läuft und der Empfangspuffer seitens Arduino gerade überläuft.

              Deshalb gilt nach wie vor: Schaut, dass loop() so frei läuft wie möglich und so selten und wenig blockiert wie möglich. Microcontroller programmieren ist auf dem Level kein Zuckerschlecken und man darf einfach nicht "nachlässig" programmieren.

              Kommentar


                #8
                Ich muss Alex ein bisschen korrigieren. Ab beta4b lesen wir Telegramme schon in einem Stück aus dem Buffer. Somit sind 400µs nicht mehr so kritisch. Je nach Buslast und RX-Buffergrösse konnte ich bis zu 1 Sekunde blockieren und so 2-3 Telegramme ins Bufferlegen und von dort hollen. aber wenn da aufm Bus viellos ist und Buffer klein ist, dann kann zu Telegrammverlust führen.

                ABER: OneWire, damit die Timings passen, schalten die ALLE Interrupts aus in dem Moment wo die Daten von/zu OneWire gesendet werden. Und ratet mal wie der Serial-Buffer gefüllt wird? genau, per Interrupt.
                Schlimmer noch DallasTemperature für OneWire bei 12 bit blockiert für 750ms (!)...

                Kommentar


                  #9
                  Zitat von Eugenius Beitrag anzeigen
                  Schlimmer noch DallasTemperature für OneWire bei 12 bit blockiert für 750ms (!)...
                  na da haben wir wohl schon den schuldigen wa...

                  OneWire oneWire(ONE_WIRE_BUS);
                  DallasTemperature sensors(&oneWire);
                  ich mach jetzt trotzdem erstmal die Messung, dann schmeiß ich das raus...
                  OpenKNX www.openknx.de | NanoBCU und OpenKNX-HW verfügbar

                  Kommentar


                    #10
                    Alle 5s hab ich den DS18B20 abgefragt und die Lib hat mir da jedesmal 52ms loop() blockiert.
                    Schmerzlich, dass mir das passiert, aber ich bin irgendwie davon ausgegangen, dass die Libs schon ordentlich implementiert sind und hab das nie überprüft.
                    Zudem hab ich den T-Auswertung erst zum Ende meiner Entwicklung eingebaut und das erst im Testbetrieb festgestellt...

                    Egal, nun funzt es! Danke!
                    OpenKNX www.openknx.de | NanoBCU und OpenKNX-HW verfügbar

                    Kommentar


                      #11
                      ich hab mittlerweile gelernt das gerade die Hardwarenahen Libs oft sehr schlecht implementiert sind. Seines es delay(100) während nur 100ns Pause nötig wären und lauter solche Sachen.

                      Kommentar


                        #12
                        99% der Arduino Libs sind auf "just make it work", vor allem in Bezug auf die 80% Standardfälle, implementiert. Da wird gerne, wie andi11 schon geschrieben hat, auch schnell mal ein "delay" eingebaut.

                        Ein "delay" hat auf einem µC eigentlich überhaupt nichts zu suchen, denn das ist nur dazu da, CPU Zeit zu "verbrennen". Es gibt kaum ein Anwendungsfall wo ein "delay" okay ist.
                        Wer 1wire, I2C, SPI oder UART oder dergleichen benutzt, muss sich die Libs schon genau ansehen. Oftmals macht es Sinn nicht die ganze Lib mit einzubauen, sondern nur die notwendige Kern-Funktionalität heraus zu extrahieren und ggf. die Implementierung nachzubessern.

                        Kommentar


                          #13
                          Zitat von SirSydom Beitrag anzeigen

                          na da haben wir wohl schon den schuldigen wa...
                          Die Zauberzeile:

                          https://github.com/milesburton/Ardui...rsion2.pde#L38

                          Kommentar

                          Lädt...
                          X