mikrocontroller.net

Forum: Compiler & IDEs Helpthread zum Wikiartikel AVR Eclipse


Autor: Rainer K. (draugdel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dies ist der Thread, den ich, wenn ich Zeit finde, ansehen und die 
Probleme zu lösen versuchen werde. Dies ist der dazugehörige 
WikiArtikel: http://www.mikrocontroller.net/articles/AVR_Eclipse

Rainer

Autor: Marco B. (avr-knecht)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Forum!

Erst mal ein großes Dankeschön an Rainer für diesen tollen Artikel und 
natürlich an alle, die daran mitgearbeitet haben.

Zu mir: Ich versuche derzeit ein lauffähiges Entwicklungs- und 
Simulationssystem für AVR unter Linux (SUSE 10.2) auf meinem Rechner 
einzurichten. Dazu muss ich sagen, dass ich ein relativer Linux-Neuling 
bin.

Dank des o.g. Artikels habe ich es auch geschafft die Pakete

* Eclipse-IDE
* Eclipse
* Eclipse-CDT-Addon for AVR
* binutils-avr
* gcc-avr
* avr-libc
* simulavr
* gdb-avr
* avrdude (uisp geht bei mir nicht, da vermutlich STK500 Firmware zu 
neu)

zu installieren.

Nach einigem Hin und Her habe ich dann auch das Beispiel aus dem Artikel 
erfolgreich in den AVR laden können. Kurzum, die LED blinkt freu

Leider bin ich bisher an der Konfiguration des Simulators gescheitert. 
Dazu folgendes:

Wenn ich simulavr und avr-gdb manuell starte und meine AVR_MAIN.elf lade 
und starte scheint der Simulator fehlerfrei zu arbeiten.
In der Kombination simulavr + Ansteuerung über Eclipse funktioniert das 
ganze nicht (Simulation startet, arbeitet aber nicht vernünftig).
Hier der Befehle von Eclipse an den AVR-GDB und die zugehörigen 
Rückmeldungen des AVR-GDB, der anscheinend nicht richtig funktioniert:


(gdb)
12 info threads
&"info threads\n"
&"warning: RMT ERROR : failed to get remote thread list.\n"
12^done


Im Disassembler-Fenster von Eclipse erscheint folgendes (Auszug):

    // PortD6 als Output konfigurieren
    DDRD |= _BV(PD6);
0x000000f8 <main+8>:  .word 0xffff  ; ????
0x000000fa <main+10>: .word 0xffff  ; ????
0x000000fc <main+12>: .word 0xffff  ; ????
0x000000fe <main+14>: .word 0xffff  ; ????
0x00000100 <main+16>: .word 0xffff  ; ????
0x00000102 <main+18>: .word 0xffff  ; ????
0x00000104 <main+20>: .word 0xffff  ; ????

Anscheinend werden irgendwie die Maschinensprachen Befehle nicht richtig 
an den simulavr übergeben, denn in einer Konsole meckert auch er:

Waiting on port 1212 for gdb client to connect...
Connection opened by host 127.0.0.1, port 19723.
decoder.h:59: WARNING: Unknown opcode: 0xffff
decoder.h:59: WARNING: Unknown opcode: 0xffff
decoder.h:59: WARNING: Unknown opcode: 0xffff
decoder.h:59: WARNING: Unknown opcode: 0xffff
decoder.h:59: WARNING: Unknown opcode: 0xffff


usw...

Hat jemand von euch eine Idee, wo ich weitersuchen muss, um dass in den 
Griff zu bekommen?

Danke schonmal für alle Anregungen und Tipps!

Gruß

Marco

Autor: Rainer K. (draugdel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Probier das mal:

Erstelle eine Datei "init" im Unterordner Standard des Projekts, wo auch 
die .elf-Datei liegt. Der Ordner wäre eigentlich egal, allerdings hast 
du so jeweils den Bezug zum jeweiligen Projekt. In der Datei muss 
folgendes stehen:
file Standard/LCD-Test.elf
targ rem :1212
load


Standard/LCD-Test.elf ist der Pfad vom Projektordner zur .elf-Datei, 
wird bei dir also vermutlich anders heißen. Diese Datei musst du dann in 
Eclipse bei den Run/Debug-Settings bei der jeweiligen "Launch 
configuration" unter dem Reiter Debugger als "GDB command file" angeben. 
Jetzt sollte eigentlich das Debuggen (und das Disassembly-Fenster) mit 
dem Simulator funktionieren. Falls es geht, schreib bitte eine 
Bestätigung, dann füge ich das ganze ins Wiki ein.

Mfg Rainer

PS: Ich habe den Simulator so aufgerufen:
simulavr -g -p 1212 -d atmega128 -P simulavr-disp

Autor: Marco B. (avr-knecht)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Rainer,

das wars dann wohl. Nach Anlegen der Textdatei und deren Angabe in den 
Debug-Settings funktioniert jetzt das ganze. Danke nochmal.

Noch eine andere Baustelle:

Die von Dir in den Build-Steps angegebene "AVR_UPLOAD" Datei für 
POST-Build und das "uisp -dprog=dasa2 -dserial=/dev/ttyS0 
-dpart=atmega16 --erase" (oder analoger Befehl für avr-dude) für 
PRE-Build macht ja nur Sinn, wenn tatsächlich ein AVR geflascht werden 
soll. Zum "trockenen" Simulieren brauche ich das zunächst nicht.
Deshalb möchte ich den eigentlichen Lösch/ Programmiervorgang vom Build 
loslösen.
Einen entsprechenden Button "AVR Download" habe ich in Eclipse ja auch 
in der Menüleiste, nur leider liegt dort ein Befehl für ein 
Windows-System (c:\winavr\bin\avrdude.exe......) hinter. Ich vermute 
mal, das ganze wird in dem "Eclipse-CDT-Addon for AVR" definiert sein. 
Hast Du eine Ahnung, wo man das entsprechend Anpassen/Einstellen kann?

Und noch einen, weil ich ja doch ein wenig schreibfaul bin: Gibt es 
vielleicht eine einfache Möglichkeit den simulavr beim Debug-Start 
automatisch mitstarten zu lassen?


Gruß

Marco

Autor: Rainer K. (draugdel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Marco B. wrote:
> Die von Dir in den Build-Steps angegebene "AVR_UPLOAD" Datei für
> POST-Build und das "uisp -dprog=dasa2 -dserial=/dev/ttyS0
> -dpart=atmega16 --erase" (oder analoger Befehl für avr-dude) für
> PRE-Build macht ja nur Sinn, wenn tatsächlich ein AVR geflascht werden
> soll. Zum "trockenen" Simulieren brauche ich das zunächst nicht.
> Deshalb möchte ich den eigentlichen Lösch/ Programmiervorgang vom Build
> loslösen.

Nimmst du die Variante 1 oder Variante 2 aus dem Wiki? Ich nehme 
persönlich die erste Variante, wo eben bei einem Build der AVR nicht 
verändert wird. Stattdessen wird da danach mit "AVR Download" geflasht.

> Einen entsprechenden Button "AVR Download" habe ich in Eclipse ja auch
> in der Menüleiste, nur leider liegt dort ein Befehl für ein
> Windows-System (c:\winavr\bin\avrdude.exe......) hinter. Ich vermute
> mal, das ganze wird in dem "Eclipse-CDT-Addon for AVR" definiert sein.
> Hast Du eine Ahnung, wo man das entsprechend Anpassen/Einstellen kann?

Siehe http://www.mikrocontroller.net/articles/AVR_Eclips...
 Einstellungen

Jetzt müssen noch gewisse Einstellungen in Eclipse angepasst werden: Unter Window->Preferences->AVRDUDE Preferences:

    * AVRDUDE executable: /usr/bin/avrdude
    * Programmer auswählen
    * Programmerport auswählen
    * Target MCU Type auswählen 

> Und noch einen, weil ich ja doch ein wenig schreibfaul bin: Gibt es
> vielleicht eine einfache Möglichkeit den simulavr beim Debug-Start
> automatisch mitstarten zu lassen?

Kenne ich leider nicht, allerdings ist es eh nicht so schlimm, den 
Simulator manuell zu starten, weil man das ja eh nur einmal pro 
Arbeitssession machen muss und dann der Simulator immer läuft. ;) 
Alternativ könntest du dir ein sehr einfaches Shellskript schreiben, was 
sowohl Eclipse als auch simulavr startet. Ich würde allerdings einfach 
ein Terminal für den Simulator reservieren, und diesen mittels History 
(strg-r) starten.

Mfg Rainer

Autor: Marco B. (avr-knecht)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, jetzt funktioniert soweit alles.

Zum Build:

Hier nehme ich jetzt folgendes Script, ob dabei die EEPROM.hex richtig 
erstellt wird, weiss ich noch nicht. Muss ich mal einen kleinen 
Quellcode zu erstellen. Da ich noch nicht so ganz Sattelfest im 
AVR-programmieren bin ist hier erstmal ein wenig basteln angesagt....

> #!/bin/sh
> # .lst-Datei erzeugen (optional)
> avr-objdump -h -S avr_main.elf > avr.lst
> # Datei in Intel-hex für Flash erzeugen
> avr-objcopy -j .text -j .data -O ihex avr_main.elf flash.hex
> # Datei in Intel-hex für EEProm erzeugen
> avr-objcopy -j .eeprom -O ihex avr_main.elf eeprom.hex

Die von dir angebotene AVR-OBJSPLIT funktioniert bei mir nicht 
fehlerfrei, keine Ahnung ob das ein SUSE eigenes Problem ist.

Zum AVR-Download:

Wer lesen kann ist klar im Vorteil :-) Läuft jetzt ebenfalls. Allerdungs 
mußte ich die Verify-Funktion abschalten, da es hier zu Fehlermeldungen 
gekommen ist. Vermutlich ein Timing-Problem wegen meinem USB - RS232 
Wandler. Ohne Veryfiy alles OK.

Zum Simulieren:

Hier habe ich ein kleines Script generiert:

> #!/bin/sh
> # simulavr starten
> simulavr -g -p 1212 -d atmega16 -P simulavr-disp

Somit kann ich den Simulavr bequem mit einem Mausklick starten und dann 
in Eclipse mit "Debug" sofort loslegen. Läuft problemlos.

Jetzt muss ich nur noch rauskriegen, wie ich bequem an die AVR-Fuses 
rankomme. Ich werde mal ein wenig in den nächsten Tagen pfriemeln und 
dann vielleicht nochmal die Hilfe hier in Anspruch nehmen (müssen).


@Rainer

Erstmal danke für die Tipps, sollten wir uns mal zufälligerweise 
irgendwo begegnen, dann gebe ich Dir einen 
Kafee/Tee/Wasser/Bier/Cola.... oder was ähnliches aus :-)


