Hallo Besucher, der Thread wurde 14k mal aufgerufen und enthält 59 Antworten

letzter Beitrag von GenerationCBM am

Firmware-Support für "Evo2" gewünscht....

    Zitat von everslick

    wir sollten echt versuchen, den evo2 code irgendwie in Unseen's repository zu bekommen. betrifft es eigentlich nur das LCD, oder muss man noch mehr patchen?

    Nix da. Über den Laden liest man immer wieder schlechtes, da werde ich keinen Finger krümmen um denen auch noch zu helfen.

    Zitat von Unseen

    Nix da. Über den Laden liest man immer wieder schlechtes, da werde ich keinen Finger krümmen um denen auch noch zu helfen.

    Kann ich verstehen und ich kann selber ein Lied davon singen, aber...


    1) die hardware selbst ist ja nicht schlecht
    2) upstream support hilft hauptsaechlich den usern, die die firmware selbst kompilieren und aktuell halten wollen
    3) genau darum gehts ja bei freier software, den user aus der abhaengikeit zum hersteller zu befreien


    natuerlich waere es anstaendig gewesen, wenn sich die selber um upstream support gekuemmert haetten, aber immerhin sind sie (mittlerweile) GPL compliant.

    Zitat von everslick

    natuerlich waere es anstaendig gewesen, wenn sich die selber um upstream support gekuemmert haetten, aber immerhin sind sie (mittlerweile) GPL compliant.

    Das brauchte ja auch nur einen "Läden, bei denen ich nicht kaufen würde"-Hinweis auf sd2iec.de...


    Weiss jemand, was für eine Hardware-ID die in ihrem Bootloader eintragen?


    Zitat

    natuerlich waere es anstaendig gewesen, wenn sich die selber um upstream support gekuemmert haetten, aber immerhin sind sie (mittlerweile) GPL compliant.

    Haben die nicht einfach den gleichen LCD-Patch verwurstet, der seit Jahren kursiert? Der, bei dem der Autor ihn bewusst nicht upstreamen wollte, weil ihm irgendwas an dem Code nicht gefallen hat?

    Zitat von Unseen

    Weiss jemand, was für eine Hardware-ID die in ihrem Bootloader eintragen?

    ich glaub da steht nichts besonderes, weil ich habe gerade den aktuellen source aus git ausgecheckt, gepatcht, compiliert und das EVO hat es geflasht.

    Zitat von everslick

    ich glaub da steht nichts besonderes, weil ich habe gerade den aktuellen source aus git ausgecheckt, gepatcht, compiliert und das EVO hat es geflasht.

    Ja, da steht wohl die gleiche ID wie in config-larsp in meinem Repo. Unpraktisch.

    Zitat von everslick

    das heisst man kann versehentlich, die falsche Firmware flashen, oder?


    Genau. Im Prinzip gibts drei Möglichkeiten:

    • Es gibt zwei Unterschiedliche Firmwares mit der gleichen Hardware-Kennung, einmal mit und einmal ohne LCD-Support. Macht das seit Jahren kommunizierte "Entpack alles auf die Karte und lass den Bootloader entscheiden"-Prinzip kaputt und käme für mich deswegen nicht in Frage.
    • Man sagt dem Nutzer, dass er einmal mit externen Mitteln den Bootloader neu flashen muss. Für die meisten Nutzer wahrscheinlich eher unpraktikabel - da bei AVRs der Befehl zum Flashen nur ausgeführt wird, wenn der Prozessor gerade Code im Bootloaderbereich ausführt, kann man das auch nicht durch eine "Update-Firmware" machen.
    • Die Firmware wird so umgeschrieben, dass die LCD-Unterstützung zur Laufzeit hinzugeschaltet werden kann - entweder durch Befehle oder durch automatische Erkennung. Die flexibelste Lösung, erfordert aber zusätzlichen Aufwand und die "Codegrössenkosten" müssen auch die Nutzer "bezahlen", die gar kein LCD verwenden.

    passiert eigentlich etwas unangenehmes, wenn man LCD support einkompiliert hat, aber keines dranhaengt, ausser natuerlich codegroesse?


    ich benutze es ohne LCD, darum hab ich in der allerletzten version den code gar nicht drinnen, hatte aber vorher die offizielle firmware drauf.


    aber vielleicht macht der 'original' LCD treiber eh auto-detection?

    Zitat von everslick

    passiert eigentlich etwas unangenehmes, wenn man LCD support einkompiliert hat, aber keines dranhaengt, ausser natuerlich codegroesse?

    Keine Ahnung, in den Code habe ich nicht reingeschaut. Wenn es einfach so läuft, als ob kein Display angeschlossen ist, wäre das natürlich viel brauchbarer als wenn es zB hängt weil keine Reaktion kommt.

    Der Lcd-Part ist tatsächlich der selbe, wie der für LarsP. Wenn ich mich noch richtig erinnere, dann ist bei dem Evo2-Code eine andere Beschaltung der Led's (Duo-Led) und eine Real-Time-Clock drin enthalten. Aber auch ich werde dafür nichts mehr machen, da ich nie eine Antwort von dem Verkäufer erhalten habe, um ihn auf ein paar Fehler im Source-Code hinzuweisen (z.B. das gerade zu ladende File aus einem D64-Image wurde bei der Evo2-Firmware nicht mehr auf dem LCD angezeigt)

    Hab jetzt auch ein evo2 und die mini von denen da weil die summasummarum eben am einbaufreundlichsten sind und alles mitbringen was sein muss.


    Wenn der code fürs RTC in der lars-p fw schon enthalten ist dann frage ich mich immer warum das bei den ganzen bausätzen nicht genutzt wird? Ist das so teuer oder aufwendig eine rtc zu integrieren? Das evo2 ist das einzige mit rtc was ich kenne und glaub noch eins aus usa das es mal gab.

    grade nachgesehen: die evo2 firmware hat auch noch einen kleinen patch fuer die RTC. der fehlt auch noch bei dem patch, den ich weiter oben gepostet habe.


    soweit ich sehe sind folgende aenderungen in der EVO2 firmware:


    CONFIG: prinzipiell larsp aber HARDWARE_VARIANT = 10
    RTC: eine kleine aenderung zum DS1307 support, der eigentlich eh schon drinnen ist
    LCD: der groesste brocken, betrifft mehrere files


    wenn man momentan ein diff zwischen git version und evo2 firmware macht, kommen endlos aenderungen, wegen copyright header (aenderung auf 2017) das ist ein bisserl unuebersichtlich.


    Ingo: Wenn ich dir einen sauberen patch fuer config und RTC zukommen lasse, ueberlegst du dir, ob du den uebernehmen willst?

    Zitat von katarakt

    Wenn der code fürs RTC in der lars-p fw schon enthalten ist dann frage ich mich immer warum das bei den ganzen bausätzen nicht genutzt wird? Ist das so teuer oder aufwendig eine rtc zu integrieren?


    Das ist weder teuer noch aufwendig, aber es mindert natürlich die Gewinnspanne der eBay-Frickler. Selbst nachrüsten ist aber auch nicht besonders aufwendig, einfach eines der billigen DS3231-RTC-Module von eBay an die sd2iec-Stromversorgung sowie die (Software-)I2C-Pins des AVRs hängen. Die sind zwar im Augenblick nicht für alle Hardware-Varianten definiert und deswegen der RTC-Support nicht überall per Default an, aber ich nehme gerne Vorschläge für geeignete Pins bei den noch nicht damit ausgestatteten Konfigurationen an.


    Zitat

    Das evo2 ist das einzige mit rtc was ich kenne und glaub noch eins aus usa das es mal gab.


    Die Final Expansion 3 hat auch eine RTC am integrierten sd2iec.


    Zitat von everslick

    CONFIG: prinzipiell larsp aber HARDWARE_VARIANT = 10


    Ohje. Was funktioniert alles nicht, wenn man die normale larsp-Hardwarekonfiguration verwendet?


    Zitat

    wenn man momentan ein diff zwischen git version und evo2 firmware macht, kommen endlos aenderungen, wegen copyright header (aenderung auf 2017) das ist ein bisserl unuebersichtlich.


    Idealerweise difft man gegen genau die Revision, von der die modifizierte abstammt - wenn das nicht bekannt ist, scripte ich meist ein wenig auf der Kommandozeile, um die Originalversion mit dem kleinsten diff zu finden.


    Zitat

    Ingo: Wenn ich dir einen sauberen patch fuer config und RTC zukommen lasse, ueberlegst du dir, ob du den uebernehmen willst?


    Ich habe bisher nicht reingeschaut, aber prinzipiell fände ich es wichtig, dass der Code die eh schon vorhandenen Display-Hooks verwendet und nicht überall eigene Aufrufe einstreut.

    Zitat von Unseen

    Ich habe bisher nicht reingeschaut, aber prinzipiell fände ich es wichtig, dass der Code die eh schon vorhandenen Display-Hooks verwendet und nicht überall eigene Aufrufe einstreut.

    ja, darum wollte ich das auch in 2 stufen machen. einmal prinzipieller support mit RTC und dann 'eventuell' LCD support, wenn man das ordentlich hinbekommt.



    Zitat von Unseen

    Ohje. Was funktioniert alles nicht, wenn man die normale larsp-Hardwarekonfiguration verwendet?

    ich bin gerade die HARDWARE_VARIANT 10 und die HARDWARE_VARIANT 3 durchgegangen und konnte keinen unterschied feststellen. d.h. es muesste mit der standard variante 3 gehen. ich werd das gleich mal testen ....

    so mal wieder ein bisserl zeit investiert:


    ich versuche eine aktuelle firmware ohne LCD aber mit RTC zu kompilieren. dabei ist mir aufgefallen, dass man anscheinend IMMER 2 rtc typen in der config aktivieren muss, damit das NEED_RTCMUX define gesetzt wird. wenn das nicht passiert fehlen beim linken die rtc_*() funktionen. ich denke das ist nicht so gedacht oder? Unseen?

    Zitat von everslick

    ich versuche eine aktuelle firmware ohne LCD aber mit RTC zu kompilieren. dabei ist mir aufgefallen, dass man anscheinend IMMER 2 rtc typen in der config aktivieren muss, damit das NEED_RTCMUX define gesetzt wird. wenn das nicht passiert fehlen beim linken die rtc_*() funktionen.

    Nö? Es fehlte lediglich in der ds1307-3231.c ein Alias von rtc_init auf dsrtc_init (gerade gefixt), aber alle anderen RTCs compilieren auch einzeln. Wenn das bei dir nicht klappt scheinst du seltsame Probleme mit deiner Toolchain zu haben, die rtc_*-Funktionen werden in jeder RTC-Implementierung per Weak Alias auf die jeweiligen Funktionen umgebogen. Wenn der RTC-Mux eincompiliert ist, sind dessen Funktionen "stärker" und überschreiben die Aliase; wenn nur eine Implementierung eingebunden ist werden ihre Aliase verwendet.