Ankündigung

Einklappen
Keine Ankündigung bisher.

Entwicklungsblog Beta5/Final 1.0.0

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

    #61
    Das Problem mit fixen Arrays ist der limitierende RAM...

    Ein 32u4 hat nur 2,5kbyte RAM (ein SAMD immerhin 32kbyte!)
    Und alleine um die Daten bzgl. GA+KO und Co. schnell zugreifbar zu haben (wir können nicht zur Laufzeit die Daten aus dem EEPROM lesen, so viel Zeit haben wir nicht), gehen wir nur mal vom "Simple Type" aus (https://wiki.konnekting.de/index.php...01#System_Type), haben wir einen Speicherverbrauch von ca. 512 Bytes wenn man den System Type "ausreizt". Hinzu kommt, was die KOs sonst noch im RAM halten müssen, ein paar Dinge damit die Lib überhaupt arbeiten kann + das was der Entwickler in seinem Sketch braucht. Da bist du - selbst ohne den Sketch - schnell bei 50% RAM Auslastung.

    Deshalb versuche ich den RAM Bedarf so gering wie möglich zu halten. Das war auch die Idee hinter der ArrayList.

    Aktuell tendiere ich aber dazu für diesen Fall die notwendige Maximalgröße beim Start aus den Daten zu ermitteln und das Array dann damit zu allokieren.

    Auch ein einmalig dynamisch allokiertes ist OK. (D.h aber nach änderungen von Zuweisungen in der Suite und upload muss MC neu gestartet werden?!)
    Der µC wird nach jeder Programmieraktion neu gestartet, bevorzugt über einen Watchdog-Timer-Reset, damit alle Register und Co. tatsächlich einen Reset erfahren, und nicht nur der Code von vorne losläuft (wie wir's beim 328P haben implementieren müssen). Echte KNX Geräte verhalten sich auch so. Und das ganze macht auch Sinn.





    Zuletzt geändert von tuxedo; 20.09.2018, 09:06.

    Kommentar


      #62
      Beim Parametriervorgang kennst du doch alle Zuordnungen und kannst die Tabelle entsprechend im EEPROM aufbauen. Nach einem Reset holst du dir die Tabelle auf den Heap. Anschließend gibt es doch keinen Grund mehr, diese Tabelle zu bearbeiten?

      Kommentar


        #63
        Warum versteht mich keiner???

        Ja, die Tabellen werden von der Suite "vorbereitet", sortiert und dann mit dem neuen Protokoll direkt in den Speicher/EEPROM des Arduino geschrieben. Und ja: Beim Start des Arduinos werden die Tabellen gelesen in in fixe Arrays geschrieben. Das ist alles schon da und funktioniert prächtig.

        Aber wenn der Code dann läuft, gibt es abseits DIESER Tabellen noch Dinge, die behandelt werden müssen:

        Wenn ein Telegramm eingeht, muss die Lib schauen:

        1) Ob die GA überhaupt ein KO adressiert
        2) Wenn ja: WELCHE (Mehrzahl) KOs betroffen sind.

        Bisher war 2) immer nur EIN EINZIGES KO. Weil eine GA konnte nur nur einem KO zugewiesen sein.

        Wenn man jetzt einen Schaltaktor hat, der mehrere Kanäle mit einer GA schalten soll, dann haben die betroffenen Kanäle/KOs eben alle diese GA.

        Das alles ist ein Laufzeit-Thema. Das kann ich nicht "vorbereiten". Deshalb die Idee der ArrayList. vereinfacht ausgedrückt:

        Ich iteriere über die Gesamt-Liste der KOs und jedes KO das auf die GA passt, wird in die Ergebnis-ArrayList gesteckt.

        Nun wissen wir aber: permanentes malloc()/free() ist auf einem µC "böhse", weswegen ich eine fixe größe vorgeben muss.

        Mein Ansatz ist jetzt - bevor ich einfach fix eine Größe hardcodiere oder es dem User überlasse: Ich schau wie groß diese Liste für die aktuelle Geräteprogrammierung maximal sein MÜSSTE und allokiere damit die Liste.

        Oder hat jemand einen besseren Vorschlag?

        Kommentar


          #64
          mach einfach max. 5/10/20 GAs pro KO je nach System-Typ und gut ist es.

          Kommentar


            #65
            Da finde ich die Lösung die ich ersonnen habe (nachschauen im EEPROM nach dem maximalwert an zuweisungen) doch noch besser, bevor ich da ein Limit einführe das doch wieder nur nervt.

            Kommentar


              #66
              Zitat von tuxedo Beitrag anzeigen
              Warum versteht mich keiner???


              Zitat von tuxedo Beitrag anzeigen
              Wenn man jetzt einen Schaltaktor hat, der mehrere Kanäle mit einer GA schalten soll, dann haben die betroffenen Kanäle/KOs eben alle diese GA.

              Das alles ist ein Laufzeit-Thema. Das kann ich nicht "vorbereiten". Deshalb die Idee der ArrayList. vereinfacht ausgedrückt:

              Ich iteriere über die Gesamt-Liste der KOs und jedes KO das auf die GA passt, wird in die Ergebnis-ArrayList gesteckt.
              Sorry, ich beschäftige mich erst seit eben damit. Zu meinem Verständnis:

              Der Aktor empfängt z.B. ein EIN-Telegram für eine GA. Nach dieser GA bzw. dessen ID wird in der 'Association Table' gesucht. Wird sie gefunden, hast du eine Liste mit 1..n KO-ID´s. Soweit korrekt?

              Kommentar


                #67
                Fast komplett richtig. Ich suche in der Addresstable nach der GA und bekomme dadurch die GA-ID. Mit der GA-ID kann ich dann in der AssocTable nach den zugehörigen KOs suchen und erhalte dadurch die KO-ID die im weiteren Verlauf dazu benutzt wird das passende KO mit den empfangenen Date zu ffütter und knxEvents () aufzurufen um den Sketch zu informieren dass da Daten angekommen sind.

                Kommentar


                  #68
                  Bitte nicht hauen weil ich es noch nicht verstehe aber wieso machst du sublisten? Würde es nicht genügen den von- und bis-Index für die KO-GA Zurodnung zu speichern wenns eh sortiert sind?

                  Gibts nen git branch der aktuell ist? Mag mal schaun was da so gemacht wird sonst kenne ich mich sowieso nicht aus und trage nur Müll dazu bei :-)


                  EDIT: Vergiss es. Hab zu lange zum posten gebraucht, dann war deine Antwort schon da...

                  Kommentar


                    #69
                    Es sind fast 4 Wochen her das ich was von mir hab hören lassen.

                    Die letzten Wochen hat sich leider KONNEKTING-technisch auch nicht viel getan. Aktuell hab ich ein dringendes Parallel-Projekt das ich verfolgen _muss_ (glasfaserinfo-neckarbischofsheim.de). Aber da wird es in den kommenden 1-2 Wochen auch stiller und ich habe wieder zeit für KONNEKTING.

                    In der zwischenzeit hat mein "Labor" auch ein Upgrade erfahren. Ein neuer 300x90cm großer Arbeitsplatz, am Stück, aus einer Tischplatte. Zusätzlich zum PC-Arbeitsplatz. Da hat nun endlich das Kabelgewirr und der mangelnden Platz ein Ende.

                    Stay tuned...

                    Kommentar


                      #70
                      So, beta5 rückt näher. Ich hab den Abend genutzt um die Implementierung für "Multi-GA-KO" soweit mal in einer ersten Phase zu vollenden.
                      Hatte noch diverse Fehler in der Vor-Sortierung der Daten, so dass der Arduino nicht lange nach den passenden Daten suchen muss.

                      Jetzt scheint das zu klappen: ich kann zuverlässig von der beta5 Suite einen beta5 Arduino programmieren. ich kann mehrere GAs pro KO zuordnen. Und der Arduino check bei jeder eingehenden GA

                      a) ob ihm diese gehört
                      b) welche ID diese GA hat
                      c) welche KOs dieser GA-ID zugeordnet sind

                      Und dann wird jedes zugeordnete KO über das eingegangene Telegramm informiert.

                      Ein bisschen Feinschliff muss noch sein, hier und da muss der Code noch optimiert werden. Aber in 1-2 Wochen könnte der Code soweit sein dass ich ihn zurück in dern Master-Branch mergen kann und wir im Team wieder zusammen optimieren können. Momentan hab ich halt halb KONNEKTING durch den Umbau zerklüftet. Das ganze gleicht einer großen Hüft-OP, zusammen mit einer Herztransplantation und austausch verschiedener Wirbelknochen auf einmal...

                      Es geht voran...

                      Stay tuned.

                      Kommentar


                        #71
                        Am Wochenende hab ich die ganze beta5 Protokolländerung auf den Master-Branch gemerged. Eugen hat hier noch einen Bug gefixt. Soweit scheint das nun zu laufen.
                        Nächste Schritte sind dann erstmal Tests innerhalb des Teams. Gerade was die größte Änderung - Multi-GA pro KO - betrifft muss man hier genau schauen ob das unseren Ansprüchen hinsichtlich Speicherbedarf und Performance genügt. Auch werden wir hier genau schauen müssen wo wir die neu eingeführten Systemgrenzen bzgl. Anzahl KOs und Anzahl verknäpfter GAs setzen.

                        Die Suite braucht auch noch ein wenig Feinschliff, gerade was den Import der GA-Daten aus der ETS betrifft.
                        Und zuguter letzt hab ich für die Suite noch eine Optimierung in der Pipeline die den Programmierprozess um einiges beschleunigen kann.

                        Wir nähern uns mit großen Schritten dem Ziel...

                        Kommentar

                        Lädt...
                        X