Datum:
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
Datum:
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
Datum:
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 |
Datum:
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
Datum:
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
Datum:
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
Datum:
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
Datum:
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
Datum:
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.
Datum:
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?
Datum:
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.
Datum:
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.
Datum:
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.
Datum:
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
Datum:
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
Datum:
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
Datum:
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
Datum:
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...
Datum:
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
Datum:
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
Datum:
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)
Datum:
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 |
Datum:
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
Datum:
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.
Datum:
Angehängte Dateien:Anbei noch ein makefile mit dem es unter Windows und dem Programmers Notepad problemlos klappt.
Datum:
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
Datum:
Prima, immerhin gibt es jetzt anscheinend einen Lösungsweg. Da kann ich auch ruhig noch einen Tag warten.
Datum:
Angehängte Dateien: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
Datum:
Wow, funktionierte sofort auf Anhieb. Erst mal vielen Dank. Vielleicht kommt aber trotzdem noch die ein oder andere Frage.
Datum:
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
Datum:
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
Datum:
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
Datum:
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
Datum:
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.
Datum:
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
Datum:
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!
Datum:
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
Datum:
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 :)
Datum:
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
Datum:
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
Datum:
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
Datum:
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
Datum:
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 ...
Datum:
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
Datum:
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
Datum:
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)
Datum:
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
Datum:
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
Datum:
Angehängte Dateien: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
Datum:
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
Datum:
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
Datum:
"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
Datum:
Angehängte Dateien: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.
Datum:
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
Datum:
Angehängte Dateien:So, dieses Mal mit Anhang. mfG Markus
Datum:
Darf ich jetzt noch fragen was du gemacht hast, das er die Funktionen erkannt hat? Grüße Stephan
Datum:
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 ...
Datum:
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
Datum:
Hallo Gemeinde, ich habe das selbe Problem wie Sven wenn ich das Programm kompilieren will. Bitte dringend um Hilfe. gruß
Datum:
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)
Datum:
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 --
Datum:
Angehängte Dateien:-
Fehlermeldung.jpg
20,7 KB, 48 Downloads -
Fehlermeldung.png
86 KB, 55 Downloads
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?
Datum:
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)
Datum:
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
Datum:
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!!!
Datum:
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!
Datum:
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
Datum:
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!!"
Datum:
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
Datum:
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.
Datum:
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
Datum:
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
E-Mail-Benachrichtigung einschalten
Neu: Seitenaufteilung einschalten