Ankündigung

Einklappen
Keine Ankündigung bisher.

Entwicklungsblog Beta5/Final 1.0.0

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

    Nein, kein edbg. Der würde das Teil nur noch teurer machen und einen HW Debugger in jedem KNX Gerät wäre Overkill.

    Kommentar


      Holla die Waldfee ... Pünktlich zum Wochenende gibt's gute Nachrichten:

      Es ist vollbracht: Auch das Lesen von Files/Daten vom Arduino klappt nun über das neue Protokoll.

      Hab nur noch einen kleinen Fehler in der CRC Berechnung und ich muss noch ein bisschen Code-Kosmetik betreiben, aber dann kanns mit der Suite weiter gehen. Ein erster public-beta Test der Beta5 steht quasi vor der Tür.

      Durch die närrische Jahreszeit dauert das aber ein wenig. Melde mich wieder wenns was neues gibt.

      Gruß
      Alex

      Kommentar


        super News. Ich warte gespannt auf die Beta5 und werde diese dann gleich in mein aktuelles SW-mäßig schon fast abgeschlossene codelock einfließen lassen.

        Kommentar


          Nachdem ich zwischenzeitlich erst noch eine DFF4.1 Bestellung fertig machen musste, bin ich heute wieder an beta5 dran.
          Das Protokoll zum lesen/schreiben von Daten über den Bus funktioniert wohl grundlegend. ABER ich hkämpfe noch mit der SerialFlash Lib (https://github.com/PaulStoffregen/SerialFlash/) die ich mit dem M0dularis+ Controller benutze um Daten im SPI zu speichern und zu lesen.

          Ich schreibe Daten in den SPI rein, und wenn ich sie wieder heraus lese, sind sie anders... das macht mich ganz konfus. Die selbe Lib habe ich bereits in anderen Experimenten benutzt: Ich hatte schon eine WAV-File per KNX auf den Arduino und den angebundenen SPI Flash geschoben und diese WAV dann über den im SAMD eingebauten DAC "abgespielt". Da hat alles funktioniert.
          Jetzt auf einmal liefert die Lib beim lesen andere Daten.
          Entweder ich mache etwas falsch, oder die Lib hat eine Macke. Ich bin da noch am debuggen und würde nur ungern "weiter machen" ohne das Problem gelöst zu haben.
          Kurzum: Es kommt aufgrund dieses Problem gerade zu einer Verzögerung.

          Vielleicht mag ja jemand mit der Lib und einem SPI Flash selbst experimentieren und schauen ob man dieses Problem nachgestellt bekommt?

          Kommentar


            So, endlich den Fehler gefunden. Er steckt in dieser Funktion:

            Code:
            bool dataRead(byte data[]) {
              if (_currFile.available()>0) {
                _currFile.read(data, sizeof(data));
              } else {
                Debug.println(F("dataRead(): nothing available"));
                return false;
              }
              return true;
            }
            Der erste der mir hier im Thread die richtige Antwort liefert bekommt ein KONNEKTING T-Shirt von mir :-)

            Nochmal der Hinweis:

            Ich schreibe Daten in den SPI rein, und wenn ich sie wieder heraus lese, sind sie anders... das macht mich ganz konfus.
            Die gezeigte Funktion ist exakt die Funktion mit der die Daten wieder aus dem SPI Flash gelesen werden.

            Hab den Bugfix eben in einem isolierten Test-Sketch ohne KONNEKTING getestet. Werde das jetzt auch noch in KONNEKTING einbauen und gegentesten. Dann kann es endlich mit der Suite weiter gehen.

            Gruß
            Alex

            Kommentar


              Ein Array wird immer als Pointer/Reference übergeben. Das sizeof geht aber nicht bei Pointer. Die Größe des Arrays müsste zusätzlich übergeben werden.
              Zuletzt geändert von STSC; 14.03.2019, 22:15.

              Kommentar


                Glückwunsch. T-Shirt Größe und Adresse bitte per PM. Sobald ich wieder Shirts bestelle und bedrucke bekommst du eins.

                Gruß
                Alex

                Kommentar


                  Noch keine PM bisher erhalten. Hmmm?!

                  Mir ist eingefallen dass ja noch eine "entladen" Funktion gewünscht war. Ganz so wie in der ETS ist es nun nicht umgesetzt. Man wird folgendes "entladen" können:

                  * Individuelle Adresse
                  * alle KO <-> GA Zuordnungen
                  * alle Parameter (damit entfallen ggf. auch GAs auf wegfallenden KOs)
                  * Auf dem Device gespeicherte Daten (solche die man in Zukunft als Datei hoch/runterladen kann)

                  PC-Seitig ist das nun schon in KonnektingDeviceConfig eingebaut. In der Suite fehlt es noch und im Arduino ist die Implementierung noch "leer". Aber protokollseitig ist es schon mit drin.

                  Werde mir jetzt aber erstmal die Suite wieder vor Augen führen und schauen was hier noch fehlt damit man releasen kann.
                  Features wie das FW-Update wird es als Plugin geben und werden nicht sofort in der Suite verfügbar sein. Wichtig ist, dass Protokollseitig alles vorhanden und implementiert ist. Die Features kann ich dann bequem als Suite-Update nachliefern ohne dass man gleich zu einer neuen KONNEKTING Device Library Version greifen muss.

                  Stay tuned....

                  - Alex

                  Kommentar


                    Ich hab noch einen Featurewunsch.
                    Ich hab mir in der ETS ein Dummy für die Konnekting-Geräte angelegt. Ist es möglich, die Reset-Funktion aus der ETS zu implementieren (Gerät zurücksetzen)? Wenn ich mich richtig erinnere spricht der Befehl direkt die PA an, ohne zusätzliche (Authentifizierungs-)Info und sollte deshalb auch mit dem Dummy gehen.

                    Kommentar


                      Reset startet das gerat neu. Das kann unser Protokoll schon. Ich müsste das nur in die Suite einbauen.
                      Damit das Gerät aber einen Reset aus der ETS versteht musste ich erst das klassische Protokoll mit read/writememory und read/writeroperty implementieren.

                      Das könnte aufwendig werden das unsere Struktur rein zu bekommen. Warum muss der Reset denn aus der ETS erfolgen? Und warum machst du überhaupt einen Reset?
                      Stichwort use-case.

                      Gruß Alex

                      Kommentar


                        Wenns aufwändig werden würde, dann lass es .
                        Use case: gerade im Entwicklungs- und Teststadium kommts manchmal zu Situationen, wo ein Gerät nix mehr auf den Bus schickt. Über den ETS reset sehe ich dann, ob zumindest die KNX-Funktion noch funktioniert und ev. nur die Applikation steckt. Geht aber meist auch über read requests. Muss einfach dann nicht die ganzen Abdeckungen (Heizungsgateway) abnehmen für nen reset.

                        Kommentar


                          D.h. ein Reset über die Suite wäre ausreichend? Das wäre nämlich kein Aufwand. Nur Reset aus ETS wird aufwendig.

                          Bzgl. "KNX Funktion" und schauen ob das noch geht: Das ist bei uns so nah aneinander gekoppelt (und bei richtigen Geräten sicherlich auch), dass da kaum ein Unterschied existiert:

                          Wenn die Applikation die loop() blockt, dann können auch keine Reset-Telegramme bearbeitet werden. Das ist bei uns so, und das ist auch bei offiziellen KNX Geräten so. Die behandlung von Telegrammen jedweder Art läuft über den µC. Und wenn der nicht reagiert, weil die App hängt, dann klappt auch da kein Reset.

                          Der einzige Ausweg ohne alle Abdeckungen zu öffnen: reset-knopf an der Spannungsversorgung. werden halt alle Geräte geresettet.
                          Zuletzt geändert von tuxedo; 18.03.2019, 10:42.

                          Kommentar


                            Ja ist auch OK.
                            Mir ist grad noch ein use-case eingefallen: Am MI ist meist kein Reset-taster verbaut bzw auch nicht nach extern verdrahtet. Und immer mit Draht da dran zu gehen ist schon ein wenig fummelig

                            Kommentar


                              Man kann selbst einen reset-taster "basteln". Ich hab experimentell dazu was über den Prog-Button implementiert: Wenn man 3x kurz hintereinander drückt, löst er einen reset aus. Geht halt nur, wenn der µC nicht abgeschmiert ist.

                              Meine Controller haben auch keinen dedizierten Hardware-Reset-Knopf, eben wie auch die meisten KNX Geräte keinen eigenen Reset-Knopf haben.
                              Während der Entwicklung arbeite ich mit einem modifizierten Controller-Board das einen Reset-Knopf hat.

                              Kommentar

                              Lädt...
                              X