Hallo,
ich habe jetzt Version 2.3 meines Eclipse plugins für AVR zum Download
bereitgestellt.
Direkter Download:
http://sourceforge.net/project/showfiles.php?group_id=189165&package_id=221494&release_id=644246
Updatesite: http://avr-eclipse.sourceforge.net/updatesite/
Eigentlich wollte ich das User Manual noch etwas mehr vervollständigen,
aber wie schon bei Version 2.2 habe ich festgestellt, das mir das
Anleitung schreiben nicht genug Spaß macht und daher ist das Manual nur
minimal überarbeitet.
Gegenüber der Beta1 gibt es noch ein paar Bugfixes und die Funktion
"Upload to Target Hardware" dürfte jetzt um einiges schneller laufen.
Des weiteren habe ich noch die Links zu den Datasheets und die
Fuse-/Lockbyte Beschreibungsdateien auf dem neusten Stand gebracht.
Hauptneuigkeit ist natürlich der Fusebyte Editor. Wer die Beta1 noch
nicht ausprobiert hat kann sich auf
http://avr-eclipse.sourceforge.net/user%20manual/other/whatsnew.html mal
ein paar Screenshots dazu ansehen.
Ansonsten beschränken sich die Änderungen gegenüber Version 2.2 auf
Detailverbesserungen und Bugfixes.
Viel Spaß beim Fuse-Byte frickeln,
Thomas
> ... und nicht vergessen ältere "Eclipse plugins für AVR" aus dem> \eclipse\plugins Verzeichniss zu löschen.
Wenn man das Plugin über die Updateseite installiert hat (das 2.2er),
muss man dann auch von Hand was machen oder reicht da ein Update über
den Upd-Manager?
Grüße,
Chris
Hallo,
> Wenn man das Plugin über die Updateseite installiert hat...
keine Ahnung :-)
konnte bei mir keine Projekte mehr öffnen, bis alle
de.innot.avreclipse.*.* bis auf
de.innot.avreclipse.source_2.3.0.20081202PRD gelöscht waren.
Grüße aus dem verschneitem Odenwald
Hat noch irgend jemand das Problem, dass er erst die alte Version des
Plugins löschen musste?
An sich sollte es kein Problem sein mehrere Versionen eines Plugins im
Eclipse Verzeichnis zu haben. Eclipse nimmt immer die aktuellste Version
und ignoriert ältere.
Ich habe es mit 2.3 noch nicht getestet, aber bei älteren Versionen des
Plugins hatte ich oft 2 oder mehr Testversionen gleichzeitig im Eclipse
Verzeichnis und hatte nie Probleme damit.
@Gast: Welche Version von Eclipse benutzt Du? 3.3 (Europa) oder 3.4
(Ganymede)?
Hallo,
Version ist Ganymede.
Problem war das Eclipse beim öffnen der Projekteinstellungen
[Project->Proporties] mit einer Fehlermeldung abbrach [Object in XY not
found ..]
Werde mal versuchen das ganze nachvollziehbar zu machen
bis bald...
Ich habe, um dem vorzubeugen erst die Version 2.2 deinstalliert, dann
das Verzeichnis wie oben beschrieben gelöscht und dann über Eclipse
Update die 2.3 installiert.
Bisher hatte ich keine Probleme, allerdings ab ich auch noch nicht
kompilliert.
Vielen Dank für das Update!
Hi,
hab grad über den UpdateManager auf 2.3 geupdatet.
Neustart von Eclipse, auswählen der C-Perspektive, anklicken von Device
Explorer. Rattert ne Weile (liegt an meiner HD), dann kommt ein
Fensterchen mit Fehlern, oben ne Liste, in der sechs mal "Initialize
Indexing" steht und unten dann wenn man einen Eintrag ausgewählt hat:
Einträge 1 und 3 bis 6:
An internal error occurred during: "Initialize Indexing".
Could not initialize class de.innot.avreclipse.core.toolinfo.AVRDude
Eintrag 2:
An internal error occurred during: "Initialize Indexing".
java.lang.ExceptionInInitializerError
Dann hab ich im Project Navigator ein AVR-Projekt angeklickt, dann kommt
ein Fehler, ErrorLog (mehr steht in der direkten Fehlermeldung auch nich
drin ;) ) dazu im Anhang.
Löschen der alten Dateien/Ordner im Eclipse-Plugins-Ordner hat nicht
geholfen.
Grüße,
Chris
Hallo Chris,
ich habe jetzt gerade zum Test bestimmt ein duzend mal das Plugin in
allen Varianten installiert (mit Neustart, mit 'Apply Changes', mit/ohne
Update Manager etc.)
Und es hat jedesmal funktioniert, auch ohne das ich das alte Plugin
deinstallieren musste. (Alle Test mit einer jungfräulichen 'Eclipse for
C/C++ Developers' Edition)
Also ist es schon mal (für mich: Gott-sei-Dank) kein grundsätzliches
Problem sondern wird durch irgendwas spezifisches ausgelöst.
Die Java Exception die Du angehängt hattest ist auch seltsam. Sie
besagt, dass eine Java Klasse aus dem Plugin eine andere Klasse aus dem
Plugin nicht finden kann. Das sollte theoretisch nicht vorkommen, da die
Klasse ja definitiv vorhanden ist.
Da es aber bei Dir praktisch doch so ist würde ich mal sagen dass der
eigentliche Fehler irgendwo anders liegt als von der Exception
angedeutet.
Könntest Du mir bitte mal das komplette Error Log schicken ( Help ->
About Eclipse SDK -> Configuration Details -> View Error Log).
Vielleicht finde ich ja irgendwo den wahren Auslöser des Problems.
Hi Thomas,
irgendwie ist das merkwürdig ... kann nichtmal wenn ich in der
Java-Perspektive bin eine C-Datei anschauen ... Glaube der passende
Fehler ist der letzte im Log.
Grüße,
Chris
Chris,
ich glaube ich habe den Fehler gefunden (die Ursache war, wie ich
vermutet hatte, ganz am Anfang des Fehlerlogs für die Session zu finden)
Ich bin jetzt mal mutig und habe eine version 2.3.1 auf die Updatesite
hochgeladen.
Kannst Du mit der mal testen ob der Fehler immer noch existiert?
Hi Thomas,
hab das Update durchgeführt (dabei kamen gleich noch zwei Updates, die
dürften aber keine Auswirkungen gehabt haben, war irgendwas mit
Graphical Editing Framework oder so). Scheint soweit alles zu
funktionieren, also getestet hab ich kompilieren und Upload und in den
Project Properties etwas rumgeschaut. Der Start der IDE (bzw der
Abschnitt, wo auch das "Building Workspace" immer in der Statusleiste
erscheint) kommt mir auch schneller vor.
Wiedermal sehr gute Arbeit, die du da geleistet hast, vielen Dank =)
Grüße,
Chris
/Edit:
Was war denn das Problem (ohne, dass ich mich jetzt in die Untiefen der
Eclipse-Plattform einarbeiten muss um das zu verstehen ;) )?
Hellow,
danke fürs neue Plugin, super Sache!
Frage in die Runde: Gibt es eine Möglichkeit, den Code mit dem "PX-400"
auf den Target zu schreiben, beziehungsweise diesen Programmer in dem
Plugin zu betreiben? Leider habe ich dies bis Dato noch nicht fertig
gebracht (habe es mit diversen anderen Pogrammer-Treiber versucht).
Einen anderen Programmer zu nehmen wird wohl schwer möglich sein, ich
habe ca 40 PX-400 und die weg zu schmeissen macht keinen Sinn :)
Hallo Christoph,
Habe mal kurz etwas gegooglet. Der PX-400 funktioniert mit den Programm
avr osp II. Das ist eine Weiterentwicklung von avr-osp, auch als AVR911
bekannt.
Probier doch mal in den Peferences bei avrdude den "Atmel AppNote AVR911
AVROSP" als "Programmer Hardware" zu nehmen. Vielleicht klappt es damit
Hallo,
Ich bin gerade dabei einen Bootloader zu schreiben.
Wo kann ich dem AVR-Plugin eintragen, dass der Code erst ab der Adresse
0x1E000 beginnen soll?
Vielen Dank im Voraus.
Thomas Holland wrote:
> Habe mal kurz etwas gegooglet. Der PX-400 funktioniert mit den Programm> avr osp II. Das ist eine Weiterentwicklung von avr-osp, auch als AVR911> bekannt.>> Probier doch mal in den Peferences bei avrdude den "Atmel AppNote AVR911> AVROSP" als "Programmer Hardware" zu nehmen. Vielleicht klappt es damit
Hallo Thomas,
leider nein. Der Programmer arbeitet zwar offiziell mit AVR911, doch
keiner der vorgeschlagenen Programmer funktioniert wirklich.
Der PX400 hält sich nicht 100% an den AVR911-Standart, auf jeden Fall
werden mit dem mitgelieferten Programm andere Daten über die
RS-Schnittstelle gesendet als im Standart definiert...
Falls jemand interesse hat, kann ich gerne die Übertragung schicken,
habe das Protokoll schon ziemlich raus
Hi,
wollte mal fragen, ob es möglich ist, mit dem Plugin eine Library ohne
viel arbeit einzubinden.
Also, dass ich quasi ein Projekt habe, welche gemeinsamen Code enthält,
und ein weiteres (oder eben mehrere), die mit diesem Projekt verknüpft
sind und dann von dort die Header includieren können und auch
automatisch deren C-Code mitcompilieren. Also nicht eine Static-Lib (da
bräuchte ich ja dann jeweils eine Version pro uC-Typ/F_CPU) sondern dass
nur die Dateien in andren Projekten mit eingebunden/compiliert werden.
Grüße,
Chris
Christian,
hab gerade etwas rumprobiert. Linked Source Folders müsste die Antwort
Deines Problems sein.
Die Properties Deines Zielprojektes öffnen (nicht von der "Library")
Dann "C/C++ General -> Paths and symbols -> Source Location"
Dort dann "Create /link folder" anklicken.
In dem Dialog erst mal einen Namen eingeben z.B. "UARTLibrary"
Dann "Advanced>>" klicken und "Link to folder in the file system"
auswählen.
Dann per "Browse..." den Pfad zu Deinem Library Projekt auswählen.
Ein paar mal auf OK und Deine Library ist mit Deinem Zielprojekt
verlinkt.
Dann musst Du wahrscheinlich noch den neuen Link als Include-Pfad
aufnehmen.
Also nochmal "C/C++ General -> Paths and symbols" und dann "Includes".
"Add" Button und dann über den "Workspace..." Button in dem Zielprojekt
den neuen Ordner (z.b. "UARTLibrary") auswählen.
Ggf. noch "Add to all configurations" auswählen wenn Du mit mehreren
Build Configurations arbeitest.
Ansonsten "OK" und es sollte (hoffentlich) gehen.
Thomas
Hi Thomas,
danke für die schnelle Antwort =)
Irgendwas einfacheres gibt es da nicht? Vor allem, da man so ja auch
noch einen Dateisystem-Pfad angeben muss und nicht nur ein Pfad im
Workspace ausreicht.
Gibt es eigentlich irgendwo auch ne funktionierende Hilfe zum CDT und
dessen Dialogen? Wenn ich in den Dialogen auf das Fragezeichen klick
kommt meist nur "Topic not found" (oder so ähnlich).
Grüße,
Chris
Na ja, zwei Settings pro Projekt finde ich nicht wirklich aufwendig. Und
wenn Du im "Link folder" Dialog statt auf "Browse..." auf "Variable..."
klickst, dann kannst Du einmalig eine Variable zu dem Library-Projekt
anlegen und musst dich danach nicht mehr mit Dateisystem-Pfaden
auseinandersetzen. (Ich gebe aber zu, dass die CDT Entwickler in dem
Dialog den "Workspace" Button vergessen haben und es auch keinen Sinn
macht in dem Dialog nicht das Standard Variablensystem von Eclipse zu
benutzen)
Vielleicht gibt es noch einen einfacheren Weg, aber Du hast ja selbst
festgestellt das die Anleitung zu CDT etwas zu wünschen übrig lässt.
Wenn Du mit meiner Lösung nicht zufrieden bist kannst Du ja auch mal auf
der CDT User Newsgroup anfragen, vielleicht kennt da jemand eine bessere
Lösung:
http://www.eclipse.org/newsportal/thread.php?group=eclipse.tools.cdt
Hi Thomas,
sollte keine Kritik oder so an dir sein (nicht, dass das noch falsch
rüberkommt ;) ). Ich weis ja, dass für so Sachen die CDT-Entwickler
zuständig sind. Hatte nur gehofft, dass ich da einfach irgendwie sagen
kann "referenziere Projekt XY aus dem Workspace" und Eclipse/CDT den
Rest erledigt ;)
Werde deinen Ratschlag mal befolgen und bei CDT direkt fragen, ob die da
noch was wissen.
Grüße,
Chris
> Hatte nur gehofft, dass ich da einfach irgendwie sagen> kann "referenziere Projekt XY aus dem Workspace" und Eclipse/CDT den> Rest erledigt ;)
Die Funktion gibt es in CDT, allerdings wird dann das referenziert
Projekt mit seinen eigenen Einstellungen compiliert und nicht mit denen
des referenzierenden Projektes. Und wenn ich Dich richtig verstanden
habe wolltest Du genau das nicht.
Man könnte auch im 'Library'-Projekt mehrere Build Configurations
anlegen (für jeden MCU Typ eine) und von referenzierenden Projekt
jeweils auf eine bestimmte zugreifen (das ist, wenn ich es richtig
gesehen habe, sogar als "Feature" in CDT eingebaut).
Ist wahrscheinlich sogar eine sauberere Lösung, da man so auch mit
richtigen static Libraries arbeiten kann. Ist aber auch mit noch mehr
Aufwand verbunden.
>> Werde deinen Ratschlag mal befolgen und bei CDT direkt fragen, ob die da> noch was wissen.
Mach das und Berichte mal wenn es noch eine andere Lösung gibt. CDT ist
komplex und ich lerne auch gerne noch dazu.
>> Grüße,> Chris
LG, Thomas
Thomas Holland wrote:
> Man könnte auch im 'Library'-Projekt mehrere Build Configurations> anlegen (für jeden MCU Typ eine)
Gut, dass du das gerade ansprichst. Ich habe diesbezüglich ein kleines
Problem, wegen dem ich schon länger mal nachfragen wollte:
Wenn ich mehrere Build-Configurations anlege, habe ich immer(*) die
Warnung:
> Invalid project path: Duplicate path entries.
Irgendein funktionales Problem scheint sich daraus nicht zu ergeben,
aber diese ständige Warnung im Problems-Window ist irgendwie "unschön".
(*) Bei der ersten Configuration erstaunlicherweise nur manchmal.
Eclipse: 3.4.1
Plugin: 2.3.1
Eigenes Makefile (falls das relevant ist)
Stefan,
ich habe mal ein bisschen gegooglet. Die Fehlermeldung ist bekannt, aber
ich habe keine klaren Lösungen gefunden. Es ist aber ein CDT Problem,
das (anscheinend) nicht mit dem AVR Plugin zusammenhängt. Es gibt dazu
auch einen (offenen) Bug-Report:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=158940
So wie ich es verstehe erzeugt CDT eine Warnung, obwohl das Problem an
sich harmlos ist und ignoriert werden könnte. Sozusagen ein "-Wall", das
nicht abgeschaltet werden kann.
Die Meldung kommt wohl auch nur bei Projekten mit eigenem Makefile und
Leerzeichen im Projektpfad können der Auslöser sein, müssen es aber
nicht.
Ich habe gerade kein makefile Projekt zur Hand um die Warnung zu
reproduzieren und auch keine Zeit mehr am Wochende. Vielleicht schaue
ich es mir mal nächste Woche an.
Thomas
Thomas Holland wrote:
> ich habe mal ein bisschen gegooglet. Die Fehlermeldung ist bekannt, aber> ich habe keine klaren Lösungen gefunden.
Das war auch mein Google-Ergebnis. Ich hatte einfach gehofft, dass du
als "Insider" vielleicht noch einen heißen Tipp hättest. ;-)
> So wie ich es verstehe erzeugt CDT eine Warnung, obwohl das Problem an> sich harmlos ist und ignoriert werden könnte. Sozusagen ein "-Wall", das> nicht abgeschaltet werden kann.
Ja, wie gesagt, eher ein "Schönheitsfehler".
> Die Meldung kommt wohl auch nur bei Projekten mit eigenem Makefile und> Leerzeichen im Projektpfad können der Auslöser sein, müssen es aber> nicht.
Im Pfad selber sind bei mir keine Leerzeichen, sondern nur im
Projektnamen. (Die dort rauszunehmen ändert aber nichts)
> Ich habe gerade kein makefile Projekt zur Hand um die Warnung zu> reproduzieren und auch keine Zeit mehr am Wochende. Vielleicht schaue> ich es mir mal nächste Woche an.
Falls du tatsächlich da mal nach schauen möchtest, hier noch ein paar
Beobachtungen:
Man kann manchmal sehen, dass die Warnung während des Build kurz
auftaucht und dann zum Ende hin wieder verschwindet. Das
unterschiedliche Verhalten (Warnung nur manchmal oder immer) scheint
sich irgendwie am Make Target festzumachen:
1) Make Target steht mit im "Build Command", dafür unter "Workbench
Build Behavior" die Häkchen weg
-> Warnung immer
2) Make Target wird von Eclipse über "Workbench Build Behavior" selber
angehängt
-> Warnung nur manchmal
ABER:
Wenn ich im "Make Targets"-Window Targets anlege und den Build darüber
starte (mit Configuration 2), habe ich die Warnung wieder immer, obwohl
hier Eclipse das Target selber an das Build Command anhängt.
Ich hab noch eine kleine Anmerkung. Der Button "Upload Project to Target
Device" bzw der entsprechende Menueintrag hat erst funktioniert
nachdem ich einmal mit rechts auf das Projekt geklickt habe und dort
AVR->Upload Project to Target Device ausgewählt habe. Vorher hat er bei
einem Click auf den Button nur gesagt "No Project selected" oder so
ähnlich.
Außerdem wären zusätzliche Avrdude Funktionen recht hilfreich, zb einen
Button/Shortcut für Erase Device, da ich den Controller nach einem Test
meistens wieder löschen muss
Es ist nicht nötig, dass man vorher den kompletten Upload im Projekt
macht, aber wenn man den Button in der Toolbar benutzt muss natürlich
ein Projekt ausgewählt sein (ein Editor mit einer Datei aus dem Projekt
aktiv, oder der Eintrag im Projekt-Explorer markiert), sonst ist ja
nicht klar welches Projekt geflasht werden soll.
ich hatte nur ein Projekt offen. Das Projekt hatte nur eine Datei die
geöffnet und aktiv war. Kann natürlich sein das man das Projekt im
Projektexplorer aktivieren muss.
Mal noch eine Frage: wie behandelt das Plugin den Mega168 Efuse Bug von
avrdude? Ich hab leider grad keinen 168 griffbereit um das man schnell
zu testen
@Thomas Holland:
Vielen Dank, ich bin erst heute weider im Büro, war ein paar Tage auf
IBN.
Wegen dem Bootloader, ich hab es eingegeben und der hat es gemacht!
other Arguments: -Wl,--section-start=.text=0x1E000
Hallo MarkusB,
es ist so wie Manuel geschrieben hat: Es muss ein AVR Project oder eines
seiner Files im Project Explorer (oder Resource Navigator oder C/C++
Explorer) angewählt sein damit der "Upload" Toolbar Button funktioniert.
Was den ATmega168 "EFuse Bug" angeht, so habe ich jetzt von Dir zum
ersten mal davon gehört. Das Plugin hat (bisher) keine Sonderbehandlung
für den 168 oder irgendeinen anderen AVR Processor. Kannst Du
beschreiben worum es sich dabei genau handelt oder kennst Du eine Quelle
in der steht was das Problem ist?
@Markus,
gut zu hören. Vielleicht werde ich in einer der übernächsten Versionen
mal einen "Bootloader Project Wizard" hinzufügen, der diese Einstellung
automatisch vornimmt.
Hi Thomas,
avrdude ließt das Efuse Byte beim Mega168 falsch. Sämtliche Bits sind
invertiert soweit ich weiß. Ich glaube auch, er schreibt sie falsch.
http://savannah.nongnu.org/bugs/?23794
Es gibt dafür einen Bug Report. Hab aber gerade gelesen das er wohl im
November gefixt wurde. Vielleicht solltest du zumindest die Version von
Avrdude abfragen und darauf hinweisen oder so.
MarkusB, ich habe mal recherchiert und der Bug ist schon im Dezember
2005 im avrdude CVS repository behoben worden und dürfte seit avrdude
5.1 (Januar 2006) nicht mehr relevant sein. 5.1 wird aber selbst bei den
langsamsten Linux Distros schon lange Geschichte sein und daher lohnt
sich hier der Aufwand für eine Versionsabfrage nicht.
Hi Thomas,
also ich bin auf das Problem aufmerksam geworden weil es mir passiert
ist. Ich wollte Fusebits setzen und es ging nicht. Und da hatte ich
avrdude 5.5 (Ubuntu Hardy, avrdude-5.5-1)
Ich hab grad keinen funktionsfähigen 168 in Griffnähe, sonst würde ich
es nochmal probieren. Aber ich bin mir sicher das der Fehler erst mit
5.6cvs behoben ist. Leider krieg ich es nicht compiliert
Komisch!?
Der Fehler ist eindeutig 2005 behoben worden:
http://cvs.savannah.gnu.org/viewvc/avrdude/avrdude.conf.in?revision=1.67&root=avrdude&view=markup
Auch bei der ältesten winAVR die ich noch auf dem Rechner habe (20071221
mit avrdude 5.5) hat die avrdude.conf den Fehler nicht mehr. Und die
Version von Ubuntu hat auch eine gefixte avrdude.conf.
Hast Du vielleicht noch eine ältere avrdude.conf im /usr/bin oder
sonstwo rumliegen, die vor der aktuellen Version in /etc gefunden wird?
Die avrdude.conf aus deinem Link ist von 2005
avrdude.conf.in,v 1.67 2005/12/01 19:55:17
meine ist von 2007
avrdude.conf.in,v 1.127 2007/10/29 22:43:00
Der Fehler besteht bei mir definitiv noch. Ich habe es gerade getestet.
Ich vermute das irgendwem mal eine alte Version reingerutscht ist.
Ich habe jetzt meine avrdude.conf manuell geändert.
ich habe den Teil von Zeile 7990 bis 7995 durch das hier ersetzt
1
read = "0 1 0 1 0 0 0 0 0 0 0 0 1 0 0 0",
2
"x x x x x x x x o o o o o o o o";
3
4
write = "1 0 1 0 1 1 0 0 1 0 1 0 0 1 0 0",
5
"x x x x x x x x i i i i i i i i";
6
;
Wenn ich jetzt die Fusebits lese bekomme ich die richtigen Werte
MarkusB, wenn das so funktioniert und die bisherige Version mit nur drei
maskierten bits nicht, dann solltest Du den oben von Dir genannten Bug
Report wieder aufmachen denn er ist so nicht umgesetzt worden - auch
nicht bei avrdude 5.6 (da hat Jörg wohl - so wie ich - falsch verstanden
was bei dem Patch die funktionierende und was die nicht funktionierende
Version ist)
Hm, so war es auf jeden Fall. Ich hab die original avrdude.conf aus den
Quellen von Intrepid Ibex genommen. Mit den Original Dateien hatte ich
das Problem.
Anschließend hab ich die Änderung vorgenommen, jetzt funktioniert es.
Womöglich
Ich wollte nochmal zwei Verbesserungsvorschläge anbringen.
1. Button/Menu für Erase Device
2. Im Fuse Editor Buttons für Read Fuse und Write Fuse.
Es ist nicht sinnvoll in der Entwicklung jedes mal die Fusebits zu
schreiben. Manchmal ist es besser wenn man den Fuse Editor öffnet, die
gewünschten Einstellungen vornimmt, die Fusebits schreibt und danach
nichts mehr ändert. Derzeit ist es etwas umständlich
Atmel hat ja mittlerweile mit dem AVR32 Studio auch gemerkt, dass
Eclipse ein cooles Framework ist. Wäre es nicht sinnvoll, sich von den
Tools und vom Workflow her daran anzunähern?
Fürs flashen scheint hier ein extra Button links neben dem Debug-Button
angebracht zu sein. Auch das Registers und Targets View ist in meinen
Augen sinnvoll.
http://www.mikrocontroller.net/wikifiles/6/66/AVR_C_Perspective.png
Manuel, ich habe mir gerade mal AVR32Studio gesaugt und angeworfen.
Die Struktur mit den "Targets" ist doch recht anders und ich weiß nicht
in wie weit man die in das AVR Plugin integrieren kann. Aber ich werde
mir mal Gedanken machen ob ein Target zentrierter Workflow (anstatt des
im Moment Projekt zentrierten Workflows) Sinn macht.
Leider bin ich beim AVR Plugin, im Gegensatz zum AVR32Studio wo alle
Teile aus einer Hand kommen, auf externe Tools angewiesen und muss mich
nach deren Bedürfnissen richten und mit den Einschränkungen leben.
Beispiel: Ich schreibe gerade die Debugger Launch Configuration. Die
wird natürlich auch ein Image File zum Target hochladen können. Aber
über avarice geht das nicht mit meinem AVR Dragon (warum auch immer).
Also muss ich noch eine Option haben, mit der avrdude im Rahmen des
Debug-Starts vorab gestartet wird um das Image zu flashen. Allein dieser
Sonderfall lässt sich mit dem Target-Management von AVR32Studio nicht
darstellen.
Sicher? Da gibt es doch auch die Möglichkeit Übertragen und Debuggen zu
trennen. Schau dir mal Seite 19 hier drin an: AVR32015: AVR32 Studio
getting started
Da gibt es getrennt ein "Target" und einen "Launch provider". Das dürfte
eigentlich das gleiche Szenario sein.
Hi,
statt jetzt alles umzumodeln würde ich sagen es ist sinnvoller, das
Bedienkonzept so zu lassen wie es ist und die Kraft lieber in die
Erweiterung inwestieren. Es funktioniert ja so wie es jetzt ist und ich
sehe darin keinen Nachteil.
Nochmal danke an Thomas für die ganze Arbeit. Endlich gibt es für Linux
mal was richtig gutes um AVRs zu programmieren.
Keine Sorge, ich werde vorsichtig rangehen :-)
Ich bin nur beim Programmieren des Debugging Supports an einem Punkt
angekommen, an dem ich mir genau überlegen muss wie ich die vielen
möglichen Varianten ordentlich unter einen Hut bringen kann ohne das es
unübersichtlich wird. "Targets" á la AVR32Studio wäre eine Möglichkeit,
aber ich bin noch nicht so überzeugt das sie sich elegant implementieren
lassen.
Noch ein Vorschlag: vielleicht sollte man für AVR Entwicklung eine
eigene Perspective erstellen. Das AVR Menu und der Download Button sind
überall zu sehen, auch bei Datenbankentwicklung oder anderen Sachen
@ MarkusB
Du kannst dir auch ein Eclipse für C, eins für Java, eins für ... auf
die Platte packen.
Ich finde das übersichtlicher und ist nicht so fehleranfällig.
Was spricht dagegen? Der Platz auf deiner Festplatte?
Ich weiß das das geht, aber wie Manuel gesagt hat, wenn dein AVR Projekt
aus einem Teil AVR und einem Teil PC besteht ist das Wechseln nervig.
Und am PC arbeite ich nicht mit C/C++ sondern mit Python.
Außerdem, wenn schon gewünscht wird das man sich an den Look & Feel von
Eclipse nähert und so macht wie beim AVR32 Studio ist das mit den
Buttons doch eher ne Kleinigkeit.
Es reicht mir eigentlich wenn ich einmal Eclipse für Web, für "normale"
Programmierung und das AVR32 Studio hab.
Simon K. wrote:
> Hab grad nochmal ein Feature Request abgedrückt: Gnu99 Language Standard> als Default benutzen.
Und was soll gemacht werden, wenn jemand anderes gerne einen anderen
Standard als default haben möchte? So ein Default ist in meinen Augen
völlig sinnfrei. Es muß nicht einmal einen Default geben. Du mußt ja
sowieso durch die Project-Optionen durch und diverse Dinge einstellen.
Da wo es Sinn macht, da sollte man einen Default nehmen (stabs als
Debug-Info z.B., weil man sonst garnicht debuggen kann unter Eclipse).
Alle anderen Optionen , die nicht solcher Art sind, brauchen keinen
default Wert.
Die Default-Werte bergen auch die Gefahr, dass man sein Hirn abschaltet
beim Einstellen der Project-Optionen. Und schon geht erstmal etwas
nicht.
Selbst die Möglichkeit seine bevorzugten Einstellungen abzuspeichern ist
sinnfrei, da sich im nächsten Projekt sowieso wieder fast alles ändert
und du deinen Kopf sowieso damit beschäftigen mußt.
Also lange Rede kurzer Sinn: Solche Requests vielleicht nicht loslassen,
da sie von wirklich wichtiger Arbeit ablenken und damit Zeit stehlen.
Just my 2 cts.
Schöne Weihnachten :-)
Gruß
900ss
900ss D. wrote:
> Also lange Rede kurzer Sinn: Solche Requests vielleicht nicht loslassen,> da sie von wirklich wichtiger Arbeit ablenken und damit Zeit stehlen.
Ob der Request vernünftig ist oder nicht, kann Thomas ja auch selber
noch entscheiden, wenn er da ran geht.
Ich sehe gerade nur nicht, warum man überhaupt mit was anderem als Gnu99
im Normalfall kompilieren sollte? Nur mit Gnu99 ist volle Kompatibilität
zur avr-libc gewährleistet und Nachteile hat es (soweit ich das sehe)
keine.
Außerdem ist ja wohl kaum großartig einen Umstand das einzubauen.
PS: Man kann ja auch ein Default "Template" machen. Das stellt man dann
einmalig ein und jedes erzeugte C Projekt erhält die Einstellungen des
Templates.
Wie auch immer. ;)
Simon K. wrote:
> Ob der Request vernünftig ist oder nicht, kann Thomas ja auch selber> noch entscheiden, wenn er da ran geht.
Das kostet schon Zeit, sich darüber Gedanken zu machen :-)
> PS: Man kann ja auch ein Default "Template" machen. Das stellt man dann> einmalig ein und jedes erzeugte C Projekt erhält die Einstellungen des> Templates.
Dann mach es doch so. Spart zumindest Thomas Arbeit.
Ich habe meine Meinung schon geäußert und bleibe dabei. Du must dein
Hirn eh benutzen. Copy&Paste gibt gerne Fehler, auch mit so einem
Template :-)
Natürlich steht es jedem frei, Wünsche zu äußern. Nur mich stört es,
wenn es Wünsche sind, die "nice to have" sind und damit Zeit
"verschwenden".
900ss D. wrote:
>> PS: Man kann ja auch ein Default "Template" machen. Das stellt man dann>> einmalig ein und jedes erzeugte C Projekt erhält die Einstellungen des>> Templates.>> Dann mach es doch so. Spart zumindest Thomas Arbeit.
Leider gibt es so eine Funktionalität nicht.
> Ich habe meine Meinung schon geäußert und bleibe dabei. Du must dein> Hirn eh benutzen. Copy&Paste gibt gerne Fehler, auch mit so einem> Template :-)
Wieso gibt es denn Fehler wenn man mit Gnu99 standardmäßig kompiliert?
Das ist ja jetzt wohl völlig aus der Luft gegriffen. Gnu99 hat einfach
nur mehr Sprachfeatures als C90 (der Compiler Standard), das ist alles.
> Natürlich steht es jedem frei, Wünsche zu äußern. Nur mich stört es,> wenn es Wünsche sind, die "nice to have" sind und damit Zeit> "verschwenden".
Genau aus dem Grund ist es ja auch als Feature Request eingestellt und
nicht als Bug. Ich gehe mal davon aus, dass Bugs wesentlich dringender
behandelt werden. Außerdem hast du immer noch nicht schlüssig begründet
wo denn genau das Problem bei der Sache ist. Ich sehe da nur Vorteile
durch (gerade für Anfängern, die dann die avr-libc benutzen und eine
"verwirrende" Fehlermeldung bekommen, dass der eingestellte Standard das
nicht unterstützt).
Warum sollte man denn überhaupt noch in ANSI-C programmieren und nicht
nach dem neuesten Standard?
Egal, Thomas wird dazu sicher irgendwann mal eine Entscheidung fällen.
Simon K. wrote:
> 900ss D. wrote:>>> PS: Man kann ja auch ein Default "Template" machen. Das stellt man dann>>> einmalig ein und jedes erzeugte C Projekt erhält die Einstellungen des>>> Templates.>>>> Dann mach es doch so. Spart zumindest Thomas Arbeit.> Leider gibt es so eine Funktionalität nicht.
Doch, du kannst dir ein "Standard-Projekt" anlegen und von diesem immer
eine Kopie machen, wenn du ein neues Projekt brauchst.
>> Ich habe meine Meinung schon geäußert und bleibe dabei. Du must dein>> Hirn eh benutzen. Copy&Paste gibt gerne Fehler, auch mit so einem>> Template :-)> Wieso gibt es denn Fehler wenn man mit Gnu99 standardmäßig kompiliert?> Das ist ja jetzt wohl völlig aus der Luft gegriffen. Gnu99 hat einfach> nur mehr Sprachfeatures als C90 (der Compiler Standard), das ist alles.
Nun mach mal halb lang. Habe ich das irgendwo geschrieben? Sag mir wo
bevor du dich so aufregst. Ich schrieb das Copy&Paste gerne Fehler gibt.
Auch wenn du ein Standardprojekt anlegst und dieses kopierst. Es ist
immer besser (auch beim kopieren) ohne Copy&Paste zu arbeiten. Man
übersieht leicht etwas und schon sucht man evtl. lange Fehler die nicht
da wären, wenn man vornherein sein Hirn benutzt hätte um den
entsprechenden Part (Projekt) mit allen Einstellungen neu zu generieren.
Dann hätte man es gleich richtig gemacht.
> Genau aus dem Grund ist es ja auch als Feature Request eingestellt und> nicht als Bug. Ich gehe mal davon aus, dass Bugs wesentlich dringender> behandelt werden. Außerdem hast du immer noch nicht schlüssig begründet> wo denn genau das Problem bei der Sache ist.
Doch oben. Aber ich habe den Eindruck, du hast mich nicht verstanden.
> Ich sehe da nur Vorteile> durch (gerade für Anfängern, die dann die avr-libc benutzen und eine> "verwirrende" Fehlermeldung bekommen, dass der eingestellte Standard das> nicht unterstützt).
Gerade für Anfänger ist soetwas meiner Meinung nach nicht so gut. Wenn
man Anfängern alles vorkaut, dann lernen sie nicht (verstehen auch
nicht) und bei einem Problem kommen sie dann alleine auch nicht weiter.
> Warum sollte man denn überhaupt noch in ANSI-C programmieren und nicht> nach dem neuesten Standard?
Hat das irgendwo einer geschrieben?
> Egal, Thomas wird dazu sicher irgendwann mal eine Entscheidung fällen.
Sicher, am Ende ist es Thomas sein Ding. Aber bevor meiner Meinung nach
"nice to have" Features dort eingebaut werden, sollten andere Dinge
gemacht werden.
Ich frag mich auch, was so schlimm daran ist, die Einstellung mit der
Hand zu machen. Gehst du nicht sowieso durch die Einstellungen? Must du
doch. Paßt doch eh wenig. Oder hast Du standardmäßig immer eine
Taktfrequenz von 1MHz? Die bietet das Plugin immer an bei einem neuen
Projekt.
Und immer ruhig mit den Pferden ;-)
Atmega8 Atmega8 wrote:
> @ 900ss> Ich will auch dass Gnu99 als Default gesetzt wird.>> .. nicht traurig sein dass du überstimmt wurdest :)
Nöö, bin ich nicht. Kein Problem. Meinetwegend kann da auch was rein was
garnicht funktioniert. Ich gehe eh alle Einstellunge durch und überlege
mir, was da rein soll wenn ich ein Projekt anlege.
Was mich allerdings traurig stimmt, dass Ihr kein wirklich greifendes
Argument habt. Alles nur nach dem Motto "Ich möchte aber, weil ich es
schön finde". Das wäre so als wenn ich wollte, dass immer 16MHz als
default gesetzt werde. Und als Prozesor verwende ich gerne den ATMEGA32.
Den hätte ich auch gerne. Einfach Blödsinn. Normalerweise sollte
nirgends ein default gesetzt werden, damit man seinen Kopf benutzt. Alle
Felder einfach leer.
Ich find es schade, dass hier "Arbeitszeit" verplempert werden soll wo
man doch viel sinnvolleres damit machen könnte. Am Ende ist es auch
Thomas sein Ding.
Gruß
900ss
900ss D. wrote:
> Was mich allerdings traurig stimmt, dass Ihr kein wirklich greifendes> Argument habt.
Sorry, auch wenn Weihnachten ist, aber langsam ist mal gut, oder?
> Alles nur nach dem Motto "Ich möchte aber, weil ich es> schön finde".
Ja, meine letzten Posts gehen genau nach dem Motto. Ansonsten noch einen
Tipp: Augen auf und lesen lernen.
> Das wäre so als wenn ich wollte, dass immer 16MHz als> default gesetzt werde. Und als Prozesor verwende ich gerne den ATMEGA32.> Den hätte ich auch gerne. Einfach Blödsinn.
Genau! Immer drauf da.
> Normalerweise sollte> nirgends ein default gesetzt werden, damit man seinen Kopf benutzt. Alle> Felder einfach leer.
Ums nochmal zu wiederholen, mein Argument war: Gnu99 als Default zu
setzen, damit das AVR-GCC Plugin kompatibel zur avr-libc ist (man
bemerke den nicht nur im Namen vorhandenen Zusammenhang zwischen dem
Plugin und der Bibliothek).
Simon K. wrote:
> Sorry, auch wenn Weihnachten ist, aber langsam ist mal gut, oder?
Ich schrieb ja schon, immer locker bleiben :-)
> Tipp: Augen auf und lesen lernen.
s.o.
>> Den hätte ich auch gerne. Einfach Blödsinn.> Genau! Immer drauf da.
Hmm... frage mich wer hier drauf haut und ein wenig persönlich wird.
> Ums nochmal zu wiederholen, mein Argument war: Gnu99 als Default zu
Ich hab dich schon verstanden (kann ja lesen ;-)) aber du verstehst mich
scheinbar nicht.
Allerdings wird mir dein "Ton" etwas zu unsachlich und er läßt Ärger
durchblicken. Dafür gibt es bisher keinen Grund. Deshalb ziehe mich dann
mal zurück. Und wiederholen möchte ich mich auch nicht.
Ende der Diskussion von mir aus. Schlaf gut :-)
Naja 900ss D. möchte halt bei jedem neuen Projekt seine Festplatte
formatieren und das System neu aufsetzen um sich dann alles ganz genau
so einzustellen, wie es sein Projekt benötigt. Aus einem gewissen
Blickwinkel kann ich das schon verstehen...
Mike J. wrote:
> @ Simon K. / 900ss D.> Ihr beiden habt der Thread von Thomas Holland ganz schön vollgemüllt.> :)
Stimmt zum Teil leider. :-( Aber damit stehen wir ja nicht alleine da
:-)
Ist man mal ein paar Tage offline und schon geht es hier drunter und
drüber :-(
Ich habe nur wenig Zeit, deshalb fasse ich micht kurz:
900ss, ich schätze Deine konservative Einstellung was Änderungen angeht
und ich weiß aus unserem privatem Austausch warum Du gegen die
vorgeschlagene Änderung des default Language Standards bist.
Ich halte mich bei der Entscheidung an folgende Grundsätze:
1. Die Eclipse UI Guidelines: Möglichst wenig Einstellungsmöglichkeiten
und dort wo unvermeidbar einen sinnvollen Standard wählen.
2. Minimierung meines Support Aufwandes (Bisher 2 Anfragen bei denen
gnu99 die Lösung war)
3. Was macht mfile? Das makefile template von mfile war bisher für mich
immer der Maßstab was Entscheidungen zu Compiler und Linker Optionen und
deren Defaults angeht. Und hier ist eindeutig "gnu99" der Standard.
Damit spricht alles dafür "gnu99" als Standard zu setzen, es sei denn es
kann mir jemand eine technische Begründung dagegen liefern.
Die Änderung des Default Language Standards ist ein Einzeiler in der
plugin.xml und ich werde es mit der nächsten Version ändern.
Damit ist dieses Thema (hoffentlich) durch und wir können uns alle bitte
wieder ernsthafteren Themen zuwenden.
Weihnachtliche Grüße,
Thomas
(Nach Diktat verreist bis Sonntag)
Bei mir geht leider die 2.3 nicht, weil er irgendwie nicht auf den
System Path beim erstellen eines neuen Projektes zugreifen kann. Auch
bei Preferences kann ich nicht auf AVR zugreifen...
Hallo Thomas,
hatte gerade das Problem, dass mir ein MEGA164P nicht mehr angeboten
wurde in Project.Properties.AVR.Target Hardware.
"Load from CPU" klappte auch nicht. "Target nicht unterstützt" kam von
AVRDude. Hmmm... Dann festgestellt, dass AVRDude von einer alten
WinAVR-Verison genutzt wurde. Hatte irgendwann mal den Pfad, der
eigentlich genutzt werden sollte, geklaut und dann ist durch die
automatische(?) Suche vom Plugin wohl unter der alten WinAVR-Version ein
AVRDude gefunden worden und das hat er dann genutzt.
Ich bekomme es aber nicht wieder gerade gebogen. Habe schon den alten
Pfad (Directory der alten WinAVR-Version) umbenannt, aber irgendwie hat
er nie wieder nach neuen Pfaden gesucht.
In Window.Preferences.AVR.Paths standen auch die alten WinAVR-Pfade,
obwohl die garnicht mehr existierten. Es gab natürlich eine
Fehlermeldung in dem Fenster, dass die Pfade nicht gültig sind.
Irgendiwe habe ich es nicht hinbekommen, dass er wieder den richtigen
Pfad nimmt (c:\programme\winavr).
Dann habe ich die Pfade dort manuell eingetragen.
Ein Umschalten der Checkbox "Disable search for system paths at startup"
hat auch nicht genutzt.
Was hab ich falsch gemacht? Hast du eine Ahnung? Ich fürchte da ist noch
ein Bug.
Danke für die Antwort schonmal.
Gruß 900ss
Hi,
so auf Anhieb fällt mir dazu nichts ein. Ich werde wohl mal den Debugger
anschmeißen müssen um zu schauen was da genau passiert (sein könnte).
Aber als Quick-Fix damit es bei Dir wieder läuft:
Die Pfade werden in der folgenden Datei gespeichert:
{Dein
Workspace}\.metadata\.plugins\org.eclipse.core.runtime\.settings\de.inno
t.avreclipse.core.prefs
Eclipse schließen und einfach die Datei öffnen und die Pfade manuell
ändern (aufpassen mit den ganzen forward- und backslashes). Vorher noch
die "Disable search for system paths at startup" Option setzen, damit
das Plugin die Pfade nicht wieder automatisch überschreibt.
Dann sollte es wieder gehen.
Thomas
Thomas Holland wrote:
> Die Pfade werden in der folgenden Datei gespeichert:>> {Dein> Workspace}\.metadata\.plugins\org.eclipse.core.runtime\.settings\de.inno
t.avreclipse.core.prefs
Danke für die Hilfe.
Hmmm... Ich habe ja die Pfade schon manuell unter Eclipse in
"Window.Preferences.AVR.Paths" eingetragen. Dort steht jetzt unter der
Spalte "Source" Custom. Hat das nicht den gleichen Effekt? Funktioniert
hat es damit.
Ich habe allerdings in der von dir angegeben Datei trotzdem noch alte
ungültige Pfade gefunden. Wo die genutzt werden, weiß der
Plugin-Entwickler ;-)
Gruß
900ss
Hab nochmal einen anderen Versuch gemacht, der aber auch scheiterte.
Ich habe die "prefs" Datei nicht angefaßt.
Wenn ich jetzt wieder mit "Edit" in "Window.Preferences.AVR.Paths" auf
System umschalte steht der ungültige Pfad darin. In dem Fenster steht
dann auch "Path is invalid". Also wenn er sich mal verrannt hat, dann
gibt es scheinbar keine Möglichkeit mehr, da rauszukommen.
Es gibt also nur noch die Möglichkeit, mit der Einstellung "Custom" und
dann die Pfade manuell eintragen. So läuft es bei mir jetzt.
Ich habe dir mal die Datei angehangen, evtl. hilft es dir ja.
Gruß 900ss
Da hatte ich Dich falsch verstanden - ich dachte Custom würde auch nicht
funktionieren.
Bei Windows versucht das Plugin die Pfade automatisch aus der Registry
zu lesen. Bei Dir ist dort offensichtlich noch ein Eintrag für die alte
Version gespeichert (alte Version nur gelöscht und nicht korrekt
de-installiert?)
Starte mal 'Regedit' und hangele Dich zu
"HKEY_LOCAL_MACHINE\SOFTWARE\WinAVR" durch. Dort findest Du
wahrscheinlich noch einen Eintrag mit 'WinAVR_20060125'. Den könntest Du
dann löschen.
Wenn da nichts ist dann kannst Du noch mal unter
"HKEY_LOCAL_MACHINE\SOFTWARE\Free Software Foundation" schauen, dort
sollte es dann einen Ordner 'WinAVR_20060125' geben, den Du auch löschen
könntest.
Leider ist das Plugin in der Hinsicht etwas simpel Programmiert,
insofern es immer nur den letzten Eintrag aus den entsprechenden
Registry Keys nimmt und nicht weiter testet, ob sie auch valide sind.
Aber wirklich dramatisch ist es ja nicht, da man immer mit 'Custom
Paths' die Auto-Erkennung überschreiben kann. Wenn ich mal zu viel Zeit
haben sollte werde ich mir die Funktion noch mal anschauen ob man sie
ohne allzugroßen Aufwand etwas verbessern kann.
Thomas Holland wrote:
> Bei Windows versucht das Plugin die Pfade automatisch aus der Registry> zu lesen. Bei Dir ist dort offensichtlich noch ein Eintrag für die alte> Version gespeichert (alte Version nur gelöscht und nicht korrekt> de-installiert?)
Nein, aber die alte glaube ich zuletzt installiert (neben den anderen).
Ich installiere immer in c:\pr..\WinAVR. Danach mach ich ein Rename des
Verzeichnisses und aktiviere die gewünschte. Ist wohl was
schiefgegangen.
> Starte mal 'Regedit' und hangele Dich zu> "HKEY_LOCAL_MACHINE\SOFTWARE\WinAVR" durch. Dort findest Du> wahrscheinlich noch einen Eintrag mit 'WinAVR_20060125'. Den könntest Du> dann löschen.
Da war es OK.
> Wenn da nichts ist dann kannst Du noch mal unter> "HKEY_LOCAL_MACHINE\SOFTWARE\Free Software Foundation" schauen, dort> sollte es dann einen Ordner 'WinAVR_20060125' geben, den Du auch löschen> könntest.
Da waren 3 Verzeichnisse:
WinAVR zeigte auf die alte Version 'WinAVR_20060125'
WinAVR_200812xx zeigte auf 'WinAVR'
WinAVR_200812x1 zeigte auf 'WinAVR'
Habe jetzt noch einen Eintrag WinAVR.
In Eclipse ist auch wieder alles OK.
Danke für den Tip.
> Leider ist das Plugin in der Hinsicht etwas simpel Programmiert,
Hmmm... nun ja, wer rechnet auch mit soviel Spieltrieb bei den Anwendern
;-)
> Paths' die Auto-Erkennung überschreiben kann. Wenn ich mal zu viel Zeit> haben sollte werde ich mir die Funktion noch mal anschauen ob man sie> ohne allzugroßen Aufwand etwas verbessern kann.
Hast du noch Zeit? Ich meine bastelst du immer noch am Debug-Plugin?
Es ist ganz schön still geworden hier.
Gruß
900ss
900ss D. wrote:
> Nein, aber die alte glaube ich zuletzt installiert (neben den anderen).> Ich installiere immer in c:\pr..\WinAVR. Danach mach ich ein Rename des> Verzeichnisses und aktiviere die gewünschte. Ist wohl was> schiefgegangen.
Nein, das Plugin nimmt immer den letzten Eintrag aus der Registry (in
der Annahme das die zuletzt installierte Version die jeweils neuste
ist).
Das Du eine ältere Version nachinstallierst ist so nicht vorgesehen :-)
> Hast du noch Zeit? Ich meine bastelst du immer noch am Debug-Plugin?
Ja. Allerdings habe ich etwas größer ausgeholt und bin jetzt erst mal
dabei ein Target Management zu schreiben mit dem man zentral alle
Einstellungen für avrdude, avarice, simulavr etc. vornehmen kann.
Damit braucht man für jede Debug Launch Configuration nur noch das
jeweilige Target anzugeben (bzw. ein Projekt mit einer verbundenen
Target Configurtion) und muss nicht mehr alles einzeln konfigurieren.
(Siehe angehängten Screenshot)
Das ganze ist aber recht umfangreich und es wird noch eine Weile dauern
bis es fertig ist.
>> Es ist ganz schön still geworden hier.
Ja! Ich hoffe mal das es ein gutes Zeichen ist und das Plugin einfach so
gut funktioniert das kaum noch Probleme auftreten.
Thomas Holland wrote:
> Das Du eine ältere Version nachinstallierst ist so nicht vorgesehen :-)
Aha. :-)
> Damit braucht man für jede Debug Launch Configuration nur noch das> jeweilige Target anzugeben (bzw. ein Projekt mit einer verbundenen> Target Configurtion) und muss nicht mehr alles einzeln konfigurieren.
Mann mann mann. Möge dir nicht die nötige Motivation ausgehen :-)
> (Siehe angehängten Screenshot)
Da bin ich schon drauf gespannt.
>> Es ist ganz schön still geworden hier.>> Ja! Ich hoffe mal das es ein gutes Zeichen ist und das Plugin einfach so> gut funktioniert das kaum noch Probleme auftreten.
Du hast ja auch eine gute Hilfe unter SF installiert. Scheint etwas zu
helfen :-)
Danke nochmal.
Thomas Holland wrote:
>> Es ist ganz schön still geworden hier.>> Ja! Ich hoffe mal das es ein gutes Zeichen ist und das Plugin einfach so> gut funktioniert das kaum noch Probleme auftreten.
Ganz genau so ist es.
Simon K. wrote:
> Thomas Holland wrote:>>> Es ist ganz schön still geworden hier.>>>> Ja! Ich hoffe mal das es ein gutes Zeichen ist und das Plugin einfach so>> gut funktioniert das kaum noch Probleme auftreten.>> Ganz genau so ist es.
Dem kann ich mich nur anschliessen! Einfach nur eine super Arbeit,
Thomas. Vielen Dank dafür.
Markus
Hallo Thomas,
das Problem hat sich inzwischen in Luft aufgelöst, das AVR-Plugin läuft
jetzt auch bei mir ganz prima. Warum ich diese Fehlermeldung bekam, weiß
ich allerdings immer noch nicht.
Kann es sein, dass die Updateseite nur funktioniert, wenn man das Plugin
zunächst von
http://sourceforge.net/project/showfiles.php?group_id=189165&package_id=221494&release_id=644246
herunterlädt und von Hand installiert? Das habe ich nämlich gemacht und
seitdem ist auch die Fehlermeldung weg.
Gruss
Andreas
> Kann es sein, dass die Updateseite nur funktioniert, wenn man das Plugin> zunächst von> http://sourceforge.net/project/showfiles.php?group_id=189165&package_id=221494&release_id=644246> herunterlädt und von Hand installiert?
Nein, es sollte auch direkt gehen und hat in der Vergangenheit auch
immer funktioniert.
Ich vermute mal, dass SourceForge an dem Tag, als Du es versucht hast,
einen Schluckauf hatte und kurzzeitig Datenmüll geliefert hat.
Hallo,
>Ich vermute mal, dass SourceForge an dem Tag, als Du es versucht hast,>einen Schluckauf hatte und kurzzeitig Datenmüll geliefert hat.
ja so ist es, scheint aber nicht nur SourceForge betroffen zu haben.
Hier im 061xx Bereich war Internet die letzten Tage Glücksache.
MfG
Falls es noch niemand probiert hat, das Plugin läuft auch unter der
neuen Eclipse Version Galileo scheinbar einwandfrei.
Ich habe jedenfalls bisher keine Probleme gehabt.
Wollte ich nur mal gesagt haben.
Gruß
900ss
Hallo,
Erst einmal vielen Dank für das geniale Plug-In! Damit macht das
Entwickeln direkt wieder Spass ;-)
Eine Frage ist heute aber bei mir aufgetaucht bei der ich irgentwie nen
Klemmer habe:
In meinem aktuellen Projekt muss ich double-Datentypen verwenden, und
diese mit der "strtod" Funktion kovertieren, und später auch mit fprintf
ausgeben
Nach dem ich im Linker unter Toolsettings->AVR C Linker->Libraries->
(-l) "m" angegeben habe gibt es beim Kompiliern schon mal keinen Fehler
mehr.
Allerdings wird im "fprintf"-Befehl der Platzhalter %f nur in ein
Fragezeichen umgewandelt.
Beim AVR-Studio muss ich in dem Fall wohl die erweiterten Bibliotheken
einbinden wie z.B. hier in der FAQ beschrieben:
http://www.mikrocontroller.net/articles/FAQ#Aktivieren_der_Floating_Point_Version_von_sprintf_beim_WinAVR_mit_AVR-Studio
Wo/wie kann ich im Eclipse diese Einstellungen vornehmen?
Rolf Luebess schrieb:
> Nach dem ich im Linker unter Toolsettings->AVR C Linker->Libraries->> (-l) "m" angegeben habe gibt es beim Kompiliern schon mal keinen Fehler> mehr.
Mit -lm bindest du die libm.a ein. Du müßtest also in Eclipse, um wie im
Beispiel für das AVRStudio die libprintf_flt einzubinden, noch
-lprintf_flt mit angeben.
Nebenbei: double unterstützt der GCC für AVR nicht. Er macht daraus
intern immer float beim rechnen. Also Vorsicht, wenn du WIKLICH double
brauchen solltest.
Gruß
900ss
Hallo 900ss,
Danke für die schnelle Antwort!
> Mit -lm bindest du die libm.a ein. Du müßtest also in Eclipse, um wie im> Beispiel für das AVRStudio die libprintf_flt einzubinden, noch> -lprintf_flt mit angeben.
Hmm. zickt immernoch rum... Aber ich schau erstmal genauer ob der Fehler
nicht doch vorm Computer sitzt ;-)
>> Nebenbei: double unterstützt der GCC für AVR nicht. Er macht daraus> intern immer float beim rechnen. Also Vorsicht, wenn du WIKLICH double> brauchen solltest.
Ups, das wusste ich noch gar nicht. Vielen Dank für den Hinweis! Da werd
ich wohl etwas genauer prüfen müssen um nicht böse Überraschungen zu
erleben. Hoffentlich wird das kein KO Kriterium.
btw, weißt du ob das bei der kommerziellen Konkurenz auch so ist(z.B.
IAR?)
MfG
Rolf
Rolf Luebess schrieb:
>> Nebenbei: double unterstützt der GCC für AVR nicht. Er macht daraus>> intern immer float beim rechnen. Also Vorsicht, wenn du WIKLICH double>> brauchen solltest.> Ups, das wusste ich noch gar nicht. Vielen Dank für den Hinweis! Da werd> ich wohl etwas genauer prüfen müssen um nicht böse Überraschungen zu> erleben. Hoffentlich wird das kein KO Kriterium.> btw, weißt du ob das bei der kommerziellen Konkurenz auch so ist(z.B.> IAR?)
Weiß ich nicht sicher, aber ich vermute, der kann das. Kannst ja mal 'ne
kostenlose Demo probieren. Es gibt hier in der Codesammlung aber auch
Libs für Double. Must mal die Suche anschmeißen.
Aber ich würde erstmal prüfen, ob du wirklich double brauchst.
Thomas,
irgendwie war mir so, dass du an einer Debug-Erweiterung programmierst.
Wollte nur mal vorsichtig anfragen, ob man sich da Hoffnung machen darf.
Ist schon lange nichts mehr passiert. Dein Plugin funktioniert ja auch
ziemlich gut. Danke nochmal dafür.
Gruß Hermann
Hi,
ich habe aus einer Reihe von Gründen (hauptsächlich Beruflich) nicht
mehr so viel Zeit in die Weiterentwicklung des Plugins stecken können.
Ich programmier immer mal wieder etwas daran, aber nicht mehr mit der
Intensität des letzten Jahres (laut Ohloh habe ich im letzten Jahr rund
6 Mannjahre Entwicklungsarbeit geleistet (und das bei einem reinem
Freizeitprodukt)).
Daher kann ich leider keine Versprechungen machen, wann es die nächste
Version des Plugins geben wird.
Thomas
Hi Thomas,
hab gerade mal wieder mein Sys neu eingerichtet. Als ich die Optionen
von Eclipse durchgegangen bin, bin ich natürlich auch beim Path-Dialog
von AVR-Eclipse vorbeigekommen. Mittlerweile nudelt der seit wohl 20-30
Minuten auf der SSD rum, ohne das da sichtbar was passiert (Eclipse hart
abschießen möchte ich eigentlich auch nicht :D ).
Dachte das wäre behoben worden? Naja, hier hängts jedenfalls noch ;)
Grüße,
Chris
/EDIT:
Lag uU an mir ;)
Hatte nen SMB-Share gemountet, glaub das hat er auch versucht komplett
abzuscannen. Grad unmount -> Rescan in dem Dialog -> sofort fertig.
ab schrieb:
> Bei mir hat das Plugin unter Eclipse Galileo nicht funktioniert. Unter> Ganymade ohne Probleme.
Kuckst du hier:
Beitrag "Re: AVR Eclipse Plugin 2.3"
Und so wie dort beschrieben ist es noch immer.
Hallo Ihr Lieben, nachdem ich meinen Rechner wegen eines Virenbefalls
neu installieren musste, habe ich jetzt auch meine "alte" ECLIPSE-AVR
Toolchain ersetzt und das hier beschriebene AVR Eclipse Plugin 2.3 unter
ECLIPSE Galileo neu installiert.
Nach Neubau der Projektfiles (delete und ADD im Projekt) kann ich auch
problemlos compilieren. Echt super das Plugin. Nun mein eiegntliches
Problem:
Im Source File Editor Fenster werden Fehler angezeigt die eigentlich
keine sind:
z.B. :
"ISR(TIMER0_OVF_vect).."
wird als Syntax Error mit oranger Schlängellinie markiert. Siehe Anhang.
Er compiliert das auch einandfrei...
Hab ich irgendwas übersehen einzustellen ?
Viele Grüße woko
Hmmm bei mir geht das nach gewisser Zeit weg, bzw. spätestens nach dem
Kompilieren.
Hast du das Problem auch bei neuen Projekten? Also leg mal mit der 2.3
ein Projekt an und versuch das da auch noch mal.
Hallo Simon,
ja Du hattest Recht, die Fehleranzeigen gehen nach einiger Zeit weg, ich
hatte einen include referenz Fehler übersehen, und dadurch kannte er den
ISR wohl nicht. Also ist gelöst....
Gruß woko
>ich hatte einen include referenz Fehler übersehen,
Die include-Fehler (wobei, es sind ja keine Fehler im Code, lediglich
der Editor kommt damit nicht zurecht) sind eigentlich die Ursache für
die fehlenden Makros und defines, wie ISR(), und die verschwinden erst
nach dem ersten build.
Irgendwo stimmt da was noch nicht 100%-ig.
Oliver
Hallo Zusammmen, ich benötige Eure Hilfe:
verwende Eclipse Galileo mit dem aktuellen AVR Eclipse Plugin. Sobald
ich im Programm printf oder sprintf Funktionen verwende, bekomme ich
jetzt die folgenden Linker-Fehler:
Building target: sht75b.elf
Invoking: AVR C Linker
avr-gcc -Wl,-Map,sht75b.map -Wl,-u,vfprintf -lprintf_flt -lm
-L"C:\WinAVR\avr\lib" -mmcu=atmega644 -o"sht75b.elf" ./sht75.o
./sht75_main.o ./uart.o
C:\WinAVR\avr\lib\libprintf_flt.a(vfprintf_flt.o): In function
`vfprintf':
(.text+0xfe): undefined reference to `__mulhi3'
C:\WinAVR\avr\lib\libprintf_flt.a(vfprintf_flt.o): In function
`vfprintf':
(.text+0x10e): undefined reference to `__mulhi3'
make: *** [sht75b.elf] Error 1
Mein Problem ist, offensichtlich findet er die Funktion nicht in den
avr-libs. Allerdings hab ich keine Ahnung, wie ich denn beeinflussen
kann wann er für die printf oder sprintf Function welche Lib
verwendet.Oder muss ich eine bestimmte "includieren" ?
Die floating optionen für den Linker habe ich hoffentlich korrekt
angegeben.
Bisher unter meiner alten Toolchain hatte ich nie das Problem.
Vielen Dank für Eure Hilfe
woko
Hallo, ich habs zumindest so hinbekommen, dass der Linker wieder
glücklich ist...
und zwar mit den folgende Optionen:
-Wl,-u,vfprintf -lprintf_min -lm
stat:
-Wl,-u,vfprintf -lprintf_flt -lm
Wer kann mir denn sagen wo der Unterschied ist (ich mein für mich als
Anwender) und wann ich welche Option verwenden sollte.
Warum hat das früher mit der lprintf_flt funktioniert und jetzt nicht
mehr.?
Gruß woko
Hi,
Das AVR-Eclipse Plugin ist super, endlich kann ich mit Linux AVRs
proggen. Doch ein was stört mich noch, kann man irgendwie gnu99 als
compilerstandart einstellen? Es ist halt nicht so schön bei jedem
Projekt dies von Hand bei jedem Projekt zu ändern.
weihnachtliche grüße
Hallo an alle AVR-Brenner,
ich bin blutiger C-Anfänger, habe noch keinen AVR richtig angefasst aber
ich habe mir in den letzten Stunden ersteinmal eine anständige
Programmierumgebung mit Eclipse und dem AVR-Plugin auf meinem mac-mini
zusammengebastelt. Jetzt werde ich mich mal langsam an C rantasten...
Ich bedanke mich für die massenhaften Infos hier auf [µC.net]
Grüße aus Thüringen
Thomas
Hallo,
ich nutze das AVR Plugin in Galileo.
Ich habe ein normales Projekt, welches auch 1a läuft.
Jetzt will ich ein produktives Projekt mit SVN machen.
Leider macht er:
a) kein auto build
b) läuft der build nicht durch
c) bringen die Projekt Einstellungen beim durchklicken Fehler ("invalid
values" und "NullPointer")
Kann das jemand reproduzieren?
Stefan
900ss schrieb:
> Oliver schrieb:>> Kann das jemand reproduzieren?>> Nein
Das schrieb garnicht Oliver, sondern Stefan. Warum dort oben Oliver
gelandet ist?? #schulterzuck#
Nach gar keiner. WinAVR installieren, Eclipse installieren,
AVR-Eclipse-plugin installieren, SVN-plugin installieren, fertig. Funzt
ohne Probleme unter Windows XP.
Zu Vista oder Windows 7 kann ich nichts sagen.
Oliver
Hallo Stefan,
für eine konkrete Hilfe müsstest Du etwas konkreter werden, Deine
bisherigen Schnipsel sind einfach zu vage.
Hier mal ein paar Fragen die uns vielleicht helfen könnten Dein Problem
besser zu verstehen (ohne Garantie allerdings :-))
1. Was möchtest Du genau tun: Ein neu erstelltes Eclipse Project in ein
SVN repository exportieren oder ein in einem SVN Repository schon
vorhandenes Projekt importieren? Bei letzterem: ist es ein Eclipse AVR
Project.
2. Wie hast Du das "produktive Projekt" angelegt? Welche Anleitung hast
Du benutzt (brach man dafür tatsächlich eine Anleitung?). Ggf. das
Projekt in eine Zip-Datei exportieren und hier hochladen.
3. Ging das "produktive Projekt" von Anfang an nicht oder erst nachdem
Du SVN darauf losgelassen hast? Mit welchen Fehlermeldungen bricht der
Build ab (Console)?
4. Was für NullPointer Exceptions waren das (Normalerweise wird der
Verursacher unter "Details>>>" angezeigt, ansonsten sollten sie im
Eclipse Error Log gespeichert sein (Bei Eclipse 3.5: Help -> About
Eclipse -> Installation Details -> Configuration -> View Error Log)
5. Was für ein System hast Du: Windows? Linux? MacOSX? Welches SVN
Plugin benutzt Du: Subclipse oder Subversive?
Thomas
P.S. Etwas offtopic, aber vielleicht ganz hilfreich ist der folgende
Artikel:
http://www.tty1.net/smart-questions_de.html
Thomas Holland schrieb:
Hallo.
> für eine konkrete Hilfe müsstest Du etwas konkreter werden, Deine> bisherigen Schnipsel sind einfach zu vage.>
Sorry.
> 1. Was möchtest Du genau tun: Ein neu erstelltes Eclipse Project in ein> SVN repository exportieren oder ein in einem SVN Repository schon> vorhandenes Projekt importieren? Bei letzterem: ist es ein Eclipse AVR> Project.>
Ich habe über die SVN Repo Ansicht ein checkout eines Ordners gemacht.
Darin dann mit dem Projekt Wizzard ein AVR Projekt angelegt.
> 2. Wie hast Du das "produktive Projekt" angelegt? Welche Anleitung hast> Du benutzt (brach man dafür tatsächlich eine Anleitung?). Ggf. das> Projekt in eine Zip-Datei exportieren und hier hochladen.>
Das ist:
http://www.mikrocontroller.net/articles/AVR_Eclipse#Projekt_erstellen> 3. Ging das "produktive Projekt" von Anfang an nicht oder erst nachdem> Du SVN darauf losgelassen hast? Mit welchen Fehlermeldungen bricht der> Build ab (Console)?>
Ja, von anfang an.
Das mit dem Build beim Speichern geht einfach nicht.
Das ander muss ich im Büro testen.
Hier gehen soweit alle testst, ausser auto-Build.
> 4. Was für NullPointer Exceptions waren das (Normalerweise wird der> Verursacher unter "Details>>>" angezeigt, ansonsten sollten sie im> Eclipse Error Log gespeichert sein (Bei Eclipse 3.5: Help -> About> Eclipse -> Installation Details -> Configuration -> View Error Log)>
An error has occurred. See error log for more details.
java.lang.NullPointerException
!ENTRY org.eclipse.jface 4 2 2010-01-29 13:38:26.427
!MESSAGE Problems occurred when invoking code from plug-in:
"org.eclipse.jface".
!STACK 0
java.lang.NullPointerException
at
org.eclipse.cdt.managedbuilder.ui.properties.DiscoveryTab.performOK(Disc
overyTab.java:625)
at
org.eclipse.cdt.managedbuilder.ui.properties.DiscoveryTab.handleToolSele
cted(DiscoveryTab.java:331)
at
org.eclipse.cdt.managedbuilder.ui.properties.DiscoveryTab.updateData(Dis
coveryTab.java:295)
at
org.eclipse.cdt.managedbuilder.ui.properties.DiscoveryTab.updateData(Dis
coveryTab.java:248)
at
org.eclipse.cdt.ui.newui.AbstractCPropertyTab.configChanged(AbstractCPro
pertyTab.java:225)
at
org.eclipse.cdt.ui.newui.AbstractCPropertyTab.handleTabEvent(AbstractCPr
opertyTab.java:533)
at
org.eclipse.cdt.ui.newui.AbstractPage.forEach(AbstractPage.java:1024)
at
org.eclipse.cdt.ui.newui.AbstractPage.cfgChanged(AbstractPage.java:981)
at
org.eclipse.cdt.ui.newui.AbstractPage.handleConfigSelection(AbstractPage
.java:438)
at
org.eclipse.cdt.ui.newui.AbstractPage.populateConfigurations(AbstractPag
e.java:793)
at
org.eclipse.cdt.ui.newui.AbstractPage.contentForCDT(AbstractPage.java:33
2)
at
org.eclipse.cdt.ui.newui.AbstractPage.createContents(AbstractPage.java:2
39)
at
org.eclipse.jface.preference.PreferencePage.createControl(PreferencePage
.java:232)
at
org.eclipse.jface.preference.PreferenceDialog.createPageControl(Preferen
ceDialog.java:1501)
at
org.eclipse.jface.preference.PreferenceDialog$14.run(PreferenceDialog.ja
va:1258)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at org.eclipse.core.runtime.Platform.run(Platform.java:888)
at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:48)
at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:175)
at
org.eclipse.jface.preference.PreferenceDialog.showPage(PreferenceDialog.
java:1252)
at
org.eclipse.ui.internal.dialogs.FilteredPreferenceDialog.showPage(Filter
edPreferenceDialog.java:679)
at
org.eclipse.jface.preference.PreferenceDialog$10.run(PreferenceDialog.ja
va:708)
at
org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
at
org.eclipse.jface.preference.PreferenceDialog$9.selectionChanged(Prefere
nceDialog.java:704)
at
org.eclipse.jface.viewers.StructuredViewer$3.run(StructuredViewer.java:8
64)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at org.eclipse.core.runtime.Platform.run(Platform.java:888)
at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:48)
at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:175)
at
org.eclipse.jface.viewers.StructuredViewer.firePostSelectionChanged(Stru
cturedViewer.java:862)
at
org.eclipse.jface.viewers.StructuredViewer.handlePostSelect(StructuredVi
ewer.java:1175)
at
org.eclipse.jface.viewers.StructuredViewer$5.widgetSelected(StructuredVi
ewer.java:1200)
at
org.eclipse.jface.util.OpenStrategy.firePostSelectionEvent(OpenStrategy.
java:251)
at org.eclipse.jface.util.OpenStrategy.access$5(OpenStrategy.java:245)
at org.eclipse.jface.util.OpenStrategy$3.run(OpenStrategy.java:419)
at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
at
org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:
134)
at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3855)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3476)
at org.eclipse.jface.window.Window.runEventLoop(Window.java:825)
at org.eclipse.jface.window.Window.open(Window.java:801)
at
org.eclipse.ui.dialogs.PropertyDialogAction.run(PropertyDialogAction.jav
a:157)
at org.eclipse.jface.action.Action.runWithEvent(Action.java:498)
at
org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(Ac
tionContributionItem.java:584)
at
org.eclipse.jface.action.ActionContributionItem.access$2(ActionContribut
ionItem.java:501)
at
org.eclipse.jface.action.ActionContributionItem$5.handleEvent(ActionCont
ributionItem.java:411)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1003)
at
org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3880)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3473)
at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2405)
at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2369)
at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2221)
at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:500)
at
org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:
332)
at
org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:4
93)
at
org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
at
org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplicat
ion.java:113)
at
org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.j
ava:194)
at
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplicat
ion(EclipseAppLauncher.java:110)
at
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(Eclip
seAppLauncher.java:79)
at
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:
368)
at
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:
179)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:559)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:514)
at org.eclipse.equinox.launcher.Main.run(Main.java:1311)
!ENTRY org.eclipse.jface 4 2 2010-01-29 13:38:28.080
!MESSAGE Problems occurred when invoking code from plug-in:
"org.eclipse.jface".
!STACK 0
java.lang.NullPointerException
at
org.eclipse.cdt.managedbuilder.ui.properties.DiscoveryTab.performOK(Disc
overyTab.java:625)
at
org.eclipse.cdt.managedbuilder.ui.properties.DiscoveryTab.handleToolSele
cted(DiscoveryTab.java:331)
at
org.eclipse.cdt.managedbuilder.ui.properties.DiscoveryTab.updateData(Dis
coveryTab.java:295)
at
org.eclipse.cdt.managedbuilder.ui.properties.DiscoveryTab.updateData(Dis
coveryTab.java:248)
at
org.eclipse.cdt.ui.newui.AbstractCPropertyTab.configChanged(AbstractCPro
pertyTab.java:225)
at
org.eclipse.cdt.ui.newui.AbstractCPropertyTab.handleTabEvent(AbstractCPr
opertyTab.java:533)
at
org.eclipse.cdt.ui.newui.AbstractPage.forEach(AbstractPage.java:1024)
at
org.eclipse.cdt.ui.newui.AbstractPage.cfgChanged(AbstractPage.java:981)
at
org.eclipse.cdt.ui.newui.AbstractPage.handleConfigSelection(AbstractPage
.java:438)
at
org.eclipse.cdt.ui.newui.AbstractPage.populateConfigurations(AbstractPag
e.java:793)
at
org.eclipse.cdt.ui.newui.AbstractPage.setVisible(AbstractPage.java:815)
at
org.eclipse.jface.preference.PreferenceDialog.selectCurrentPageAgain(Pre
ferenceDialog.java:1020)
at
org.eclipse.jface.preference.PreferenceDialog$9.handleError(PreferenceDi
alog.java:694)
at
org.eclipse.jface.preference.PreferenceDialog$9.access$0(PreferenceDialo
g.java:687)
at
org.eclipse.jface.preference.PreferenceDialog$10.run(PreferenceDialog.ja
va:710)
at
org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
at
org.eclipse.jface.preference.PreferenceDialog$9.selectionChanged(Prefere
nceDialog.java:704)
at
org.eclipse.jface.viewers.StructuredViewer$3.run(StructuredViewer.java:8
64)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at org.eclipse.core.runtime.Platform.run(Platform.java:888)
at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:48)
at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:175)
at
org.eclipse.jface.viewers.StructuredViewer.firePostSelectionChanged(Stru
cturedViewer.java:862)
at
org.eclipse.jface.viewers.StructuredViewer.handlePostSelect(StructuredVi
ewer.java:1175)
at
org.eclipse.jface.viewers.StructuredViewer$5.widgetSelected(StructuredVi
ewer.java:1200)
at
org.eclipse.jface.util.OpenStrategy.firePostSelectionEvent(OpenStrategy.
java:251)
at org.eclipse.jface.util.OpenStrategy.access$5(OpenStrategy.java:245)
at org.eclipse.jface.util.OpenStrategy$3.run(OpenStrategy.java:419)
at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
at
org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:
134)
at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3855)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3476)
at org.eclipse.jface.window.Window.runEventLoop(Window.java:825)
at org.eclipse.jface.window.Window.open(Window.java:801)
at
org.eclipse.ui.dialogs.PropertyDialogAction.run(PropertyDialogAction.jav
a:157)
at org.eclipse.jface.action.Action.runWithEvent(Action.java:498)
at
org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(Ac
tionContributionItem.java:584)
at
org.eclipse.jface.action.ActionContributionItem.access$2(ActionContribut
ionItem.java:501)
at
org.eclipse.jface.action.ActionContributionItem$5.handleEvent(ActionCont
ributionItem.java:411)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1003)
at
org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3880)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3473)
at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2405)
at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2369)
at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2221)
at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:500)
at
org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:
332)
at
org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:4
93)
at
org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
at
org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplicat
ion.java:113)
at
org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.j
ava:194)
at
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplicat
ion(EclipseAppLauncher.java:110)
at
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(Eclip
seAppLauncher.java:79)
at
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:
368)
at
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:
179)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:559)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:514)
at org.eclipse.equinox.launcher.Main.run(Main.java:1311)
> 5. Was für ein System hast Du: Windows? Linux? MacOSX? Welches SVN> Plugin benutzt Du: Subclipse oder Subversive?
Windows 7 Professional x64 mit subclibse.
Danke,
Stefan Kuhne
OK, da kommen wir der Sache schon näher.
Den Schalter fürs "Auto-Build bei Save" habe ich gefunden: Er muss jetzt
(Eclipse 3.5/Galileo) für jedes Projekt einzeln angeschaltet werden. Zu
finden ist der Schalter unter Project Properties -> C/C++ Build ->
Behaviour Tab -> 'Build on resource save (Auto Build)'
Wurde wahrscheinlich so gemacht, um global Autobuild (z.B. für Java)
anschalten zu können, ohne das es für C Projekt aktiv ist (ich finde
autobuild geht nur für sehr kleine C Projekt, sonst wird die Wartezeit
nach jedem Save einfach zu lang)
Zu den NullPointerExceptions: Kann ich reproduzieren, auch bei nicht-SVN
Projekten. Da scheint es eine Inkompatibilität zwischen dem Plugin und
Eclipse 3.5 zu geben.
Ich werde am Wochenende mal den Debugger anwerfen und schauen ob ich den
Grund finde.
Die Exceptions treten (bei mir) aber nur auf, wenn man bei den Project
Properties die Seite 'C/C++ Build' -> 'Discovery Options' anwählt und
dann 'OK' oder 'Apply' klickt.
Also als Workaround diese Seite einfach nicht mehr anwählen.
Thomas
Thomas Holland schrieb:
> Zu den NullPointerExceptions: Kann ich reproduzieren, auch bei nicht-SVN> Projekten.
Wie hast du das denn hinbekommen? Ich habe mir eben wirklich alle
erdenkliche Mühe gegeben, klappt nicht. Läuft perfekt, im Ernst.
Meine Eclipse-Version:
Version: 3.5.1.R35x_v20090910-9gEeG1_FthkNDSP2odXdThaOu9GFDPn83DGB7
Build id: M20090917-0800
Das AVR-Plugin ist das neueste von Dir.
Stefan Kuhne schrieb:
> Ich habe über die SVN Repo Ansicht ein checkout eines Ordners gemacht.> Darin dann mit dem Projekt Wizzard ein AVR Projekt angelegt.
Normalerweise kannst du schon beim auschecken anwählen "Checkout with
the "New Project Wizard". In dem Ablauf kannst du dann schon wählen, das
es ein AVR-Projekt werden soll. Dann brauchst du das nicht hinterher
machen, wußte auch garnicht dass das möglich ist.
OT auch an @Stefan:
Zu deiner Art hier Fragen zu stellen. Ich verweise auf zwei Links unten.
Thomas sein Link (http://www.tty1.net/smart-questions_de.html) spricht
das zwar an, aber das ließt sich keiner durch, weil es zu lang ist.
Beide Links sind Postings von J.W., der mir damit aus der Seele spricht:
Beitrag "Re: Wohin entwickelt sich microcontroller.net?"Beitrag "Re: Wohin entwickelt sich microcontroller.net?"
Das ist der Grund, warum meine Antwort genauso knapp, ohne Bemühungen
und undurchsichtig ausfällt, wie die Frage gestellt wurde. Thomas ist da
etwas toleranter "gestrickt" :-) Und so ein Errorlog, wie du oben
gepostet hast, aknn man auch in eine Datei packen und als Anhang
mitschicken. Das bedingt allerdings auch mehr Mühe beim Poster.
So und nun viel Erfolg beim Programmieren deiner AVRs :-)
Hallöchen..
Bin Neuling was das programmieren in C mit Eclipse und dem AVR-PlugIn
angeht. Habe davor immer mit AVR-Studio gearbeitet. Ich habe mein
C-Programm (es besteht nur aus einem Source-File) aus AVR-Studio in
Eclipse kopiert. Leider treten diverse Syntax-Fehler auf, die ich nicht
verstehe. Mein C-Programm lief mit AVR-Studio problemlos.
Beim speichern des C-Programms kommt diese Fehlermeldung:
"Save could not be compledet. Some characters cannot be mapped using
"Cp1252" character encoding."
Meine Entwicklungsumgebeung:
Win7 64Bit
aktuelles WinAVR
aktuelles AVR-Studio
aktuelles Eclipse IDE for C/C++ Developers
AVR Eclipse Plugin Version 2.3
Includes:
1
#include<avr\io.h> // AVR Register und Konstantendefinitionen
2
#include<util\delay.h> // Bibliothek mit Warteroutinen (es wird kein Timer im ATmega verwendet)
3
#include<avr\interrupt.h> // Timer-Interuppts
4
#include<avr/pgmspace.h> // Zugriff auf int. Programmspeicher
Rolf Degen schrieb:> Beim speichern des C-Programms kommt diese Fehlermeldung:>> "Save could not be compledet. Some characters cannot be mapped using>> "Cp1252" character encoding."
File-> Properties -> Text file encoding -> und dann UTF-8 eingeben ist
dieses Problem gelöst.
Grüße
Andreas
Ich habe das Programm gerade mal compiliert. Bei mir geht es
einwandfrei. Man musste nur unter den Projekteigenschaften für den
Compiler bei Language Standard: ISO C99 (-std=c99) einstellen. Dann
klappts auch mit dem Compiler
Grüße
Andreas
Rolf Degen schrieb:> Was kann das bedeuten?
In etwa:
"Compiler optimizations disabled; functions from <util/delay.h> won't
work as designed"
Schalt halt die Optimierung ein.
Oliver
Hallo
Die Optimierung stand in den AVR-Compiler Properties auf -Os. Nach dem
kompilieren hatte mein Programmcode eine Größe von ca. 48kByte. Nachdem
ich alle Optimierungseinstellungen ausprobiert habe (keine war unter
16kByte) habe ich die Einstellung wieder auf -Os zurückgestellt und
nocheinmal kompiliert. Jetzt liegt er wie bei AVR-Studio knapp über
16kByte und passt in meinen ATmega169.
Danke für Eure Mithilfe. Klasse Forum. Hab diese Wocheende viel
dazugelernt.
Gruß Rolf
Ein "bisschen" OT. Ich würde gerne Eclipse benutzen (wegen des Plugins).
Wie schaffe ich es, meherere Source-Fenster gleichzeitig anzuzeigen
(Side-by-Side) ????
tia, Thomas
Thomas Zeisluft schrieb:> Wie schaffe ich es, meherere Source-Fenster gleichzeitig anzuzeigen>> (Side-by-Side) ????
Oder Doppelclick auf die jeweilige zu öffnende Datei im Projekt Explorer
Wenn du mehrere Monitore hast, ist es oft auch praktisch einzelne Views
komplett aus dem Eclipse-Hauptfenster zu lösen und auf den anderen
Monitor zu schieben. Geht natürlich auch mit Source-Editoren.
Hi,
nach langer Zeit habe ich mich mal wieder an das Plugin gemacht und habe
zumindest mal versucht, alle bekannten Bugs zu beheben. Version 2.3.2
(beta 1) steht jetzt auf Sourceforge zum Download bereit:
https://sourceforge.net/projects/avr-eclipse/files/
Ich werde es auch in ein paar Tagen auf der UpdateSite bereitstellen,
sobald ich genug Feedback bekomme dass das Plugin keine neuen Fehler
hat.
Hier die Änderungen dieser Version:
Ich habe es zwar nur kurz getestet, aber das Plugin scheint auch unter
dem brandneuen Eclipse 3.6 (Helios) problemlos zu funktionieren. Helios
soll heute released werden, ist aber bisher (19:30) noch nicht auf der
Download Page erschienen.
Vielen Dank Thomas! Ich arbeite schon längere Zeit regelmäßig mit deinem
Plugin. Das ist bisher die beste IDE um AVRs zu programmieren, wie ich
finde.
Ein "Keep up the good work" von mir :-)
Bei mir läuft AVR Eclipse 2.3.1 auf Helios problemfrei, ein herzliches
Dankeschön für das tolle Plugin!
Ich bin schon gespannt auf 2.3.2 ...
mfG
Markus
Und es gibt mal wieder ein Bugfix-Release.
Version 2.3.4 steht auf Sourceforge zum download bereit. Wie schon bei
den letzten Releases ist es ein P2 Repository, das man mit Eclipse
3.5/3.6 über 'Install Software' direkt installieren kann.
Auch die Updatesite geht, nach einigen Problemen in den letzten Wochen,
wieder.
Sourceforge: https://sourceforge.net/projects/avr-eclipse/files/
Updatesite: http://avr-eclipse.sourceforge.net/updatesite/
Hier die aktuellen Änderungen:
Ein Update ist damit interessant für alle, die mit XMegas rumspielen
oder für Windows-64bit-Nutzer.
Wenn keine neuen Fehler mehr auftreten werde ich damit die 2.3 Serie
abschließen und mich mal wieder neuen Features zuwenden.
Thomas
Hallo Thomas,
hab gerade von dem Update gelesen und doch direkt mein Eclipse (Galileo
V3.5) gestartet. Er hat auch brav gemeldet dass es ein Update des
AVR-Plugins gibt. Ich hab das Update gestartet und nach akzeptieren der
License kam folgendes eine Fehlermeldung, siehe Anhang.
Mein Path zum Plugin:
http://avr-eclipse.sourceforge.net/updatesite/
Im Helios hab ich das Plugin noch nicht installiert, da bin ich noch am
schnuppern. Es ist ja schließlich nicht alles Gold was glänzt ;-)
Gruss 900ss
Hi,
ich hab auch eben die neue Version runtergeladen und installiert, sie
funktioniert auch bei mir (Galileo, Ubuntu 10.04) nicht).
Grüße,
Michael
PS: Tolles Plugin (ich mein nicht die Versionen mit Fehler, sondern die
die funktionieren) hast du da geschrieben, fettes Danke!
Ich habe mal nach Eurer Fehlermeldung gegoogelt und dieser Fehler tritt
häufiger auf (nicht nur mit meinem Plugin), und zwar immer dann, wenn
die Haupt-Updatesite von Eclipse nicht erreichbar ist oder aufgrund von
Updates kurzfristig inkonsistent ist.
Das ist wohl ein Designproblem des Eclipse-Updatemechanismus. Siehe z.B.
hier: http://forums.instantiations.com/viewtopic.php?f=4&p=10999
Bitte den Update einfach nochmal probieren. Wenn das nicht klappt
Eclipse mit dem Parameter '-clean' aus einer Shell starten. Spätestens
damit sollte klappen.
Ich habe gerade mehrfach das Plugin installiert, immer mit einer
jungfräulichen 'Eclipse for C/C++ Developer' Installation (Galileo +
Helios). Sowohl die direkte Installation als auch ein Update von 2.3.3
haben problemlos funktioniert.
Thomas
@Thomas: Danke! Ich freue mich immer, wenn ich sehe, dass da noch Leben
im Plugin ist. Wobei ich ehrlich gesagt zugeben muss, dass ich schon
länger mit den ATxmegas am rumbasteln bin und mir bisher kein Fehler
aufgetreten ist.
Wie auch immer ;-) Habe zur Zeit die gleichen Probleme wie 900ss.
An error occurred while collecting items to be installed
session context was:(profile=epp.package.cpp,
phase=org.eclipse.equinox.internal.provisional.p2.engine.phases.Collect,
operand=, action=).
No repository found containing:
osgi.bundle,de.innot.avreclipse,2.3.4.20100807PRD
No repository found containing:
osgi.bundle,de.innot.avreclipse.core,2.3.4.20100807PRD
No repository found containing:
osgi.bundle,de.innot.avreclipse.doc,2.3.4.20100807PRD
No repository found containing:
osgi.bundle,de.innot.avreclipse.source,2.3.4.20100807PRD
No repository found containing:
org.eclipse.update.feature,de.innot.avreclipse,2.3.4.20100807PRD
No repository found containing:
org.eclipse.update.feature,de.innot.avreclipse.source,2.3.4.20100807PRD
Mal abwarten.
Ich bin im Moment ziemlich ratlos warum die Updatesite bei mir
problemlos funktioniert und bei euch nicht.
Vielleicht ist es wirklich ein Problem mit Caches. Sourceforge stellt
den "Expires" HTTP Header recht großzügig ein, so das evtl. sichtbare
und unsichtbare Caches noch veraltete Seiten zwischenspeichern.
Um das zu checken bitte mal die folgenden Links öffnen und im Browser
einen reload erzwingen (Firefox: STRG+F5, IExplorer STRG+SHIFT+F5)
http://avr-eclipse.sourceforge.net/updatesite/site.xmlhttp://avr-eclipse.sourceforge.net/updatesite/content.xmlhttp://avr-eclipse.sourceforge.net/updatesite/artifacts.xml
Damit sollten diese Dateien auch in den unsichtbaren Caches, die manche
ISPs haben, aktualisiert sein und in allen Dateien sollte Version
2.3.4.20100807 auftauchen.
Wenn das nichts hilft dann bitte folgendes ausprobieren:
In Eclipse unter "Window -> Preferences -> Install/Update -> Available
Software Sites" den Eintrag für das AVR Plugin löschen und wieder neu
anlegen. Damit werden alle Daten, die Eclipse für die Updatesite
gespeichert hat, gelöscht.
Thomas Holland schrieb:> http://avr-eclipse.sourceforge.net/updatesite/site.xml> http://avr-eclipse.sourceforge.net/updatesite/content.xml> http://avr-eclipse.sourceforge.net/updatesite/artifacts.xml
Habe ich mal gemacht.
> Damit sollten diese Dateien auch in den unsichtbaren Caches, die manche> ISPs haben, aktualisiert sein und in allen Dateien sollte Version> 2.3.4.20100807 auftauchen.
Also nach dem Aktualisieren kann ich jetzt tatsächlich deine neue 2.3.4
Version sehen.
Update geht aber trotzdem nicht.
Ein -clean habe ich auch schon ausprobiert. Geht ebenfalls nicht.
> Wenn das nichts hilft dann bitte folgendes ausprobieren:>> In Eclipse unter "Window -> Preferences -> Install/Update -> Available> Software Sites" den Eintrag für das AVR Plugin löschen und wieder neu> anlegen. Damit werden alle Daten, die Eclipse für die Updatesite> gespeichert hat, gelöscht.
Löschen der Site, Neustarten, Hinzufügen der Site, Update anstoßen
klappt!
Benutze Eclipse Galileo. Build 20100218
Ein großes Danke an dich!
Jetzt funktioniert es plötzlich (ohne weiteres zutun) ... auch die o.g.
Dateien sind jetzt aktuell.
Schätze dass da in irgend einem Cache zwischen den SF-Servern und mir
noch alte Daten hängen geblieben waren.
Danke für den Support und das Plugin!
mfG
Markus
So, nachdem sich die Probleme mit der Updatesite so langsam in Luft
aufzulösen scheinen kann ich beruhigt schlafen gehen.
Danke an alle, die das Plugin gleich getestet haben und Feedback gegeben
haben.
Thomas
Hi Thomas,
ich möchte nochmal auf ein Problem zurückkommen, dass ich schonmal hatte
und wir haben auch einen Workaround gefunden.
Siehe hier:
Beitrag "Re: AVR Eclipse Plugin 2.3"
Ich bin auch erstaunt, dass da kein andere Anwender drüber stolpert.
Bisher hab ich jedenfalls nichts davon gelesen.
Ich habe mir vor Monaten einen neuen Rechner eingerichtet. Dort habe ich
den WinAVR nicht auf dem offiziellen Weg installiert, sondern ich habe
von der alten Platte alle dort installierten WinAVR-Versionen so rüber
kopiert.
Es entstehen dann also keine Einträge in der Registry, das Plugin findet
also nichts und trägt unter "Window.Preferences.AVR.Paths" keine Pfade
ein.
Wenn ich die WinAVR-Version wechsel, dann mache ich ein "Rename" der
Verzeichnisse.
Ich habe jetzt unter "Window.Preferences.AVR.Paths" wieder "custom" und
den gültigen Pfad eingetragen (c:\Programme\WinAvr). "Disable search"
ist OFF.
Nachdem ich mir die #include Pfade in einem Projekt angesehn habe, waren
dort jetzt zusätzlich zu den alten falschen Pfaden auch die richtigen
eingetragen. Alles gut. Jetzt hab ich Eclipse beendet, die WinAVR
Version gewechselt und Eclipse wiweder gestartet. Jetzt steht in dem
Projekt kein neuen Pfad aber alle alten ungültigen. Das könnte ich jetzt
in der prefs-Datei per Hand ändern. Hmmm.... :-/
Nun gut, also mit Workarounds bekommt man es wohl hin.
Aber ich finde das suboptimal ;-)
Wenn ich die Toolchain ändere, dann sollte es doch möglich sein, dass
das automatisch gerade gebogen wird. Also meinetwegend einen Button
"rescan".
Wenn dann "Window.Preferences.AVR.Paths" auf "custom" steht, dann gräbt
er das nochmal durch, löscht die alten Pfadangaben im Projekt und trägt
die neuen gültigen ein. Der Rescan-Button, dann auch irgendwo im Projekt
unterbringen.
Ich würde als Workaround auch noch akzeptieren, in
"Window.Preferences.AVR.Paths" "Disable search" auf ON und dass ich die
Pfadangaben im Projekt editieren kann. Das geht leider auch nicht, dort
sind die Pfadangaben nicht editierbar, man kann nur neue hinzufügen und
die könnte man dann auch ändern.
Lange Rede kurzer Sinn, wenn man die Toolchain wechselt, ist es etwas
krampfig. Wenn ich "custom" unter "Window.Preferences.AVR.Paths"
eintrage, dann macht er keinen Update der Projektpfade, auch wenn
"Disable search" auf OFF steht. Das ist wohl eher ein Bug oder hab ich
was falsch verstanden.
Wieso ist da noch kein anderer drüber gefallen?
Für das Gedanken machen sag ich schon mal danke. Wenn dann alles so
bleibt, finde ich es zwar nicht schön, werde aber auch nicht in Tränen
ausbrechen ;-)
900ss
Hallo 900ss,
doch, das ist auch schon anderen aufgefallen. Ich hatte auch schon
rumexperimentiert, aber das Problem war, das vor CDT 7.0 (Helios) kein
API vorhanden war um alte Einträge zu löschen. Es war schlicht unmöglich
bei laufendem Eclipse an die Listen zu kommen, da sie alle intern als
'private' markiert waren und damit nicht zugänglich.
Ich habe es noch nicht ausprobiert, aber ab 7.0 gibt es jetzt wohl ein
API um alte Einträge zu löschen. Und die ersten Builds von CDT 7.0.1
(Release ca. Sep'10) haben wohl auch einen Button um alle alten Einträge
zu löschen.
Siehe: https://bugs.eclipse.org/bugs/show_bug.cgi?id=206372
Da Du sicher nicht der einzige bist, der mit mehreren avr-gcc toolchains
arbeitet habe ich mir auch schon überlegt, ob es nicht Sinn macht,
mehrere Toolchains parallel zu unterstützen und dann jeweils eine pro
Build-Configuration auszuwählen. Vielleicht tut sich auch auf der CDT
Front was dazu: https://bugs.eclipse.org/bugs/show_bug.cgi?id=142619
Dazu möchte ich aber noch abwarten, was mit WinAVR passiert. Atmel hat
ja die Entwicklung übernommen und die aktuelle Beta-Version ist nur noch
ein Plugin für das Hauseigene (zukünftige) AVRStudio4Eclipse. Vielleicht
kann man das ja irgendwie nutzen.
Thomas
Hallo zusammen
Ich habe ein Problem bei der Verwendung des Plugins. Und zwar tritt ein
Problem beim Aufruf von AVRDUDE auf.
Dabei wird folgender Aufruf getätigt (aus der Konsole in Eclipse
gelesen)
Wie zu sehen ist werden zusätzliche Hochkommata beim Port eingefügt. Das
stimmt natürlich nicht un der Com Port kann nicht geöffnet werden. "The
Port for the programmer is blocked" kommt als Fehlermeldung.
Wenn ich den befehl direkt in der Kommandozeile ohne die Hochkommata,
also wie folgt aufrufe
Ich habe die Lösung gefunden. Und zwar habe ich unter
Window->Preferences->AVR->AVRDude bei der Programmer Configuration im
Feld override default Port vor und hinter dem COM3 noch eine leerzeile
gehabt. Diese leerzeilen dürfen nicht sein da ansosnten wohl diese
Hochkommata eingefügt werden. Nach deren Entfernung geht nun alles
wunderbar.
Thomas Holland schrieb:> Dazu möchte ich aber noch abwarten, was mit WinAVR passiert. Atmel hat> ja die Entwicklung übernommen und die aktuelle Beta-Version ist nur noch> ein Plugin für das Hauseigene (zukünftige) AVRStudio4Eclipse. Vielleicht> kann man das ja irgendwie nutzen.
Atmel hat die 8-Bit GCC-Toolchain veröffentlicht [1], wie schauts mit
dem Support dafür aus? Manuelles reinhacken sollte ja möglich sein,
würde die Pfaderkennung die neue Toolchain auch automatisch finden? Ein
erster Versuch ohne die WinAVR-Installation zu deinstallieren ergab
keine Änderungen.
mfG
Markus
[1] Beitrag "Re: WinAVR-2010 soll die letzte Version sein?"
Das Plugin sollte mit der neuen AVR Toolchain von Atmel problemlos
funktionieren. Man muss nur die Pfade in den Preferences von 'System'
auf 'Custom' stellen und entsprechend umbiegen.
Eine automatische Erkennung wird es auch geben sobald ich mal wieder
ernsthaft an dem Plugin arbeiten werde.
Thomas
Sehr interessant. Benutze dein Plugin immer noch regelmäßig.
Hat schon jemand Erfahrungen mit der AVR Toolchain von Atmel? Haben die
jetzt einfach nur den Namen geändert und den Support (Bugtracker) von
WinAVR übernommen? Oder ist das komplett neu aufgesetzt? Was soll mich
bewegen die Software statt dem WinAVR (AVR-GCC avr-libc) zu benutzen?
Simon K. schrieb:> Was soll mich> bewegen die Software statt dem WinAVR (AVR-GCC avr-libc) zu benutzen?
Neuere GCC-Versionen (4.4.3 statt 4.3.3), Support für neuere Devices,
behobene Bugs, neue Bugs ;)
mfG
Markus
> Haben die> jetzt einfach nur den Namen geändert und den Support (Bugtracker) von> WinAVR übernommen?
im Prinzip ja. Außer neuen Versionen der Toolchain und minimal andere
Registry-Einträge (weshalb das Plugin die neue Toolchain nicht
automatisch erkennt), hat sich, zumindest auf den ersten Blick, nicht
viel verändert.
P.S. es gibt noch eine Alternative zum alten WinAVR:
http://www.makehackvoid.com/group-projects/mhvavrtools mit GCC 4.5.x für
alle, die es ganz aktuell haben möchten. Habe ich aber noch nicht
ausprobiert, sollte aber genauso gut funktionieren.
Hallo zusammen,
bei meinem Linux-Umstieg ist mir eine Kleinigkeit unangenehm
aufgefallen, die das Arbeiten mit dem Plugin momentan etwas erschwert:
Im Gegensatz zu Eclipse unter Win(AVR/-dows) werden hier die Headerfiles
der avr-libc nicht automatisch unter "Paths and Symbols" eingetragen.
Mein Setup: Ubuntu 10.10, Eclipse Helios SR2 mit CDT 7.0.2 (von
eclipse.org heruntergeladen/installiert) und AVR Eclipse 2.3.4, daneben
noch eine Reihe weiterer Java-Plugins.
Quizfrage: Bug, Feature oder Fehler meinerseits, und wenn letzteres: Was
mache ich falsch?
mfG
Markus
Mea culpa, es geht um die Projektoptionen, nicht um die Konfiguration
von (AVR) Eclipse selbst.
Die Erkennung der avr-gcc-Installation bereitete keine Probleme, es geht
nur darum, dass die gefundenen Pfade nicht unter "Paths and Symbols"
meiner Projekte auftauchen, damit findet der Indexer die Headerfiles der
avr-libc nicht und Eclipse jammert bei jedem Aufruf einer
avr-libc-Funktion.
Das Kompilieren selbst funktioniert weiterhin problemlos, die Pfade
werden also zumindest an avr-gcc übergeben.
mfG
Markus
Hallo Thomas,
ich verwende Dein Plugin mit Eclipse Indigo SR1. Funktioniert soweit
super, nur der Befehl "AVR Device Explorer" scheint in dieser
Eclipse-Version ein Problem zu haben, eine View zu öffnen. Folgende
Ausgabe ist zu sehen:
So, ich habe nun mal selbst etwas nachgeforscht und festgestellt, dass
das Problem mit dem Befehl AVR Device Explorer mit der Zeile
1
#elif defined (__AVR_M3000__)
in den neueren Versionen der Datei include/avr/io.h zusammenhängt.
Der Parser des Plugins scheint diesen Namen nicht zu mögen. Wenn man ihn
ändert, z.B. in
1
#elif defined (__AVR_ATm3000__)
funktionierts. Die io.h so zu verändern geht natürlich nur, wenn man den
M3000 nicht verwendet, sonst findet der Compiler die Deviceinformationen
nicht.
Thread beobachten
Seitenaufteilung abschalten