Gruß

Marco

Autor: Immanuel Nekvasil (sputnik)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo

Ich bemühe mich zur Zeit auch gerade unter Linux eine 
Entwicklungsumgebung für AVR hinzukriegen. Ich nutze die Distri Fedora 
und bin noch nicht sehr erfahren.

Also ich habe, so denke ich, alles eingestellt wie man sollte (natürlich 
kann ich mich au irren). Ich habe mit dem Shell-Scrpt avr-objsplit ein 
Problem. Der rest vornherein deim Build-Prozess funzt schön.

Hier einmal der Output in der Console zum Problem:
------------------------------------------------------------------------ 
-----
Building target: avr_plugin_test.elf
Invoking: Linker
avr-gcc -L/usr/avr/lib -Wl,-Map,.map -mmcu=atmega16 
-o"avr_plugin_test.elf"  ./StarField.obj ./delay.obj ./lcd.obj ./led.obj 
./user_int.obj
Finished building target: avr_plugin_test.elf

make --no-print-directory post-build
Invoking: Object to Hex Splitter
avr-objsplit
make[1]: execvp: avr-objsplit: Keine Berechtigung

make[1]: [post-build] Fehler 127 (ignoriert)
------------------------------------------------------------------------ 
-----

Also die *.elf hat er noch prav erzeugt. Es schein ein 
Berechtigungsproblem zu sein. Das Script avr-objsplit liegt unter 
/usr/bin/.

Ich hoffe Du kannst mir helfen.

PS an alle die von Windows kommen:
Wenn man einen include hat, zb so:
#include <avr\io.h>
Dann funzt das unter Linux nicht weil man das so schreiben muss:
#include <avr/io.h>
Ist grunsätzlich sicher jedem klar, aber man kann es schnell mal 
vergessen, wenn man einfach schnell ein altes Project, welches unter 
Windows geschrieben wurde wieder mal compilieren und auf den Controller 
spitzen will. Also nicht grün und blau ärgern wenn er die Header-Files 
nicht findet ;-)

mfg
Sputnik

