www.mikrocontroller.net

Forum: Compiler & IDEs AVR Eclipse Plugin 2.0.1 Released


Autor: Thomas Holland (innot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, der erste Bugfix Release ist raus.

Hauptänderung ist, dass das Size Tool jetzt auch unter nicht-winAVR 
toolchains läuft. Das Plugin testet, welche Format Optionen avr-size hat 
und bietet auch nur diese an, mit allen entsprechenden flags.

Weiter Änderungen:

------------------------------------------------------------------------ 
--------
Version 2.0.1.20071229 [29 December 2007]

The main point of this release is to fix the avr-size bug that made it 
impossible to use the Size tool on non-winAVR toolchains (Linux / 
MacOSX). Some other fixes minor features are included as well.

Features:
* Assembler Tool
   - Added options to use preprocessor and for debug information
 * Compiler Tool
   - Added option to omit the F_CPU definition from the commandline
   - Added options for debug level and debug information format
   - Added option to select the language standard (Bug 1783023)
 * Size Tool
   - Added option to display size in hex

Fixes:
* Assembler Tool
   - Changed command from avr-as to avr-gcc to enable the preprocessor 
for
     assembler sources
   - Extended the org.eclipse.cdt.core.asmSource contentType to include
     (uppercase) .S files
* Size Tool
   - fixed the bug that -mcu was always passed on to commandline,
     regardless of format
   - Only the size formats applicatable to the platform are shown
* Other
   - fixed wrong paths on non-Windows platforms, now looks in /usr/bin
     and /usr/local/bin. The whole path managment will be rewritten in 
2.1

----------------------------------------------------------------

Download wieder über die Update Site 
http://avr-eclipse.sourceforge.net/updatesite/

oder als direkter Download über die sourceforge Projektseite 
https://sourceforge.net/projects/avr-eclipse/

brgds und einen guten Rutsch,

Thomas

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sehr schön. Fettes Mercy. Diesmal hat auch das Update geklappt. Werds 
mal testen

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich weiß nicht ob du es schonmal probiert hast, aber wenn ich ein C++ 
Projekt compilieren will kommt nur die Meldung:

**** Build of configuration Debug for project cpptest ****

Nothing to build for project cpptest

Außerdem funktioniert bei mir der AVR Device Explorer nicht mehr. Ich 
bekomm die Meldung
"Error creating View. (Time of error: 30. Dezember 2007 00:30:21 MEZ)
Reason:
null argument:

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jau, Update ging ohne Probleme.

Autor: Thomas Holland (innot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Markus,

C++ habe ich bis jetzt aussen vorgelassen, da ich hier 
(http://www.mikrocontroller.net/articles/AVR-GCC) gelesen hatte, dass 
AVR-GCC nur eingeschränkt mit C++ funktioniert. Das kann allerdings 
schon längst veraltet sein, da doch recht aktiv an der avr gcc Toolchain 
Entwickelt wird.

Ich kann das Thema C++ gerne mit in die Pipeline schieben, aber dann 
bräuchte ich mal ein paar Beispiel C++ Source Dateien zum testen. Im 
Netz habe ich so auf die schnelle nichts gefunden.

Zum AVR Device View bin ich jetzt erstmal überfragt, weil sich da am 
ganzen Code nichts geändert hat. Mehr als
- Viewer explizit schliessen und wieder neu öffnen
- Preferences checken, ob der Pfad zu avr/io.h Datei noch stimmt
kann ich im moment nicht bieten. Mal schauen, ob das Problem auch bei 
Anderen auftritt.

Thomas

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Asche auf mein Haupt. Nach der Neuinstallation hab ich die io.h 
vergessen.

Zu C++ hab ich selbst noch nix. Ich will damit mal anfangen und hatte es 
getestet. Ich werd mal schauen das ich was schönes zusammenbastle wenn 
ich so nix finde

Autor: Martin Thomas (marathon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Thomas,

vielen Dank für das AVR Eclipse Plugin 2.0.1.
benutze es, um bestehende Sourcen eines Elektor-Projekts aus dem Jahr 
2004 zu bearbeiten.
Die Erweiterungen der Assembler-Unterstützung waren für mich genau 
richtig.

Habe meines Erachtens noch einen kleinen Fehler gefunden:
Unter Properties -> C/C++ Build -> Settings lassen sich in der 
Configuration 'Release' beim winAVR Compiler keine Optionen angeben. 
Beispiel:
In den Subsets wie z.b. Warnings ist per Default -Wall gesetzt. Das Feld 
all Options des winAVR Compilers ist aber leer.
(Für den Assembler funktioniert es)
Die Configuration 'Debug' hat das Problem nicht. Dort läuft mein Build 
durch.

Weiteres Problem: wenn ich nach erfolgreichem Build in der Configuration 
'Debug' den Debugger starten will, bekomme ich ein Fehlerfenster:
Problem occurred
Launching measure.elf(1)
Exec error:Launching failed

Ich denke das Problem liegt, an einer fehlenden Einstellung von mir.

Würde mich über Unterstützung sehr freuen.
Martin

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Thomas,
schau mal auf http://www.qfix.de/. Im Downloadbereich haben die ein ISO 
File. Das ist nix anderes als eine angepasste WinAVR Version. Die 
verwenden da Klassen um ihre Hardware anzusteuern. Vielleicht hilft das

Autor: Meierkurt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Version 2.0.1.20071229

Das ist geil. Da fällt mir ein, ich muss ja noch den neuen Kernel 
Version 8.5.6.78965.34.2.beta.432abc.alpha.beta345.6RC1.alpha3c 
kompilieren.

Autor: Thomas Holland (innot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Markus,

die Asche muss ich über mein Haupt streuen. Denn ich hatte den Fall, 
dass der Viewer die io.h Datei nicht findet nicht bedacht und auch nicht 
getestet. Das er mit einer nichtssagenden Fehlermeldung abbricht muss 
ich dringend ändern.

----

@Martin,
Man kann zwar grundsätzlich auch aus Eclipse heraus AVR Programme 
debuggen, aber so einfach mit "Debug As..." geht es leider noch nicht.
Da das ganze doch ein etwas komplexeres Thema ist bei dem ich mich auch 
noch einarbeiten muss, hier nur der grobe Ablauf:

1. Externen gdb server starten (z.B. simulavr)
2. Eclipse "Open Debug Dialog..." auswählen
3. GDB Hardware Debugging auswählen
4. Ausprobieren :-)

Schau mal hier als Einstieg: 
http://www.mikrocontroller.net/articles/AVR-Simulation

Ich habe es vor einiger Zeit schon mal ausprobiert und es geht 
grundsätzlich.

Dein anderes Problem mit den fehlenden Einstellungen in der Release 
Konfiguration kann ich nicht nachvollziehen. Könntest Du noch mal etwas 
detailierten beschrieben, was genau nicht geht?

brgds,

Thomas

Autor: Thomas Holland (innot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Meierkurt wrote:
>>Version 2.0.1.20071229
>
> Das ist geil. Da fällt mir ein, ich muss ja noch den neuen Kernel
> Version 8.5.6.78965.34.2.beta.432abc.alpha.beta345.6RC1.alpha3c
> kompilieren.

Sieht vielleicht komisch aus, ist es aber auch :-)

Nee, es gab auch ein paar 2.0.1 Versionen mit einem anderen Datum, die 
waren aber nur intern für mich zum testen und mit dem Datum kann ich sie 
auseinanderhalten.

Autor: Martin Thomas (marathon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas Holland wrote:
> ....
>
> Dein anderes Problem mit den fehlenden Einstellungen in der Release
> Konfiguration kann ich nicht nachvollziehen. Könntest Du noch mal etwas
> detailierten beschrieben, was genau nicht geht?
>
> brgds,
>
> Thomas

Hallo Thomas,
danke für die schnelle Reaktion.
Was nicht funktioniert, kann ich am besten anhand meines konkreten 
Problems beschreiben:
In der Configuration 'Debug' läuftg mein Build vollständig durch.
In der Configuration 'Release' bricht er beim ersten File ab.
Grund ist, daß das File io.h aus dem avr-Verzeichnis nicht eingebunden 
wird.
Das Problen hatte ich ursprünglich auch in der Configuration 'Debug'
Ich konnte es dort lösen, indem ich unter
Properties -> C/C++Build ->Settings ->winAVR Compiler -> Directories
den Eintrag
"C:\WinAVR\avr\include"
gemacht habe.
Dieser Eintrag ist dann auch unter
'Properties -> C/C++Build ->Settings ->winAVR Compiler' rechts im 
Fenster 'all Options' zu sehen.
Wenn ich nun in die Configuration 'Release' umschalte, ist unter
'Properties -> C/C++Build ->Settings ->winAVR Compiler' rechts im 
Fenster 'all Options' alles leer. Dies ist der Fall, obwohl ich auch 
hier unter
'Properties -> C/C++Build ->Settings ->winAVR Compiler -> Directories'
den Eintrag
"C:\WinAVR\avr\include"
gemacht habe.
Anscheinend wird in dieser Configuration die Eingabe nicht gespeichert.

Gruß
Martin

Autor: Ha Jo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Thomas,

auch von mir erstmal ein großes Danke schön. Bin wirklich begeistert :-)
Im übrigen lese ich das Forum viel per "Mailbenachrichtigung", so dass 
dein
Posting in dem Thread zur Vorversion des Plugins durchaus Sinn machte 
:-)

Folgendes kann ich bestätigen:

> Wenn ich nun in die Configuration 'Release' umschalte, ist unter
> 'Properties -> C/C++Build ->Settings ->winAVR Compiler' rechts im
> Fenster 'all Options' alles leer. Dies ist der Fall, obwohl ich auch
> hier unter
> 'Properties -> C/C++Build ->Settings ->winAVR Compiler -> Directories'
> den Eintrag
> "C:\WinAVR\avr\include"
> gemacht habe.
> Anscheinend wird in dieser Configuration die Eingabe nicht gespeichert.


Das ist bei mir jetzt auchder Fall. Das war vorher nicht bzw. bei der
ersten Version nicht. Bei der letzten hatte ich das garnicht probiert.

@Martin: Zum Debuggen unter Eclipse ganz grob:
Wenn Du mit echter Hardware arbeitest, also Dragon oder JTAGICE MKII,
dann brauchst Du auch AVaRICE zum debuggen. Das stellt die Verbindung
zwischen dem ICE und dem (AVR-)GDB her. Versuche erstmal damit eine 
Verbindung zu deiner Hardware herszustellen. Dann weiter...
In Eclipse must Du Dir eine Debugkonfiguration erstellen, wo Du
als Debugger "gdbserver debugger" wählst.
Dort unter Debugger Options->Main->GDB-Debugger AVR-GDB einstellen.
unter Debugger Options->Connection: TCP, localhost, Port number: die die 
Du beim Start von AVaRICE angegeben willst.

Dann must Du in einem Konsolenfenster (DOS) den AVaRICE starten 
(Portnumber beachten).
Danach kannst Du im Eclipse den Debugger aufrufen. Achtung! Wenn der 
Debugger beendet wird, dann beendet sich auch AVaRICE automatisch. Also 
vor jeder Debugsession AVaRICE neu starten. Man kann das starten des 
AVaRICE auch in Eclipse über External Tools einrichten.

So dann viel Spaß beim debuggen.

Hajo

Autor: Thomas Holland (innot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Martin,

ich habe jetzt über eine Stunde versucht das Problem zu reproduzieren, 
aber bei mir klappt es immer, egal was ich einstelle.

> In der Configuration 'Debug' läuftg mein Build vollständig durch.
> In der Configuration 'Release' bricht er beim ersten File ab.
> Grund ist, daß das File io.h aus dem avr-Verzeichnis nicht eingebunden
> wird.

Mich wundert auch, dass Du .../avr/include per Hand einbinden musst. 
avr-gcc hat den Pfad zu dem avr include Verzeichnis fest eingebaut, so 
dass man normalerweise nichts eingeben muss.

Gibt doch mal in einer Shell "avr-gcc -E -P -v deinFile.c" ein. Irgendwo 
am Anfang der Ausgabe sollte dann die Zeile
#include <...> search starts here:
 sein mit dem Eintrag
c:/WinAVR/bin/../avr/include

Wenn nicht ist möglicherweise etwas mit Deiner winAVR Installation nicht 
in Ordnung.

> Das Problen hatte ich ursprünglich auch in der Configuration 'Debug'
> Ich konnte es dort lösen, indem ich unter
> Properties -> C/C++Build ->Settings ->winAVR Compiler -> Directories
> den Eintrag
> "C:\WinAVR\avr\include"
> gemacht habe.
> Dieser Eintrag ist dann auch unter
> 'Properties -> C/C++Build ->Settings ->winAVR Compiler' rechts im
> Fenster 'all Options' zu sehen.
> Wenn ich nun in die Configuration 'Release' umschalte, ist unter
> 'Properties -> C/C++Build ->Settings ->winAVR Compiler' rechts im
> Fenster 'all Options' alles leer. Dies ist der Fall, obwohl ich auch
> hier unter
> 'Properties -> C/C++Build ->Settings ->winAVR Compiler -> Directories'
> den Eintrag
> "C:\WinAVR\avr\include"
> gemacht habe.
> Anscheinend wird in dieser Configuration die Eingabe nicht gespeichert.

Ich habe da mal eine Vermutung:
Schau doch mal in Eclipse, ob das Icon Deines Source-Files ein winziges 
Symbol "<>" in der oberen rechten Ecke hat.

Wenn ja, dann hat die Datei eigene Settings, die die Einstellungen in 
der Gesamtkonfiguration überschreiben. In diesem Fall musst Du die 
Compiler Settings für diese Datei getrennt ändern.

Wenn nein, dann habe ich im Moment keine weiteren Ideen.

brgds

Thomas

Autor: Ha Jo (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Thomas,

nochmal zu den Compileroptionen: die sind bei der Configuration
für "Release" einfach weg (All Options unter winAVR Compiler).
Ich habe Dir 2 Screenshots angehängt, einmal mit DEBUG und einmal
mit Release Configuation.

Da ist jetzt irgendetwas faul :-(

Gruß
Hajo

Autor: Ha Jo (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier der Anhang 2.

Hajo

Autor: Thomas Holland (innot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hajo,

OK... oder besser nicht OK.

Schick mir doch mal die ".cproject" Datei aus dem Projektverzeichniss. 
Darin sind alle Einstellungen gespeichert und vielleicht kann ich daraus 
erkennen, was da nicht richtig läuft.

Autor: Ha Jo (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Da ist die cproject-Datei im Anhang.

Gruß Hajo

Autor: Thomas Holland (innot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hajo, der Fehler lässt sich mit der Deiner .cproject Datei 
reproduzieren, d.h. wenn ich ein neues Projekt anlege und die .cproject 
Datei ersetze, dann habe ich den selben Fehler.
Ich habe aber noch keine Idee woran es liegen könnte. Werde mich mal 
heute Abend durch die Datei wühlen um zu sehen ob ich die Ursache für 
den Fehler lokalisieren kann.

Autor: Thomas Holland (innot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
OK, ich habe den Fehler gefunden.

Im Moment habe ich noch keine elgante, Plugin-Interne Lösung.

Eine Lösungsmöglichkeit ist die, ein neues Projekt anzulegen, alle 
Dateien rüberkopieren und alle Toolchain Einstellungen noch mal machen.

Zweite Möglichkeit:
Man kann den Fehler beheben, in dem man die .cproject Datei manuell 
bearbeitet:

1. Eclipse schliessen

2. In das Verzeichnis des betroffenen Projektes gehen und die Datei 
".cproject" mit einem beliebigen Texteditor öffnen.

3. Nach dem folgenden Text suchen (2x):
id="de.innot.avreclipse.compiler.option.debug.
(der Punkt und die fehlenden Anführungszeichen am Ende sind wichtig!)

4. Die gesamte Zeile, also von "<option" bis "/>" löschen.

Der Suchtext kommt zweimal vor, einmal für die Debug und einmal für die 
Release Configuration.

5. Eclipse starten. Die Settings sollten wieder funktionieren.

Dritte Möglichkeit: Auf 2.0.2 warten, aber das kann 3-4 Tage dauern bis 
ich mich in das Thema "projectConverter" eingearbeitet habe.


Hier eine kurzer Hintergrundinfo:
Jede Option in der Toolchain hat eine eigene ID, die im Plugin definiert 
ist und die in der Datei .cproject abgespeichert wird. Solange der 
default Wert der Option nicht geändert wird speichert CDT aber den Wert 
selbst nicht ab, sondern verweist auf original Toolchain aus dem Plugin 
und deren Default Value.

In den Versionen bis 2.0.0 gab es für den Compiler die Option -g (Debug 
info an) mit der id "de.innot.avreclipse.compiler.option.debug", die in 
2.0.1 entfallen ist und durch 
"de.innot.avreclipse.compiler.option.debug.level" ersetzt wurde, der 
Auswahl des Debug-Levels.

In Projecten, die mit 2.0.0 oder früher erstellt wurden existiert in 
.cproject aber noch der Verweis auf die alte Option. Solange diese mit 
einem Wert versehen ist (Debug Configuration) macht das nichts und CDT 
ignoriert den gespeicherten Wert einfach. In der Release Configuration 
ist aber normalerweise kein Wert gespeichert und CDT versucht den 
Default Wert  aus dem Plugin zu holen, welcher aber nicht mehr 
existiert. Folge -> Interner Fehler und es werden gar keine Optionen 
mehr verarbeitet.

Autor: Martin Thomas (marathon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Thomas,
habe Deinen Lösungsvorschlag 1 umgesetzt.
Funktioniert! vielen Dank.

@Hajo
Danke für die Tips zum debuggen.
Ich mache gerade erste Schritte mit dem Controller, habe noch keine 
Debug-HW.
Prorgrammiere mit TwinAVR und mini LPT-Adapter. (Werde mir Dragon 
anschaffen.)
Mein Anwendungsfall ist folgender:
Ich habe eine Elektor-Schaltung zur Wasserstandsmessung. Das Projekt ist 
aus 2004. Beim Compilieren der Sourcen mit modernem GCC hat es 
Fehlermeldungen gehagelt. Im wesentlchen implizite Typecasts die der 
neue Compiler anmeckert.
Ich wollte das Programm unabhängig von der Target-HW an den geänderten 
Stellen durchsteppen.
Die größte Aufgabe steht mir noch bevor: das Interrupt-Handling wurde 
von GCC3.x auf GCC4 geändert.

Gruß
Martin

Autor: Ha Jo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Martin Thomas wrote:
> @Hajo
> Danke für die Tips zum debuggen.

Bitte schön, ich will schon lange mal eine Anleitung schreiben und die 
in die Artikelsammlung packen, aber..... soviele Dinge mit höherer 
Priorität. :-(

> Ich mache gerade erste Schritte mit dem Controller, habe noch keine
> Debug-HW.
> Prorgrammiere mit TwinAVR und mini LPT-Adapter. (Werde mir Dragon
> anschaffen.)

Angebot - Ich hab noch einen neuen Dragon über. Gab es Weihnachten und 
ich hatte schon einen, was aber keiner wußte. Preisvorstellung: 45 Euro 
+ 6,90 Euro Versand (DHL). Das ganze bitte per Vorkasse oder Nachnahme. 
Habe sonst vor das Ding bei Ebay reinzusetzen. Also falls Du JETZT einen 
haben möchtest, dann einfach melden.

> Ich wollte das Programm unabhängig von der Target-HW an den geänderten
> Stellen durchsteppen.

Das kannst Du auch über Eclipse - AVR-GDB machen. Anstatt dem Dragon 
nimmst Du simulavr. Der Simulator gehört zum zum WINAVR Paket. Jetzt 
frage mich bitte nicht, wie das geht. KEINE AHNUNG. Mußt DU mal hier im 
Forum suchen bzw. die Doku zu WINAVR durchstöbern. Ich mag keine 
Simulatoren. Das ist mir doch zuviel Behelf.


> Die größte Aufgabe steht mir noch bevor: das Interrupt-Handling wurde
> von GCC3.x auf GCC4 geändert.

Das sind doch meines Wissens nur Änderungen der Namen der 
Interruptroutinen. Das ist sicher nicht sooo schwer. Hat auch eigentlich 
nichts mit dem GCC zu tun sondern eher mit der verwendeten AVR-LIB.
Nehme die Doku dazu: http://www.nongnu.org/avr-libc/

Dann viel Spaß
Hajo

Autor: Martin Thomas (marathon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ha Jo wrote:
> Angebot - Ich hab noch einen neuen Dragon über. Gab es Weihnachten und
> ich hatte schon einen,....
Hätte ich das gewusst, Dragon ist schon bestellt -:(
>> Die größte Aufgabe steht mir noch bevor: das Interrupt-Handling wurde
>> von GCC3.x auf GCC4 geändert.
>
> Das sind doch meines Wissens nur Änderungen der Namen der
> Interruptroutinen. Das ist sicher nicht sooo schwer. Hat auch eigentlich
> nichts mit dem GCC zu tun sondern eher mit der verwendeten AVR-LIB.
> Nehme die Doku dazu: http://www.nongnu.org/avr-libc/
>
> Dann viel Spaß
> Hajo
Danke für den Einstieg, mal sehen wie ich vorankomme.
Martin

Autor: Thomas Holland (innot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, die beiden gröberen Fehler des 2.0.1 releases sind gefixed (Verlust 
der Release Compiler Optionen und die NullPointer Fehler, wenn avr/io.h 
nicht gefunden wird).

Allerdings habe ich es noch nicht so weit testen können, dass es zu 
einem Release reicht. Im SVN repository sind sie drin, falls jemand es 
unbedingt austesten muss.

Ich gehe jetzt erst mal eine Woche Skifahren und danach werde ich mich 
dann an  Version 2.1 machen.

Thomas

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schönen Urlaub :-)

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habs jetzt auch seit einer Weile installiert, und es läuft (fast)
prima. Eine tolle Sache.

Ich habe eigentlich nur zwei Probleme, die aber vielleicht mit eclipse,
und nicht mit dem avr-plugin zu tun haben:

1.) Genau wie bei Claus speichert eclipse geänderte Dateien nicht vor
dem build-prozess.

2.) Die automatisch generierten makefiles berücksichtigen keinerlei
dependencies zu den header-Dateien. Ich meine, daß das mit einer älteren
Version funktioniert hat, aber mit den aktuellen eclipse CDT und
avr-plugin gehts nicht.

Beide Probleme können sehr unschöne Auswirkungen haben...

Bin ich nur zu blöd, kann man das irgendwo einstellen, oder geht das
wirklich nicht?

Oliver

Autor: Sven K. (skasko)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ZU 1)

Du musst unter Window->Preferences->General->Workspace den 
entsprechenden Haken setzen.

Gruß
Sven

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, Haken gesetzt. Danke.

Aber das andere Problem mit den fehlenden Dependencies bleibt. In den 
makefiles werden nirgendwo welche erzeugt oder ausgewertet. Und jedesmal 
ein clean vor dem make ist doch fehleranfällig.

Oliver

Autor: Sven K. (skasko)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich weiß jetzt nicht was Du damit meinst, für welche Header soll das 
gelten?

Sven

Autor: Markus Burrer (Firma: Embedit Mikrocontrollertechnik) (_mb_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was mir auch aufgefallen ist: im Outline View werden Headerfiles zwar 
angezeigt, aber wenn man Doppelklickt kann man sie nicht öffnen. Hier 
gibts anscheinend noch irgendwo ein Problem

Ich hab versucht mir das anzuschauen, aber ich kriegs nicht auf die 
Reihe. Müssen wohl warten bis Thomas wieder da ist

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Für alle header-Dateien aus dem Projekt. In den makefile(s) fehlt die 
info, welche .c-Dateien von welchen .h-Dateien abhängig sind, damit nach 
Änderungen in den header-Dateien alle .c-Dateien neu kompiliert werden, 
die von der Änderung betroffen sind.

Für Projekte mit nur zwei Dateien mag das egal sein, aber wenn es mehr 
werden, wird es umständlich und fehleranfällig.

Oliver

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Was mir auch aufgefallen ist: im Outline View werden Headerfiles zwar
>angezeigt, aber wenn man Doppelklickt kann man sie nicht öffnen.

Stimmt auch. Das hat mit der Vorversion funktioniert. Allerdings, wenn 
du im sourcefile auf den Headerfilenamne klickst, und dann rechte 
Maustaste, Open Declaration, auswählst, funktioniert es.

Oliver

Autor: Rainer K. (draugdel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Erstmals herzlichen Dank für das tolle Plugin, Thomas.

Ich verwende es unter Linux und es funktioniert soweit toll.

>Was mir auch aufgefallen ist: im Outline View werden Headerfiles zwar
>angezeigt, aber wenn man Doppelklickt kann man sie nicht öffnen.

Wenn sich das z.B. auf die "avr/io.h" bezieht, dann habe ich folgende 
Lösung gefunden: Ich habe unter den Projektsettings unter "winAVR 
Compiler", "Directories" den Pfad zu den Dateien angeben müssen (bei 
mir: "/usr/avr/include".
Für eigene Header im gleichen Verzeichnis hat es von Anfang an 
funktioniert.

Debuggen funktioniert soweit auch, ich habe es allerdings nur direkt auf 
der Hardware getestet. Den Simulator werde ich demnächst noch testen. 
Ich hätte allerdings den Vorschlag, eine Möglichkeit einzubauen, um 
avarice bzw. simulavr mittels "Pre debug command" laufen lassen zu 
können. Das wäre noch einmal eine gute Verbesserung.

Gibt es eine Möglichkeit die Standardeinstellungen für das Projekt zu 
ändern? Ich lasse mir die Hex-Files automatisch generieren, und damit 
diese vom avrdude-plugin erkannt werden, müssen sie "flash.hex" bzw. 
"eeprom.hex" heißen, damit ich nicht für jedes Projekt die Einstellungen 
ändern muss.

Hat irgendwer schon probiert, ein Projekt nur mit einer Assembler-Datei 
zu erstellen und diese auf der HW laufen zu lassen? Das hat bei mir noch 
gar nicht funkioniert.

Autor: Rainer K. (draugdel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mir ist zum Debuggen noch etwas eingefallen und das Editieren hat nicht 
geklappt:

Eine weitere Verbesserung wäre, die Möglichkeit die Register mittels 
"AVR Device Explorer" auslesen zu können. Momentan muss man dazu 
selbstständig die Adresse mittels Startadresse und Offset berechnen und 
dann in der Debug-Console "p/t *(char *)Adresse" eingeben, was doch 
etwas umständlich ist (vor allem im Vergleich zum AVR Studio).

Debuggen mittels Simulator ("simulavr") funktioniert auch.

Autor: Ha Jo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Rainer K. wrote:
> Gibt es eine Möglichkeit die Standardeinstellungen für das Projekt zu
> ändern? Ich lasse mir die Hex-Files automatisch generieren, und damit

Damit paßt es dann bei Dir und bei 100 anderen wieder nicht. Die 
nächsten anderen hätten gerne noch etwas anderes. Also kann es so 
bleiben, da es keine Option gibt, die dann bei allen paßt. (meine 
Meinung). Du mußt doch sowieso bei jedem neuen Project Einstellungen 
vornehmen (Faulpelz ;-) ).

> Eine weitere Verbesserung wäre, die Möglichkeit die Register mittels
> "AVR Device Explorer" auslesen zu können. Momentan muss man dazu
> selbstständig die Adresse mittels Startadresse und Offset berechnen und

Das geht auch bequemer. Im Eclipse Menu: Window->Show View -> Registers
kannst Du alle Register anzeigen lassen. Da ist also auch keine Änderung 
notwendig.

Ich meine Thomas muß wissen, was er einbaut an Schnörkel und was nicht.

Meine Meinung: Das Plugin so wie es ist erstmal lassen. Es dafür aber 
von den Bugs befreien. Daran liegt mir wesentlich mehr, als an weiteren 
Schnörkeln. Das Plugin macht alles, was man braucht um scho sehr bequem 
Code für die AVRs zu erzeugen. Wenn dann alle Bugs raus sind und es 
stabil und übersichtlich ist, dann kann man die Wunschliste durchgehen 
und das einbauen, was die meisten sich gerne zum nächsten Weihnachtsfest 
wünschen.

Happy programming....

Hajo

Autor: Rainer K. (draugdel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Ha Jo wrote:
> Damit paßt es dann bei Dir und bei 100 anderen wieder nicht. Die
> nächsten anderen hätten gerne noch etwas anderes. Also kann es so
> bleiben, da es keine Option gibt, die dann bei allen paßt. (meine
> Meinung). Du mußt doch sowieso bei jedem neuen Project Einstellungen
> vornehmen (Faulpelz ;-) ).

Anscheinend habe ich mich nicht genau genug ausgedrückt:
Ich wollte eigentlich nicht, dass die Standardeinstellungen des Plugins 
geändert werden, sondern meine Einstellungen im Workspace speichern 
können, um diese dann quasi als Template zu verwenden. Bis jetzt habe 
ich dafür noch keine elegante Möglichkeit in Eclipse gefunden. Momentan 
probiere ich, ein Templateprojekt mit den Einstellungen zu verwenden und 
dieses dann zu kopieren, vielleicht kennt jemand eine bessere 
Möglichkeit?

@ Faulpelz: Da hast du sicher recht, allerdings sehe ich nicht viel Sinn 
darin meine Zeit mit Projekteinstellungen, welche bei mir fast immer 
gleich sind, zu vergeuden. Besonders wenn ich statt dessen schon 
Programmieren könnte. ;)

> Das geht auch bequemer. Im Eclipse Menu: Window->Show View -> Registers
> kannst Du alle Register anzeigen lassen. Da ist also auch keine Änderung
> notwendig.

Bei der Register-View werden (bei mir: ATMEGA128) nur die Register 
r0-r32, sowie Stackpointer, SREG und PC angezeigt. Ich habe mich auf 
z.B. PORTS, TMISK usw. bezogen. Gibt es eine Möglichkeit diese Register 
zu definieren, damit ich sie bei der Register-View hinzufügen kann?

> Ich meine Thomas muß wissen, was er einbaut an Schnörkel und was nicht.
>
> Meine Meinung: Das Plugin so wie es ist erstmal lassen. Es dafür aber
> von den Bugs befreien. ...

Da stimme ich dir wieder zu 100% zu.

Rainer

Autor: Ha Jo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rainer K. wrote:
> Hallo!
> Anscheinend habe ich mich nicht genau genug ausgedrückt:
> Ich wollte eigentlich nicht, dass die Standardeinstellungen des Plugins
> geändert werden, sondern meine Einstellungen im Workspace speichern

Upps. So gut kenne ich Eclipse auch noch nicht, um dir das zu 
beantworten.

> Bei der Register-View werden (bei mir: ATMEGA128) nur die Register
> r0-r32, sowie Stackpointer, SREG und PC angezeigt. Ich habe mich auf
> z.B. PORTS, TMISK usw. bezogen. Gibt es eine Möglichkeit diese Register
> zu definieren, damit ich sie bei der Register-View hinzufügen kann?

Nein, ich weiß nicht, wo er die Registerdefinitionen hernimmt.
Du hast natürlich recht, es wäre auch schön, die anderen Register 
zusehen. Ich vermute mal, das komm evtl. vom GDB. Man müßte den nochmal 
studieren. Evtl. gibt der auch nicht mehr her.

>
>> Ich meine Thomas muß wissen, was er einbaut an Schnörkel und was nicht.
>>
>> Meine Meinung: Das Plugin so wie es ist erstmal lassen. Es dafür aber
>> von den Bugs befreien. ...
>
> Da stimme ich dir wieder zu 100% zu.

Fein :-)

Hajo

Autor: Thomas Holland (innot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, nach einer Woche Party (mit etwas Gleitsport-Rahmenprogramm) bin ich 
wieder wohlbehalten heimgekehrt.

Ich freue mich, dass mein Plugin noch nicht in Vergessenheit geraten ist 
und immer noch aktiv diskutiert wird :-)

Ich bin auch schon wieder aktiv und habe am Plugin gearbeitet (scheint 
eine art Sucht zu sein :-))

Aber nun zu Euren Problemen und Anregungen:

1. Header Files:
CDT benutzt ein sogenanntes "ScannerConfigurationDiscoveryProfile" um 
die verwendeten Header files zu finden.

Die CDT beigelegten Profiles rufen dazu den Compiler mit den Optionen 
"-E -P -v -dD" auf. Allerdings ist der Compiler per Default "gcc", nicht 
"avr-gcc". Wer einen "gcc" in seinem Pfad hat, bei dem sollte es auch so 
funktionieren, ansonsten muss man den Compiler manuell ändern:

In den Project-Properties unter "C/C++ Build" -> "Discovery options"
den "Compiler invocation command" von "gcc" auf "avr-gcc" setzen.
Wenn das Feld "Compiler invocation command" fehlt dann mal ein anderes 
"Discovery profile" auswählen.

Danach sollten im Outline View die kleinen Warndreiecke in der linken 
unteren Ecke der Headerfiles verschwunden sein und man kann z.B. im C 
Source mit F3 direkt zu den Headerfiles springen.

Ich habe schon mehrfach versucht, ein eigenes Discovery Profile für AVR 
zu erstellen, aber war bislang noch nicht erfolgreich, da die Erstellung 
eines eigenen Profiles praktisch nicht dokumentiert ist. Aber vielleicht 
schaffe ich es ja doch noch irgendwann...

2. Dependencies
CDT kennt grundsätzlich Dependencies. Ich war aber für meine mini- und 
test-Projekte mit einem clean build zufrieden, da ein clean build nur 
1-2 Sekunden gedauert hat. Daher habe ich mir noch nicht angeschaut, 
warum Dependencies derzeit nicht berücksichtigt werden.
Vielleicht liegt es an dem Discovery Profile (siehe oben). Werde ich mal 
bei Gelegenheit weiter nachforschen.

3. AVR Device Explorer zum Debuggen
Grundsätzlich würde es schon gehen und ist auch schon angedacht. Aber 
die gdb-Integration in Eclipse ist für mich noch Terra Incognita und ich 
werde mich erstmal um ein paar andere Sachen kümmern.
Auch ist avr/io.h als Datenquelle nicht optimal dafür geeignet, da 
zwischen einigen sub-types einer Serie nur per #ifdef unterschieden 
wird, was der Device Explorer derzeit nicht beachtet.

4. Default Name für flash und eeprom hex files
Ich hatte mich entschieden, die defaults "flash.hex" und "eeprom.hex" 
des alten Plugins durch "Projekt.hex" und "Projekt.eep" zu ersetzen, da 
dies auch der Standard der meisten sample-makefiles ist, die ich bisher 
gesehen habe.
Ich habe mich auch bewusst dafür entschieden, dies fest zu verdrahten 
und nicht durch den User änderbar zu machen, um eine mögliche 
Fehlerquelle für Anfänger auszuschliessen. Dies wird erst richtig zum 
tragen kommen, wenn avrdude wieder in das Plugin integriert ist.

5. Template Projekteinstellungen
Dies ist meines Wissens in CDT nicht vorgesehen und daher ist mir der 
Aufwand das zu Programmieren derzeit zu hoch, da sich ja jeder sein 
eigenes Template Projekt anlegen und mit einem schnellen Copy und Paste 
neue Projekte daraus erstellen kann.


So, ich hoffe ich habe jetzt alle offenen Punkte abgedeckt.

Ansonsten: Wenn möglich benutzt die "Bugs" und "Feature Requests" der 
Sourceforge Projektseite. Damit kann ich die offenen Punkte viel besser 
verfolgen und abarbeiten.


Jetzt werde ich als nächstes in das Thema Unit Tests einarbeiten, da das 
Plugin langsam so komplex wird, dass ich nicht mehr alles manuell testen 
kann. Danach geht es dann an die Version 2.1 mit neuen Features.

brgds

Thomas

Autor: Thomas Holland (innot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nachtrag zu den Dependencies:

Ich habe es mir angeschaut und es musste nur eine Zeile in plugin.xml 
geändert werden. Dependencies funktionieren jetzt und scheinen nach den 
ersten Tests auch gut zu funktionieren.

brgds

Thomas

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

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Weißt jemand ob man im avrdude plugin einstellen kann dass er kein 
eeprom.hex überträgt?
Ich kann mir nämlich kein eeprom.hex erstellen lassen wenn nichts im 
EEprom stehen soll. Oder kann ich eine Art Dummy-File erstellen?

Vielen Dank
Matthias Eder

Autor: Thomas Holland (innot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Direkt aus avr-objsplit.bat vom alten Plugin:
echo :00000001FF > eeprom.hex

Damit hast Du eine Dummy eeprom.hex (Windows / Linux evtl. mit cat statt 
echo).

Autor: Thomas Holland (innot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe eine erste Beta der neuen Version 2.1 bei SourceForge 
bereitgestellt.

Hier gibts mehr Details: 
Beitrag "AVR Eclipse Plugin 2.1 Beta Release"

Autor: Thomas Holland (innot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und jetzt ist auch die entgültige 2.1 raus.

Siehe Beitrag "AVR Eclipse Plugin 2.1 Released"

Autor: Julien (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich verwende auch gerade das Plugin in der Version 2.2
Weiterhin nutze ich WINAVR_20080610 und Eclipse 3.4 (Ganymede) inkl. 
C/C++ Developement.

Leider findet er beim compilieren sämtliche Include-Dateien nicht.
Sobald ich ein ein neues Projekt starte bindet er die Pfade von WINAVR 
ein.

Ich habe zum testen eine einfache LED blinken lassen.

Jedoch bekomme ich nach dem BUILD Vorgang folgende Fehlermeldungen:
../blink.c: In function 'main':
../blink.c:37: error: 'DDRC' undeclared (first use in this function)
../blink.c:37: error: (Each undeclared identifier is reported only once
../blink.c:37: error: for each function it appears in.)
../blink.c:37: error: 'PC0' undeclared (first use in this function)
../blink.c:42: error: 'PORTC' undeclared (first use in this function)
../blink.c:43: warning: implicit declaration of function '_delay_ms'


Gibt es bereits brauchbare Lösungen?

Gruß Julien

Autor: Thomas Spenger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!

Obwohl der Thread schon etwas älter ist:

Ich verwende das AVR plugin und konnte damit auch bereits übers STK500 
uns ISP AVRs problemlos programmieren.
Nun konnte ich ein mk II jtag ice auftreiben und damit funktioniert es 
einfach nicht.

Ich bekomme ständig eine Meldung, dass der Port geblockt bzw. von einer 
anderen instanz von AVR DUde oder einer anderen Anwendung benutzt wird.
Habe aber weder AVRStudio noch sonst etwas laufen, was darauf zugreifen 
könnte.

Kann mir jemand sagen, was es mit der Meldung auf sich hat bzw. wie sie 
zu beheben ist?!

Danke bereits im Voraus!

Lg;
Tom

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Um USB Programmer mit avrdude benutzen zu können musst du den libusb 
Filtertreiber installieren.
http://libusb-win32.sourceforge.net/#downloads
(der obere).

Autor: Thomas Spenger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke, das werd ich gleich mal ausprobiern! =)

Autor: Thomas Spenger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hmm , nur blöd, dass das Teil nicht unter Vista läuft.

--> für mich leider sinnlos ;-( aber danke!

Grüße,
Tom

Autor: Kim F. (kim_f)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin zusammen,

ich bin dabei von M$ auf Linuxprogrammierung umzusteigen. Habe jetzt 
Eclipse, das dazugehörige AVR Plugin sowie avr-gcc besorgt und 
installiert.
Eclipse lässt sich problemlos öffnen, jedoch hab ich das Problem, dass 
ich kein neues C (und auch kein anderes) Projekt erstellen kann. Ich 
gehe auf:
File-> new -> C-Project (empty Project mit gcc-toolchain) dann einen 
namen vergeben und auf next (auch schon finish probiert) aber es 
passiert nichts. Hatte dieses Problem schoneinmal jemand und kann mir 
helfen?

danke

Gruß Kim

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.