mikrocontroller.net

Forum: Compiler & IDEs Problem mit Compiler (Linux)


Autor: suse_user (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/Deu...

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

Autor: suse_user (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: suse_hilfe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: suse_hilfe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: suse_hilfe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vergessen:

Könntest du mir sagen welche Paketversionen du genommen hast ?

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;-)

Autor: suse_hilfe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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


Autor: suse_hilfe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

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

Autor: suse_hilfe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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!

Autor: suse_user (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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 <....

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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&f...

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.

Autor: suse_user (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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")

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: suse_user (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.