Autor: Rainer K. (draugdel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!
make[1]: execvp: avr-objsplit: Keine Berechtigung

Hast du schon die Berechtigungen deines Users auf das Script überprüft?
(mittels
ls -la avr-objsplit
)

Stell mir bitte mal den Output davon hier herein.

Lg Rainer

Autor: Immanuel Nekvasil (sputnik)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hau mir eine rein! So unerfahren bin ich jetzt nun auch wieder nicht. 
Naja, war heute morgen schon ein wenig früh.

Also nicht mal als rout durfte ich das Script ausführen. Ich habe dann 
mittels my Best-Friend chmod mir meine Berechtigungen erteilt und funzt 
jetzt prima.

Tut mir leid für die ungebührliche Störung!

mfg
Sputnik

PS: Auch wenn ich ein Idiot bin, könnte man das mit den 
Ausführungsrechten in die Anleitung einbezihen, villeicht ist ja 
wirklich mal ein kompletter Neuling am Werk.

Autor: Benedikt Bauer (mastacheata)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Ich habe Variante 1 ausprobiert, allerdings scheitere ich daran ein 
neues Projekt anzulegen. Das dafür nötige Plugin wird gar nicht geladen.
Das avrdude Plugin hingegen wird geladen. Ich gehe davon aus das dieses 
dann auch funktioniert.
Irgendjemand eine Idee wie ich Eclipse dazu überrede das entsprechende 
Plugin zu laden und wo ich nachlesen kann welche Plugins gerade geladen 
sind?
Also ich zweifle das ich bei der Installation irgendwas falsch gemacht 
habe.
Ich habe die beiden org.irgendwas verzeichnisse nach 
/usr/lib/eclipse/plugins gepackt. (Eclipse habe ich aus den Paketquellen 
meines Ubuntu 7.10 Systems installiert, daher liegt das plugins 
Verzeichnis nicht unterhalb eines eclipse hauptverzeichnis)
Mehr war doch nicht zu tun um ein Eclipse Plugin zu installieren, oder?

Autor: Rainer K. (draugdel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Unter Help:About Eclipse Platform:Plugin Details findest du eine Liste 
mit allen aktivierten Plugins. Da sollte sowohl das "AVR Dude"- als auch 
das "AVR Cross Target"-Plugin zu finden sein.

Welche Version von Eclipse ist momentan in den Repositories? Wenn es 
nicht mindestens die Version (3.3.0, die verwende ich) ist, kann es 
sein, dass die Plugins nicht kompatibel sind.

Autor: Benedikt Bauer (mastacheata)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ahh dann ist wohl klar woran es liegt.
In den Paketquellen von Gutsy ist noch die Version 3.2.2 aktuell.
Werde das dann später mal mit der aktuelleren Version versuchen.

Autor: Benedikt Bauer (mastacheata)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
In Ermangelung einer Bearbeitungsfunktion für den vorigen Beitrag hier 
ein Doppelpost:
Mit der neuen 3.3er Version funktioniert alles bestens vielen Dank für 
den Hinweis.
Wird langsam mal Zeit das Ubuntu die 3.3er in die Paketquellen aufnimmt. 
Ich hatte damit ja eigentlich schon "damals" zur Veröffentlichung von 
7.10 gerechnet.

Autor: Robert D. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

von mir auch erstmal ein großes Dankeschön für den sehr hilfreichen 
Artikel. Es hat auch fast alles geklappt. Fast, weil ich wirklich das 
z.Z. neueste AVR-Eclipse-plugin (Version 2.0.1 von 2007-12-29) und 
nicht wie angegeben Version 20070813 heruntergeladen habe. Ab Version 
2.0.0 wurde das Plugin komplett neu überarbeitet. Nach kopieren in den 
Eclipse-Pluign-Ordner war auch kein AVRDUDE-Eintrag zum konfigurieren 
da. Nachdem ich dann die im Artikel angegebene Version genommen habe, 
ging es. Hab mich wohl von "...das neueste Plugin..." irreführen lassen. 
(Obwohl man ja eigentlich immer zur neuesten Version tendiert)
Da ich aber auch erst Anfänger in Sachen Linux und speziell in 
uC-Programmierung unter Linux bin, hab ich auch nicht herausgefunden, 
wie man es mit den neuen Versionen zum laufen bekommt.

Viele Grüße,
Robert

Autor: Rainer K. (draugdel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ah, danke. Ich werde mir die Unterschiede mit der neuen Version bei 
Gelegenheit anschauen und dann den Artikel entsprechend anpassen. 
Allerdings ist es momentan ziemlich stressig, kann also etwas dauern.

Rainer

Autor: E. M a t t h i a s (hias)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Ich habe ein kleines Problem mit dieser avr-objsplit.bat:
Verwende ich die Datei aus dem Plugin Ordner, dann bekomme ich folgende 
Ausgabe:
make --no-print-directory post-build
Invoking: Object to Hex Splitter
avr-objsplit.bat
/usr/bin/avr-objsplit.bat: 1: @avr-objcopy: not found
/usr/bin/avr-objsplit.bat: 2: @avr-objcopy: not found
/usr/bin/avr-objsplit.bat: 3: @if: not found
make[1]: [post-build] Error 127 (ignored)

Modifiziere ich die Datei wie im Wiki, dann schaut das ganze so aus:
make --no-print-directory post-build
Invoking: Object to Hex Splitter
avr-objsplit.bat
make[1]: avr-objsplit.bat: Command not found
make[1]: [post-build] Error 127 (ignored))

Die beiden Dateien liegen im /usr/bin/-Ordner und haben 
executable-Rechte.

Ich bin in der Linux-Shell-Programmierung nicht fit genug um da 
Feinheiten zu erkennen.

Woran könnte der Fehler liegen?

Danke
Matthias Eder

Autor: Thomas Holland (innot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe diesen Thread zufällig gesehen. Ich habe die Entwicklung des 
AVR Eclipse Plugins übernommen und bin für die Versionen ab 2.0 
verantwortlich.

@Robert D.:
Ja, dem neuen Plugin (2.0.1) fehlt im Moment noch die avrdude 
Unterstützung. Hatte ich etwas hinten angestellt, weil ich selbst noch 
gar keine Hardware besitze um avrdude zu nutzen (arbeite derzeit nur mit 
Simulationen). Aufgrund der hohen Nachfrage hat avrdude support 
inzwischen die Priorität 1 und wird in der nächsten Version (2.1) wohl 
wieder kommen (allerdings etwas integrierter und eleganter als in der 
alten Version 20070813).

Allerdings funktioniert das alte org.mrm.avrdude plugin auch weiterhin 
und kann auch benutzt werden.

@Matthias:
Versuchs doch mal mit der neueren Version (2.0.1) des Plugins, dann 
brauchst Du avr-objsplit nicht mehr, da die flash und eeprom Dateien 
direkt erzeugt werden.

brgds

Thomas

Autor: Pascal S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hi zusammen!

ich habe wohl ein ähnliches Problem wie Marco B:
starte ich den simulator, und lade dann das programm manuell via 
gdb-avr, kann ich problemlos in eclipse debuggen. wenn ich allerdings 
nicht via gdb-avr das file lade, klappts nicht (variabeln haben falsche 
werte etc).

ich habe das gdbinit file im Standard unterordner des projekts erstellt 
und in eclipse mit absolutem oder relativem pfad angegeben, jedoch 
scheint das keine auswirkung zu haben. das gdbinit file scheint 
fehlerfrei zu sein, da gdb-avr es automatisch ausführt, sobald ich es in 
einem ordner mit .gdbinit aufrufe.

es wäre kein grosses problem, müsste ich nicht nach jeder 
programmänderung das elf file mit gdb-avr manuell neu laden...

Autor: Rainer K. (draugdel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Ich bin momentan im Klausurstress und hab deswegen momentan keine Zeit 
mir das anzuschauen.

@ Mathias: Funktioniert es mittlerweile mit der neuen Version?

@ Pascal: Welche Version vom Plugin benützt du? Wie schaut der genaue 
Fehler aus? Gibt es eine Meldung in der Console? Wo liegen alle Dateien?

Ich werde mir das ganze anschauen, sobald ich wieder Zeit habe.

Rainer

Autor: E. M a t t h i a s (hias)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Auch ich hab Stress mit anstehenden Klausuren. :)
Ich hab zwischenzeitlich die neue Version getestet, ein flash.hex kann 
ich mir erzeugen lassen. Allerdings schreibt er noch kein (dummy)eeprom 
File. In einem anderen Thread hab ich aber schon einen Tipp bekommen wie 
das funktioniert. Schöner wäre allerdings, dass avrdude gar nicht 
versucht das eeprom file zu schreiben, aber dass funktioniert 
anscheindend mit dem alten (avrdude)Plugin nicht.

Matthias

Autor: Pascal S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich benutze noch Version 20070813, da die neueren nicht mit Eclipse 
3.2.2 funktionieren.
Es gibt keine Fehlermeldung im eigentlichen Sinne, in der Console sieht 
man, wie eclipse bzw gdb die Werte der Variabeln abfragt, und dann als 
antwort 0 erhält. es scheint als würde das programm nicht richtig auf 
den simulavr geladen.

die quelldateien liegen im projektorder, und die .elf und .hex files 
liegen im unterordner Standard, wo ich auch die .gdbinit abgelegt habe 
(habe sie aber auch schon im projektordner gespeichert, ohne erfolg)

Autor: shell (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

ich habe hier ein sehr merkwürdiges Problems. Ich muss dazu sagen, ich 
bin ein fast blutiger Anfänger bei der c programmierung. Für eine 
Mikrokontroller / Roboter Programmierung muss ich eigene Librarys 
einbinden.
Das klappt so weit auch ganz gut und bis zum kompilieren erhalte ich 
keinen Fehler.
Mein Eclipse läuft unter gentoo.
Hier zuerst einmal mein Testprogramm:
#include "RP6RobotBaseLib.h"
int main(void)
{
      initRobotBase();
      //writeString("Hallo Welt!\n");
      return 0;
}

So weit klappt das ganz gut. Die includes stehen im Projectexplorer auch 
ordentlich drin. Sobald ich aber kompiliere erhalte ich folgende 
Fehlermeldung:
**** Build of configuration Release for project bot6 ****

make all 
Building target: bot6.elf
Invoking: AVR C Linker
avr-gcc -Wl,-Map,bot6.map -L/home/hellmann/files/rp6libs -mmcu=atmega32 -o"bot6.elf"  ./hw6.o   
./hw6.o: In function `main':
hw6.c:(.text+0x0): undefined reference to `initRobotBase'
make: *** [bot6.elf] Fehler 1

Autor: Thomas Holland (innot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo shell,

ich bin nicht der große Linker Experte, aber es sieht so aus, dass Du 
zwar den Pfad zu den Libraries eingestellt hast 
("-L/home/hellmann/..."), aber vergessen hast den Namen der Library 
anzugeben (es fehlt ein "-lxxxxx" im output).

Schau doch mal nach, ob bei den Project Properties unter C/C++ Build -> 
Settings -> Tool settings -> AVR C Linker -> Libraries im oberen 
Eingabefeld ("Libraries (-l)") die RP6RobotBaseLib steht (ohne "lib" am 
anfang und ohne ".a" am ende).

LG

Thomas

Autor: shell (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Thomas,

ich glaube das ist schon die richtige Richtung. Klappt aber leider nocht 
nicht. Er sagt dann:

cannot find -lRP6RobotBaseLib

Wie gesagt, bin da absoluter Neuling und verstehe mal wieder null was er 
da will.

Autor: shell (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Anbei noch ein makefile mit dem es unter Windows und dem Programmers 
Notepad problemlos klappt.

Autor: Thomas Holland (innot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nein, es ist nicht die richtige Richtung.

Die RP6Lib nennt sich zwar Library, wird aber von Deinem Makefile nicht 
als Library benutzt sondern direkt eingebunden.

Du musst also die RP6 Dateien mit in Dein Projekt aufnehmen. Ist nicht 
ganz trivial, aber ich habe es gerade geschafft ein entsprechendes RP6 
Projekt anzulegen und erfolgreich zu compilieren.

Leider bockt Eclipse gerade bei dem Versuch das Projekt zu exportieren, 
damit ich es Dir als Beispiel anhängen kann. Ich habe heute leider auch 
keine Zeit mehr das Problem zu lösen und muss Dich daher auf Morgen 
vertrösten.

Thomas

Autor: shell (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Prima, immerhin gibt es jetzt anscheinend einen Lösungsweg. Da kann ich 
auch ruhig noch einen Tag warten.

Autor: Thomas Holland (innot)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
So, jetzt habe ich es geschaft, das Project anständig zu exportieren.

Also:
- Angehängtes zip file downloaden
- in Eclipse "File -> Import... -> General -> Existing Projects into 
Workspace" auswählen
- Im Import Dialog "Select archive file" selektieren und RP6Project.zip 
auswählen
- "Finish"

In dem Projekt sind nur zwei Besonderheiten:

1. Bei den Project Properties sind unter "C/C++ Build -> Settings -> 
Tool settings -> AVR Compiler -> Directories" die Pfade zu der RP6Lib 
aufgenommen.

2. Die beiden Dateien "RP6Lib/RP6common/RP6I2CmasterTWI.c" und "xxx.h" 
sind vom Build ausgenommen ("Exclude from build..."), entsprechend 
Deines makefiles und da man nur entweder slave oder master benutzen 
kann.

Der Rest des Projektes ist trivial und entspricht einem frischen AVR 
Projekt ohne Modifikationen.

Viel Spaß beim Programmieren deines RP6.

LG

Thomas

Autor: shell (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wow, funktionierte sofort auf Anhieb. Erst mal vielen Dank. Vielleicht 
kommt aber trotzdem noch die ein oder andere Frage.

Autor: Moritz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist es eigentlich ein Problem für die diversen beteiligten Tools, sowohl 
\ als auch / als Verzeichnis-trenner zu lesen? z.b.:

#include <...> search starts here:
 c:\winavr\bin\../lib/gcc/avr/4.3.0/include
 c:\winavr\bin\../lib/gcc/avr/4.3.0/include-fixed
 c:/winavr/lib/gcc/../../lib/gcc/avr/4.3.0/include
 c:/winavr/lib/gcc/../../lib/gcc/avr/4.3.0/include-fixed
 c:/winavr/lib/gcc/../../avr/include

Auszug aus Eclipse-Console bei build. Ebenso sind beide gemixt in der 
Systemvariablen-Ansicht des Projekts.

Es gibt keine Fehler aber es macht mich schon skeptisch.

Das Ganze unter Xp SP3, Eclipse Ganymede 3.4.1, CDT 5.0.1, Avr-Plung 
2.2.0

Autor: Thomas Holland (innot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Moritz,

sieht zwar komisch aus, ist aber so :-)

Nein - ist kein Problem. Backslash und forward slash lassen sich bei 
Windows schon seit langem mischen, zumindest so lange man nicht über die 
Shell (cmd.exe) geht.

Die paar Zeilen, die Du da ausgeschnitten hast, stammen übrigens nicht 
vom Plugin sondern werden so vom avr-gcc ausgegeben. D.H. nicht nur das 
Plugin, sondern auch avr-gcc selbst benutzt bei Varianten nach belieben.

Thomas

Autor: Jonathan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Ich habe folgendes Problem mit AVR-Eclipse Plugin:

Seit kurzem hört das Buildkommando nach dem Aufruf des AVR C Linkers 
auf, ohne jedoch einen Fehler anzuzeigen. Die letzte Zeile, die aich 
also auf der Konsole sehe, ist "Finished building target: Firmware.elf". 
Die zusätzlichen Kommandos (AVR Create Flash Image, AVR Create EEPROM 
Image, Print Size) werden nicht mehr aufgerufen, obwohl sie in den 
Projekteinstellungen unter C/C++ Build/Settings für alle Build 
Konfigurationen aktiviert sind. Leider kann ich nicht mehr sagen ob und 
was ich an den Einstellungen geändert habe, bevor das Problem auftrat.

Ich habe schon versucht, das Problem nachzuverfolgen, allerdings kenne 
ich mich zu wenig mit make und den Build-Mechanismen von Eclipse aus. So 
viel habe ich herausgefunden: Im automatisch erzeugten Makefile ist das 
all-Target so definiert:

# All Target
all: Firmware.elf secondary-outputs

Und secondary-outputs so:

secondary-outputs: $(LSS) $(FLASH_IMAGE) $(EEPROM_IMAGE) $(SIZEDUMMY)

secondary-outputs wird offensichtlich bei mir nicht aufgerufen bzw. tut 
nichts. Blos wo werden $(LSS) $(FLASH_IMAGE) $(EEPROM_IMAGE) und 
$(SIZEDUMMY) festgelegt? Weiter oben im Makefile wird eine Datei 
../makefile.defs eingebunden. Müssten diese Variablen dort definiert 
sein? Die Datei kann ich nicht finden. Vielleicht wird sie aber auch nur 
temporär erzeugt und dann wieder gelöscht...

Wenn jemand sich da besser auskennt und mir helfen kann, wäre ich sehr 
dankbar.

Ich habe bis gerade eben Version 2.3.0 BETA1 des Plugins benutzt, bin 
nun aber auf 2.3.1 umgestiegen, was das Problem aber nicht behoben hat.

Viele Grüße,
Jonathan

Autor: Thomas Holland (innot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Jonathan,

ich habe die Frage jetzt auf SourceForge beantwortet, aber der 
Vollständigkeithalber hier auch noch mal der Link mit der 
(wahrscheinlichen) Lösung Deines Probelems: 
http://avr-eclipse.sourceforge.net/wiki/index.php/...

Thomas

Autor: Jakob (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo, liebe Forumsbesucher,

ich habe ein kleines Problem:
Mein Eclipse erstellt kein HEX-File. Ich habe in den Properties 
eingestellt: GENERATE HEX FILE

aber es wird nicht erstellt. Ich bekomme aber beim builden keine 
Fehlermeldung. Die ausgabe ist lediglich:


**** Build of configuration Release for project Test 1 ****

make
make: Nothing to be done for `Quelltext/main.d'.

Ich probiere schon seit Wochen, mein Eclipse zum Laufen zu bringen. Was 
könnte der Fehler sein?

Schonmal Danke für die Hilfe.

Autor: Thomas Holland (innot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Jakob,

ist etwas schwer mit so wenig Informationen ein troubleshooting zu 
betreiben.

Zuerst einmal:
Ziel des Build Prozesses ist eine '*.elf' Datei. Wenn die nicht erzeugt 
wird dann gibt es auch keine .hex datei.

Aber so wie es aussieht baut Eclipse bei Dir überhaupt nichts.

Was ist 'Quelltext/main.d' für eine Datei? '.d' Dateien sind automatisch 
erzeuge dependency files, die aber nie von dem von Eclipse erzeugenten 
makefile als Target verwendet werden.

Normalerweise sollte der output ungefähr so aussehen:
**** Build of configuration Release for project Test 1 ****

make all 
Building file: ../Quelltext/main.c
Invoking: AVR Compiler
...

Ich vermute mal, dass Du Dein Projekt bei der Fehlersuche ziemlich 
zerkonfiguriert hast. Erstelle doch mal ein neues Projekt, kopier die 
sourcen dahin und poste dann den output noch bevor Du irgendwas an der 
Konfiguration änderst.

Wenn das immer noch nicht klappt, dann packe das ganze 
Projektverzeichnis in ein ZIP und poste es auch noch, damit ich mal am 
"lebenden Objekt" die Fehlersuche betreiben kann.

Thomas

Autor: Christoph P. (sirbundy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!
Ich bin seit gestern damit beschäftigt, Eclipse unter Ubuntu 
einzurichten und möglichst alle erdenklichen AVR-Funktionalitäten mit 
einzubinden. Hat bis jetzt auch soweit ganz gut geklappt. 
C-Programmieren geht, Flashen mit avrdude geht usw. Beim Debuggen und 
Simulieren wirds jetzt aber langsam holprig. Den avr-gdb Debugger habe 
ich allen Anscheins nach in eclipse zum Laufen gebracht. Die Tatsache, 
dass ich auf dem Pollin Eval-Board mit dem seriellen ISP arbeite 
(Ponyser) lässt einen on chip-Test natürlich nicht zu. Mit simulavr 
komme ich aber bis jetzt noch gar nicht klar. Die Einbindung als 
Debugger habe ich "frei schnautze" gemacht. Heißt:

Debugger: gdbserver debugger
GDB debugger: /usr/bin/simulavr
GDB command file: Release/link.elf (file Release/Test.elf; targ rem 
:1212; load)
verbose console mode
Connection: TCP, localhost, 1212

Fehlermeldung:
Error creating session
Process Terminated
  Process Terminated
  Process Terminated

Mit den Hinweisen am Anfang des Threads zum ähnlichen Thema bin ich 
nicht wirklich weitergekommen und Mr. Google hat auch nicht geholfen.
Habe gehofft, es ähnlich wie im AVRStudio simulieren zu können. Und mit 
der Konsole bin ich bei simulavr auch nicht richtig schlau geworden. Ja, 
lange Rede kurzer Sinn.
Danke schon mal für Tipps und Anregungen!

Autor: Thomas Holland (innot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christoph, hast Du schon die Anleitung unter 
http://avr-eclipse.sourceforge.net/wiki/index.php/... 
ausprobiert?

Damit hat es zumindest bei mir funktioniert (ich habe allerdings auch 
den Artikel geschrieben).

Thomas

Autor: Christoph P. (sirbundy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, das scheint soweit geklappt zu haben. So schön komfortabel wie im 
AVRStudio ist das zwar nicht, aber gut. Interessanter ist ja am Ende 
doch das On chip debugging.
Vielen Dank auf jedenfall! Es funktioniert erstmal :)

Autor: Benny (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
Ich sitze schon seit Tagen daran es hinzubekommen eine Sourcedatai in 
Eclipse mit Simulavr zu simulieren. Mal so ne Frage: Funktioniert es bei 
noch jemand anderen?

Mein Problem ist dass der Debugger keinen Disassembler und keinen Memory 
anzeigt. Simulavr startet wunderbar und das GDB stellt eine Verbindung 
her und startet auch den Debugger aber gleich danach wird mir undefined 
optcode 0xFFFFFFFF angezeigt...

Kann mir jemand helfen?
Benny

Autor: Benny (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sorry habs grad irgendwie hinbekommen....
Anscheinend muss man die .elf Datei noch über ein Command file für das 
gdb explizit einbinden sonst funktioniert es nicht. Doch jetzt ist ein 
weiteres Problem aufgetreten: Ich kann mir leider nicht den Speicherort 
bzw allgemein den Ram anzeigen lassen. Memory zeigts wunderbar an. Ist 
das jetzt normal so oder ist bei mir immernoch etwas nicht in ordnung?
Benny

Autor: Micha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich schreibe gerade ein Programm für einen Atmega8u2 mit Eclipse. Dabei 
würde ich gern auf einen Debugger zurückgreifen (mittels AVR JTAGICE 
mkii). AVARice bietet jedoch keine Unterstützung für Atmega8u2, nicht 
ein mal für Atmega8... . Gibt es hierfür schon einen Lösungsansatz? Ich 
habe ebenfalls nichts im Netz gefunden.

Aus den Bildern im Tutorial sieht man, dass das dortige Programm wohl 
für einen Atmega8 bestimmt war (Target -> Atmega8). Beim Start von 
AVARice wird jedoch ein Atmega128 als Platform angegeben. Könnte man 
dadurch AVARice "austricksen" und trotzdem debuggen?

Micha

Autor: Stephan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute, hab mal ne Frage zur Dateigröße der Hex-Datei. Hab mein 
Eclipse so eingerichtet wie im Artikel. Wenn ich ein Programm schreibe 
und es compliliere, dann bekomme ich eine hex-Datei mit 18,4kB. Schreib 
ich sie mit dem Programmers-Notepad und compiliere sie, dann hab ich nur 
10,5kB! An was liegt das, das die Dateigröße so unterschiedlich ist? Es 
wäre ja dann total uneffektiv die Datei mit Eclipse zu erzeugen!?

Danke und Grüße

Autor: Mitleser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stephan schrieb:
> Wenn ich ein Programm schreibe
> und es compliliere, dann bekomme ich eine hex-Datei mit 18,4kB. Schreib
> ich sie mit dem Programmers-Notepad und compiliere sie, dann hab ich nur
> 10,5kB! An was liegt das, das die Dateigröße so unterschiedlich ist?

Der Knackpunkt wird der Compiler, oder dessen Aufruf (Parameter) sein 
...

Autor: Markus J. (markusj)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Ursache dafür dürften verschiedene Optimierungseinstellungen sein. 
Außerdem läuft ein neues AVR-Eclipse-Projekt ganz gerne Mal mit der 
Konfiguration "Debug" als Standardeinstellung, damit ist die Optimierung 
normalerweise deaktiviert.

Sieh dir Mal die aktivierten Compilerschalter im Makefile an und 
vergleiche sie mit der Build-Konfiguration deines Eclipse-Projektes.

mfG
Markus

Autor: Stephan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also Debug hab ich aus der Konfiguration draußen, an dem liegts nicht!
Mein automatisch generiertes makefile sieht so aus, wo finde ich da die 
Schalter?
################################################################################
# Automatically-generated file. Do not edit!
################################################################################

-include ../makefile.init

RM := rm -rf

# All of the sources participating in the build are defined here
-include sources.mk
-include subdir.mk
-include objects.mk

ifneq ($(MAKECMDGOALS),clean)
ifneq ($(strip $(C_DEPS)),)
-include $(C_DEPS)
endif
ifneq ($(strip $(ASM_DEPS)),)
-include $(ASM_DEPS)
endif
ifneq ($(strip $(S_DEPS)),)
-include $(S_DEPS)
endif
ifneq ($(strip $(S_UPPER_DEPS)),)
-include $(S_UPPER_DEPS)
endif
endif

-include ../makefile.defs

# Add inputs and outputs from these tool invocations to the build variables 
LSS += \
Asuro.lss \

FLASH_IMAGE += \
Asuro.hex \

EEPROM_IMAGE += \
Asuro.eep \

SIZEDUMMY += \
sizedummy \


# All Target
all: Asuro.elf secondary-outputs

# Tool invocations
Asuro.elf: $(OBJS) $(USER_OBJS)
  @echo 'Building target: $@'
  @echo 'Invoking: AVR C Linker'
  avr-gcc -Wl,-Map,Asuro.map -mmcu=atmega8 -o"Asuro.elf" $(OBJS) $(USER_OBJS) $(LIBS)
  @echo 'Finished building target: $@'
  @echo ' '

Asuro.lss: Asuro.elf
  @echo 'Invoking: AVR Create Extended Listing'
  -avr-objdump -h -S Asuro.elf  >"Asuro.lss"
  @echo 'Finished building: $@'
  @echo ' '

Asuro.hex: Asuro.elf
  @echo 'Create Flash image (ihex format)'
  -avr-objcopy -R .eeprom -O ihex Asuro.elf  "Asuro.hex"
  @echo 'Finished building: $@'
  @echo ' '

Asuro.eep: Asuro.elf
  @echo 'Create eeprom image (ihex format)'
  -avr-objcopy -j .eeprom --no-change-warnings --change-section-lma .eeprom=0 -O ihex Asuro.elf  "Asuro.eep"
  @echo 'Finished building: $@'
  @echo ' '

sizedummy: Asuro.elf
  @echo 'Invoking: Print Size'
  -avr-size --format=avr --mcu=atmega8 Asuro.elf
  @echo 'Finished building: $@'
  @echo ' '

# Other Targets
clean:
  -$(RM) $(OBJS)$(C_DEPS)$(ASM_DEPS)$(EEPROM_IMAGE)$(FLASH_IMAGE)$(ELFS)$(LSS)$(S_DEPS)$(SIZEDUMMY)$(S_UPPER_DEPS) Asuro.elf
  -@echo ' '

secondary-outputs: $(LSS) $(FLASH_IMAGE) $(EEPROM_IMAGE) $(SIZEDUMMY)

.PHONY: all clean dependents
.SECONDARY:

-include ../makefile.targets
Kann mir hier jemand sagen an was es liegt? und warum?

Danke und Grüße

Autor: Markus J. (markusj)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hust - Du sollst die Build-Parameter des Eclipse-Projektes 
(Rechtsklick, Properties, C/C++ Build, Settings) mit dem Makefile von 
Programmers Notepad vergleichen!

Ist doch irgendwie sinnlos die Konfiguration von Eclipse mit dem von 
Eclipse nach dieser Konfiguration generierten Makefile zu vergleichen, 
oder?

mfG
Markus

PS: Am besten suchst du dir erst einmal ein paar Informationen über die 
verschiedenen Compilerschalter zusammen ...

PPS: Was ich bei meinen Projekten so verwende:
AVR Compiler:
Optimization: Beide Haken + "-ffunction-sections -fdata-sections"
Language Standard: Beide Haken + GNU99
Miscellanous: "-W -Wextra -Wundef -Wunreachable-code -Wstrict-prototypes 
-Winit-self -Wno-main -msize" (Jede Menge Warnings)

AVR C Linker:
General: "-Wl,--gc-sections,--relax -Os"
Libraries: + "m" (= libmath)

Autor: Stephan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok danke für die Antwort und sorry für meine lange Leitung.
Hab deine Konfiguartion ausprobiert und auch die, die in der Makefile 
vom Programmers Notepad drinsteht, aber an der Dateigröße ändert sich 
nichts! An was könnte es sonst noch liegen? HAb auch schon verschiedene 
Optimierungsmodi ausprobiert, aber bei -Os kommt das beste Ergebnis 
raus...-O3 hab ich auch ausprobiert, aber da ist mein Speicher vom AVR 
dann voll :-D Könnte mir jemand noch nen weiteren Tipp geben?

Danke und Grüße
Stephan

Autor: Markus J. (markusj)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie wäre es wenn du dein Projekt mal packst ("zippst") und hier 
reinpostest?
Hast du die Konfiguration auch für den richtigen Build-Modus gemacht 
(oben gibts nen Umschalter Release-Debug).

Du kannst auch Mal die Konsolen-Ausgaben aus Eclipse hier posten, dort 
sieht man die tatsächlichen Aufrufparameter des GCC.

Bei mir führen Makefile und Eclipse zu identischen Binaries (bei 
gleichen Einstellungen ...)

mfG
Markus

Autor: Stephan (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hab die Einstellungen für den Build Modus gemacht, weil ich den Debug 
Mode gar nicht dabei hab, anbei hab ich mal das Projekt. Die Makefile 
vom Programmers Notepad ist auch dabei. Schon mal vielen Dank

Grüße Stephan

Autor: Markus J. (markusj)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Stefan,

entweder hast du die Einstellungen erst vorgenommen nachdem du das 
Projekt hier eingestellt hast, oder du hast sie nicht gespeichert (OK 
bzw. Apply)
Wenn ich mir die Build-Optionen ansehe, sind das: "-Wall -Os 
-fpack-struct -fshort-enums -std=gnu99 -funsigned-char 
-funsigned-bitfields -W -Wextra -Wundef -Wunreachable-code 
-Wstrict-prototypes -mmcu=atmega8 -DF_CPU=8000000UL" alle Schalter die 
gesetzt wurden.
Speziell alle Zusatzparameter die in die Textfelder rein sollen/müssen, 
fehlen komplett.

Nur so als Vergleich, bei einem meiner Projekte: "-Wall -g2 -gdwarf-2 
-Os -fpack-struct -fshort-enums -ffunction-sections -fdata-sections 
-std=gnu99 -funsigned-char -funsigned-bitfields -W -Wextra -Wundef 
-Wunreachable-code -Wstrict-prototypes -Winit-self -Wno-main -msize 
-mmcu=attiny2313 -DF_CPU=8000000UL"

-g2 und -gdwarf-2 sind fürs Debugging via AVR-Studio, -mmcu=X wählt den 
entsprechenden AVR X aus, DF_CPU gibt die verwendete Taktfrequenz des 
AVR an.

Alle anderen Schalter dienen entweder der Optimierung oder der 
Sicherheit/Fehlervermeidung.

Daher nochmal: Geh die oben genannten Einstellungen durch und passe sie 
entsprechend an, ich vermute dass vor allem gc-sections Option im Linker 
einiges sparen kann.

Was ich gerade noch bei der Betrachtung des Makefiles sehe: Das Makefile 
verwendet zusätzlich asuro.c - dein Eclipse-Projekt bindet stattdessen 
eine ominöse asuro.o von einer Stelle ein, wo sie überhaupt gar nicht 
hingehört (In das WinAVR-Verzeichnis gehört imho NUR WinAVR). Kopiere 
asuro.h und asuro.c doch einfach ins Projektverzeichnis, Eclipse 
erledigt den Rest! (Ich gehe davon aus dass du die 
Original-ASURO-Bibliothek verwendest, wenn nicht, gibt Bescheid).

mfG
Markus

Autor: Stephan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jetzt hab ich die Original asuro.h und asuro.c in das Projektverzeichnis 
kopiert! Aber er bringt mir in der asuro.c Warnungen wie "inline 
function 'MotorDir' declared but never defined" und außerdem bei den 
Aufrufen in meinem Programm "undefined reference to `MotorDir'". Ich 
weiß nicht was ich falsch mach, du meintest ja, dass ich die einfach 
reinkopiere und dann #include "asuro.h".  Dieses Problem hatte ich 
anfangs auch schon und deshalb hab ich die "komische" Aktion mit der 
asuro.o gemacht, weil ich in nem Formum was über includen der 
object-Datei gelesen hab. Oder muss ich doch irgendeinen Pfad noch 
angeben, damit er die Funktionen findet.

Grüße Stephan

Autor: Markus J. (markusj)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"inline function 'MotorDir' declared but never defined" ist ein Fehler 
in der ASURO-Lib.
Zu "undefined reference to `MotorDir'" fehlt mir der Kontext.

Wenn du das Projekt nochmal hochlädst, kann ich dir evtl. die restlichen 
Parameter zurechtbiegen oder den Fehler ausfindig machen.
Eigentlich ist das ganze ja relativ unkompliziert ...

mfG
Markus

Autor: Stephan (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Normal ist es ja auch unkompliziert, aber irgendwo stimmt was nicht, 
dann hoff ich mal das du den Fehler finden kannst, ach übrigens, bei 
meinen Compiler Options hab ich jetzt folgende drin:
"-Wall -Os -fpack-struct -fshort-enums -std=gnu99 -funsigned-char 
-funsigned-bitfields -Wall -g2 -gdwarf-2 -Os -fpack-struct -fshort-enums 
-ffunction-sections -fdata-sections -std=gnu99 -funsigned-char 
-funsigned-bitfields -W -Wextra -Wundef -Wunreachable-code 
-Wstrict-prototypes -Winit-self -Wno-main -msize -mmcu=atmega8 
-DF_CPU=8000000UL"

und beim Linker:
-Wl,-Map,Asuro.map -Wl,--gc-sections,--relax -Os -mmcu=atmega8

aber du siehst es gleich selbst, wenn du das projekt öffnest.
Danke für deine Bemühungen.

Autor: Markus J. (markusj)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du hast es leicht übertrieben - Ich hab bezüglich der Compilerschalter 
etwas aufgeräumt (Optimierung in Optimierung, der Rest nach 
Miscellanous, bereits vorhandene Optionen entsprechend dort aktiviert).
Außerdem habe ich den Language Standard auf GNU90 gestellt, damit fallen 
Fehlermeldungen weg. Um C99/GNU99 verwenden zu können wirst du aber wohl 
die Bibliothek etwas bereinigen müssen (Tipp: Das "inline" im Headerfile 
ist SEHR sinnlos und böse).

mfG
Markus

EDIT: Anhang vergessen -> Kommt gleich

Autor: Markus J. (markusj)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
So, dieses Mal mit Anhang.

mfG
Markus

Autor: Stephan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Darf ich jetzt noch fragen was du gemacht hast, das er die Funktionen 
erkannt hat?

Grüße Stephan

Autor: Markus J. (markusj)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Markus J. schrieb:
> Außerdem habe ich den Language Standard auf GNU90 gestellt, damit fallen
> die Fehlermeldungen weg.

mfG
Markus

Edit: "die" im Satz eingebaut ...

Autor: Sven (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guten Tag,

ich programmiere seit kurzen mit dem Nibo2 und versuche ein 
Online-Beispiel zum Ansteuern der IR-Abstandsmessung zu kompilieren. Bis 
jetzt ohne Erfolg.

Das ist der Quelltext:
#include <stdlib.h>
#include <avr/interrupt.h>

#include <nibo/niboconfig.h>

#include <nibo/delay.h>
#include <nibo/pwm.h>
#include <nibo/display.h>

#include <nibo/leds.h>
#include <nibo/bot.h>
#include <nibo/gfx.h>
#include <nibo/irco.h>

void float2string(float value, int decimal, char* valuestring)
{
 //... siehe oben!
}

float SupplyVoltage(void)
{
    bot_update();
    return(0.0166 * bot_supply - 1.19);
}

void textout(int x, int y, char* str, int ft)
{
    gfx_move(x,y);
    gfx_print_text(str);
}

void Init(void)
{
    sei(); // enable interrupts
    bot_init();
    leds_init();
    pwm_init();
    display_init();
    gfx_init();
}

int main()
{
    Init();

    leds_set_displaylight(1000);

    while(1)
    {
        float Ubatt = SupplyVoltage();
        char text[6];
        float2string(Ubatt,2,text);

        textout( 0,0,text,  0);
        textout(35,0,"Volt",0);

        irco_update();
        irco_startMeasure();
        irco_update();

        char irco_string[5][5];
        int i;

        for(i=0; i<5; ++i)
        {
             textout(i*21,8,"      ",0); //löschen
        }

        for(i=0; i<5; ++i)
        {
             itoa(irco_distance[i],irco_string[i],10);
             textout(i*21,8,irco_string[i],0);
        }
        delay(200);
    }

    while(1);
    return 0;
}

Beim Build-Prozess kommt folgende Fehlermeldung.

make all
Building file: ../main.c
Invoking: AVR Compiler
avr-gcc -I"C:\Program Files\NiboLib\include" -Wall -Os -fpack-struct 
-fshort-enums -std=gnu99 -funsigned-char -funsigned-bitfields -D_NIBO_2_ 
-mmcu=atmega128 -DF_CPU=16000000UL -MMD -MP -MF"main.d" -MT"main.d" -c 
-o"main.o" "../main.c"
../main.c: In function 'main':
../main.c:57: warning: implicit declaration of function 'irco_update'
../main.c:58: warning: implicit declaration of function 
'irco_startMeasure'
../main.c:71: error: 'irco_distance' undeclared (first use in this 
function)
../main.c:71: error: (Each undeclared identifier is reported only once
../main.c:71: error: for each function it appears in.)
make: *** [main.o] Error 1

Diese Fehlermeldung kommt nur beim Einbinden der irco-Header. Die 
Biblioteken habe ich über Project -> Properties -> C/C++ Build -> 
Settings -> AVR C Linker -> Libaries unter Libraries direkt inzu gefügt. 
Dazu zählen:
"C:\Program Files\NiboLib\lib\libnibo2.a"
"C:\WinAVR\avr\lib\libprintf_flt.a"
"C:\WinAVR\avr\lib\libm.a"
Dem Linker werden folgende Optionen mitgeliefert:
-Wl,-Map,NiboTest2.map -u, -vfprintf -mmcu=atmega128

Leider funktioniert es mit dieser Einstellung nicht. Habe ich 
irgendetwas vergessen?

Gruß

Sven

Autor: Martin Sonntag (leilahasi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Gemeinde,

ich habe das selbe Problem wie Sven wenn ich das Programm kompilieren 
will.

Bitte dringend um Hilfe.

gruß

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich verzweifle langsam, ich versuche einfach nur eines der simpelsten 
Testprogramme für die Nibobee (Atmega16) zu kompilieren, habe das 
Verzeichnis src der Nibobee-Lib eingebunden, unter WInAVR läuft das 
wohl:
#include <nibobee/iodefs.h>
#include <nibobee/led.h>
#include <nibobee/delay.h>

int main(){
  led_init();
  while(1==1){
    int ledNr;
    for(ledNr=0; ledNr<4; ledNr++){
      led_set(ledNr, 1);
      delay(350);
      led_set(ledNr, 0);
      delay(150);
    }
  }
  return 0;
}

Aber ich bekomme immer diesen Fehler:
avr-gcc -I/home/mustermann/workspace/Lib/Nibobee/src -Wall -Os -fpack-struct -fshort-enums -std=gnu99 -funsigned-char -funsigned-bitfields -mmcu=atmega16 -DF_CPU=15000000UL -MMD -MP -MF"src/try.d" -MT"src/try.d" -c -o"src/try.o" "../src/try.c"
In Datei, eingefügt von ../src/try.c:1:
/home/mustermann/workspace/Lib/Nibobee/src/nibobee/iodefs.h:46:3: Fehler: #error "no robot platform defined"
In file included from ../src/try.c:2:
/home/mustermann/workspace/Lib/Nibobee/src/nibobee/led.h:48: Fehler: »IO_LEDS_BIT_L_YE« ist hier nicht deklariert (nicht in einer Funktion)
/home/mustermann/workspace/Lib/Nibobee/src/nibobee/led.h:49: Fehler: »IO_LEDS_BIT_L_RD« ist hier nicht deklariert (nicht in einer Funktion)
/home/mustermann/workspace/Lib/Nibobee/src/nibobee/led.h:50: Fehler: »IO_LEDS_BIT_R_RD« ist hier nicht deklariert (nicht in einer Funktion)
/home/mustermann/workspace/Lib/Nibobee/src/nibobee/led.h:51: Fehler: »IO_LEDS_BIT_R_YE« ist hier nicht deklariert (nicht in einer Funktion)
make: *** [src/try.o] Fehler 1

Hat jemand ne Ahnung, was hier schief läuft?

Autor: Hans Mayer (Firma: mayer) (oe1smc) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo

im file iodefs.h steht auf zeile 46
#error "no robot platform defined"

vermutlich gibts im #ifdef darueber eine bedingung, die nicht erfuellt 
ist.

gruess
hans

--

Autor: Markus (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich hab mir die Schaltun aufgebaut, und die schritte einen nach dem 
anderen erledigt (ist übrigens gut erklärt).

Ich häng nun an der stelle das ich das übungbeispiel nicht auf den 
Controller aufspielen kann. Ich bekomme immer eine fehlermeldung mit dem 
Text:

"
The port for the Programmer "stk500v2" is blocked.

Check that no other istances of AVRDude or any other programm is using 
the port

Reason:
avrdude: ser_open(): can't open device"\\.\com1":Das System kann die 
angegebene Datei nicht finden.
"

Kann mir jemand sagen was ich falsch mach oder was ich vergessen hab?

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was ich noch vergessen hab zu erwähnen ist das bei dem schritt "Make 
Target" in der Console, unter anderem folgende Zeile stehen habe:

make: [AVRTest.lss] Error 128 (ignored)

Autor: JR (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ich versuche schon seit 2 Tagen Exlipse mit AVR-GCC zum Laufen zu
kriegen. Habe schon google gequält aber finde keine zufriedenstellende
Antwort.

Ich benutze Win7 64-bit, habe die 32-bit Version von Eclipse und die CDT
über Eclipse direkt installiert.

Wenn ich Eclipse starte und ein neues Projekt erstellen will, schreibt
Eclipse: "Could not execute avr-gcc. Please check the AVR paths in the
preference." Bei Details: "Cannot run program ...avr-gcc:CreateProcess
error=5, Zugriff verweigert".

Ich führe aber Eclipse schon als Administrator aus und habe die Pfade
manuell bei den preferences eingefügt.

Hat vllt. jemand von euch das schon mal erlebt, und dafür vllt. einen
Lösungsweg?

Danke im voraus

JR

Autor: JR (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habe nun doch eine Lösung für mein Problem gefunden(Hat was mit 
Schutzmechanismen von Win7 zu tun):
Ich hatte Eclipse auf meinem C-Laufwerk(System). Habs nun gemeinsam mit 
WinAVR auf ein anderes Laufwerk verschoben und siehe da, es geht!!!

Autor: bpuder (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich hab seit ubuntu 11.04 das Problem (eher ein Luxusproblem), dass bei 
der Erstellung eines neuen Projektes nicht gleich die Includes definiert 
sind. Das erstellte Projekt ist somit komplett leer. Kann mir da jemand 
helfen oder hat es schon jemand anderes beobachtet? Der Fehler tritt 
Eclipse Helios und Indigo auf.

Beste Grüße aus Leipzig,
Benny

Autor: Silent Bob (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ich habe das Problem das Eclipse immer Fehler bringt, wenn ich
auf irgendein Register/Eintrag aus der <avr/io.h> zugreifen wil.

Im Anhang hab ich mal einen Screenshot angehängt von meinem Problem.

Hoffe ihr könnt mir weiterhelfen :)

Danke euch!

Autor: Soja (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich hatte ein eigenes Thema aufgemacht bevor ich diesen Thread hier 
gefunden hatte (Beitrag "Neues Projekt in AVR Studio nicht möglich")
Vielleicht finde ich hier eher jemanden der mir weiterhelfen kann, 
deswegen hier nochmal der Text:

Ich habe mir auf meinem Linux-Rechner AVR-Studio über den Eclipse
Marketplace instlliert. Ich kann die Beispielprojekte öffnen und
kompilieren, allerdings kein neues Projekt erstellen.
Wenn ich ein neues AVR C project erstellen möchte, kommt das Dialogfeld
zum erstellen. Darin ist aber das feld "Project type" inaktiv, so dass
ich da nichts auswählen kann und damit auch der "Finish"-Button
ausgegraut ist.

Hab ich da noch was am Anfang vergessen? Hat jemand einen Tipp? Hab im
Internet dazu bis jetzt noch nichts gefunden.

Vielen Dank und beste Grüße,

   Jan

Autor: Thomas Holland (innot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Soja

Jan, bei dem "AVR Studio" aus dem Eclipse Marketplace handelt es sich um 
das AVR32 Studio von Atmel. Dieses Plugin hat nichts mit dem "AVR 
Eclipse Plugin" zu tun, ist nur für AVR32 MCUs gedacht und wird von 
Atmel nicht mehr supported da es durch das AVR Studio 5.0 ersetzt wurde.

Autor: Thomas Holland (innot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe eine (Beta) Version des AVR Eclipse Plugins released die 
(hoffentlich) die Probleme mit dem Erkennen der Include-Dateien behebt.

Weitere Details findet ihr hier: 
Beitrag "Re: AVR eclipse error message problem!!"

Autor: Willi K. (kucky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,
habe nun, mit Hilfe von Jörg,  eine fast einsatzfähige Debugumgebung in 
Eclipse hinbekommen.
Winwows7 64bit
Eclipse Helios
AVaRICE 2.12 (über Cygwin eingebunden)
GDB 7.2 (über Mingw eingebunden,  soll aber 7.3 sein)
AVR Plug-In (aktuell von T. Holland aus diesem Helpthread)
AVR Dragon (aktuelle Firmware)
ATMEGA 2560 (auf Arduino Mega)

Geflasht mit AVRDUDE unter Eclipse (No Optimizations (-0o) und Debug 
Info Standard (-g2) und stabs(avr-gdb/Insight)

AVaRICE startet mit diesem Kommando…
Avarice –dragon –ignore-intr –B4000khz –jtag usb :4242
einwandfrei, und wartet auf “Antwort”. Dies habe ich sowohl von der 
Kommandozeile als auch in Eclipse getestet.

Der GDB wird nun wohl nicht mehr mit avr-gdb, sondern mit gdb gestartet. 
Von der Kommandozeile sieht es so weit gut aus. Datei wird gefunden, und 
„target“ :4242 wohl auch. Der erste Breakpoint (main) wir mit „b main“ 
auch gefunden. Mit „c“ wird es dann seltsam. Es dauert lange bis sich 
was tut, erst wenn ich „strg  c“ tut sich wieder was. Aber nichts was 
ich verstehe.
Wenn ich den GDB aus Eclipse starte, sieht auch erst einmal alles gut 
aus. Die beiden Icons „Step into“ und „Step over“ sind auch anfangs 
aktiv. Nach dem ersten anklicken aber nicht mehr, und das Ganze ruht vor 
sich hin. Ich habe auch den Rat von 900ss befolgt, und nicht Load Image 
sondern nur Load Symbols ausgewählt.
Weis hier jemand Rat? Ich kann auch gerne Screenshots posten.
LG Willi

Autor: Thomas Holland (innot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Willi,

hast Du Dir mal den Artikel zum Thema Debugging auf der AVR Plugin 
Homepage angeschaut? 
http://avr-eclipse.sourceforge.net/wiki/index.php/Debugging

Der Artikel müsste zwar mal wieder aktualisiert werden, da er sich noch 
auf Eclipse 3.4 bezieht, aber die grundlegenden Prinzipien dürften sich 
auch mit Indigo (3.7) nicht verändert haben.

Autor: Willi K. (kucky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Thomas,
danke für die Antwort. Ich glaube, den Artikel kann ich schon beten, was 
aber nicht heißen soll, dass ich was übersehen habe könnte. Der ist 
wirklich gut und verständlich geschrieben. Ich denke aber, ich habe hier 
alles richtig eingestellt. Der Unterschied besteht derzeit darin, dass 
ich GDB Hardware Debugging anstatt C/C++ Local Application ausführe. 
Müssen hier etwa beide Konfigurationen eingestellt werden?
Etwas anderes: Wollte gerade wieder weiter testen, da kommt beim 
Compilieren diese Meldung:

make: write error: No such file or directory
java.lang.NullPointerException

Ich hatte aber nichts (hoffe ich) seit gestern geändert.

Soll ich besser auf Indigo umstellen?

LG
Willi

Autor: Gerd S. (gerd_s)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Thomas,
vielen Dank für deine Arbeit an diesem Plugin.  "Much appreciated !"

Kleiner Verbesserungsvorschlag:
In den Pfaden für AVR-GCC kann man keine Eclipse Variablen eintragen, 
sondern nur absolute Pfade. z.B. '${eclipse_home}\..\Winavr\bin' 
versteht er nicht oder ${AVR32_HOME}\bin.

Das wäre sehr hilfreich um die Umgebung unabhängiger und u.U. portabel 
zu machen.

Ich kam darauf durch einen Artikel in der aktuellen C'T, der das 
Aufsetzen einer 'C'- Entwicklungsumgebung als portable Version 
beschreibt.

Gruß und Dank
Gerd

Autor: Michael B. (michael_b25)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Thomas,

ich habe die aktuelle Toolchain aus Atmel Studio 6 eingebunden. 
Prinzipiell funktioniert das Ganze auch prima, mit einer kleinen 
Unschönheit :-\

Neuere avr-gccs scheinen eine zusätzliche Option zu benötigen, um die 
device list auszuspucken und tun dies dann auch in einem etwas anderen 
Format:
#avr-gcc --target-help -mlist-devices

[...]
  -mtiny-stack                Change only the low 8 bits of the stack pointer

List of parts supported by avr-gcc:
at90s2313           __AVR_AT90S2313__
at90s2323           __AVR_AT90S2323__
at90s2333           __AVR_AT90S2333__
at90s2343           __AVR_AT90S2343__
attiny22            __AVR_ATtiny22__
attiny26            __AVR_ATtiny26__
at90s4414           __AVR_AT90S4414__
[...]
attiny11            __AVR_ATtiny11__
attiny12            __AVR_ATtiny12__
attiny15            __AVR_ATtiny15__

Assembler options
=================
[...]

Als Resultat ist die Liste der supporteten MCUs leider leer, keine 
Auswahlen möglich :-(

Ist vielleicht irgendwann/-wo eine Version mit einem Bugfix in Sicht?

Viele Grüße
michaelb

Autor: Elmar Faber (elmar-faber)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

so ich habe ein Problem mit AVR und Eclipse bzw ein Problem generell.
Ich kann in meiner Eclipse Version (Eclipse IDE for C/C++ Developers
Version: Juno Release Build id: 20120614-1722) kleine AVR Projekte ganz 
normal erzeugen. Nun habe ich vor, ein etwas umfangreicheres Projekt zu 
beginnen. Eine der Libraries hierfür soll die u8glib sein 
(http://code.google.com/p/u8glib/). Unter einer Arduino Umgebung läuft 
diese Lib sehr gut aber mit der avr-Version habe ich so meine Probleme.
Ich habe mir das einfachste Beispiel herausgesucht und es nun endlich 
geschaft es zu compillieren. Es kommen sagenumwogene 676000 Bytes raus 
und die Meldung:

Building target: u8g_test.elf
Invoking: AVR C Linker
avr-gcc -Wl,-Map,u8g_test.map -mmcu=atmega328p -o "u8g_test.elf" 
./main.o
c:/winavr/bin/../lib/gcc/avr/4.3.3/../../../../avr/bin/ld.exe: 
u8g_test.elf section .text will not fit in region text
c:/winavr/bin/../lib/gcc/avr/4.3.3/../../../../avr/bin/ld.exe: region 
text overflowed by 676402 bytes
make: *** [u8g_test.elf] Error 1

13:32:22 Build Finished (took 9s.891ms)

Die Optimierung ist eingeschaltet und nun komme ich nicht mehr weiter. 
Ich denke es liegt wohl eher an einem prinzipiellen Problem aber... wie 
gesagt
kleinere Projekte kann ich völlig normal erzeugen.

Hier mal der Quellcode:
/*
 * main.c
 *
 *  Created on: 27.09.2012
 *      Author: elmar faber
 */

#include <avr/interrupt.h>
#include <avr/io.h>

#include "../include/u8glib/src/u8g.h"

/*
 *  Hier beginnt es schon, im Beispielcode mußten diese
 *  include-Angaben nicht vorgenommen werden, aber dami ich es 
 *  compillieren konne ging es nicht anderst...
 *  
 */

#include "../include/u8glib/src/u8g_dev_st7565_dogm132.c"
#include "../include/u8glib/src/u8g_font_data.c"
#include "../include/u8glib/src/u8g_font.c"
#include "../include/u8glib/src/u8g_com_api.c"
#include "../include/u8glib/src/u8g_ll_api.c"
#include "../include/u8glib/src/u8g_com_io.c"
#include "../include/u8glib/src/u8g_delay.c"
#include "../include/u8glib/src/u8g_state.c"
#include "../include/u8glib/src/u8g_pb.c"
#include "../include/u8glib/src/u8g_pb8v1.c"
#include "../include/u8glib/src/u8g_com_atmega_sw_spi.c"
#include "../include/u8glib/src/u8g_com_atmega_hw_spi.c"
#include "../include/u8glib/src/u8g_page.c"

u8g_t u8g;

void u8g_setup(void)
{
  /*
    Test Envionment, ATMEGA with the following settings:
    CS: PORTB, Bit 2
    A0: PORTB, Bit 1
    SCK: PORTB, Bit 5
    MOSI: PORTB, Bit 3
  */
  u8g_InitSPI(&u8g, &u8g_dev_st7565_dogm132_sw_spi, PN(1, 5), PN(1, 3), PN(1, 2), PN(1, 1), U8G_PIN_NONE);
}

void sys_init(void)
{
#if defined(__AVR__)
  /* select minimal prescaler (max system speed) */
  CLKPR = 0x80;
  CLKPR = 0x00;
#endif
}

void draw(void)
{
  u8g_SetFont(&u8g, u8g_font_6x10);
  u8g_DrawStr(&u8g, 0, 15, "Hello World!");
}

int main(void)
{
  sys_init();
  u8g_setup();

  for(;;)
  {
    u8g_FirstPage(&u8g);
    do
    {
      draw();
    } while ( u8g_NextPage(&u8g) );
    u8g_Delay(100);
  }

}

Ich komme einfach nicht auf die Lösung, trotz stundemlangen lesen...

Nun hoffe ich hier auf Hilfe...

Viele Grüße

Elmar Faber

Autor: Christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich hab bei mir im Projektverzeichnis ein Unterverzeichnig "scr" gemacht 
und da alles reinkopiert, aber ich glaube da gibts zwei Versionen von 
der Lib, eine für AVR.

Dann in main.c #include "src/u8g.h"

das funktioniert.

Christian

Autor: Elmar Faber (elmar-faber)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Soooo,

ich habe es nun hinbekommen, wenn man die korrekten Pfadeinträge macht 
und
genauer liest, d.h. folgende Compiler/Linkerschalter setzt:

    [Compiler Options - Optimizations]
        -ffunction-sections
        -fdata-sections
    [Linker Options]
        -Wl,--gc-sections

dann klappt es auch mit dem compilieren. Trotzdem klappt die
Ausgabe auf dem Display nicht, die gleichen einstellungen im Arduino
Beispiel funktionieren bei meiner Hardware perfekt...
Aber das gehört nicht hierher (falls jemand die Lösung kennt kann
er sich jedoch gerne austoben :-)

Ich verwende folgendes Display:

u8g_InitSPI(&u8g1, &u8g_dev_st7920_128x64_sw_spi, PN(3, 4), PN(3, 6),
            PN(3, 5), U8G_PIN_NONE, U8G_PIN_NONE);


Viele Grüße

Elmar

Autor: Elmar Faber (elmar-faber)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

der Vollständigkeits halber hier noch die Lösung des letzen Problems
mit dem Display:

[[Beitrag "Re: u8glib: Grafik LCD 12864zw am ATmega32"]]

Viele Grüße

Elmar

Autor: David (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ich habe ein Problem mit Eclipse(for C/C++ Programmers, Helios SR2) beim 
Kompilieren. Es werden die im Screenshot gezeigten Fehler gemeldet.
Weiß jemand was ich ändern muss?
Gruß David

Autor: Davis (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
David schrieb:
> Hallo,
> ich habe ein Problem mit Eclipse(for C/C++ Programmers, Helios SR2) beim
> Kompilieren. Es werden die im Screenshot gezeigten Fehler gemeldet.
> Weiß jemand was ich ändern muss?
> Gruß David

Könnte an der "make"-Datei liegen.

Autor: David (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die make.exe Datei stürzt während dem kompilieren immer ab.
Kurz nach dem "reading on chip flash-data" in der Konsole auftaucht, 
wird endlos "make: write error: No such file or directory" ausgegeben.

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
tolles Tutorial.
Bei mir wurde die delay_ms Zeitschleife vom compiler wegoptimiert.

Habe einen Assembler NOP Befehl in die j-Zählschleife eingefügt. 
Genauer:
_asm_ volatile("nop");
Dann ging es.

Autor: muggel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Im moment scheint das Plugin sehr ungepflegt.

Die von der Toolchain unterstützten Controller werden nicht mehr richtig 
erkannt.

AVRDude 6.01 wird auch nicht unterstützt.

Hier scheint sich jemand des Plugin angenommen zu haben :

http://www.ijzerbout.nl/avr-eclipse/updatesite

Autor: S3ler (Gast)
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
Hallo an alle die das Eclipse AVR Plugin nutzen,

ich habe mich des Problems angenommen, dass das AVR PLugin mit dem 
neueren avr-gcc und avrdude versionen nicht geht. Konkret um den Bug das 
Programmer oder von avr-gcc unterstütze Mikrocontroller nicht angezeigt 
werden.

Wer will kann das Plugin von mir gern testen (ich gebe keine Garantie 
das es funktioniert) es basiert auf der AVR Plugin version 2.4.1 von 
sourceforge.
Bei mir selbst laufen die die Funktionen wie hochladen und compilieren 
problemlos.
Ich nutze Ubuntu 14.04 64Bit, Eclipse IDE for C/C++ Developers Version: 
Luna Release (4.4.0), OpenJDK version "1.7.0_65", avr-gcc (GCC) 4.8.2, 
avrdude version 6.0.1.

Am besten das Plugin in ein "frisches" Eclipse installieren
(Help->Install new Software->Add...->Local...->
GespeichertePluginAuswählen->...Installieren etc.)

Ich hoffe einfach, es hilft dem einen oder anderen.

Mfg

PS.: Ich hoffe es ist ok wenn ich es hier in de Helpthread schreibe und 
werde nicht der Leichenschänderei bezichtigt :)

Autor: Michael B. (michael_b25)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
S3ler schrieb:
> ich habe mich des Problems angenommen

Hast du die geänderten Quellen auch irgendwo allgemein zugänglich 
abgelegt?

VG michaelb

Autor: S3ler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nein noch nicht, da ich die Version erst noch an einem Mac in der Uni 
mit einem anderen AVR-GCC, AVRDude, Board und Bootloader testen wollte 
bevor ich es ins SourceForge Repository schiebe.
Auserdem schlagen noch einige Test von AVARice fehl, das wollte ich mir 
eventuell auch noch anschauen bevor ich es commite.

Autor: Harry L. (mysth)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
S3ler schrieb:
> ich habe mich des Problems angenommen, dass das AVR PLugin mit dem
> neueren avr-gcc und avrdude versionen nicht geht. Konkret um den Bug das
> Programmer oder von avr-gcc unterstütze Mikrocontroller nicht angezeigt
> werden.

Hallo,
es ist mal wieder so weit.
Das Plugin funktioniert mit dem aktuellen avrdude und GCC nicht mehr 
richtig.
Das Problem tritt hier nach dem Update auf Ubuntu 16.04 auf.

GCC ist Version 4.9.2, und avrdude liegt in der Version 6.2. vor.

Vielleicht kann sich mal jemand darum kümmern.
Java ist leider nicht meine Welt.

Harry

Autor: Md Ma (Firma: Potilatormanufaktur) (mdma)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gibt es dazu irgendwo genauere Informationen? Welche Versionen von 
eclipse, gcc und avrdude funktionieren zusammen und welche nicht?

Autor: Pete K. (pete77)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Md Ma (Firma: Potilatormanufaktur) (mdma)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aha, ein verbuggtes Plugin also. Hab den Rotz aber eh schon längst in 
die Tonne getreten und bin bei Editor, Makefile und gdb (ja) gelandet 
und damit zufrieden.

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.