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
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
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
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
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
>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.
@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
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.
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
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
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
1
#include <...> search starts here:
sein mit dem Eintrag
1
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
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
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.
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.
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):
1
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.
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
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
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
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
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
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
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
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
>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
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.
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.
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
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
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
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
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
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
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:
1
../blink.c: In function 'main':
2
../blink.c:37: error: 'DDRC' undeclared (first use in this function)
3
../blink.c:37: error: (Each undeclared identifier is reported only once
4
../blink.c:37: error: for each function it appears in.)
5
../blink.c:37: error: 'PC0' undeclared (first use in this function)
6
../blink.c:42: error: 'PORTC' undeclared (first use in this function)
7
../blink.c:43: warning: implicit declaration of function '_delay_ms'
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
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
Thread beobachten
Seitenaufteilung abschalten