Hello, Guest the thread was called1.1k times and contains 16 replays

last post from Unseen at the

Wie SD2IEC firmware compilieren

  • Hallo Leute,


    nun ist es endlich soweit: Ich habe mein eigenes SD2IEC - Lochraster-version wie hier im Forum beschrieben. Alles funktioniert zu meiner Zufriedenheit. Jetzt möchte ich ein paar Experimente bezüglich LCD-Anbindung machen und hierzu die firmware selbst modifizieren und natürlich auch compilieren. Leider fehlen mir hierzu einige wichtige Informationen. Zudem bin ich AVR-Einsteiger und mit AVRStudio nicht vertraut. Mit embedded Software-Entwicklung an sich allerdings schon. Ich hoffe also meine Fragen sind nicht zu blöd...


    Also, kann mir jemand in Stichworten erklären, was zu tun ist, um aus den heruntergeladenen Sourcen ein binary-file zu erstellen? Wäre ne echte Hilfe. Sollte es irgendwo ne Anleitung geben, reicht auch der Verweis darauf.


    meine Versuche bis jetzt:
    download von sd2iec-0.10.1.tar.gz und entpacken in mein Arbeitsverzeichnis
    Installation von AVR Studio 4 incl. der toolchain
    In der DOS-box ins Arbeitsverzeichnis wechseln und folgendes eintippen:
    > make CONFIG=config-larsp
    dies ergibt folgendes:
    Das System kann den angegebenen Pfad nicht finden.
    " MKDIR obj-m644p-larsp"
    " CONF2H config-larsp"
    " AS fastloader-ll.S"
    " CC buffers.c"
    buffers.c:292: fatal error: opening dependency file .dep/buffers.o.d: No such fi
    le or directory
    compilation terminated.
    make: *** [obj-m644p-larsp/buffers.o] Fehler 1

    was mache ich falsch???
    Und wie mache ich ein "make clean"? (Geht nämlich ebenfalls nicht)
    und muß ich mit dem Ergebnis (wenn ich mal eins hätte) irgendwie noch was machen, damit der bootloader zufrieden ist?


    Über Antworten freut sich
    Andi

  • OK, CYGWIN wäre jetzt mein nächster Versuch gewesen. Habe hier eben gerade ein WinXP Rechner und der Windows-Version von AVR-Studio. Die bringt die Windows-Version der make tools und den compiler für Windows etc gleich mit. Aber anscheinend mag das build-system alles unter linux haben. Auch gut. Zur Not dann eben eine virtuelle Maschine mit Linux drauf installieren.


    Dennoch bleibt die Frage, wie compiliert wird:
    stimmt meine Vermutung "make CONFIG-config-larsp"? Geht unter Unix dann auch das "make clean"?
    muß man das binary noch irgendwie bearbeiten bevor es geflasht werden kann?


    Gruß,
    Andi

  • Deine Vermutung wird ja von der README bestätigt:


    Code
    1. make CONFIG=config-larsp


    make clean geht dann wie folgt:


    Code
    1. make CONFIG=config-larsp clean


    Bei mir unter OSX 10.6.6 war noch etwas Handarbeit nötig, weil ein awk-script kein strftime findet - das wird aber nur für einen Kommentar benötigt, damit im Kommentar stehen kann, wann die Datei angelegt wurde - also ersatzlos gelöscht.
    crcgen-new hätte er wohl auch gerne noch, gibt's separat auf sd2iec.de. Hat aber im Test eben die Compilate erzeugt, aber ich denke mal, die Prüfsumme sollte schon richtig eingetragen werden, sonst gibt's Ärger.


    edit: Binary bearbeiten? Wieso sollte man? Nö.

  • etwas spät, aber ich setze mich derzeit nur sporadisch dran. Also:


    cygwin installiert und siehe da - das make läuft durch. Was jetzt noch etwas unschön ist, ist die Tatsache, dass der avr-gcc compiler bei mir eigentlich der von AVR-Studio installierte WinAVR ist. Da der aber im path steht, funktioniert das compilieren trotzdem. Sauberer wäre jetzt avr-gcc direkt aus den sourcen unter cygwin zu compilieren und dann diese "Cygwin-Version" zu verwenden. Da dies aber auf Anhieb auch erst mal nicht geklappt hat, bleibe ich erstmal bei meiner derzeitigen "Mischinstallation"


    Also compilieren klappt, jetzt gehts dann (irgendwann mal ans) modifizieren...


    wie sieht das denn aus, sind codebeiträge eigentlich erwünscht? Oder bleiben Änderungen (auch wenn sinnvoll) ein Hobbyprojekt, weil sie nie in den offiziellen Code gelangen? Gibts jemanden, der sich quasi offiziell um den Code kümmert? (Müsste vermutlich nur die mehr von der Expertenrunde lesen, um dies rauszufinden, oder?)


    Gruß,
    Andi

  • OK, hat wieder nen bisschen gedauert. Problem ist jetzt das folgende:
    Ich kann compilieren :-)
    Es entsteht ein binary :-)
    Binary auf SD-Karte und rein damit ins SD2IEC
    geht nicht!!! :-(
    (bootloader im generellen funktioniert, habe das überprüft :-))
    Also binary direkt über ISP geflasht.
    Binary läuft nicht :-(


    Irgendwelche Tipps???


  • Ich kann compilieren :-)
    Es entsteht ein binary :-)
    Binary auf SD-Karte und rein damit ins SD2IEC
    geht nicht!!! :-(


    Es sollte nicht nur ein Binary entstehen.
    Welches Binary kopierst du auf die Karte?



    (bootloader im generellen funktioniert, habe das überprüft :-))
    Also binary direkt über ISP geflasht.
    Binary läuft nicht :-(


    Wie hast du den bootloader überprüft? ggf. mal ein Binary von der sd2iec.de-Seite genommen?
    Welche Firmware hast du derzeit auf dem sd2iec? Stabile versionen weren nur geflasht wenn sie neuer (Größere Versionnummer) sind.
    Welches Dateisystem hast du auf der Karte? Welchen Bootloader verwendest du? Ich vermute du hast einen ATmega644(P) auf der Platine?

  • also, es entstehen mehrere binaries. 2x eine .bin und einmal eine .hex. Sitzte gerade nicht am entsprechenden Rechner, aber eine bin und eine hex hießen so ähnlich wie "sd2iec_v_0101.bin/hex" und die andrere bin hieß "mm2iec_firmware.bin". Ich habe glaube ich alle erfolglos durchprobiert (werd das aber heute abend nochmal überprüfen). Welche sollte ich denn flashen?


    Bootloader: Das mit dem Versionscheck war mir so nicht bewußt. Möglicherweise gings also deshalb nicht. Aber mit offiziellen binaries von der sd2iec homepage gehts. Hatte per ISP die Version 0.08 geflasht und konnte die 0.10.1 dann per bootloader wieder draufspielen. Ja, es ist ein 644p, aber der hat trotzdem immer funktioniert.


    Ach ja. Per ISP flashe ich mit den tools von myAVR: "mySmartUSB light" + "myAVR ProgTool". Das hat soweit immer gut funktioniert. Auch die "blink644.bin" konnte ich damit flashen und es blinkte...

  • So, gestern abend hab ich wieder mal ein paar Stunden investiert. Jetzt geht alles soweit, wenn ich über ISP flashe. Auch mit selbscompilierter Software. Sogar wenn ich Modifikationen einbaue. Woran es vorher lag, kann ich nicht sagen. Ich hatte allerdings im makefile die bootloaderconfiguration nicht ausgeschaltet. Das wars möglicherweise.
    Über den bootloader gehts irgendwie nur sporadisch. Ich scheine jedes mal die Version hochzählen zu müssen, damit das binary geflasht wird. Das ist etwas mühsam. Das PRERELEASE flag ist im makefile gesetzt, so daß das eigentlich nicht nötig sein sollte, aber möglicherweise ist mein bootloader ja zu alt. Ich verwende den aus dem Lochrasterthreat hier im forum. Ich schau mal, da gibts bestimmt was aktuelleres.
    Alsdenn vielen Dank für alle Tipps!
    Andi

  • Über den bootloader gehts irgendwie nur sporadisch. Ich scheine jedes mal die Version hochzählen zu müssen, damit das binary geflasht wird. Das ist etwas mühsam.


    Mit Bootloader gibt es einen Trick. Soviel ich weiss flashed der die Version 0 immer.



    Andererseits braucht man den Bootloader zum entwickel ja wirklich nicht. ISP finde ich da viel besser.


    Der Bootloader ist klasse für Leute die keinen ISP Flasher haben. Für jemanden der einfach nur ein neues Release drauf spielen will, so alle paar Wochen oder gar Monate, ist das eine feine Sache. Man bringt so halt neue Release Stände sehr einfach in die Breite.


    Beim entwickeln will ich nicht immer SD Karte rein und raus. ISP dran stöpseln und gut. Wenn die Sache fertig entwickelt ist und für eine breite öffentlichkeit interessant ist, dann kann man ja ein release für den Bootloader erstellen.

  • Woran es vorher lag, kann ich nicht sagen. Ich hatte allerdings im makefile die bootloaderconfiguration nicht ausgeschaltet. Das wars möglicherweise.


    Sollte trotzdem funktionieren, sofern das Binary nicht so gross ist, dass die Bootloader-Signatur irgendwas überschreibt - das Problem kann aber zur Zeit eigentlich nur mit den 64KB-Chips auftreten.


    Quote

    Über den bootloader gehts irgendwie nur sporadisch. Ich scheine jedes mal die Version hochzählen zu müssen, damit das binary geflasht wird.


    Das ist eigentlich auch so geplant beim Bootloader.


    Quote

    Das PRERELEASE flag ist im makefile gesetzt, so daß das eigentlich nicht nötig sein sollte, aber möglicherweise ist mein bootloader ja zu alt.


    Da müsstest du aber schon einen richtig alten Bootloader von 2007 rauskramen, damit das Feature fehlt - und selbst dann würde es mit Versionsnummer 0xffff funktionieren. Allerdings aktualisiert der Bootloader selbst mit 0-Versionskennung nicht, wenn die CRC in Datei und Chip identisch sind, damit nicht ständig die gleiche Datei neu geflasht wird.

  • Hallo unseen,


    aha, mir wird langsam einiges klar!


    Vermute mein binary war zu groß! Wie groß darf es eigentlich werden auf nem 664? Es war (als es nicht ging) so 61-62k groß. Das ist vermutlich zu viel. Hätte erwartet, daß ich irgend eine linker Warning bekomme. Das scheint aber wohl nicht der Fall zu sein.
    In meinem aktuellen Projekt habe ich aus Platzgründen fast alle fastloader deaktiviert. Jetzt hats gerade nur 51k und das geht locker.


    Denke, ich werde mir mal nen 1284er besorgen. Dann sind die Platzsorgen für ein Weilchen weg.


    Nochmal zum bootloader:
    Was muss ich jetzt genau im Makefile eintragen, damit ich ein binary erhalte, welches sich auf jeden Fall flashen läßt, egal welche version drauf ist? Der CRC-check ist klar - nur ein verändertes binary wird neu geflasht (auch bei gleicher Version). Muß ich zusätzlich zum PRERELEASE flag die version major/minor zu 255/255 setzen? Oder kann ich die vorhandene Version 10/1 beibehalten (so hab ichs gemacht). Bislang musste ich immer den fix-level um eins hoch zählen und konnte dann wieder flashen.


    Ohmann! Hab gerade im makefile gesehen, das bei mir "PRERELEASE=" steht! Sollte da nicht "PRERELEASE=y" stehen???


    Andi

  • Die Größen der Binaries ist wie folgt:

    Code
    1. 126976 larsp-m1284.bin
    2. 61440 larsp-m644.bin


    Und der Bootloader (zumindest den, den ich mal in der Hand hatte) flasht nur Images mit dieser Größe, passender Hardware-Signatur und passernder Versionsnummer (also Major.Minor größer oder 0).


    D.h. entweder du hast nen strange Bootloader oder irgendwas anderes ist kaputt, z.B. Bootloader mag die Karte oder das Filesystem auf der Karte nicht (nicht alle Bootloader koennen FAT32) oder z.B. deine Minor.Major hat nicht gepasst, wenn PRERELEASE leer ist.

  • Vermute mein binary war zu groß! Wie groß darf es eigentlich werden auf nem 664?


    Bei der Ausgabe am Ende des Compiliervorgangs dürfen die (size-)Werte für .data und .text zusammen maximal 61432 ergeben. Von den 64KByte des Chips belegt der Bootloader 4K und für die Signatur am Dateiende sind nochmal 8 Byte fällig. Im 0.10.1-Release sind IIRC nur 300 Byte frei und das auch nur wenn man keine gcc-Version erwischt, die ungünstig grossen Code erzeugt (hier zZt 4.3.2 aus dem Paket von Debian lenny).


    Quote

    Muß ich zusätzlich zum PRERELEASE flag die version major/minor zu 255/255 setzen?


    Nein, würde auch nicht funktionieren weil die Versionsnummer, die crcgen-new bekommt anders erzeugt wird.


    Quote

    Hab gerade im makefile gesehen, das bei mir "PRERELEASE=" steht! Sollte da nicht "PRERELEASE=y" stehen???


    PRERELEASE ist ein String, der ans Ende der Versionskennung gehängt wird. Wenn er leer ist, wird die Bootloader-Version aus der Softwareversion erzeugt, wenn da irgendwas eingetragen ist wird die Bootloader-Version immer auf 0 gesetzt.