brauche Starthilfe

[jagdfalke]

Hi,
ich würde gerne AVR-GCC lernen, da ich mittlerweile ausschließlich unter Suse Linux arbeite.
Ich hab selber schon gesucht und dieses avr-gcc gefunden. Allerdings bräuchte ich ein Tutorial, das mit von Anfang an erklärt, wie alles funktioniert. Dh. das erste wäre wohl die Installation von avr-gcc, danach wäre wohl dran, wie man das Prog. auf das RNBFRA bringt, usw...
Hat da jemand was tolles auf lager? Hab schon mikroscontroller.net gefunden, das sieht schon sehr gut aus, allerdings weiß ich schon mal nicht, welche dateien ich für avr-gcc runterladen muss.
Wäre sehr dankbar für schnelle Abhilfe.
mfg
jagdfalke

[SprinterSB]

Willkommen im avr-gcc-Club :-)
Zum Anfang ersma die Installation:
Installationsanleitung /Build von avr-gcc, avr-libc, binutils auf linuxfocus.org (http://www.tldp.org/linuxfocus/English/November2004/article352.shtml)
Hab ich schon mal ausprobiert und hat prompt geklappt. Teilweise muss man in den ftp-Archiven etwas rumsuchen weil die Links nicht mehr up to date sind, aber das schaffst du.

[Manne51]

Hallo

um den Hexfile zu erstellen, brauchst Du einen Makefile. Dafür gibt es fertige Vorlagen, die man nur an wenigen Stellen anpassen muss.
Zum Übertragen des Hexfiles in den AVR benutze ich den Avrdude und bin sehr zufrieden damit.

[bluebrother]

um den Hexfile zu erstellen, brauchst Du einen Makefile
das ist so nicht richtig. Du kannst das hex-file auch von Hand erstellen, aber mit einem passenden Makefile ist das deutlich einfacher. Ein Makefile ist letztendlich nur eine "Bauanleitung" die in der richtigen Reihenfolge die richtigen Befehle aufruft.
mfile müsste eigentlich auch unter Linux laufen. Habs aber bisher noch nicht ausprobiert.

[jagdfalke]

ok, ich werd mal anfangen der Anleitung zu folgen. Melde mich wenn was nicht klappt
Danke schon mal

[jagdfalke]

Ok, ich habe soweit alles installiert. Hat auch gut geklappt. Jetzt habe ich mir das Programbeispiel angeschaut: avrm8ledtest-0.2. Das steht dort zum download zur Verfügung.
Man soll in das Verzeichniss wechseln und make und make load ausführen.

make:


avr-gcc -g -mmcu=atmega8 -Wall -Wstrict-prototypes -Os -mcall-prologues -o avrm8ledtest.out -Wl,-Map,avrm8ledtest.map avrm8ledtest.o
ld: unrecognised emulation mode: avr4
Supported emulations: elf_i386 i386linux elf64alpha alpha hppalinux elf64_ia64 m68kelf m68klinux elf32ppclinux elf32ppc elf32ppcsim elf64ppc elf_s390 elf64_s390 elf32_sparc sparclinux elf64_sparc sun4 elf_x86_64
make: *** [avrm8ledtest.out] Fehler 1


make load:

avr-gcc -g -mmcu=atmega8 -Wall -Wstrict-prototypes -Os -mcall-prologues -o avrm8ledtest.out -Wl,-Map,avrm8ledtest.map avrm8ledtest.o
ld: unrecognised emulation mode: avr4
Supported emulations: elf_i386 i386linux elf64alpha alpha hppalinux elf64_ia64 m68kelf m68klinux elf32ppclinux elf32ppc elf32ppcsim elf64ppc elf_s390 elf64_s390 elf32_sparc sparclinux elf64_sparc sun4 elf_x86_64
make: *** [avrm8ledtest.out] Fehler 1


Das sieht mir alles sehr kryptisch aus, kann damit rein garnichts anfangen. Was mir noch aufgefallen ist, ist dass ich unter Windows der Programmieradapter ans Board angesteckt lassen kann und das programm läuft problemlos (mit Bascom). Unter Linux aber zuckt kein einziger Servo, solange bis ich den Adapter abnehme. Wenn ich dann das Programm neu starte läuft alles wie gewohnt. Kann das was mit diesem Printer Deamon zu tun haben, von dem da die Rede ist? Ich weiß gar nicht wo ich den ausschalten kann. Hab einfach mal alle installierten Printer gelöscht aber Fehlanzeige.

Kann jemand helfen?

mfg
jagdfalke

[SprinterSB]

Offenbar wird der falsche ld aufgerufen. Sieht aus wie der host ld und nicht wie avr-ld.
Da stimmt also etwas mit deiner Installation nicht bzw mit den Pfaden.
Wenn du gcc zusätzlich den Schalter -v gibst, siehtst du genauer, was er macht und welchen linker er versucht aufzurufen.

::Edit::
Hast du die Installationsanleitung befolgt? Vielleicht ist es ein zu neues bfd, was noch nicht auf AVR angepasst ist...?
avr-ld gehört nicht zum gcc, sondern ist Teil von bfd.

[jagdfalke]

ich hab halt immer die neuste Version der jeweiligen Sources genommen. Dann probier ichs halt nochmal mit genau den selben, wie in der Anleitung.

kleine Zwischenfrage: was ist ein Linker????

[jagdfalke]

Ich hab jetzt alles genauso gemacht, wie des in der Anleitung steht. Mit folgenden Files:

avr-libc-1.0.5.tar.bz2
binutils-2.15.tar.bz2
gcc-core-3.4.2.tar.bz2
uisp-20040311.tar.bz2

in genau der Reihenfolgen wie in der Anleitung beschrieben.

Folge von make und make load:


mathias@linux:~/avrm8ledtest-0.2> make
avr-gcc -g -mmcu=atmega8 -Wall -Wstrict-prototypes -Os -mcall-prologues -o avrm8ledtest.out -Wl,-Map,avrm8ledtest.map avrm8ledtest.o
ld: unrecognised emulation mode: avr4
Supported emulations: elf_i386 i386linux elf64alpha alpha hppalinux elf64_ia64 m68kelf m68klinux elf32ppclinux elf32ppc elf32ppcsim elf64ppc elf_s390 elf64_s390 elf32_sparc sparclinux elf64_sparc sun4 elf_x86_64
make: *** [avrm8ledtest.out] Fehler 1
mathias@linux:~/avrm8ledtest-0.2> make load
avr-gcc -g -mmcu=atmega8 -Wall -Wstrict-prototypes -Os -mcall-prologues -o avrm8ledtest.out -Wl,-Map,avrm8ledtest.map avrm8ledtest.o
ld: unrecognised emulation mode: avr4
Supported emulations: elf_i386 i386linux elf64alpha alpha hppalinux elf64_ia64 m68kelf m68klinux elf32ppclinux elf32ppc elf32ppcsim elf64ppc elf_s390 elf64_s390 elf32_sparc sparclinux elf64_sparc sun4 elf_x86_64
make: *** [avrm8ledtest.out] Fehler 1



allerding lauteten die letzten paar Zeilen von make install in bin-utils:

make[1]: Leaving directory `/home/mathias/binutils-2.15/obj-avr/intl'
make[1]: Entering directory `/home/mathias/binutils-2.15/obj-avr/ld'
make[1]: *** Keine Regel, um »install« zu erstellen. Schluss.
make[1]: Leaving directory `/home/mathias/binutils-2.15/obj-avr/ld'
make: *** [install-ld] Fehler 2

Da ist ja ein Fehler passiert. Kann das damit zusammenhängen?

mfg
jagdfalke

[SprinterSB]

Da wird immer noch der i386-ld aufgerufen.

avr-ld: supported targets: elf32-avr elf32-little elf32-big srec symbolsrec tekhe
avr-ld: supported emulations: avr2 avr1 avr3 avr4 avr5
Dein avr-ld wird also nicht gefunden --> Pfade anpassen, evtl das Makefile. Wie gesagt, mach mal die Option -v zum gcc-Aufruf dazu (im Makefile).
Oder du hast beim configure was vergessen, evtl einen neuen configure-Lauf, zum Build das obj-Verzeichnis wegputzen.

::Edit::

Ein Linker bindet (linkt) die Objekte, die der Assembler generiert zusammen. Zu einem neuen Objekt, einem Executable, einer Lib, ...
Der Assembler wiederum wird von Compiler aufgerufen, meist implizit.

[jagdfalke]

Ach du Schande, ich glaub das wird was größeres sich da einzuarbeiten. So ein paar C-Befehle lernen ist ja nicht so schwer, aber bis man da mal was compiliert kriegt wird was größeres. Ich kenn das ganze Prinzip mit Makefiles und den Make-Befehlen gar nicht.

Hier mal das Makefile: Vielleicht kann es jemand so hinbauen, damit ich wenigstens mal testen kann ob das flashen funktioniert.

# makefile, written by guido socher
MCU=atmega8
CC=avr-gcc
OBJCOPY=avr-objcopy
# optimize for size:
CFLAGS=-g -mmcu=$(MCU) -Wall -Wstrict-prototypes -Os -mcall-prologues
#-------------------
all: avrm8ledtest.hex
#-------------------
help:
@echo "Usage: make all|load|load_pre|rdfuses|wrfuse1mhz|wrfuse4mhz|wr fuse8mhz|wrfusecrystal"
@echo "Warning: you will not be able to undo wrfusecrystal unless you connect an"
@echo " external crystal! uC is dead after wrfusecrystal if you do not"
@echo " have an external crystal."
#-------------------
avrm8ledtest.hex : avrm8ledtest.out
$(OBJCOPY) -R .eeprom -O ihex avrm8ledtest.out avrm8ledtest.hex
avrm8ledtest.out : avrm8ledtest.o
$(CC) $(CFLAGS) -o avrm8ledtest.out -Wl,-Map,avrm8ledtest.map avrm8ledtest.o
avrm8ledtest.o : avrm8ledtest.c
$(CC) $(CFLAGS) -Os -c avrm8ledtest.c
# you need to erase first before loading the program.
# load (program) the software into the eeprom:
load: avrm8ledtest.hex
uisp -dlpt=/dev/parport0 --erase -dprog=dapa
uisp -dlpt=/dev/parport0 --upload if=avrm8ledtest.hex -dprog=dapa -v=3 --hash=32
# here is a pre-compiled version in case you have trouble with
# your development environment
load_pre: avrm8ledtest_pre.hex
uisp -dlpt=/dev/parport0 --erase -dprog=dapa
uisp -dlpt=/dev/parport0 --upload if=avrm8ledtest_pre.hex -dprog=dapa -dno-poll -v=3 --hash=32
#-------------------
# fuse byte settings:
# Atmel AVR ATmega8
# Fuse Low Byte = 0xe1 (1MHz internal), 0xe3 (4MHz internal), 0xe4 (8MHz internal)
# Fuse High Byte = 0xd9
# Factory default is 0xe1 for low byte and 0xd9 for high byte
# Check this with make rdfuses
rdfuses:
uisp -dlpt=/dev/parport0 -dprog=dapa --rd_fuses
@echo " "
@echo "Explanation: Fuse Low Byte: 0xe1 (1MHz intern), 0xe3 (4MHz intern), 0xe4 (8MHz intern)"
@echo " Fuse High Byte should be 0xd9"
# use internal RC oscillator 1 Mhz
wrfuse1mhz:
uisp -dlpt=/dev/parport0 -dprog=dapa --wr_fuse_l=0xe1
# use internal RC oscillator 4 Mhz
wrfuse4mhz:
uisp -dlpt=/dev/parport0 -dprog=dapa --wr_fuse_l=0xe3
# use internal RC oscillator 8 Mhz
wrfuse8mhz:
uisp -dlpt=/dev/parport0 -dprog=dapa --wr_fuse_l=0xe4
# use external 3-8 Mhz crystal
# Warning: you can not reset this to intenal unless you connect a crystal!!
wrfusecrystal:
@echo "Warning: The external crystal setting can not be changed back without a working crystal"
@echo " You have 3 seconds to abort this with crtl-c"
@sleep 3
uisp -dlpt=/dev/parport0 -dprog=dapa --wr_fuse_l=0xee
#-------------------
clean:
rm -f *.o *.map *.out *t.hex
#-------------------


Wo ist der gcc-Aufruf? Oder besser: Was ist ein gcc-Aufruf?

Vielleicht brauch ich erstmal weitere Links zum Thema Make usw. !?

mfg
jagdfalke

[SprinterSB]

Ach du Schande, ich glaub das wird was größeres sich da einzuarbeiten. So ein paar C-Befehle lernen ist ja nicht so schwer, aber bis man da mal was compiliert kriegt wird was größeres. Ich kenn das ganze Prinzip mit Makefiles und den Make-Befehlen gar nicht.

Hier mal das Makefile: Vielleicht kann es jemand so hinbauen, damit ich wenigstens mal testen kann ob das flashen funktioniert.
Das Beispiel kommt offenbar mit einem schon generiertem hex daher; mit avrm8ledtest_pre.hex
Zum laden ein "make load_pre" ausführen.

make ist schon eine eigene Welt mit vielen Fallstricken und Fehlerquellen, vor allem bei komplexeren Projekten.

gcc kannst du auch ohne make benutzen, direkt von der Commandline aus. Das ist etwas umständlicher, aber für den Anfang auf jeden Fall klarer und leichter zu durchschauen!

Geändert hab ich an dem makefile nix, nur ein paar Kommentare dazu gemacht. So sonderlich toll ist das Makefile übrigens nicht, weil es viele Redundanzen enthält und man schnell was vergisst, wenn andere/neue Quellen hinzu kommen.


#Hier wird der Compiler festgelegt (und auch der Linker)
# CC ist eine vordefinierte Variable von make
# anstatt $(CC) könnte man unten auch einfach avr-gcc schreiben
CC=avr-gcc
# Vatiable für objcopy definieren, braucht man um hex zu erstellen aus elf32 etc
OBJCOPY=avr-objcopy
# optimize for size:
# Optionen für gcc, hier könnte zB ein -v dazu
CFLAGS=-g -mmcu=$(MCU) -Wall -Wstrict-prototypes -Os -mcall-prologues
...
# Regel zum erstellen der hex
avrm8ledtest.hex : avrm8ledtest.out
$(OBJCOPY) -R .eeprom -O ihex avrm8ledtest.out avrm8ledtest.hex
# Regel zum Linken. avr-gcc wird wie ein Linker aufgerufen.
# Wenn gcc Objekte sieht, leitet er an den linker weiter.
# impliziter linker-Aufruf.
# Anstatt .out sollte die suffix besser .elf sein!
#denn es wird elf32 erzeugt und kein aout!
avrm8ledtest.out : avrm8ledtest.o
$(CC) $(CFLAGS) -o avrm8ledtest.out -Wl,-Map,avrm8ledtest.map avrm8ledtest.o
# compile: erstelle ein Objekt-File aus der Quelle
avrm8ledtest.o : avrm8ledtest.c
$(CC) $(CFLAGS) -Os -c avrm8ledtest.c
# you need to erase first before loading the program.
# load (program) the software into the eeprom:
load: avrm8ledtest.hex
uisp -dlpt=/dev/parport0 --erase -dprog=dapa
uisp -dlpt=/dev/parport0 --upload if=avrm8ledtest.hex -dprog=dapa -v=3 --hash=32
# here is a pre-compiled version in case you have trouble with
# your development environment
load_pre: avrm8ledtest_pre.hex
uisp -dlpt=/dev/parport0 --erase -dprog=dapa
uisp -dlpt=/dev/parport0 --upload if=avrm8ledtest_pre.hex -dprog=dapa -dno-poll -v=3 --hash=32



Wo ist der gcc-Aufruf? Oder besser: Was ist ein gcc-Aufruf?

Vielleicht brauch ich erstmal weitere Links zum Thema Make usw. !?

mfg
jagdfalke

http://www.gnu.org/software/make/manual/make.html
http://de.wikipedia.org/wiki/Make
http://www.linuxfibel.de/make.htm

[jagdfalke]

make load_pre bingt das hier:


uisp -dlpt=/dev/parport0 --erase -dprog=dapa
make: uisp: Kommando nicht gefunden
make: *** [load_pre] Fehler 127


So wie's aussieht schmeiß ich Windows als zweiter OS drauf un programmier mit Bascom. Ich hab gedacht, es gäbe ne realtiv einfache Möglichkeit das unter Linux zu machen, aber der Aufwand isses nicht wert. Wenn man schon ne Woche opfern muss um überhaupt das erste Programm draufzuladen ist die Effizienz gleich null. Soviel Zeit und Lust hab ich dann auch nicht.

[SprinterSB]

bevor du uisp nutzt musst du es installieren.
Und wenn es installiert ist, dann muss 'which uisp' den Pfad dazu anzeigen, ansonsten musst du PATH anpassen.

[SprinterSB]

Wenn du auf Windows umsteigst: WinAVR ist deutlich einfacher zu installieren. Und da sind die binutils und avr-libc schon dabei und auch ein progger (avrdude). Oder PonyProg o.ö. verwenden.

[jagdfalke]

Ok, scheiß auf des Linuxzeug. Ich machs unter Windows. Gibts irgendwelche Gründe das ganze unter Windows trotzdem mit C zu machen? Ich mein, wenn ich wieder Window draufschmeiß kann ich gleich Bascom nehmen.

mfg
jagdfalke

[bluebrother]

Ähm, also da liegt doch schon mal der erste Fehler:

make[1]: Leaving directory `/home/mathias/binutils-2.15/obj-avr/intl'
make[1]: Entering directory `/home/mathias/binutils-2.15/obj-avr/ld'
make[1]: *** Keine Regel, um »install« zu erstellen. Schluss.
make[1]: Leaving directory `/home/mathias/binutils-2.15/obj-avr/ld'
make: *** [install-ld] Fehler 2
dein Linker wird nicht richtig installiert, also kann das linken nicht funktionieren.
edit: du hast daran gedacht das make install mit den richtigen Berechtigungen aufzurufen? Bauen tust du es ja als user ...

Eine Toolchain zu bauen ist nicht gerade trivial, aber wenn du es einmal geschafft hast ist es eigentlich recht einfacht. Nicht so schnell aufgeben!

Ja, es gibt Gründe unter Windows C zu programmieren. C kann einfach mehr und *hust* Basic auf nem µC? *urgs*

Nach welcher Anleitung hast du die Toolchain gebaut?

[jagdfalke]

was ist eine toolchain?
Meinst du nach welcher Anleitung ich die Sources compiliert hab und so? Dann wars hier (http://www.tldp.org/linuxfocus/English/November2004/article352.shtml ) Der Link wurde oben schon mal gepostet. Ich einfach blind in die Konsole abgetippt, was da steht. Ich check realtiv wenig von dem was da gemacht wurde. Es wurden halte ständig irgwelche make-Befehle ausgeführt un configure mit massig parametern, die alle nicht erklärt wurden.

[bluebrother]

was ist eine toolchain?
Eine Toolchain bezeichnet die Tools (also Programme) die du in der richtigen Reihenfolge brauchst (binutils, gcc, etc) um dein Programm zu kompilieren. Siehe http://en.wikipedia.org/wiki/Toolchain

Meinst du nach welcher Anleitung ich die Sources compiliert hab und so?
ja, hab den Link vorhin überlesen. Das ist ein bischen veraltet (avr-libc hat mittlerweile Version 1.2). Ich hoffe du hast das unter
# as root:
auch als root gemacht -- also vorher ein "su" gemacht. Als normaler user darfst du nix systemweit installieren (und das ist auch gut so).

Typischerweise geht das Bauen aus Sourcen so:


tar zxf foo.tar.gz
cd foo
./configure
make
su
make install
exit

Hab für meine avr-Toolchain auch ne Weile gebraucht. Neulich die für den Coldfire gebaut und das war dann wirklich einfach. Vielleicht solltest du einfach nochmal die Installation machen, ich hab den Eindruck dass da gerade beim Installieren einiges nicht funktioniert hat weil du falsche Rechte hattest.
Wenn Fehler auftauchen (gerade wenn make was von "Stop" sagt) musst du die ernst nehmen!

[jagdfalke]

jo, ich sollte mkdir /usr/local/avr machen und da hat er mir schon gesagt ich hab keine Rechte um das zu machen. deshalb hab ich in root gewechselt und auch gleich so weitergemacht. war das falsch?

noch was:
Falls ich es jemals schaffen sollte das ans laufen zu kriegen: Wo lerne ich, welche C-Befehle der alle kann und z.B wie man einen Servo über den Coprozessor (rns1) bewegt?

[bluebrother]

jo, ich sollte mkdir /usr/local/avr machen und da hat er mir schon gesagt ich hab keine Rechte um das zu machen. deshalb hab ich in root gewechselt und auch gleich so weitergemacht. war das falsch?


nein. Aber dann sollte es eigentlich problemlos durchlaufen. Vielleicht ist es am einfachsten wenn du alles nochmal baust und evw. auftretende Fehlermeldungen hier postest.

edit: probier mal /usr/local/avr in den Pfad aufzunehmen. Also
export PATH=/usr/local/avr(bin:$PATH
mir scheint der installiert in ungewöhnliche Pfade (das --prefix bei den configure-Aufrufen)

[SprinterSB]

Nö, das geht. Du kannst das Zeug auch lokal bei dir im home installieren. Sind wohl kaum andere User an deinem Rechner, die das Zeug nutzen wollen...
Die Optionen dann sinngemäss anpassen.

Nochmal die Frage: Hast du PATH angepasst? (in deinem .shrc oder .bashrc oder was auch immer).
Nur ein export von path tut's eben nur kurzzeitig, und dann werden die Sachen nicht mehr gefunden.
Die Optionen bei configure brauchst du schon, mit einem 'nackten' configure wird's nicht funzen (configure, build und install vielleicht, aber run nicht mehr)
.

[SprinterSB]

...und nach einem erneuten configure *alle* zugehörogen Objekte in die Tonne kloppen!!! configure änder ja nicht die Quellen und make denkt dann oft, es hätte nix zu tun.

Am besten so was wie
rm -rf obj-dir
mkdir obj-dir

[bluebrother]

Nö, das geht. Du kannst das Zeug auch lokal bei dir im home installieren. Sind wohl kaum andere User an deinem Rechner, die das Zeug nutzen wollen...
schon, aber halt nicht mit den Pfaden die in dem Tut stehen :)


Die Optionen bei configure brauchst du schon, mit einem 'nackten' configure wird's nicht funzen (configure, build und install vielleicht, aber run nicht mehr)
.
die meisten Tarballs lassen sich ohne Optionen im configure problemlos bauen -- meistens ist prefix=/usr/local. uisp wäre so ein Beispiel. Funktioniert natürlich nicht mehr wenn du ein anderes prefix haben willst oder andere optionen brauchst (--enable-language=c usw. in diesem Fall).

Ich hab das Zeug übrigens nach /usr/local installiert (kein /usr/local/avr), tut prima und ich hab keine neuen Pfad den ich brauche -- /usr/local ist eh lokal installiertes Zeug, da passt das von meiner Philosophie sowieso besser rein. Aber das ist Ansichtssacht.

[bluebrother]

Am besten so was wie
rm -rf obj-dir
mkdir obj-dir
in der Regel macht das auch ein
make clean
oder
make distclean
Aufrufen muss man es natürlich noch selber :)

[jagdfalke]

ich hab das ganze gleich nach der installation ausprobiert. hab also kurz vorher export gemacht.
Wie soll ich denn alles Fehlermeldungen finden? Das läuft doch so schnell durch, dass ma keine chance hat mitzukommen.

[bluebrother]

wenn eine kritische Fehlermeldung kommt hält das ganze an. Wie das von dir genannte "... Schluß."
Du kannst mit Shift-PgUp/Down in der Konsole scrollen.

[SprinterSB]

make bricht bei fehlern ab.
Und du kannst die Ausgabe in ne Datei pipen und in Ruhe nachlesen oder mit grep suchen.
zB
make >& out.txt
Das >& weil du nicht nur stdout, sondern auch stderr einfangen willst.

[SprinterSB]

Ich hatte das mal in meinem home installiert, mit der Hilfe von linuxfocus. Vorher hatte ich auch Probleme, und habs dann sinngemäß durchgezogen. Ging prompt, und zwar mit:
avr-libc 1.0.5
binutils 2.15
gcc 3.4.4
uisp brauch ich net

[jagdfalke]

also nur nochmal die 3 packages laden und so machen wie beschrieben, ja?

[bluebrother]

ja.
Wobei ich mich frage ob es nicht einfacher wäre das erste mkdir /usr/local/avr bis zum export PATH=/usr/local/avr/bin:${PATH} wegzulassen und dann überall wo --prefix=/usr/local/avr auftaucht stattdessen --prefix=/usr/local zu setzen. /usr/local/bin ist idR. schon in $PATH drin (einfach mal echo $PATH machen und gucken ob es auftaucht)

[SprinterSB]

Ja

15 Zeichen:
...............

[jagdfalke]

also ich hab jetzt nochmal alles gemacht:

das hier kam nach configure in binutils:

loading cache ./config.cache
checking host system type... i686-pc-linux-gnu
checking target system type... avr-unknown-none
checking build system type... i686-pc-linux-gnu
checking for a BSD compatible install... (cached) /usr/bin/install -c
*** This configuration is not supported in the following subdirectories:
target-libiberty
(Any other directories should still work fine.)
*** removing intl/Makefile to force reconfigure
*** removing libiberty/Makefile to force reconfigure
*** removing opcodes/Makefile to force reconfigure
*** removing bfd/Makefile to force reconfigure
*** removing binutils/Makefile to force reconfigure
*** removing gas/Makefile to force reconfigure
*** removing etc/Makefile to force reconfigure
checking for i686-pc-linux-gnu-ar... no
checking for ar... (cached) ar
checking for i686-pc-linux-gnu-as... no
checking for as... (cached) as
checking for i686-pc-linux-gnu-dlltool... no
checking for dlltool... (cached) dlltool
checking for i686-pc-linux-gnu-ld... (cached) /usr/lib/gcc-lib/i586-suse-linux/3.3.5/../../../../i586-suse-linux/bin/ld
checking for i686-pc-linux-gnu-nm... no
checking for nm... (cached) nm
checking for i686-pc-linux-gnu-ranlib... no
checking for ranlib... (cached) ranlib
checking for i686-pc-linux-gnu-windres... no
checking for windres... (cached) windres
checking for i686-pc-linux-gnu-objcopy... no
checking for objcopy... (cached) objcopy
checking for i686-pc-linux-gnu-objdump... no
checking for objdump... (cached) objdump
checking for avr-ar... no
checking for avr-as... no
checking for avr-dlltool... no
checking for avr-ld... no
checking for avr-nm... no
checking for avr-ranlib... no
checking for avr-windres... no
checking whether to enable maintainer-specific portions of Makefiles... no
creating ./config.status
creating Makefile

Fand ich verdächtig, wegen den ganzen nos

binutils make:

checking lex output file root... /home/mathias/binutils-2.15/ld/configure: line 4505: lex: command not found
configure: error: cannot find output from lex; giving up
make: *** [configure-ld] Fehler 1

binutils make install:

make[1]: Leaving directory `/home/mathias/binutils-2.15/obj-avr/intl'
make[1]: Entering directory `/home/mathias/binutils-2.15/obj-avr/ld'
make[1]: *** Keine Regel, um »install« zu erstellen. Schluss.
make[1]: Leaving directory `/home/mathias/binutils-2.15/obj-avr/ld'
make: *** [install-ld] Fehler 2



gcc make install:

make[2]: Entering directory `/home/mathias/gcc-3.4.2/obj-avr/libiberty/testsuite'
make[2]: Für das Ziel »install« ist nichts zu tun.
make[2]: Leaving directory `/home/mathias/gcc-3.4.2/obj-avr/libiberty/testsuite'
make[1]: Leaving directory `/home/mathias/gcc-3.4.2/obj-avr/libiberty'
"nichts zu tun" is immer schlecht.

avr_lib domake:

make[1]: Für das Ziel »all-am« ist nichts zu tun.

uisp make:

make[1]: Für das Ziel »all-am« ist nichts zu tun.


das sind so die Ausgaben dir mir komisch vorkamen.
Und? Ist es jetzt installiert oder nicht?

mfg
jagdfalke

[bluebrother]

ok. Also:
- das "configure" von den binutils sieht soweit ich sehe gut aus.
- "make" von den binutils: du hast "lex" nicht installiert. Auf meinem System (Fedora Core 3) gehört das zu dem Paket "flex". Musst du nachinstallieren.
- damit geht dann auch das "make install" der binutils in die Hose. Damit kann dann aber auch wieder der gcc nicht gebaut werden weil der die binutils braucht.
- ich würde dir empfehlen die Ordner mit den Quellen nochmal zu löschen und die Archive neu auszupacken damit kein "Müll" übrig ist. (SprinterSB hat das auch erwähnt, es geht auch "einfacher", aber ich denke dass ist für dich die einfachste Variante.
- uisp make sieht deswegen gut aus weil du es schon mal gebaut hast. "make clean" machen und dann nochmal beim configure anfangen.
- kann Susi Paketgruppen installieren? Wenn ja schau mal ob es eine Gruppe "Development" gibt und schau dass die komplett installiert ist. Sonst kann es passieren dass dir bald wieder irgendwelche benötigten Tools fehlen.

[jagdfalke]

flex ist installiert. Wenn ich die ganze Gruppe Development installieren will kommen lauter Abhängigkeitsprobleme.

[bluebrother]

merkwürdig. nach deinem output

checking lex output file root... /home/mathias/binutils-2.15/ld/configure: line 4505: lex: command not found
wird eindeutig lex nicht gefunden. Was sagt rpm -qil flex? Hast du mal probiert die binutils komplett neu zu bauen?

[jagdfalke]

seltsam, der haken in yast war da, aber rpm -qil flex sagt not installed. Ich habs jetzt einfach mal aktualisieren lassen.
Und so geht alles wieder von vorne los...

[jagdfalke]

so, hier nochmal die letzten paar zeilen der Ausgaben:

binutils
configure:

checking for avr-windres... no
checking whether to enable maintainer-specific portions of Makefiles... no
updating cache ./config.cache
creating ./config.status
creating Makefile

make:

rm -f ld.pod
make[3]: Leaving directory `/home/mathias/binutils-2.15/obj-avr/ld'
make[2]: Leaving directory `/home/mathias/binutils-2.15/obj-avr/ld'
make[1]: Leaving directory `/home/mathias/binutils-2.15/obj-avr/ld'

make install:

make[2]: Entering directory `/home/mathias/binutils-2.15/obj-avr/libiberty/testsuite'
make[2]: Für das Ziel »install« ist nichts zu tun.
make[2]: Leaving directory `/home/mathias/binutils-2.15/obj-avr/libiberty/testsuite'
make[1]: Leaving directory `/home/mathias/binutils-2.15/obj-avr/libiberty'

gcc
configure:

checking for avr-windres... no
checking whether to enable maintainer-specific portions of Makefiles... no
updating cache ./config.cache
creating ./config.status
creating Makefile

make:

avr-ar rc avr5/libgcov.a libgcc/avr5/_gcov.o libgcc/avr5/_gcov_merge_add.o libgcc/avr5/_gcov_merge_single.o libgcc/avr5/_gcov_merge_delta.o
avr-ranlib avr5/libgcov.a
make[2]: Leaving directory `/home/mathias/gcc-3.4.2/obj-avr/gcc'
echo timestamp > stmp-multilib
make[1]: Leaving directory `/home/mathias/gcc-3.4.2/obj-avr/gcc'

make install:

make[2]: Entering directory `/home/mathias/gcc-3.4.2/obj-avr/libiberty/testsuite'
make[2]: Für das Ziel »install« ist nichts zu tun.
make[2]: Leaving directory `/home/mathias/gcc-3.4.2/obj-avr/libiberty/testsuite'
make[1]: Leaving directory `/home/mathias/gcc-3.4.2/obj-avr/libiberty'

avr-lib
domake:

ln crt1/crttn26.o crttn26.o >/dev/null 2>/dev/null || cp crt1/crttn26.o crttn26.o
rm -f crt86401.o
ln crt1/crt86401.o crt86401.o >/dev/null 2>/dev/null || cp crt1/crt86401.o crt86401.o
make[1]: Leaving directory `/home/mathias/avr-libc-1.0.5/build'

make:

mkdir /usr/local/avr/avr/include
mkdir /usr/local/avr/avr/include/avr
make[2]: Leaving directory `/home/mathias/avr-libc-1.0.5/build'
make[1]: Leaving directory `/home/mathias/avr-libc-1.0.5/build'

uisp
configure:

config.status: creating uisp.1
config.status: creating uisp.spec
config.status: creating src/Makefile
config.status: creating src/config.h
config.status: executing depfiles commands

make install:

/usr/bin/install -c -m 644 ChangeLog-2002 /usr/local/avr/share/doc/uisp-20040311/ChangeLog-2002
/bin/sh ./mkinstalldirs /usr/local/avr/man/man1
/usr/bin/install -c -m 644 ./uisp.1 /usr/local/avr/man/man1/uisp.1
make[2]: Leaving directory `/home/mathias/uisp-20040311'
make[1]: Leaving directory `/home/mathias/uisp-20040311'

Jetzt alles klar?

[bluebrother]

Der Output sieht gut aus. Mal probiert die Programme aufzurufen?
avr-as --version
avr-gcc --version
uisp --version
sollte dir die Versionsnummern liefern. Wenn das tut biste fertig :) (an den PATH denken wenn du --prefix=/usr/local/avr benutzt hast, ansonsten müsste /usr/local/bin im Pfad sein und es ootb tun)

[jagdfalke]

linux:/home/mathias # avr-as --version
GNU assembler 2.15
Copyright 2002 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License. This program has absolutely no warranty.
This assembler was configured for a target of `avr'.
linux:/home/mathias # avr-gcc --version
avr-gcc (GCC) 3.4.2
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

linux:/home/mathias # uisp --version
uisp version 20040311
(C) 1997-1999 Uros Platise, 2000-2003 Marek Michalkiewicz

uisp is free software, covered by the GNU General Public License.
You are welcome to change it and/or distribute copies of it under
the conditions of the GNU General Public License.


sieht gut as oder? Und wie geht weiter?

[bluebrother]

Die Toolchain ist fertig. Glückwunsch!

Jetzt kannst du mal mit dem Beispiel loslegen. Aber aufpassen, es gibt noch ne Menge Beispiele die cbi, sbi und andere veraltete Makros benutzen -- cbi und sbi gibts in der aktuellen avr-libc nicht mehr (oder hast du die alte 1.0 installiert? Dann ist es kein Problem. Ich rate aber von der Verwendung der Makros ab).
Zum programmieren deines Controllers musst du den Druckerspooler wahrscheinlich anhalten. Bei Susi ist das Cups: "service cups stop" als root. Oder probiers über irgend ein Susi-Tool, bin mir nicht sicher ob das "service" da auch tut (hab keine Ahnung von Susi. Frauen halt *g*)

[jagdfalke]

ist das absicht, dass du immer "Susi" sagst? Schätz mal schon :D
das mit make und make load zum rüberspielen stimmt schon oder?

Ich hatte die version 1.0.5 installiert. Ist das schlimm? Ich kanns auch ändern. Bins ja mittlerweile gewohnt die paar Befehle reinzuklopfen :D

Danke, dass ihr mir so gedulgig geholfen habt!!!

mfg
jagdfalke

[bluebrother]

ist das absicht, dass du immer "Susi" sagst? Schätz mal schon :D
ja. Hab schon vor Jahren aufgehört die Distri zu benutzen weil sie mir zu "zickig" ist und nicht an das rankommt was ich haben will ;-)

das mit make und make load zum rüberspielen stimmt schon oder?
in einem Makefile hast du ein default-target. Normalerweise heißt das "all". Das default-target wird gebaut wenn du make nix mitgibst. D.h. "make" baut das default-target, "make install" das target "install". Die einzelnen targets können voneinander abhängen, müssen aber nicht. "load" wäre also ein Ziel dass dir uisp anwirft, "make load" ruft make auf und lässt ihn das target bauen. Kann ich dir aber so nicht sagen weil ich das noch nie gebraucht hab (und auch grad keine passenden Dateien hier). Im Zweifelsfall kannst du in das Makefile reingucken. Oder das Beispiel fragen ;-)


Ich hatte die version 1.0.5 installiert. Ist das schlimm? Ich kanns auch ändern. Bins ja mittlerweile gewohnt die paar Befehle reinzuklopfen :D
solange wie du keine Probleme damit hast macht das nix. Generell empfiehlt es sich halt die neueste Version zu nehmen weil da i.a. bekannte Bugs gefixed sind. U.u. wirst du irgendwann auf Code stoßen der die neuere libc will weil sich irgendwas geändert hat. Aber dann kannst du das ja immer noch machen :)

Viel Erfolg!

[jagdfalke]

also make schein erfolgreich zu sein:


linux:/home/mathias/avrm8ledtest-0.2 # make
avr-gcc -g -mmcu=atmega8 -Wall -Wstrict-prototypes -Os -mcall-prologues -o avrm8ledtest.out -Wl,-Map,avrm8ledtest.map avrm8ledtest.o
avr-objcopy -R .eeprom -O ihex avrm8ledtest.out avrm8ledtest.hex


make load:

linux:/home/mathias/avrm8ledtest-0.2 # make load
uisp -dlpt=/dev/parport0 --erase -dprog=dapa
An error has occurred during the AVR initialization.
* Target status:
Vendor Code = 0xff, Part Family = 0xff, Part Number = 0xff

Probably the wiring is incorrect or target might be `damaged'.


Dh, dass er den AVR nicht findet oder?

[bluebrother]

linux:/home/mathias/avrm8ledtest-0.2 # make load
uisp -dlpt=/dev/parport0 --erase -dprog=dapa
An error has occurred during the AVR initialization.
* Target status:
Vendor Code = 0xff, Part Family = 0xff, Part Number = 0xff

Probably the wiring is incorrect or target might be `damaged'.


Dh, dass er den AVR nicht findet oder?
Mehr oder weniger: der AVR reagiert nicht richtig, es kommt nur 0xff zurück. Normalerweise muss sich der AVR über die angezeigten Werte identifizieren (damit die Software sicherstellen kann dass der richtige Typ dranhängt).
Jetzt gibts mehrere Möglichkeiten:
- falsches Kabel / Protokoll
- Kabel kaputt
- AVR kaputt / ausgeschaltet.

Da kann ich dir aber nicht wirklich weiterhelfen, ich hatte bisher immer ein JTAG für sowas. Lies mal die manpage von uisp (ich vermute -dprog=dapa passt nicht). Was für ein ISP-Dongle benutzt du?

[jagdfalke]

Ich kann eigentlich alles ausschließen, was die an möglichen Problemen aufgeführt hast:
1. Kabel bei Robotikhardware.de gekauft, genauso wie rnbfra1.0
2. Hab auf ner Windowsmaschine getestet und ich kann mit Bascom programmieren und was wird auch das gemacht, was ich sag.
3. nicht kaputt wegen 2. und auch nicht ausgeschaltet

[bluebrother]

dann bleibt nur noch: falsches Protokoll :)
Was hast du denn unter Windows eingestellt? Siehe hier: http://www.nongnu.org/uisp/faq.html -- ich glaube du brauchst -dprog=stk200 (anstelle von -dprog=dapa) Müsste sich im Makefile recht einfach ändern lassen.

[jagdfalke]

Aha, das wars also. "Protokoll" hat mir wenig gesagt. Unter Bascom hieß das "Programmer".

Die Fehlermeldung hat sich aber nur geändert:

mathias@linux:~/avrm8ledtest-0.2> make load
uisp -dlpt=/dev/parport0 --erase -dprog=stk200
/dev/parport0: Permission denied
Failed to open ppdev.
make: *** [load] Fehler 2


Was ist parport? Was ist ppdev?

[bluebrother]

/dev/parport0 -> LPT1
"Protokoll" war wohl auch ein etwas ungeschickter Begriff von mir -- ISP funktioniert letztendlich über SPI und da ist das Protokoll letztendlich immer gleich, unabhängig vom Programmer. #-o
entweder du sorgst dafür dass user "matthias" auf /dev/parport0 schreiben darf oder du wirst root. Würde ich zum testen so machen, und danach über ne Gruppe lösen.

[jagdfalke]

linux:/home/mathias/avrm8ledtest-0.2 # make load
uisp -dlpt=/dev/parport0 --erase -dprog=stk200
Atmel AVR ATmega32 is found.
Erasing device ...
Reinitializing device
Atmel AVR ATmega32 is found.
uisp -dlpt=/dev/parport0 --upload if=avrm8ledtest.hex -dprog=stk200 -v=3 --hash=32
Reset inactive time (t_reset) 1000 us
AVR Direct Parallel Access succeeded after 0 retries.
Vendor Code: 0x1e
Part Family: 0x95
Part Number: 0x02
Atmel AVR ATmega32 is found.
Page Write Enabled, size=128
FLASH Write Delay (t_wd_flash): 12500 us
EEPROM Write Delay (t_wd_eeprom): 25000 us
Uploading: flash
#####
(total 150 bytes transferred in 0.14 s (1110 bytes/s)
Polling: count = 2, min/avg/max = 4.40/4.57/4.74 ms


Sieht schon besser aus! Na schön, jetzt muss ich nur noch lernen in C zu programmieren. Wo kann ma da am besten Anfangen (Links?) ?

mfg
jagdfalke

[bluebrother]

z.b. hier: http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial und einfach mal hier rumsuchen bzw. googlen. Gibt bzw. gab hier schon genug zu dem Thema.

[alexander_ro]

Hallo,
ich lese schon seit einiger Zeit in diesem Forum mit es gefällt mir sehr gut. Ich habe mir einen Atmega8 organisiert und einen Programieradapter gebaut. Habe aber mit uisp ein Problem deshalb habe ich es mal hier mit eingefügt weils gerade das gleiche Thema ist.

Beim Aufruf "uisp -dlpt=/dev/parport0 --erase -dprog=stk200" bekomme ich die Meldungen
"/dev/parport0: No such file or directory"
"Failed to open ppdev".

parport0 existiert auch wirklich nicht es gäbe /dev/printer gibt aber die gleiche Meldung. Ich verwende Debian Sarge mit einem 2.6 Kernel. Die Kernelmodle parport, parport_pc und ppdev sind geladen.

Hat vielleicht jemand eine Idee? Mir fällt im moment nichts mer ein.

*EDIT*
LÖSUNG: Wenn ich das Modul lp auch mit modprobe lade dann wird das Devfile /dev/parport0 angelegt und das Programmieren funktioniert. Ich verstehe zwar nicht warum es gebraucht wird aber im moment reichts mir wenns funktioniert.
*EDIT*

Güße
Alexander

[jagdfalke]

Hi, ich musste leider mein Linux neu installieren (hab irgendwas mit den Partitionen verbockt). Jetzt will ich wieder avr-gcc installieren, also fängt die ganze Sache von vorne an ](*,)

Der make-Befehl in gcc-core endet in:

make[2]: avr-ar: Kommando nicht gefunden
make[2]: *** [libgcc.a] Fehler 127
make[2]: Leaving directory `/home/mathias/AVRGCC/gcc-4.0.1/obj-avr/gcc'
make[1]: *** [stmp-multilib] Fehler 2
make[1]: Leaving directory `/home/mathias/AVRGCC/gcc-4.0.1/obj-avr/gcc'
make: *** [all-gcc] Fehler 2


Der Fehler ist ja bei den ersten Installation garnicht vorgekommen. Deshalb kann ich auch nicht nachlesen was der Fehler war.

config funktioniert hier:

checking whether to enable maintainer-specific portions of Makefiles... no
checking if symbolic links between directories work... (cached) yes
creating ./config.status
creating Makefile

Kann mir nochmal jemand helfen?

mfg
jagdfalke