Ankündigung

Einklappen
Keine Ankündigung bisher.

Beta4 - Fortschrittsthread

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

    Beta4 - Fortschrittsthread

    Damit hier nicht der Eindruck entsteht es tut sich nichts mehr, werde ich versuchen in diesem Thread den Fortschritt von Beta4 zu dokumentieren.

    Aktueller Stand:

    Der zentrale Logging-Ansatz funktioniert. D.h. man kann im Sketch selbst entscheiden wie man wohin loggt (Hardware Serial, Softwareserial auf welchen Pins auch immer) und dies dann der Konnekting-Lib zur Verfügung stellen.

    Die Notwendigkeit am Index 0 das "Prog-CommObjekt" zu erstellen ist so gut wie weggefallen. Damit sollte nun der Com-Objekt-Index in der Suite mit dem im Sketch übereinstimmen.

    Die Sache mit dem Funtionspointer für die alternative Speicherung der Daten (z.B. benötigt für den Ansatz mit dem externen EEPROM beim Arduino Zero) hab ich mir schon angeschaut. Sollte nicht so schwer sein das umzusetzen. Den normalen Arduino Nutzer wird das aber nicht weiter interessieren/betreffen.

    Aktuell beiß ich mir wieder die Zähne an einem vermutlich simplen Problem aus: Die BCU lässt sich nicht resetten. Hab das Problem mal hier geschildert: https://knx-user-forum.de/forum/%C3%...bar#post962712

    Ich meine ich hatte das Problem schon einmal. Hab aber keinen Plan wie ich es gelöst hatte und was die Ursache war.... *grübel*

    Die Suite hat auch eine kleine Änderung erfahren. Aber mehr unter der Haube... für den normalo-User eher uninteressant.

    #2
    Danke für deine Arbeit daran!

    Kommentar


      #3
      Kleinen Vorgeschmack auf die EEPROM Funktionspointer...

      Ausschnitt aus einem Sketch:


      Code:
      int readEeprom(int index) {
          return EEPROM.read(index);
      }
      
      void writeEeprom(int index, int val) {
          return EEPROM.write(index, val);
      }
      
      void updateEeprom(int index, int val) {
          return EEPROM.update(index, val);
      }
      
      
      void setup() {
         // ....
          Konnekting.setEepromReadFunc(&readEeprom);
          Konnekting.setEepromWriteFunc(&writeEeprom);
          Konnekting.setEepromUpdateFunc(&updateEeprom);
         // ....
      }
      So ganz fertig ist es noch nicht. Getestet auch noch nicht. Aber so in der Art wird's funktionieren.
      Setzt man im setup() keine der drei Funktionen, wird automatisch der AVR interne EEPROM genutzt. Im Fall von Arduino Zero, wird man die drei EEPROM-Methoden wie oben gezeigt basteln müssen (und eben statt EEPROM.(read|write|update) dann eben die I2C EEPROM Lib nutzen) und Konnekting wie gezeigt "mitteilen".
      Konnekting erkennt das dass dass es da eine "Sonderlocke" gibt und nutzt die eingestellten Methoden um seine Daten zu lesen/zu schreiben...

      Kommentar


        #4
        So, ich denke die Funktionspointer-Sache ist erledigt.

        https://github.com/KONNEKTING/Konnek...1786e763c02193
        https://github.com/KONNEKTING/Konnek...df7f6e9f1cdd7d

        Habs bis jetzt noch nicht getestet, sollte aber denke ich funktionieren.

        Die Benutzung ist dann wie im letzten Post beschrieben:

        Die eigentliche EEPROM Funktionalität die unsere Device Lib nutzt, lässt sich mit drei Funktionen definieren:

        * Lesen
        * Schreiben
        * Updaten

        Hat man nun keinen internen EEPROM und kann die EEPROM.h Lib demnach nicht nutzen, so bastelt man sich wie im letzten Post beschrieben drei Funktionen um die EEPROM Funktionalität nachzubauen. Wie die Funktionen mit Namen dann heißen ist egal. Wichtig ist dass die Argumente und Rückgabewerte dem gezeigten Muster entsprechen.

        Die drei Funktionen kann man dann mit einem "&" vorangestellt als "Funktionspointer" unserer KonnektingDeviceLib bekannt geben (wie im letzten Post zu sehen).

        Intern schaut unsere Lib dann ob ein Pointer vorhanden ist/gesetzt wurde. Wenn ja, wird eure Methode verwendet. Wenn nicht, wird EEROM.h bemüht.

        Für die Arduino Zero und Co. Benutzer unter uns heißt das:

        Die drei Funktionen erstellen und darin dann die Adaption auf eure jeweilige externe EEPROM-Lib machen. Sollte nicht viel schwieriger sein als oben gezeigt.
        Wer will kann auch versuchen den Flash des z.B. Arduino Zero zu benutzen. Muss man sich halt ein wenig mit dessen eigenheiten ausseinander setzen. Aber mit diesem Ansatz ist es nun prinzipiell egal wie und wo ihr die Daten speichert. Ihr könnt auch ohne weiteres ein SD-Karten-Shield nutzen und alles auf einer SD Karte speichern wenn ihr lustig seid :-)

        Noch ist die beta4 aber nicht fertig. Ist noch ein wenig zu tun ...

        Kommentar


          #5
          jeha !!! Super, dann kann ich endlich meine Arduino Zeros benutzen !!! :-)

          Vielleicht kann ich dann auch meinen KNX 4CH LED-Dimmer im 5cm x 10cm Gehäuse hier zeigen :-)

          Die Applikationsplatine für das 4TE Gehäuse mit den 9CH LED-Dimmer ist auch fertig und wird hier auch bald gezeigt.

          www.smart-mf.de | KNX-Klingel | GardenControl | OpenKNX-Wiki

          Kommentar


            #6
            So, Funktionspointer getestet... Läuft.

            Jetzt den Rest noch "hübsch" machen und dann fehlt nicht mehr viel bis zum beta4 release.

            Kommentar


              #7
              hast du das direkt in der Arduino lib schon geändert !?
              www.smart-mf.de | KNX-Klingel | GardenControl | OpenKNX-Wiki

              Kommentar


                #8
                Im Beta4 Branch ist die Änderung eingecheckt. Aber in Summe ist beta4 noch nicht benutzbar, da ist noch vieles unfertig.

                Kommentar


                  #9
                  Saß gestern Abend/Nacht noch lange dran. Irgendwo ist mal wieder der Wurm drin:

                  Mit beta4 muss man das ProgComObjekt nicht mehr explizit selbst erzeugen und angeben. Das passiert automatisch, intern. In dem Umfeld hat sich aber ein Problem eingeschlichen das irgendwie (mal wieder) hart zu knacken ist:

                  Telegramme gehen zwar ein, werden aber schon nach dem ersten Byte quasi wieder verworfen weil die Prüfsumme angeblich nicht stimmt. Denke das ist die letzte "größere" Hürde für beta4.

                  Kommentar


                    #10
                    Eben nochmal in den Code geschaut und mit Franck's originalcode verglichen (soweit das überhaupt noch vergleichbar ist):

                    Es scheint am Timing zu hängen.... Telegramme werden byte für byte von der seriellen Schnittstelle gelesen. Und wenn zwischen zwei Bytes mehr als 2ms liegen, dann gilt das Telegramm als "komplett übertragen". Und wenn der Status des Telegramms bis dahin nicht mindestens "addressed" (als "für uns interessant, weil an uns adressiert") ist, dann ist das Telegramm fehlerhaft.

                    Habs noch nicht gemessen, aber so eine Debug-Zeile über Software-Serial verschlingt ausreichend Zeit, dass dieses 2 Millisekunden-Fenster schnell überschritten ist.
                    Das ist für das "debuggen" mit einer seriellen Konsole natürlich fatal. Ich werde meinen ganzen Debug-Code in dieser Klasse wieder auskommentieren und nochmal probieren.

                    Überlege gerade wie ich das in Zukunft besser mache.... Selbst wenn ich den Code ins Atmel Studio verschiebe und dort mit meinem Atmel ICE debugger debugge: Solche 2ms Fallen gibt's öfters. Und zum Teil auch noch "schlimmer" (µs Fenster statt ms...).

                    Franck hatte an dieser Stelle gar keinen Debug-Code?!

                    An anderen Stellen hat er sich die direkte Ausgabe gespart und die Log-Zeilen nur an einen String angehängt und diesen dann zu späterer Zeit (wo es eben zeitlich nicht ganz so kritisch ist) auf der Konsole ausgegeben.

                    Mal sehen. Jedenfalls werde ich mir diese brisanten Stellen entsprechend markieren, Logausgaben entfernen und beim nächsten Versuch dann einfach hoffen dass es dieses mal klappt.

                    Kommentar


                      #11
                      Eben die Sache nochmal genauer unter die Lupe genommen... Und dabei etwas gravierendes feststellen müssen:

                      In der Arduino Funktion "loop()" muss man ja "Knx.task()" aufrufen, damit der Arduino Zeit bekommt mit dem KNX Transceiver zu sprechen. Soweit so gut, soweit verständlich.

                      In der Doku von Franck liest man dann, man solle das alle 400µs machen. Um kein Telegramm zu verpassen.
                      Das ist schon mal recht heftig. Mit diversen Sensoren hat man quasi gar keine Chance sich daran zu halten. Schnell dauert eine Messung mal 10ms und mehr.
                      Aber es kommt noch schlimmer:

                      Wenn ich mich nicht total "verguckt" habe, wird in einem solchen Knx.task() Aufruf nur 1 (!!!) Byte vom BCU gelesen. Eine Programmiernachricht z.B. hat 23 Bytes. Um diese vollständig zu lesen, muss die Knx.task() also 23x aufgerufen werden.

                      Dachte Anfangs noch da wäre eine "intelligenz" drinnen die, wenn sie ein Telegramm für sich entdeckt, das Telegramm gleich komplett liest. Aber Pustekuchen.
                      Bin gespannt wie sich das auf unsere weitere Bastelei auswirkt. Da könnte es ruckizucki passieren, dass ein Gerät das Anzeige (LED, Display, ...) und Sensor zugleich ist, seine Anzeige nicht aktualisieren kann, weil das Lesen des Sensors den Telegrammempfang blockiert. Ich seh auch aktuell nicht, wo/ob es für so einen Fall einen retry-mechanismus (im KNX Transceiver und oder im Code) gibt.

                      Unter dem Strich heisst das bis jetzt: Wenn ein Gerät ein Telegramm empfangen soll: Das Telegramm so kurz wie möglich halten um das Risiko einer unterbrochenen Empfangskette zu minimieren.

                      Ob ich das umbauen kann und ob dies Sinn macht, oder ob man Sensortechnisch einen anderen Weg gehen muss: Wird sich zeigen.

                      Kommentar


                        #12
                        Boah, das ist ja ein richtiger Bummer. Ist schon heftig, wenn man sich auf den Empfang nicht 100%tig verlassen kann...

                        Kommentar


                          #13
                          Du kannst dich schon drauf verlassen. Du musst nur sicherstellen dass die Daten schnell genug geholt werden ;-)

                          Oder du musst dein Gerät nur in eine Richtung ausprägen:
                          ENTWEDER
                          Sensor --> dann empfängt es wenig bis gar nix, sondern sendet nur
                          ODER
                          Aktor --> dann muss es keine Sensoren lesen und damit nix senden, sondern nur Schaltbefehle annehmen, sprich lesen. Und Ausgänge schalten kostet quasi keine Zeit.

                          Die Programmierung an sich ist davon nicht betroffen. Denn sobald die Programmierung beginnt, wird in der loop()-Funtion nix mehr anderes als nur die Programmierung gemacht. Siehe: https://github.com/KONNEKTING/Konnek...kting.ino#L109

                          In Beta4 wird das ganze nochmal ein wenig verbessert und ausgeweitet.

                          Ein anderer Ansatz wäre, die ganze BCU Kommunikation mit einem zweiten Arduino zu entkoppeln (das hatte Masifi schon mal überlegt). Aber das macht das Gerät gleich komplexer und entbindet dich nicht davon, die aufgelaufenen Telegramme rechtzeitig (bevor der Empfangspuffer volläuft) vom zweiten Arduino abzuholen. Aber es würde dir zeitlichen Aufschub geben.

                          Ich könnte mir vorstellen, dass wenn das tatsächlich in der Praxis häufiger zu Problemen führt, wir ein "KNX Modul" basteln das diese Arbeit übernimmt (also Modul mit eigenem µC und KNX Transceiver, das dann über eine wie auch immer geartete Verbindung mit dem eigentlichen µC kommuniziert) und welches man dann in allen Geräten einsetzen kann. Das "könnte" zugleich die Verwendung noch einfacher machen. Aber der Preis wird dadurch nicht besser :-(

                          Kommentar


                            #14
                            So, Debug-Meldungen raus und schon flutscht es wieder.. zumindest fast ;-) Jetzt klemmts offenbar an einer weiteren Stelle.
                            Das hat man davon wenn man tagelang am Code bastelt und nur gegen den Compiler testet ;-)

                            Kommentar


                              #15
                              Es geht voran... nach weiteren zwei Stunden bin ich nun soweit, dass die Telegramme am Arduino richtig ankommen und eine Antwort gesendet wird.

                              Leider ist mir noch völlig schleierhaft wieso die ersten zwei Bytes der Antwortnachricht, nachdem sie aus dem RingPuffer kommen anders aussehen als vor dem reinstecken...

                              Dabei ist es egal ob ich

                              0x00
                              0x16

                              reinstecke,

                              oder testweise

                              0xcc
                              0xff

                              Es kommt, nachdem das Telegramm aus dem Ringpuffer kommt und dann tatsächlich versendet wird, immer

                              0x7d
                              0x03

                              an besagter Stelle wieder raus... Und dementsprechend werden diese beiden bytes falsch gesendet. Sehr mysteriös. Aber ich werd's rausfinden.

                              Kommentar

                              Lädt...
                              X