Ankündigung

Einklappen
Keine Ankündigung bisher.

BME280 - noch blocking lesen?

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

    BME280 - noch blocking lesen?

    hat da schon jemand was gemacht? Unter 1-2ms geht mit den Libs (BlueDot und Adafruit) nichts...

    #2
    was meinst du hier denn ?! :-)

    Kommentar


      #3
      öhm das dauert zu lange? Ist mir noch garnicht aufgefallen, und wir haben ca 10Stk im Haus im Einsatz die im 5Minuten Intervall arbeiten @Mega644.

      Kommentar


        #4
        blöde autokorrektur - "non blocking".

        Einmal Temp.Lesen dauert zwischen 1 und 2 ms.
        Laut Wiki soll KNX.Task mind. alle 400µs aufgerufen werden!

        Kommentar


          #5
          Ich Hab einen M644 @8Mhz in meinen Tastern. Ich verwende die Adafruit_BME280 Library. Ich habs aufgesplittet, so dass Temperatur und die anderen Werte nicht in einem Rutsch gelesen werden sondern immer mit ein bisschen Zeit zwischen drin für die Library.
          Das mit den 400µs weis ich, aber ich hab nie nachgemessen wie lange das BME lesen braucht. Hatte aber auch nie Probleme, und daher keinen Grund dafür (war für mich beim programmieren "wird scho passen")

          Kommentar


            #6
            Man kann auch länger als 400µs "blockieren", allerdings läuft man dann Gefahr, dass man einzelne Bytes vom Bus nicht mitbekommt.
            Eugen hat das (ich meine für Beta5) schon etwas entschärft, indem Knx.task(), wenn einmal ein Telegramm kommt, das Telegramm am Stück liest und dann erst zurück zur loop() kommt.
            Bisher wurde nach jedem empfangenen Zeichen zur loop() zurückgekehrt. Das war mehr als sub-optimal.

            Ideal wäre interrupt-gesteuert zu lesen, aber zum einen habens uns die Erfinder des Arduino SDKs da nicht so einfach gemacht, und zum anderen kann das auch zu konflikten mit anderen Interrupts führen.

            Ideal ist also die 400µs nach besten wissen und Gewissen einzuhalten und ggf. naiv implementierte Libraries, die im Arduino-Universum gerne "blockierend" ausgelegt sind, umzubauen, so dass sie nicht mehr blockieren (sofern möglich): Oftmals ist es so, dass per I2C dem Sensor gesagt wird: Gib mir bitte den Messwert. Der Sensor "misst" dass und sendet den Wert zurück. Die Lib wartet in dieser Zeit blockierend auf das Ergebnis. Stattdessen könnte man auch zur Loop() zurück kehren und in jedem Durchlauf schauen: Kam schon was?

            Wie gesagt: Das geht nicht mit jedem Sensor, aber mit einigen. Erfordert halt ein wenig Umbauarbeit.
            Wäre cool wenn wir hier eine Liste mit Sensoren pflegen könnten die das mitmachen und für die man schon Umbaumaßnahmen getroffen hat.

            Alles in allem: Im worst-Case gehen also Zeichen vom Bus verloren und man bekommt ein Telegramm nicht mit. Bei einem Schaltaktor wäre das Blöd (Licht an und es geht nicht an ...).

            Gruß
            Alex

            Kommentar


              #7
              Zitat von tuxedo Beitrag anzeigen
              Liste mit Sensoren
              -) VL53L0x - Time-of-flight Entfernungsmesser - kann grundsätzlich non-blocking, man findet aber keine Beispiele dafür. Bei Bedarf PN.

              dringend gesucht: OneWire auf non-blocking. Das Auslesen für einen TempSensor dauert 12ms (und funktioniert trotzdem).

              Kommentar


                #8
                evtl. müssen wir auc zwischen I2C und SPI unterscheiden.
                Ich lese per I2C.
                Pro Byte dauert das mit dem SAMD21 ziemlich genau 400µs.
                Temp lesen braucht 3 Byte => 1,2ms.

                Ich überlege ob ich einfach die Bytes aufteile und zwischen durch dann knx.task aufrufe.
                Wie praxisrelevant die 400µs weiß ich nicht, ob man die nur bei hoher Buslast braucht oder auch wichtig sind für Timing (Link Layer ACK ??) - keine Ahnung.


                Aber bzgl aufteilen - da frage ich mich, wie denn (auch jetzt schon) sichergestellt ist, dass die 3 gelesenen Bytes "zusammenpassen". Nehmen wir an man liest das erste byte, dann kommt eine neue Messung, dann das zweite byte. Wenn blöd läuft und sich der messwert unglücklich an der bytegrenze ändert gibts das völlig falsche Werte...

                Kommentar


                  #9
                  die letzten beiden Posts haben sich mit meinem überschnitten, die habe ich vor dem verfassen nicht gelesen.

                  Zitat von SirSydom Beitrag anzeigen
                  Aber bzgl aufteilen - da frage ich mich, wie denn (auch jetzt schon) sichergestellt ist, dass die 3 gelesenen Bytes "zusammenpassen". Nehmen wir an man liest das erste byte, dann kommt eine neue Messung, dann das zweite byte. Wenn blöd läuft und sich der messwert unglücklich an der bytegrenze ändert gibts das völlig falsche Werte...
                  kann ich direkt selbst beantworten:

                  BME280 datasheet:
                  4.Data readoutTo read out data after a conversion, it is strongly recommendedto use a burst read and not address every register individually. This will prevent a possible mix-up of bytes belonging to different measurements and reduce interface traffic. Note that in I²C mode, even when pressure was not measured, reading the unused registers is faster than reading temperature and humidity data separately.

                  Kommentar


                    #10
                    Danke Sonnengruesser
                    Denke wenn wir weiter Sammeln macht ne Wiki-Seite Sinn.

                    @SirSydom
                    Jepp SPI und I2C haben selbstverständlich ein unterschiedliches Verhalten.

                    Und ja: Die 400µs haben sich aus den 9600 Baud auf dem Bus ergeben. Mit zunehmendem Traffic steigt das Risiko.
                    Zuletzt geändert von tuxedo; 16.09.2019, 07:57.

                    Kommentar


                      #11
                      Ich denke man bekommt den BME280 auch asynchron ausgelesen, ich kenne dir Wire lib noch nicht wirklich, aber auf den ersten Blick bin ich ganz optimistisch.
                      Wenn dabei ne Mini-Lib oder ein code example rauskommt, kann das ja auch ins wiki.

                      Kommentar


                        #12
                        Zitat von tuxedo Beitrag anzeigen
                        Man kann auch länger als 400µs "blockieren", allerdings läuft man dann Gefahr, dass man einzelne Bytes vom Bus nicht mitbekommt.
                        Verwendet ihr nicht auch serial.read() bei konnekting? da landet doch alles in einem "arduino" Ringbuffer, und da 9600baud nicht gerdade schnell sind läuft der auch bei deutlich längerem blockieren als 400us nicht so schnell über. Einzig das ACK an den TPUart ist da kritisch weil das genau in einem bestimmten Zeitfenster kommen muss. Wird das Timig also nicht eingehalten kommt halt kein ACK aber das empfangene Frame geht deswegen nicht verloren.
                        Da soweit ich weiß bei konnekting alles über die Gruppenadresskommunikation geht, wird ja eigentlich nie eine "unicast" verbindung aufgebaut wo das timing wieder relevant wäre.

                        Die Wire lib an sich ist ja schon blocking, das senden eines einzelnen bytes über den Bus dauert da schon fast 200us bei (100kHz I2C speed)

                        Kommentar


                          #13
                          Korrekt, wir haben da noch einen Buffer. Dessen Größe unterscheidet sich von Board zu Board ggf. Der Buffer hilft das Problem weiter zu entschärfen. Dennoch möchte ich nicht dein Eindruck erwecken: "Ist ja schon alles gekapselt und mit einem Fallback versehen, da kann ich ruhig verschwenderisch mit der Zeit in loop() umgehen".

                          Fakt ist: Wenn man immer wieder blockiert und das auch für längere Zeit, können Pakete verloren gehen. Und dann ist das Vertrauen in die Firmware "komplett dahin". Wenn ihr nur für euch selbst bastelt und den Code niemandem zeigt: Alles gut, euer Bier.
                          ABer die Idee von KONNEKTING ist ja ein kleines Ökosystem zu schaffen. Und ihr könnt euch vllt. noch nicht ganz ausmalen in welchem Stress das endet wenn sich User melden und sagen da geht was nicht. Wenn dann die Ursache ein Zeit-Thema ist, sucht man sich ggf. nen Wolf. Deshalb besser von vornherein mit der Zeit vernünftig umgehen.

                          Kommentar


                            #14
                            Zitat von tuxedo Beitrag anzeigen
                            Deshalb besser von vornherein mit der Zeit vernünftig umgehen.
                            Bin ich voll bei dir, leider ist da das Arduino Framework nicht ideal und die Arduino Community in der Regel nicht darauf sensibilisiert, um es nett auszudrücken

                            Kommentar


                              #15
                              Ja, das ist leider so. Gerade bei den Libs wird oft "quick'n'dirty" implementiert.
                              "Eigentlich" sollte man KONNEKTING außerhalb des Arduino Universums entwickeln. ABER da wird dann die Entwicklergemeinde bzw. die Zielgruppe gleich viel kleiner :-(

                              Kommentar

                              Lädt...
                              X