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
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
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.
