Moin, Frage an die Xilinx Spezies: sehe ich das richtig, das ISE 13.4 jetzt den MicroBlaze auch in der Web Edition (die frei downloadbare) mitbringt ? Wird auch hier das SDK benutzt ? Hab darauf keinen Hinweis gefunden ... Er ist zwar etwas abgespeckt (nur lokaler RAM (BRAM), leider kein DDR), aber immerhin, etwas potenter als der PicoBlaze und was die Codegröße betrifft nicht auf 1024 Befehle beschränkt. Da Teile der PicoBlaze Toolchain unter Windows7 nicht mehr ohne Kopfstände zum Laufen gebracht werden können, wäre dies eine gute Alternative ;) Gruss Uwe
Uwe N. schrieb: > Frage an die Xilinx Spezies: sehe ich das richtig, das ISE 13.4 jetzt > den MicroBlaze auch in der Web Edition (die frei downloadbare) mitbringt > ? MicroBlaze MCS? Das ist vermutlich nur eine aufgepeppte Version von XAPP1141 The Simple MicroBlaze Microcontroller Concept. > Wird auch hier das SDK benutzt ? Hab darauf keinen Hinweis gefunden ... Man kann es sicher nutzen. Aber ich glaube nicht, daß das SDK jetzt mit deb Webpack verschenkt wird. Die SDK-Alternative ist z.B. mb-gcc + Makefile. Duke
Duke Scarring schrieb: > MicroBlaze MCS? Das ist vermutlich nur eine aufgepeppte Version von > XAPP1141 The Simple MicroBlaze Microcontroller Concept. Naja, aufgepeppt ist gut, eher etwas auf Diät gesetzt :-) Wenn ich das richtig sehe, wird der MCS hier direkt aus dem IP Generator heraus erzeugt (keine EDK nötig, dafür kaum Konfigurationsmöglichkeiten (ausser z.B. BRAM Größe)). http://www.xilinx.com/tools/mb_mcs.htm Duke Scarring schrieb: >> Wird auch hier das SDK benutzt ? Hab darauf keinen Hinweis gefunden ... > Man kann es sicher nutzen. Aber ich glaube nicht, daß das SDK jetzt mit > deb Webpack verschenkt wird. Das sehe ich auch so, leider. Wobei ich ehrlich gesagt keine Problem hätte, das EDK + SDK zu kaufen (zusammen afaik ca.500-600€) - das Problem damit ist, das die Lizenz nur ein Jahr gültig ist. Stimmt das ? Duke Scarring schrieb: > Die SDK-Alternative ist z.B. mb-gcc + Makefile. Ok, danke für den Tip, muss ich mal testen, ob ich das zum Laufen bringe. Gruss Uwe
Hi, > das Problem damit ist, dass die Lizenz nur ein Jahr gültig ist. >Stimmt das ? Das stimmt so nicht. Du kannst dann nur ein Jahr updaten. Aber benutzen kannst du es dann auch nach 12 Monaten noch. Erst wenn du nach den 12 Monaten auf eine neue Version willst werden wieder Lizenzkosten fällig. Aber wozu willst du dir die SDK kaufen. Wir benutzen hier Eclipse und Makefiles (so ähnlich wie Duke mb-gcc benutzt). Die SDK ist nichts anderes als Eclipse mit Makefiles in ner GUI. Gruß Boris
BorisM schrieb: >> das Problem damit ist, dass die Lizenz nur ein Jahr gültig ist. >>Stimmt das ? > Das stimmt so nicht. Du kannst dann nur ein Jahr updaten. Aber benutzen > kannst du es dann auch nach 12 Monaten noch. Erst wenn du nach den 12 > Monaten auf eine neue Version willst werden wieder Lizenzkosten fällig. Also, wenn ich mir das Paket kaufe, kann ich (die gekaufte Version) unbegrenzt nutzen ? Das ist klasse :-) Neue Version = neue Kosten ist o.k. BorisM schrieb: > Aber wozu willst du dir die SDK kaufen. Wir benutzen hier Eclipse und > Makefiles (so ähnlich wie Duke mb-gcc benutzt). Die SDK ist nichts > anderes als Eclipse mit Makefiles in ner GUI. Weil ich ehrlich gesagt damit besser klarkomme ... Ich habe vor kurzen probiert, den "PLASMA" Prozessor (SoftCore) zum spielen zu bringen, bin grandios an Dingen wie "make" gescheitert. Danke für die Infos ! Gruss Uwe
> > Weil ich ehrlich gesagt damit besser klarkomme ... > Ich habe vor kurzen probiert, den "PLASMA" Prozessor (SoftCore) zum > spielen zu bringen, bin grandios an Dingen wie "make" gescheitert. > > Danke für die Infos ! Mich würde gerne interessieren woran du gescheitert bist? Der Plasma ist noch für mich aktuell, nur in einer anderen Form. Ist noch nicht spruchreif.
René D. schrieb: > Mich würde gerne interessieren woran du gescheitert bist? Was mir spontan einfällt, ist z.B. die Fehlermeldung des Compilers: "Startadresse/ od.Symbol "__Start" nicht gefunden, nehme defaultmäßig 0800200h" (so ähnlich in Englisch). Bei dem Code-Beispiel handelte es sich um dieses hier: "lcd_leds.c" (dies ist als Beispiel im PLASMA-Packet enthalten, nicht selbstgeschrieben) Aber es scheint ein .ELF File geschrieben worden zu sein ... Dies muss dann, wenn ich mich recht entsinne, mit einem anderen Konverter-Tool in eine -.vhd Datei eingebettet werden. Ich habe auch keine Ahnung, wie ein make-File korrekt geschrieben wird - die kryptischen Einträge darin irritieren mich - Kommandozeilentools sind nicht so ganz mein Ding ... Das ganze scheint ein reines Verständnisproblem mit der GNU/ GCC Toolchain zu sein, mit dem PicoBlaze hat es (damals, unter XP) sofort funktioniert. Und mit dem AVR Studio hab ich auch keine GCC-Probleme, eben weil das ganze drumherum in der GUI vor mir (mehr oder weniger) verborgenbleibt. Wie auch immer, die ganze Prozedur ist recht umständlich ... > Der Plasma ist noch für mich aktuell, nur in einer anderen Form. Ist > noch nicht spruchreif. Was meinst du mit "anderer Form" ? Gruss Uwe
Uwe N. schrieb: > Was meinst du mit "anderer Form" ? Ich war auf der Suche nach eine Softcore. Da habe ich verschiedene Softcores ausprobiert. Um nicht alles neu zu erfinden wollte ich eine verbreitete CPU nehmen. Mit dem Hintergrund, das ich eine Toolchain nutzen kann. Denn von Compilerbau habe ich keine Ahnung. Zuerst habe ich mich vorsichtig in die 8biter Z80, C51 herangewagt. Das eigentliche Ergebnis war, diese CPUs lassen sich nicht optimal in einen FPGA umsetzen. Dann bin ich über den Plasma gefallen. Ich hatte die gleichen Probleme und habe gleichzeitig sehr viele Unterlagen zur Mips gefunden. Das ist scheinbar das Paradebeispiel in der Lehre für Rechnerarchitektur. Das Ergebnis ist lässt sich gut im FPGA umsetzen mit sehr gutem Befehlsumfang. Ich habe den Plasma zerlegt und neugeschrieben. Und da bin ich jetzt bei 70-80%.
Uwe N. schrieb: > Was mir spontan einfällt, ist z.B. die Fehlermeldung des Compilers: > "Startadresse/ od.Symbol "__Start" nicht gefunden, nehme defaultmäßig > 0800200h" (so ähnlich in Englisch). Das war der Linker und nicht der Compiler :-) Offenbar passt da das Linkerscript nicht. Uwe N. schrieb: > Das ganze scheint ein reines Verständnisproblem mit der GNU/ GCC > Toolchain zu sein, mit dem PicoBlaze hat es (damals, unter XP) sofort > funktioniert. Der PicoBlaze hat aber auch keine GNU-Toolchain. Da gab es doch nur diese Mediplex-IDE die mit C was anfangen konnte. Alles andere war Assembler. Und da brauch ich keinen Softcore, wenn ich dann doch nur Assembler mache ;-) Duke
Duke Scarring schrieb: > Das war der Linker und nicht der Compiler :-) > Offenbar passt da das Linkerscript nicht. Ich hatte das so aus dem Gedächtnis heraus versucht zu beschreiben ... Autsch ! > Der PicoBlaze hat aber auch keine GNU-Toolchain. Da hab ich mich falsch ausgedrückt, der PicoBlaze hat seinen eignen Assembler (KCPSM), das hat natürlich nix mit dem GNU/ GCC zu tun - deshalb hat es wohl auch geklappt ;) > Und da brauch ich keinen Softcore, wenn ich dann doch nur > Assembler mache ;-) Da hast du sicher recht. So als Einstieg in die Materie erscheint mir der PicoBlaze aber durchaus geeignet (selbst als lausiger Anfänger). Grund ist wohl die fast narrensichere und gute Doku von Ken Chapman. So was in der Form bräuchte ich für GNU/ GCC. Gruss Uwe
Hallo Uwe, Aus jeder Datei ein Objektfile erzeugt. Das siehst du ach daran, dass sich dein Verzeichnis mit Dateien *.o füllt. Als allerletztes kommt der Linker und bindest die Objektdateien zusammen. Da du kein Betriebssystem hast, wird die boot.asm genommen. Da sind Initialisierungen enthalten. Das Linkerscript ist für den Linker, dass er weiss wo sich an deiner CPU Speicher sich befindet. Wichtig ist auch den Anfang auf 0x0 zu legen da von dort auch der Programmcounter startet. Ich habe hier einen Auszug für den Linkerscriptaufruf. So ähnlich ist er auch in einem Makefile in Plasma. $(LD_MIPS) -Ttext 0 -eentry -Map test.map -s -N -o test.axf opcodes.o #> #> Die Option -Ttext ruft das Linkerskript text auf. Oder bin ich da #> falsch? Diese Datei gibt es leider nicht. #Nein, -Ttext gibt einfach die Adresse an, an die das .text-Segment (also #der ausführbare Code) gelinkt werden soll.
Hallo René, sorry für das späte Feedback, hatte am WE gut zu tun. René D. schrieb: > Aus jeder Datei ein Objektfile erzeugt. Das siehst du ach daran, dass > sich dein Verzeichnis mit Dateien *.o füllt. Aha, hatte nochmal in meinen Plasma-Ordner geschaut und tatsächlich einige *.o Dateien endeckt. Ich dachte, das sind irgendwelche *.elf Dateien, weil ich beim Öffnen dieser im Texteditor in der ersten (und einzig lesbaren) Zeile "elf" sah ... (elf-Files = Linker Files ?) Also war das keine Fehlermeldung, sondern eine Warnung ("fehlendes Symbol")? Ich denke, ich werde mich mal nach einer (für mich) verständlichen GNU/ GCC - am besten mit Fokus auf Plasma - Doku/ Tutorials im Netz umschauen. Und zur Not bleibt ja noch das "SDK" von Xilinxs ... Danke an alle hier für die Infos ! Gruss Uwe
Uwe N. schrieb: > Hallo René, > > sorry für das späte Feedback, hatte am WE gut zu tun. > > René D. schrieb: >> Aus jeder Datei ein Objektfile erzeugt. Das siehst du ach daran, dass >> sich dein Verzeichnis mit Dateien *.o füllt. > > Aha, hatte nochmal in meinen Plasma-Ordner geschaut und tatsächlich > einige *.o Dateien endeckt. Ich dachte, das sind irgendwelche *.elf > Dateien, weil ich beim Öffnen dieser im Texteditor in der ersten (und > einzig lesbaren) Zeile "elf" sah ... (elf-Files = Linker Files ?) > Also war das keine Fehlermeldung, sondern eine Warnung ("fehlendes > Symbol")? Die Objektdateien sind im elf Format. Sie sind aber keine ausführbare Dateien. Wenn du wissen willst, was so in den Dateien befindet gibt es den Befehl readelf (zuminedst unter Linux) Als Beispiel: readelf -a gdb.o ELF Header: Magic: 7f 45 4c 46 01 02 01 00 00 00 00 00 00 00 00 00 Class: ELF32 Data: 2's complement, big endian Version: 1 (current) OS/ABI: UNIX - System V ABI Version: 0 Type: REL (Relocatable file) Machine: MIPS R3000 usw. > Ich denke, ich werde mich mal nach einer (für mich) verständlichen GNU/ > GCC - am besten mit Fokus auf Plasma - Doku/ Tutorials im Netz > umschauen. Das wäre eine gute Maßnahme. Wenn du etwas gefunden hast, bitte Info zurück. Wenn du den Weg gehst, dann dokumentiere bitte deine Lernkurve. Du kanns dir auch einen kleine Einstieg in Assember bei der Mips verschaffen. Das ist sehr hilfreich. Der C-Compiler muss aber folgen. Zumindest als Einstieg sollte man es schon wissen. Suche mal nach dem Dokument HP_AppA.pdf das ist ein guter Schnelleinstieg.
René D. schrieb: >> Ich denke, ich werde mich mal nach einer (für mich) verständlichen GNU/ >> GCC - am besten mit Fokus auf Plasma - Doku/ Tutorials im Netz >> umschauen. > Das wäre eine gute Maßnahme. Wenn du etwas gefunden hast, bitte Info > zurück. Werd ich machen. > Wenn du den Weg gehst, dann dokumentiere bitte deine Lernkurve. Mein Hauptproblem ist leider fehlende Zeit, für Projekte hab ich fast nur am Wochenende Zeit, die 2-3 h am Tag, die für das Hobby übrigbleiben, sind arg knapp, da hat man sich gerade "warmgelaufen" ... Nunja, zumindest werde ich an meinem TFT-Controller weiter arbeiten - das ist auch noch ein haufen Arbeit (und ist, vorrausgesetzt eines schönes Tages läuft der PLASMA auf meiner Hardware, ein sehr praktisches Hilfsmittel zum Debuggen). Gruss Uwe PS.: das Pdf hab ich schon mal grob überflogen (hab hier auf Arbeit nicht so viel Zeit) - sieht aber sehr interessant aus !
Duke Scarring schrieb: >> Wird auch hier das SDK benutzt ? Hab darauf keinen Hinweis gefunden ... > Man kann es sicher nutzen. Aber ich glaube nicht, daß das SDK jetzt mit > deb Webpack verschenkt wird. Nachtrag: Ab ISE 14.1 ist das SDK auch in der WebPACK-Version enthalten. http://www.xilinx.com/products/design-tools/ise-design-suite/ise-webpack.htm Gruss Uwe
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.