Guten Abend ! Ich bins wieder mal ^^. Ich benutze SuSe 10.2 und möchte gerne einen Compiler drauf installieren. Ich weiß das einer dabei ist, abe rich install einen anderen, der getrennt ist. Dazu befolge ich die Anleitung auf dieser Seite: http://mercury.chem.pitt.edu/~sasha/LinuxFocus/Deutsch/November2004/article352.shtml#352lfindex3 Auch wenn die Dateien schon dort veraltet sind, habe ich genau diese geladen. Ich konnte die binutils compilen und sie installieren. dann habe ich den gcc kompiliert und versucht den zu installieren aber bekamm da ein Fehler. Ich kann mich nur dran erinnern das er den Command avr oder so nicht finden konnte.. Ich habe mal weiter gemacht und bin bei dem installieren der AVR LIB hängen geblieben. Er findet den ordner ./doconf nicht... BTW: Was muss ich machen um alles rückgängig zu machen ? Einfach die neu angelegten ordner löschen oder muss ich da nochmehr machen ?? Hoffe ihr könnt mir da weiter helfen. Gruß, suse_user
Nachtrag: Das ist der Fehler, wenn ich gcc core make'en will: make[2]: avr-ar: Command not found make[2]: *** [libgcc.a] Error 127 make[2]: Leaving directory `/root/Desktop/gcc-core-3.4.2/gcc-3.4.2/obj-avr/gcc' make[1]: *** [stmp-multilib] Error 2 make[1]: Leaving directory `/root/Desktop/gcc-core-3.4.2/gcc-3.4.2/obj-avr/gcc' make: *** [install-gcc] Error 2
Ich habs doch hinbekommen. Für alle die das gleiche Problem haben: Einfach export PATH=$PATH:/usr/local/avr/bin nochmal als ROOT ausführen, dann sollte es gehen. Gruß, suse_user
Hast du nach dem make der binutils diese Zeile beachtet: "Füge die Zeile /usr/local/avr/lib zu der Datei /etc/ld.so.conf hinzu und laß den Befehl /sbin/ldconfig laufen, um den Linker-cache erneut zu bilden." Die ist dafür verantwortlich, dass die neu gemachten binutils (u.a. avr-ar) als Kommandos/Programme überhaupt erst gefunden und ausgeführt werden können. Ich schätze du kannst weiterkommen, wenn du obigen Schritt machst und dann ab der Softwareinstallation: AVR gcc weitermachst. Ich bin aber selbst am kompilieren der Pakete und kann später mehr sagen. Hat es einen besonderen Grund, warum du eine so uralte (2004) Toolchain aufbauen willst? Ich würde ja eine modernere nehmen...
Hallo Stefan ! Ich hab eine alte genommen, weil ich genau 1:1 mit der Anleitung gehen wollte. Kann ich die alten löschen ? Wenn ja wie geht das ? Einfach die Ordner löschen ? Hast du eventuell ICQ oder MSN ? Gruß, suse_user
Vergessen: Könntest du mir sagen welche Paketversionen du genommen hast ?
Ich habe aus Neugier die oben in deinem Link übersetzt. Ausser bei der avr-libc. Dort war die 1.0.4 nicht mehr auf dem Server und ich habe die älteste vorhandene Version genommen, d.h. die 1.0.5. Das Kompilieren und Installieren ging an sich problemlos genau nach Anleitung. Ich werden noch hin gehen und eine aktuelle Toolchain mit dem GCC 4.1.1 aufsetzen. Dazu werde ich den Ordner /usr/local/avr umbenennen nach /usr/local/avr-3.4.2 und /usr/local/avr neu anlegen und die Installation mit den neuen Paketen wiederholen. Ich denke im Prinzip könnte man /usr/local/avr auch löschen und aus dem PATH rausnehmen und alles wäre wie vor der Installation von avr-gcc. ICQ oder MSN habe ich nicht. Bindet mich zu stark an den Rechner als es eh schon der Fall ist ;-)
Hallo Stefan.
>> Ich werden noch hin gehen und eine aktuelle Toolchain mit dem GCC 4.1.1
aufsetzen. Dazu werde ich den Ordner /usr/local/avr umbenennen nach
/usr/local/avr-3.4.2 und /usr/local/avr neu anlegen und die Installation
mit den neuen Paketen wiederholen. Ich denke im Prinzip könnte man
/usr/local/avr auch löschen und aus dem PATH rausnehmen und alles wäre
wie vor der Installation von avr-gcc.<<
Diesen Teil habe ich nicht ganz verstanden. Du benennst den
/usr/local/avr nach ..../avr-3.4.2 um und legst /usr/local/avr neu an ?
Ich dachte die ganzen Pfade müssten gleich sein.
BTW: Wie kann ich den das aus dem PATH nehmen ? Was ist der Befehl dazu
?
Danke
Gruß,
suse_user
Der Ansatz mit dem Umbenennen ist für den Fall, dass ich zwei avr-gcc auf der Platte halten will. Die alte Version ist in dem .../avr-3.4.2 Ordner und die neue in dem .../avr Ordner. Wenn ich mal die AVR-GCC Version wechseln will, nenne ich .../avr nach .../avr-4.1.1 um und setze .../avr als Link auf .../avr-4.1.1 (arbeiten mit neuem AVR) oder auf .../avr-3.4.2 (arbeiten mit altem AVR) Du kannst auf mehrere Arten einen Text aus dem Pfad entfernen. Ich schreibe folgendes für die Shell bash (Standardshell bei Suse) Die einfachste Art ist von Hand. Ausgeben des alten Inhalts und eintippen des neuen Inhalts: echo $PATH export PATH=eintippen... Eine komfortablere Art geht mit automatischer Bearbeitung durch das Tool sed: export PATH=`echo $PATH | sed 's/\/usr\/local\/avr\/bin://'` Das setzt mehrere Kenntnisse in der Shellbedienung voraus: * Die Klammer mit ` ` führt dazu, dass dieser Teil als Kommando ausgeführt wird. D.h. vor der Zuseisung von PATH wird der Inhalt der Zuwesung zuerst erzeugt * echo $PATH gibt den Inhalt von PATH aus * | leitet die Standardausgabe des vorherigen Kommandis (Echo) in die Standardeingabe des nächsten Kommandos (sed). Diese Weiterleitung nennt man Pipeing. * sed führt das s Kommado auf der Standardeingabe aus. Das s Kommando ist ein ersetzen von Ausdruck1 durch Ausdruck2. Ausdruck1 und Ausdruck2 stehen zwischen //. Also vollständiges s Kommando: s/ausdruck1/ausdruck2/. Ausdruck2 ist hier leer (/usr/local/avr/bin: soll gelöscht werden). Bei Ausdruck1 sind den / \ vorangestellt. Dieses Quoten verhindert, dass die / aus dem Ausdruck als Ende des Ausdruck1 im s Kommando gelesen werden. Das ganze s Kommando ist mit einer ' ' Klammer zusammengefasst. Tipp: Speil mit dieser Art der Kommandos mal rum. Du kannst (und solltest) eigene Variablen benutzen. export TESTPATH=$PATH echo $TESTPATH export TESTPATH=`echo $PATH | sed 's/\/usr\/local\/avr\/bin://'` echo $TESTPATH Wenn das alles zufriedenstellend verläuft, kannst du ja die scharfen Variablen ändern. Überflüssige Variablen (TESTPATH,,,) wirst du so wieder los: export -n TESTPATH
Hallo Stefen. Es ist bei mir zum verzweifeln... Ich habe mal den Ordner avr gelöscht und die Anleitung auf dieser Seite durchgearbeitet: http://www.roboternetz.de/wissen/index.php/Avr-gcc_und_avrdude_installieren Ich habe mir binutils-2.17, gcc-core 4.1.2 und avrlibc-1.4.5 geladen und diese auch installiert. Die Installation hat funktioniert. Nur wenn ich das Beispiel auf dieser Seite kompilieren will bekomm ich diese Fehlermeldung: avr-objcopy: "blink.hex": No such file avr-objcopy: error: the input file "blink.hex" is empty. Was ich mich wundert ist das bei der Makefile in der Zeile: $(TARGET).elf: $(TARGET).o $(CC) $(CFLAGS) -o $@ -Wl,-Map,$(TARGET).map $^ als Dateiendung elf ist.. wenn ich elf lasse bekomm ich die Fehlermeldung das es keine .out Datei existiert die für die HEX benötigt wird. Ich habe dieses. elf durch .out ersetzt und die Fehlermeldung ging weg, aber jetzt hab ich diese neue Fehlermeldung mit dem avr-objcopy. Ich habe mir eine andere Makefile angeguckt und dort wurde auch als Dateiendung .out gewählt. Ist das ein Fehler oder was läuft hier ? Danke
Nachtrag: Ich habe es mit einer anderen Makefile versucht und es hat einwandfrei funktioniert. Ich habe einfach die eine Makefile mit der anderen gemischt und meine eigene Makefile gemacht g, die auch funktioniert. Habe mit KontrollerLab die .HEX File in µC gejagt und siehe da.. die LED blinkt. Aber ob mein Programm auch mit 12MHZ läuft -habe einen externen Quarzoszilator- weiß ich nicht. Zu mindestens funktioniert das Kompilieren der Source Dateien und das Flashen. Wenn du evtl. auch Probleme mit der Makefile bekommen solltest, schicke ich dir gerne meine, aber da du ja der erfahrenere Linux Benutzer von uns beiden bist, schaffst du es bestimmt auch allein. :-). Wenn das so weiter gut läuft, sehe ich eine gute Zukunft mit SuSe und mir. Vielen Dank für deine Hilfe. Wäre prima, wenn du dir ein Messanger Tool besorgen würdest. g. Grüße, suse_user
> Aber ob mein Programm auch mit 12MHZ läuft -habe einen externen > Quarzoszilator- weiß ich nicht. Wenn du keine Fuses umprogrammiert hast, rennt es nicht mit 12 MHz. Du kannst ja mal ein 10s-Blinken-Beispiel schreiben. Den Unterschied zwischen extern 12 MHz und 1 MHz intern merkst du damit schnell ;-) > aber da du ja der erfahrenere Linux Benutzer von uns beiden > bist, schaffst du es bestimmt auch allein. Naja, eher "der Einäugige führt den Blinden". Aber du bist doch schon ein gutes Stück weit gekommen. Selbst AVR-GCC übersetzt. Selbst KontrollerLab installiert. Selbst Programm übersetzt und gebrannt... > Wäre prima, wenn du dir ein Messanger Tool besorgen würdest. Bloss nicht!
Hallo Stef"a"n ! Ich habe die Fuse Settings schon so eingestellt das er den externen Takt benutzt. Ich dachte das das Programm was man in den µC jagt auch den exakten Takt wissen muss. > Wäre prima, wenn du dir ein Messanger Tool besorgen würdest. > Bloss nicht! Schade :p. Wünsche dir noch einen schönen Abend. Grüße, suse_user
> Ich dachte das das Programm was man in den µC jagt auch > den exakten Takt wissen muss. Das ist richtig gedacht, wenn es im Programmcode auf den Takt ankommt. Man macht das z.B. in dem man im makefile oder am Anfang der Source das Makro F_CPU mit dem Takt in Hz angibt. Im makefile (Normal- und beste Methode): F_CPU=12000000UL Oder in der Source (Notmethode): #define F_CPU 12000000UL #include <....
Ich habe mir übrigens noch keine modernere AVR-GCC Version übersetzt und werde bis nach Ostern sicher auch nicht dazu kommen, bin unterwegs. Wenn ich das "in Angriff nehme", will ich nach dieser Anleitung vorgehen: http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=42631 Diese Anleitung hat zusätzlich einen Teil zum Patchen (Ändern) des GCC Quellcodes. Diese Änderungen möchte ich auch in meiner AVR-GCC Toolchain unter Linux drin haben.
Hallo Stefan. Vielen dank für deine Erklärung. Ich werde es morgen testen. Ich habe eben -endlich bin ich dazu gekommen- meine Atmega8 Platine aufgebaut. Hatte noch Lochrasterplatinen liegen und andere Bauelemente und dachte mir, das ich das mal jetzt fertig mache. Hatte irgendwie langeweile. Habe ein Testprogramm drauf gepackt und es funktioniert. Allerdings habe ich es auf Windows getestet. Morgen werde ich in SuSe 10.2 eine Makefile für den atmega8 (inkl. dem MHZ Wert des Quarzoszilators :p ) fertig machen und es dort nochmal testen. Wie gesagt, ich habe einfach den alten avr Ordner gelöscht und die Anleitung nochmal durchgearbeitet, aber diesmal aktuellere Pakete übersetzt -> GCC-Core 4.1.1 und avr-libc 1.45. Es funktioniert einwandfrei. Nur würde ich gerne noch wissen, wie ich die Befehle zum Laden der Module für die Benutzung des Parallelportes bei jedem Systemstart autom. durchführen lassen kann. In welche Datei kann ich diese Befehle schreiben ?. Gemeint sind (ppdev,parport und parport_pc) Ich bedanke mich im Voraus ;). Grüße, suse_user
Wenn du auf deinem System auch Drucken willst, würde ich den ISP-Programmer nicht in den Bootvorgang einbinden, weil sich Druckdämon und ISP-Programmieren beissen können. Du hast quasi die Wahl zwischen Drucken (Druckdämon lpd aktiv, ISP inaktiv) und ISP-Brennen (ISP-Programmer aktiv, Druckdämon lpd inaktiv). Eins kannst du automatisch starten, die andere Option erfordert einen manuellen Eingriff. Meine Präferenz wäre das Drucken. Manuell heisst nicht, du musst alles tippen. Du tippst dir einmal als root ein Skript z.B. ISP.sh mit allen Befehlen und ab dann nur noch einmal vorm ISP-Brennen einmal dieses Skript ausführen... #! /bin/sh # ISP.sh = Parallelport für ISP-Brennen vorbereiten # Skript starten mit sudo ./ISP.sh /sbin/modprobe parport /sbin/modprobe parport_pc /sbin/modprobe ppdev chmod 666 /dev/parport0 # ggf. Befehl zum Stoppen des Druckdämons lpd einbauen OK. Wenn du immer noch weiter den ISP als Grundeinstellung automatisch hochfahren willst... Das geht, allerdings musst du dafür das (Suse) Bootkonzept verstehen. Eine Einführung ist in der Textdatei /etc/init.d/README und bei "man init.d" und die sollst du dann durchlesen. Du kannst dann entweder ein Skript bei dem gewünschten Runlevel (wahrscheinlich 5) einklinken, welches die Befehle enthält, oder wenn du nur modprobe Befehle hast, kannst du die in der Datei /etc/modprobe.conf.local angeben. Modprobe führt die automatisch beim Hochfahren des Systems aus ("man modprobe")
Stefan wrote: > Wenn du auf deinem System auch Drucken willst, würde ich den > ISP-Programmer nicht in den Bootvorgang einbinden, weil sich Druckdämon > und ISP-Programmieren beissen können. Wirklich? Ich dachte, dass die beiden Geräte (/dev/lptN vs. /dev/parportN) sich zur Laufzeit einfach gegenseitig verriegeln würden, d. h. solange einer von beiden das Interface haben will, kann es der andere nicht bekommen. Dafür muss ich doch bei parport extra das Interface "claimen", bevor ich es benutzen kann. Der lpd seinerseits öffnet /dev/lptN nur für die Zeit, da er wirklich drucken will. (Für andere Printspooler als lpd habe ich selbst keine Erfahrung.) Zumindest funktioniert es auf diese Weise unter meinem FreeBSD. Nichtsdestotrotz: allein das Laden des parport-Moduls sollte doch auf keinen Fall mit dem Printspooler kollidieren. Worst case wäre, dass man den Druckdienst für die Zeit anhalten muss, während man den Port fürs ISP nehmen will, aber da hätte ja sowieso Sinn.
Guten Morgen ! Danke für die ausführliche Erklärung Stefan. Ich werde sowieso keinen Drucker benutzen. Die Drucker benutzen doch heutzutage USB. Gruß, suse_user
@ Jörg Wunsch ich bin wie gesagt "Einäugiger" und habe den Hinweis auf den Druckerspooler aus dem ersten Artikel von 2004. Nach Überlegen - es kann gut sein, dass dort das zeitweise Anhalten oder Abschalten des Druckerspoolers gemeint ist und nicht das entweder oder Starten an sich. Versuch macht kluch, bin gespannt wie es aussieht, wenn ich die moderne Toolchain aufgesetzt habe. Wenn man bei diesen Versuchen nicht ISP Brennen probiert sondern nur Auslesen probiert, sollte das dem µC nicht schaden können.
Bitte 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.