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
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:
1
file Standard/LCD-Test.elf
2
targ rem :1212
3
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:
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
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_Eclipse#Alternative_1:
1
Einstellungen
2
3
Jetzt müssen noch gewisse Einstellungen in Eclipse angepasst werden: Unter Window->Preferences->AVRDUDE Preferences:
4
5
* AVRDUDE executable: /usr/bin/avrdude
6
* Programmer auswählen
7
* Programmerport auswählen
8
* 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
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
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
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.
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?
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.
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.
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.
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. neuesteAVR-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
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
Hallo!
Ich habe ein kleines Problem mit dieser avr-objsplit.bat:
Verwende ich die Datei aus dem Plugin Ordner, dann bekomme ich folgende
Ausgabe:
1
make --no-print-directory post-build
2
Invoking: Object to Hex Splitter
3
avr-objsplit.bat
4
/usr/bin/avr-objsplit.bat: 1: @avr-objcopy: not found
5
/usr/bin/avr-objsplit.bat: 2: @avr-objcopy: not found
6
/usr/bin/avr-objsplit.bat: 3: @if: not found
7
make[1]: [post-build] Error 127 (ignored)
Modifiziere ich die Datei wie im Wiki, dann schaut das ganze so aus:
1
make --no-print-directory post-build
2
Invoking: Object to Hex Splitter
3
avr-objsplit.bat
4
make[1]: avr-objsplit.bat: Command not found
5
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
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
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...
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
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
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)
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:
1
#include"RP6RobotBaseLib.h"
2
intmain(void)
3
{
4
initRobotBase();
5
//writeString("Hallo Welt!\n");
6
return0;
7
}
So weit klappt das ganz gut. Die includes stehen im Projectexplorer auch
ordentlich drin. Sobald ich aber kompiliere erhalte ich folgende
Fehlermeldung:
1
**** Build of configuration Release for project bot6 ****
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
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.
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
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
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
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
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
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.
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:
1
**** Build of configuration Release for project Test 1 ****
2
3
make all
4
Building file: ../Quelltext/main.c
5
Invoking: AVR Compiler
6
...
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
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!
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 :)
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
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
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
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
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
...
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
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?
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)
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
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
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
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
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
"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
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.
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
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 ...
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:
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
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:
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
--
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?
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)
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
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!!!
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
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!
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
@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.
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!!"
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
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.
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
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
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:
1
#avr-gcc --target-help -mlist-devices
2
3
[...]
4
-mtiny-stack Change only the low 8 bits of the stack pointer
5
6
List of parts supported by avr-gcc:
7
at90s2313 __AVR_AT90S2313__
8
at90s2323 __AVR_AT90S2323__
9
at90s2333 __AVR_AT90S2333__
10
at90s2343 __AVR_AT90S2343__
11
attiny22 __AVR_ATtiny22__
12
attiny26 __AVR_ATtiny26__
13
at90s4414 __AVR_AT90S4414__
14
[...]
15
attiny11 __AVR_ATtiny11__
16
attiny12 __AVR_ATtiny12__
17
attiny15 __AVR_ATtiny15__
18
19
Assembler options
20
=================
21
[...]
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
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:
1
/*
2
* main.c
3
*
4
* Created on: 27.09.2012
5
* Author: elmar faber
6
*/
7
8
#include<avr/interrupt.h>
9
#include<avr/io.h>
10
11
#include"../include/u8glib/src/u8g.h"
12
13
/*
14
* Hier beginnt es schon, im Beispielcode mußten diese
15
* include-Angaben nicht vorgenommen werden, aber dami ich es
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
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
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
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.
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.
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.
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
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 :)
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.
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
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.
Thread beobachten
Seitenaufteilung abschalten