- LiFePO4 Speicher Test         
Seite 2 von 6 ErsteErste 1234 ... LetzteLetzte
Ergebnis 11 bis 20 von 53

Thema: brauche Starthilfe

  1. #11
    Erfahrener Benutzer Roboter-Spezialist
    Registriert seit
    22.02.2005
    Beiträge
    385
    Anzeige

    Praxistest und DIY Projekte
    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

  2. #12
    Erfahrener Benutzer Robotik Einstein Avatar von SprinterSB
    Registriert seit
    09.06.2005
    Ort
    An der Saar
    Beiträge
    2.802
    Zitat Zitat von 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.
    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.

    Code:
    #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
    Zitat Zitat von jagdfalke
    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
    Disclaimer: none. Sue me.

  3. #13
    Erfahrener Benutzer Roboter-Spezialist
    Registriert seit
    22.02.2005
    Beiträge
    385
    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.

  4. #14
    Erfahrener Benutzer Robotik Einstein Avatar von SprinterSB
    Registriert seit
    09.06.2005
    Ort
    An der Saar
    Beiträge
    2.802
    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.
    Disclaimer: none. Sue me.

  5. #15
    Erfahrener Benutzer Robotik Einstein Avatar von SprinterSB
    Registriert seit
    09.06.2005
    Ort
    An der Saar
    Beiträge
    2.802
    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.
    Disclaimer: none. Sue me.

  6. #16
    Erfahrener Benutzer Roboter-Spezialist
    Registriert seit
    22.02.2005
    Beiträge
    385
    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

  7. #17
    Erfahrener Benutzer Roboter-Spezialist
    Registriert seit
    05.11.2004
    Ort
    Karlsruhe
    Beiträge
    223
    Ä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?

  8. #18
    Erfahrener Benutzer Roboter-Spezialist
    Registriert seit
    22.02.2005
    Beiträge
    385
    was ist eine toolchain?
    Meinst du nach welcher Anleitung ich die Sources compiliert hab und so? Dann wars hier 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.

  9. #19
    Erfahrener Benutzer Roboter-Spezialist
    Registriert seit
    05.11.2004
    Ort
    Karlsruhe
    Beiträge
    223
    Zitat Zitat von jagdfalke
    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:
    Code:
    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!

  10. #20
    Erfahrener Benutzer Roboter-Spezialist
    Registriert seit
    22.02.2005
    Beiträge
    385
    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?

Seite 2 von 6 ErsteErste 1234 ... LetzteLetzte

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  

LiFePO4 Speicher Test