Ankündigung

Einklappen
Keine Ankündigung bisher.

Entwicklungsblog Beta5/Final 1.0.0

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

    #76
    Hey,

    für das Feature gibt es in Beta5 im Protokoll grundlegende Änderungen/Erweiterungen. Ich bin gerade dabei das tatsächlich einzubauen.
    Ein erster Prototyp-Sketch hat bereits funktioniert. Sowohl die Übertragung von etlichen kbytes über den Bus, als auch das anwenden der neuen Firmware klappt.
    ABER: Es bedarf aktuell eines SAMD21 Microcontrollers. Mit den kleinen AVR geht das derzeit noch nicht. Theoretisch kann man das auch für die AVRs realisieren, aber da muss man noch ein wenig Hirnschmalz reinstecken. Da wir aber mehr und mehr an die Grenzen der AVRs stoßen, werde zumindest ich da erstmal keine Zeit rein investieren. Aber die Infrastruktur wäre immerhin vorhanden, so dass sich da gerne andere drum kümmern können.

    Wenn die Firmware nicht allzu groß ist, kann man für das Firmware-Update über den Bus ggf. auch ohne separaten Flash-Speicher auskommen. Eugenius hat hierzu glaube ich schon Tests gemacht. Da die Flash-Chips aber nicht die Welt kosten, mehr Flexibilität bieten (weil viel mehr Platzangebot) und ich auf den Platinen ausreichen Platz habe, kommen meine Controller gleich mit entsprechendem Flash-Chip.

    Welchen Speicher man verwendet (vor allem wenn man selbst Controller baut), ist einem selbst überlassen. Man wird der Lib mitteilen müssen wie das speichern und lesen funktioniert (wohl wieder funktionspointer), so dass wir das die größtmögliche flexibilität haben. D.h. du kannst eine SD-Karte anbinden, einen entsprechend großen I2C EEPROM, einen SPI Flash, oder im Worst-Case ein USB-Stick. Solange du weißt wie man schreibt und liest und die Funktionen der Lib zur Verfügung stellst, klappt das. Bevorzugt aber SPI Flash ;-)

    Bevor man das erste mal ein Firmware-Update über den Bus aufspielen kann, muss man aber erst einen Update-fähigen Sketch aufspielen.
    Zuletzt geändert von tuxedo; 11.12.2018, 08:47.

    Kommentar


      #77

      Zitat von tuxedo Beitrag anzeigen
      für das Feature gibt es in Beta5 im Protokoll grundlegende Änderungen/Erweiterungen. Ich bin gerade dabei das tatsächlich einzubauen.
      Ein erster Prototyp-Sketch hat bereits funktioniert. Sowohl die Übertragung von etlichen kbytes über den Bus, als auch das anwenden der neuen Firmware klappt.


      Zitat von tuxedo Beitrag anzeigen
      Bevor man das erste mal ein Firmware-Update über den Bus aufspielen kann, muss man aber erst einen Update-fähigen Sketch aufspielen.
      eh klar...

      Zitat von tuxedo Beitrag anzeigen
      Mit den kleinen AVR geht das derzeit noch nicht. Theoretisch kann man das auch für die AVRs realisieren, aber da muss man noch ein wenig Hirnschmalz reinstecken. Da wir aber mehr und mehr an die Grenzen der AVRs stoßen, werde zumindest ich da erstmal keine Zeit rein investieren. Aber die Infrastruktur wäre immerhin vorhanden, so dass sich da gerne andere drum kümmern können.
      Wie funzt die ganze Geschichte?
      Aus dem Sketch schreibe ich das neue Programm in irgendeinen Speicher (EEPROM, FLASH whatever) - und dann?
      Wer kopiert das Zeug dann in das Programm-Flash an die richtige Stelle? Der Arduino Bootloader?

      Ich wollte jetzt auch gar nicht den 1.0.0 Thread kapern, vielleicht kannst du diesen und die beiden vorherigen Beiträge in ein extra Faden schieben?

      Kommentar


        #78
        Aus dem Sketch schreibe ich das neue Programm in irgendeinen Speicher (EEPROM, FLASH whatever) - und dann?
        Korrekt.

        Wer kopiert das Zeug dann in das Programm-Flash an die richtige Stelle? Der Arduino Bootloader?
        Fast. Der eigentliche BL weiß davon ja nichts. Der Sketch muss eine Art 2nd-Stage Bootloader enthalten. Der tritt an die Stelle des Sketches (wird also da geladen wo normalerweise der Sketch geladen wird). Der eigentliche Sketch liegt NACH diesem 2nd-Stage-BL im Speicher des µC.
        Der 2nd-Stage-BL prüft dann den Flash (oder was auch immer) und kopiert ein gefundenes FW-Update an die Stelle wo der Sketch nun liegt. Danach wird an die passende Stelle im Speicher gesprungen und den dortigen Code ausgeführt. Wird kein Update gefunden, wird einfach so an die Sketch-Stelle gesprungen.
        Ist ein bisschen Tricky (weil quasi zwei Sketches im µC liegen und man den einen oder anderen Klimmzug mit dem Linker und Co. braucht), aber wird vom SAMD-Core in Arduino unterstützt.

        Kommentar


          #79
          Interessant. Hab gestern mal das Datenblatt des ATmega bzgl Bootloader Flash etc quergelesen..
          Vielleicht wirds Zeit auf den SAMD21 umzusteigen...

          Kommentar


            #80
            Ich meine, das Prozedere das man für den SAMD für das Update nutzt, kann man auch im AVR benutzen. Nur sind die Kommandos um aus dem Code heraus in den Flash zu schreiben eben andere. Aber wie gesagt: Der SAMD ist viele Vorteile ggü. den alten AVRs. Allein schon die 32k RAM ggü. 2,5k RAM des 32u4 sind "der Wahnsinn". Der SAMD hat auch mehr Platz für den Sketch (256k). Da kann man dann auch schon was in Richtung DAC machen (ist bei mir gerade in der Prototyp-Phase: Audio abspielen mit dem SAMD ohne extra Wiedergabe-Hardware). Und mit den 48Mhz und den 32bit (ggü. 8Bit und max. 16Mhz) der klassischen AVRs sind auch größere Aufgaben kein Problem.

            Es spricht so vieles für den SAMD und nur eines gegen ihn: Der Preis der Bastel-Boards.

            Aber ST hat mittlerweile auch gute ARM-basierte µC im Angebot. Die kosten verdammt wenig. Nur deren Support für Arduino muss noch etwas besser werden. Hier bin ich noch am aufholen der Infos. Eugenius weiß hier schon wieder mehr ;-)

            Kommentar


              #81
              ich weiß nicht wie das beim SAMD ist, aber bei den ATMegas gibts die BOOTSZ Fuse, die das Boot vom Programm Flash trennt. Diese müsste man ändern, damit der 2nd stage BL im Boot Flash liegt.
              Dafür ist zumindest mal ein Programmer notwendig, und eine Errungenschaft der Arduinowelt ist ja, dass man keinen Programmer mehr braucht.

              Kommentar


                #82
                Beim SAMD funktioniert das wie folgt:

                Normalerweise

                Code:
                [Bootloader]
                [Sketch]
                Der Bootloader st der klassiche Arduino BL für den SAMD. Er prüft beim start die USB Verbindung und bekommt ggf. darüber einen neuen Sketch, den er dann an den Adressbereich von [Sketch] kopiert.

                Mit dem Update-Feature sieht das nun so aus:

                Code:
                [Bootloader]
                [2nd-Stage-BL]
                [Sketch]
                Der BL schaut beim Start wieder nach der USB Verbindung. Kommt da nix oder is hier nichts zu tun, springt an an die Adresse wo der Sketch zu finden ist. Doch da liegt nun der 2nd-Stage-BL. Dieser prüft z.B. die angebundene SD Karte ob es hier ein Update zu holen gibt. Wenn ja, kopiert er es an die Stelle von [Sketch] und danach springt er an die Stelle/Adresse von [Sketch] und macht da weiter mit der Codeausführung.

                Der 2nd-Stage-BL ist ein normales Stück C++-Code der über eine Main-Methode verfügt.

                Der Trick beim aufspielen des Sketches (und der 2nd-Stage-BL per Arduino IDE) ist es nun, VOR den eigentlichen Sketch per Linker- und was-weiß-ich-Kommando in den Speicher zu schreiben, und den eigentlichen Sketch direkt dahinter an eine definierte Adresse.

                Dieses Prozedere sollte bei allen Microcontrollern funktionieren, völlig Hersteller- und Modellunabhängig.
                Hat nur einen Nachteil: Der Platz für den Sketch wird um die Größe des 2nd-Stage-BL kleiner. Beim SAMD kann man das aufgrund der unmenge an Speicher vernachlässigen. Bei den kleinen AVRs schränkt das schon ein wenig ein.

                "Besser" wäre es, den eigentlichen BL um diese Update-Funktion zu erweitern. Ihm also die Option zu geben, nicht nur per USB, sondern auch anderswoher die Daten für das Update zu bekommen. Problem hierbei ist nur: An den eigentlichen BL kommt man nur per Programmer ran. Und beim SAMD ist das nicht so einfach durch einen weiteren kleinen Arduino zu bewerkstelligen. Deshalb hat man wohl diese Lösung gewählt. Kein Programmer, keine Fuses, kein gar nix. Einfach noch ein weiteres Stück Code in den Flash und fertig.

                Wie gesagt: Unsere Lib wird man, wenn man so ein Update-Feature implementieren will, mit ein paar Funktionspointern versorgen müssen. Die Lib nutzt dann die bereitgestellten funktionen um das Update vom Bus auf einen beliebigen Speicher zu kopieren. Wie man dann das Update auf den µC bringt, so dass er das auch nutzt, ist dann ein ganz anderes Problem, welches eben exemplarisch für den SAMD schon gelöst ist. Kurzum: Mit dieser vorangehensweise ist unsere Lib für jegliche Updates gewappnet, auch für künftige µC.

                Kommentar


                  #83
                  Bei den ATmegas darf aber nur Code im Boot Flash den Programm Flash schreiben. Und der Boot Flash wird durch die BOOTSZ Fuse festgelegt.
                  Das von dir vorgeschlagene Vorgehen würde also nicht funktionieren, da der 2nd Stage BL für den µC kein BL wäre und damit nicht schreibend auf den Flash zugreifen darf.

                  Kommentar


                    #84
                    Ah, ok, wieder was dazu gelernt. Dachte das darf der Programm-Flash auch. Der SAMD scheint hier dann die Ausnahme zu sein, da er ja allgemein als Flash-Speicher gilt den man auch so benutzen kann.

                    Nun gut, dann bedarf es bei den ATmegas eben einen anderen/neuen BL. ich meine hier gibt's aber schon verschiedene Ansätze. Github hilft.

                    Was jedoch allgemein beachtet werden sollte: Die Konnekting Lib wächst und wächst. Ohne Debug-Code frisst sie aktuell in einem recht einfachen Demo-Sketch mit separatem I2C EEPROM rund 65% des Speichers eines 32u4. Das ist schon verdammt viel. Mit Debug-Ausgaben liegen wir bei 92%.

                    Unsere ganz klare Empfehlung ist: SAMD
                    Dort werden mit Debug-Ausgabe-Code nur etwa 15% belegt...

                    Ggf. kann man mit noch ein paar zusätzlichen #ifdef hier und da nochmal sparen. Aber das werden wir dann nch sehen. Erstmal den geplanten Funktionsumfang fertigstellen.

                    Aktuell bin ich wieder am File-Up/Download dran, der auch für das FW-Update genutzt wird. Wer lust hat, kann mit dieser Funktionalität auch sowas wie einen Datenlogger bauen der auf eine SD-Karte aufzeichnet. Später kann man dann mit der Suite die Daten vom Device auf den PC runterladen. Oder man kann für angeschlossene Displays Icons und dergleichen auf das Device schieben. Möglichkeiten gibt's viele.

                    Kommentar

                    Lädt...
                    X