Hallo,
ich habe jetzt Version 2.2 meines Eclipse plugins für AVR zum Download
bereitgestellt.
Direkter Download:
https://sourceforge.net/project/showfiles.php?group_id=189165&package_id=221494&release_id=607883
Updatesite: http://avr-eclipse.sourceforge.net/updatesite/
Eigentlich wollte ich das User Manual noch etwas mehr vervollständigen,
aber aufgrund beruflicher Termine habe ich mich doch dazu entschlossen
das Ganze mit nur 2/3 der Anleitungen zu veröffentlichen, damit Ihr
nicht zu lange auf die neuen Features warten müsst.
Gegenüber der Beta1 sind noch - wie schon angekündigt - ein Toolbar
Button und ein Main Menu Eintrag dazugekommen um den Upload mit avrdude
zu starten. Außerdem habe ich noch 3 Fehler behoben. Da ich sonst keine
weiteren Fehlerreports bekommen habe, glaube ich dass das Plugin jetzt
sehr stabil läuft.
Hauptneuigkeit ist natürlich die Unterstützung von avrdude. Damit kann
man jetzt Projekte direkt von Eclipse aus auf eine MCU hochladen.
Daneben gibt es noch ein paar weitere neue Features und Verbesserungen,
die Ihr entweder dem Changelog entnehmen könnt oder, etwas ansprechender
von dieser Seite (aus dem User Manual):
http://avr-eclipse.sourceforge.net/user%20manual/other/whatsnew.html
Viel Spass beim avrdude'n :-)
brgds,
Thomas
Ich ziehe meinen Hut und liege symbolisch auf Knien! :-)
PS: Weißt du zufällig ob die die Struktur der Updatesites mit Ganymede
geändert haben? Scheint nicht hinzufügbar deine Updatesite.
Hi Simon,
Danke fürs Feedback :-)
Zu Ganymede kann ich noch nichts sagen da ich noch keine Zeit zum
ausprobieren hatte. Werde ich aber baldmöglichst nachholen.
Thomas Holland wrote:
> Hi Simon,>> Danke fürs Feedback :-)>> Zu Ganymede kann ich noch nichts sagen da ich noch keine Zeit zum> ausprobieren hatte. Werde ich aber baldmöglichst nachholen.
Alle Ruder zurück. Es geht! ;) Kannst es beruhigt ausprobieren.
Mein Update hat auch geklappt, also zumindest die Installation. :-)
Mehr kann ich grad nicht testen, da ich mir gerade den Rechner neu
einrichte.
Aber ich werde berichten.
Danke für die gute Arbeit.
900ss
Simon K. wrote:
> Alle Ruder zurück. Es geht! ;) Kannst es beruhigt ausprobieren.
Per Updatesite oder hast Du manuell installiert?
Ich habe gerade mal Ganymede runtergeladen und mit der Update site hat
es nicht funktioniert - Es wurde nur das Source Plugin installiert,
nicht das eigentliche Plugin. Ausserdem noch der Eintrag "Uncategorized"
-- es sieht so aus als erwartet Ganymede tatsächlich ein leicht anderes
Format bei der site.xml.
Mit der manuellen Installation hat es dann bei mir auch funktioniert und
wie es scheint funktioniert das Plugin, wenn es erstmal installiert ist,
einwandfrei unter Ganymede.
So, jetzt habe ich mal die site.xml etwas umgestellt und ohne
inhaltliche Änderungen funktioniert es jetzt besser mit Ganymede.
Es gibt zwar immer noch einen Eintrag "uncategorized", aber ansonsten
Funktioniert der Update über die Update Site (bei mir).
Thomas Holland wrote:
> Funktioniert der Update über die Update Site (bei mir).
Dito, bei mir auch.
Mittlerweile finde ich, könnte man mal den AVR-Eclipse Wiki-Eintrag
überarbeiten.
Im moment ist es ja wirklich einfach geworden:
WinAVR installieren
Eclipse installieren
Updatesite(s) hinzufügen
fertig.
Was mache ich falsch?
Nachdem ich mi Ganymed folgendes versucht habe:
- Update-Site hinzufügen
"http://avr-eclipse.sourceforge.net/updatesite/";
- installieren,
bekomme ich leider folgende Fehlermeldung:
"Cannot complete the request. See the details."
Die Details sehen wiefolgt aus:
Cannot complete the request. See the details.
Cannot complete the request. See the details.
Cannot find a solution where both Match[requiredCapability:
org.eclipse.equinox.p2.iu/de.innot.avreclipse.feature.jar/[2.2.0.2008061
8PRD,2.2.0.20080618PRD]] and Match[requiredCapability:
org.eclipse.equinox.p2.iu/de.innot.avreclipse.feature.jar/[2.1.0.2008021
0PRD,2.1.0.20080210PRD]] can be satisfied.
Cannot find a solution where both Match[requiredCapability:
org.eclipse.equinox.p2.iu/de.innot.avreclipse.feature.jar/[2.2.0.2008061
8PRD,2.2.0.20080618PRD]] and Match[requiredCapability:
org.eclipse.equinox.p2.iu/de.innot.avreclipse.feature.jar/[2.1.0.2008021
0PRD,2.1.0.20080210PRD]] can be satisfied.
Cannot find a solution where both Match[requiredCapability:
org.eclipse.equinox.p2.iu/de.innot.avreclipse.source.feature.jar/[2.2.0.
20080618PRD,2.2.0.20080618PRD]] and Match[requiredCapability:
org.eclipse.equinox.p2.iu/de.innot.avreclipse.source.feature.jar/[2.1.0.
20080210PRD,2.1.0.20080210PRD]] can be satisfied.
Cannot find a solution where both Match[requiredCapability:
org.eclipse.equinox.p2.iu/de.innot.avreclipse.feature.jar/[2.2.0.2008061
8PRD,2.2.0.20080618PRD]] and Match[requiredCapability:
org.eclipse.equinox.p2.iu/de.innot.avreclipse.feature.jar/[2.1.0.2008021
0PRD,2.1.0.20080210PRD]] can be satisfied.
Cannot find a solution where both Match[requiredCapability:
org.eclipse.equinox.p2.iu/de.innot.avreclipse.source.feature.jar/[2.2.0.
20080618PRD,2.2.0.20080618PRD]] and Match[requiredCapability:
org.eclipse.equinox.p2.iu/de.innot.avreclipse.source.feature.jar/[2.1.0.
20080210PRD,2.1.0.20080210PRD]] can be satisfied.
Cannot find a solution where both Match[requiredCapability:
org.eclipse.equinox.p2.iu/de.innot.avreclipse.feature.jar/[2.2.0.2008061
8PRD,2.2.0.20080618PRD]] and Match[requiredCapability:
org.eclipse.equinox.p2.iu/de.innot.avreclipse.feature.jar/[2.1.0.2008021
0PRD,2.1.0.20080210PRD]] can be satisfied.
Cannot find a solution where both Match[requiredCapability:
org.eclipse.equinox.p2.iu/de.innot.avreclipse.source.feature.jar/[2.2.0.
20080618PRD,2.2.0.20080618PRD]] and Match[requiredCapability:
org.eclipse.equinox.p2.iu/de.innot.avreclipse.source.feature.jar/[2.1.0.
20080210PRD,2.1.0.20080210PRD]] can be satisfied.
Cannot find a solution where both Match[requiredCapability:
org.eclipse.equinox.p2.iu/de.innot.avreclipse.feature.jar/[2.2.0.2008061
8PRD,2.2.0.20080618PRD]] and Match[requiredCapability:
org.eclipse.equinox.p2.iu/de.innot.avreclipse.feature.jar/[2.1.0.2008021
0PRD,2.1.0.20080210PRD]] can be satisfied.
Cannot find a solution where both Match[requiredCapability:
org.eclipse.equinox.p2.iu/de.innot.avreclipse.source.feature.jar/[2.2.0.
20080618PRD,2.2.0.20080618PRD]] and Match[requiredCapability:
org.eclipse.equinox.p2.iu/de.innot.avreclipse.source.feature.jar/[2.1.0.
20080210PRD,2.1.0.20080210PRD]] can be satisfied.
Unsatisfied dependency: [de.innot.avreclipse.source.feature.group
2.1.0.20080210PRD] requiredCapability:
org.eclipse.equinox.p2.iu/de.innot.avreclipse.source.feature.jar/[2.1.0.
20080210PRD,2.1.0.20080210PRD]
Unsatisfied dependency: [de.innot.avreclipse.feature.group
2.1.0.20080210PRD] requiredCapability:
org.eclipse.equinox.p2.iu/de.innot.avreclipse.feature.jar/[2.1.0.2008021
0PRD,2.1.0.20080210PRD]
Unsatisfied dependency: [de.innot.avreclipse.feature.group
2.1.0.20080210PRD] requiredCapability:
org.eclipse.equinox.p2.iu/de.innot.avreclipse.source.feature.group/[2.1.
0.20080210PRD,2.1.0.20080210PRD]
ich nochmal.
Habe inzwischen die Methode 'Direkt-Donwload' angewendet und bin zu Ziel
gekommen (soweit ich dies in den letzten 5 Minuten vor dem Wochenende
noch festzustellen vermag :)
Schönes Wochenende und viel Spaß beim Fußballgucken! ;)
Hallo sous,
leider kann ich den Fehler nicht reproduzieren.
Habe gerade ein frisches Ganymede gezogen, die AVR-Eclipse Update Site
eingetragen und der Download sowie die Installation des Plug-ins haben
auf Anhieb funktioniert.
Vielleicht hatte SourceForge gerade ein Störung oder es gibt noch
irgendeine unbekannte Rahmenbedingung, die den Fehler auslöst.
Welches Betriebssystem benutzt Du?
LG
Thomas
Mein Posting weiter oben bezog sich auf einen Versuch auf dem Rechner an
meinem Arbeitsplatz. Jetzt habe ich das selbe zuhause versucht, wieder
mit dem gleichen Ergebnis.
Ich werde jetzt die manuelle Installation durchführen, das hat ja bei
meinem ersten Versuch auch geklappt.
Mein Rechner zuhause: WinXP, SP2.
@Sous und @Oliver
Ich habe jetzt verschiedenes probiert, aber ich kann den Fehler einfach
nicht reproduzieren (habe auch WinXP SP3)
ich habe jetzt die update site nochmal modifiziert, vielleicht bringt
das ja was. Es wäre schön, wenn Ihr es nochmal probieren könntet.
LG
Thomas
Es kann den AVR109 Bootloader direkt in Java ansprechen.
Bei avrdude hat man immer das Problem, dass die Ausgabe erst zum Schluss
angezeigt wird. Bei meinem Plugin hat man über alles die Kontrolle.
Jeder einzelne Schritt (Erase, Flash, Read) ist auch ein Eclipse-Job.
Außerdem habe ich vor den verwendeten Port mit einem Terminal-Emulator
zu teilen, so dass man beim Flashen nicht jedesmal ein Programm trennen
muss.
> Und jetzt hoffe ich mal auf eine erfolgreichere zweite Halbzeit... :-)
Nein!
Na dann kann ich mich ja wieder an die Plugin Programmierung machen. :-)
Cool, hab eben mal Ganymede installiert und das neue Plugin dazu. Sieht
schonmal gut aus. Bis zum Wochenende hab ich hoffentlich auch mal Zeit
gehabt das unter Linux zu testen
mal ein dickes Lob an Thomas
Hi,
hab ein Problem unter Linux (Ubuntu). avrdude akzeptiert den AVRISP mkII
nur als root. Ich müsste also jedes mal sudo davor angeben und das
Passwort eingeben.
Ich steh grad etwas auf dem Schlauch wie ich meinem normalen User die
entsprechenden Rechte geben kann. Oder gibt es eine andere Möglichkeit?
von der Konsole aus mit sudo funktioniert avrdude mit dem AVRISP mkII
Hi,
ich habe mir Ganymede runtergeladen und das Plugin installiert. Nach dem
Start fängt Eclipse aber immer erstmal einige Minuten an auf der Platte
zu rödeln. Kann aber nicht genau sagen ob es Eclipse oder das Plugin
ist. Ich habe das Gefühl das das Plugin nach den Pfaden für die Dateien
sucht. Kann das sein?
Hi Markus,
das kann nicht nur sein, das ist leider auch so :-(
Ich habe das Plugin unter Linux nur mit einer abgespeckten Ubuntu Distro
(in einer Virtual Maschine) getestet und da waren die Suchzeiten kaum zu
bemerken.
Für die nächste Version des Plugins werden die Pfade unter Linux nur
noch ein einziges mal gesucht und die Ergebnisse gespeichert. Der Code
dafür ist auch schon im SVN repository, ich habe ihn nur noch nicht
getestet.
Hier ein Link zu dem entsprechenden Bug Report:
http://sourceforge.net/tracker/index.php?func=detail&aid=1962594&group_id=189165&atid=928231
Thomas
Hallo,
was Eclipse angeht bin ich absoluter Neuling. Ich habe mir in den
letzten Tagen die aktuellste Version (WinXP) heruntergeladen und nach
Anleitung das AVR-PlugIn installiert. Ich konnte danach sofort ein
kleines Beispielprogramm über die IDE fehlerfrei compilieren. Dennoch
gibt es ein paar Fragen zu Eclipse :
1.) Das Debuggen (Simulator!) funktioniert nicht. Muss ich hierzu noch
etwas bestimmtes einbinden, oder geht nur Hardwaredebugging (AVR-Dragon,
JTagIce ...) ? Oder muss ich den Unweg über das AVR-Studio gehen ? Was
MUSS bzw. KANN ich tun ?
2.) Kann bei Eclipse so eine Art "Vorschlag-Funktion" aktiviert werden ?
Damit meine ich, dass wenn ich Variablennamen oder Funktionsnamen
schreibe, welche im Projekt bereits deklariert sind, dass diese in einem
"Vorschlags-Fenster" zur Auswahl bereitstehen.
1) Sollte mit dem WinAVR Simulator funktionieren, weiß aber nicht wie.
Mit dem AVRStudio-Simulator geht es wohl nicht. Mußt mal hier im
Forum suchen oder Google fragen. Stichwort GDB, AVR-Simulator.
2) Du mußt STRG-Space drücken, dann bekommst Du Vorschläge.
Hat jemand schon das Hardwaredebugging zum laufen gebracht? Ich hab ein
JTAG ice debugger, das flashen funktioniert, aber das debuggen krieg ich
nicht hin? kann jemand helfen
ich die Einstellungen von dem Beitrag "Debuggen in Eclipse geht nicht
GDB <-> AVaRICE problem" übernommen, nun erscheint folgende Eclipse
Fehlermeldung (siehe Anhang). Weiss jemand woran das leigen könnte?
Hallo Thomas,
mir ist da eine Kleinigkeit aufgefallen:
Wenn ich im Project-Explorer ein Projekt umbenenne rappelt im
Hintergrund irgendwas los, es scheint also einen Hook zu geben der dann
greift. Meinst du da könnte man das Umbenennen von Properties -> C/C++
Build -> Environment -> BUILDARTIFACT mit dranhängen? Oder (anderer
Ansatz) BUILDARTIFACT auf ${PROJECTNAME} setzen, falls es solch eine
Variable gibt?
Ich bin mir nicht sicher ob meine Frage direkt mit deinem Plugin zu tun
hat oder ein allgemeines Eclipse-Problem darstellt.
gruss
f
Edith: Ich sehe gerade ...->C/C++ Build->Settings->Build Artifact wäre
noch so ein Kandidat.
Hallo Frank,
Kein Problem :-)
Eclipse hat schon eine Variable für den aktuellen Projektnamen eingebaut
(genauer gesagt sogar zwei):
${project_name} oder ${ProjName}
Einfach bei "Project Properties -> C/C++ Build -> Settings -> Build
Artifact -> Artifact name" eine der beiden Variablen eintragen und schon
macht der Output alle Umbenennungen mit.
Ich habe gerade versucht mit dem Plugin das als Default für neue Projekt
zu setzen, aber CDT weigert sich meine Vorgabe für
artifactName="${ProjName}" aus der plugin.xml zu übernehmen (obwohl es
so dokumentiert ist)... Egal, dann kommt das halt in die Tipps & Tricks
Sektion :-)
Du kannst übrigens Eclipse/CDT eine Liste aller verfügbaren Variablen
anzeigen lassen:
Project Properties -> C/C++ Build -> Variables -> Show system variables
Liebe Grüsse
Thomas
Hi Thomas,
ich will ja nicht drängen, aber kannst du in etwa sagen wann du ein
Update machst um den Bug mit dem Gerödel auf der Platte zu fixen? Das
wird auf Dauer nämlich echt störend wenn man jedes mal 2-3 Minuten fast
nicht am PC arbeiten kann bis Eclipse fertig ist
Markus,
ich denke, das ich in ca. 2 Wochen die erste Beta Version von 2.3 raus
bringen kann.
Damit Du nicht mehr so lange warten musst habe ich für Dich eine
spezielle Vorabversion des Plugins erstellt:
http://www.innot.de/eclipse/avreclipse/de.innot.avreclipse-2.2.9.20080806INOFFICIAL.zip
Diese Version entspricht dem aktuellen Stand im SVN repository (Rev 578)
und ich weiss von einem anderen Benutzer, das bei ihm genau dieser Stand
unter Linux (grundsätzlich) funktioniert.
Mit dem Fix in dieser Version sollte das Plugin nur noch ein einziges
mal die Festplatte rödeln lassen und sich danach merken, wo die Pfade
liegen (Kann man sogar optional in den Preferences einstellen).
Diese Version enthält auch schon Elemente der kommenden Version 2.3,
allerdings noch rudimentär und ohne den letzten Feinschliff, also nicht
beschweren wenn die Optik noch nicht stimmt. Andere Bugs darfst Du aber
gerne melden.
Thomas
> ich werds mal testen.
Schon mal getestet? Ich würde doch gerne wissen, ob der Fix
funktioniert, da ich ihn in meiner mini-Linux VM nicht ordentlich testen
kann.
Thomas
Er rödelt auf jeden Fall jedes mal wenn man einen neuen Workspace
anfängt. Ich komme erst jetzt dazu richtig damit zu arbeiten. Am
Wochenende sag ich nochmal Bescheid.
Aber ich hab grad noch einen anderen merkwürdigen Fehler.
1
make all
2
make: Warnung: Datei 'subdir.mk' hat Änderungszeit 2,1 s in der Zukunft
So, ich hab jetzt extra nochmal ein wenig rumexperimentiert. Den zweiten
Fehler mit der Uhrzeit hatte ich weil ich auf dem Desktop noch 2.2.0
installiert hatte. Ich habe jetzt 2.2.9 installiert. Folgendes Szenario:
1. Eclipse habe ich im /home/user/Programme/eclipse Verzeichnis
installiert
2. die Eclipse Workbench speichere ich auf einem NFS Verzeichnis
(Netzwerklaufwerk). Sollte aber nichts ausmachen das die sich wie ganz
normale Verzeichnisse verhalten.
Wenn ich nach einem Neustart des Rechners zum ersten mal Eclipse starte
und dabei einen Workspace mit einem AVR Projekt öffne geht nach dem
Start sofort das Gerödel los. Ich kann dabei sogar noch Eclipse
bedienen, aber sobald ich in Window/Preferences auf AVR klicke bleibt er
hängen bis er fertig gerödelt hat. Das dauert etwa 2 Minuten
Vielleicht fällt es dir in der VM nicht auf weil Eclipse ansonsten zu
funktionieren scheint (ich habe nicht versucht zu compilieren).
Wenn du sonst noch etwas wissen musst oder ich für dich irgend etwas
testen soll sag Bescheid
Ich habe glaube ich die Ursache für das Problem. Die Uhr auf dem NFS
Server geht seltsamerweise knapp eine Sekunde vor. Ich hab sie jetzt
manuell mal 2 Sekunden zurückgestellt. Jetzt tritt das Problem wohl
nicht mehr auf.
Hi Markus,
danke für die Info. Da der Fix nicht zu funktionieren scheint (es sollte
nur noch ein einziges mal rödeln und dann bei weiteren Starts nicht
mehr), werde ich mir das Pfadmanagement nächste Woche noch mal
vorknöpfen.
LG
Thomas
P.S.: Nur um sicher zu gehen: Ist "Window -> Preferences -> AVR -> Paths
-> Disable search for system paths at startup" gesetzt? Evtl. mal das
Flag ändern.
Irgs, Kommando zurück. Der hat das Update nicht richtig gemacht. Ich
hatte die ganze Zeit 2.2.0.
Hab nochmal neu installiert. Jetzt scheint es zu gehen
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'
Julien wrote:
> Sobald ich ein ein neues Projekt starte bindet er die Pfade von WINAVR> ein.
Was meinst Du genau damit?
Du mußt die "Compiler" Headerfiles mit <> einbinden, nicht mit "".
Du mußt auch die folgende Datei einbinden:
#include <avr\io.h>
Wenn Du das berücksichtigt hast, dann sollte es gehen. Bei mir
funktioniert es so.
Gruß 900ss
Hallo,
Ich habe gerade eine erste Beta der Version 2.3 auf SourceForge bereit
gestellt:
https://sourceforge.net/project/showfiles.php?group_id=189165&package_id=261459&release_id=626401
Diese Beta hat schon alle für 2.3 geplanten Features. Nur die User
Documentation muss noch überarbeitet werden.
Ich habe die Beta mit Windows und Linux getestet und sie scheint soweit
stabil zu laufen. Bitte probiert sie auch mal bei Euch aus und sagt
bescheid ob alles läuft oder ob es noch Probleme gibt.
Wenn Ihr einen Bug findet meldet euch! Wenn Ihr es nicht tut wird es
auch niemand anders tun und von selbst beheben sich die Fehler leider
nicht.
Aber auch wenn Ihr keine Fehler findet würde es mich freuen zu höhren
das die Beta funktioniert. Ich hätte gerne ein paar positive
Rückmeldungen damit ich die endgültige Version entspannt rausgeben kann.
Liebe Grüße,
Thomas
Changelog:
Auf den ersten Blick sieht es gut aus. Neue Projeke, existierendee
Projekte und libs funktionieren bei mir. Pfade werden auch richtig
gefunden. Programmer hab ich keinen dran, das muß jemand anderes
probieren.
Windows XP, SP3, Eclipse Ganymed.
Oliver
Auf den ersten Blick sieht es gut aus. Neue Projekte, existierende
Projekte und libs funktionieren bei mir. Pfade werden auch richtig
gefunden. Programmer hab ich keinen dran, das muß jemand anderes
probieren.
Windows XP, SP3, Eclipse Ganymed.
Oliver
Hallo Thomas,
ich arbeite noch mit dem Plugin V2.2 (nicht die neuere BETA).
Nun habe ich wieder ein Problem gehabt, dass alle Tools nach dem Linker
in der DEBUG-Konfiguration nicht mehr aufgerufen wurden. Das hatten wir
schon mal bei einer älteren Plugin-Version. Damals lag der Fehler in der
.cproject-Datei. Ich hatte gerade ein Backup gemacht um habe diese Datei
von dort wieder genommen und jetzt funktioniert es wieder.
Im Anhang ist die "defekte" Datei. Ich hatte übrigens bei einer
C-Source-Datei im C/C++-Explorer unter Eclipse die Einstellung "Exclude
resource from build" für die Release-Variante verändert. Ich meine,
danach ist der Fehler aufgetreten.
Vielleicht findest Du das Problem mit der cproject-Datei.
Gruß
900ss
Die .cproject Datei hast Du zwar vergessen, aber ich denke, das ich die
diesmal nicht brauchen.
Schau mal, ob in Deinem Projekt eine Datei so ein kleines "<>" Symbol
oben rechts im File-Icon hat. Wenn ja, dann rechts-klick auf die Datei
und "Build Configurations -> Delete resource cfgs..." auswählen. Dann
"Select All" und "OK".
Das "Exclude from Build" sollte an sich normal funktionieren, aber wenn
Du es über die File Properties gesetzt hast (nicht direkt über das
File-Context-Menü), dann kann der Bug mit der kaputten "Resource Cfg"
leicht ausgelöst werden.
Thomas
Käse, der Anhang ist verloren gegangen, als ich auf den Button Vorschau
getreten habe. Danach hab ich nicht wieder dran gedacht. Danke für den
Tip. Muß ich erst die "kaputte" cproject wieder einspielen. Mach ich
morgen mal.
Und immer genug Luft unter den Tragflächen ;-)
900ss
Hallo zusammen!
Ich habe mir als WE-Projekt mal den Umstieg von AVR Studio zu Eclipse
vorgenommen. Ich konnte auch C Projekte übersetzen und meinen UsbProg
Adapter nutzen.
Vielen vielen Dank für das Eclipse Plugin und das Generieren des
Makefiles! Ist für mich als fortgeschrittener Frischling in der
MC-Programmierung extrem hilfreich. Ich komme halt ursprünglich aus der
Java-Welt...
Nun habe ich aber seit einem ganzen Tag schon ein Problem, wo mir dieses
Forum und das Internet eine Antwort schuldig geblieben ist...
Wie konfiguriere ich das Eclipse-Projekt, um in einer foo.S Assembler
Datei per .include eine macros.inc Datei einbinden zu können?
Im AVR-Studio konnte ich den Assembler-Code erfolgreich übersetzen.
Der Compiler findet die macros.inc (eine Atmel AppNote) nicht.
Es hat nicht geholfen, die Datei dem Projekt hinzuzufügen bzw. den
Ordner mit der macros.inc als Pfad den Includes hinzuzufügen.
Die macros.inc-Datei wird auf der GUI im Project-Explorer nicht als
Assembler erkannt.
Was muss ich tun bzw was läuft da im Hintergrund ab?!?
Ich arbeite unter XP mit Ganymede 3.4.1 und dem Beta-Plugin.
Hier die Fehlermeldung:
Building file: ../usi_master.S
Invoking: AVR Assembler
avr-gcc -x assembler-with-cpp -I"C:\AVR\workspace\inc" -gstabs
-mmcu=atmega169 -MMD -MP -MF"usi_master.d" -MT"usi_master.d" -c
-o"usi_master.o" "../usi_master.S"
C:\DOKUME~1\TWEI~1\LOKALE~1\Temp/ccU0yqXs.s: Assembler messages:
C:\DOKUME~1\TWEI~1\LOKALE~1\Temp/ccU0yqXs.s:6: Error: can't open
macros.inc for reading: No such file or directory
make: *** [usi_master.o] Error 1
Was mir noch unklar ist:
- Warum kommen die avr-gcc Meldungen aus einem temp-Verzeichnis?!?
- Wo liegt eigentlich das generiere MakeFile? Wird mfile im Hintergrund
genutzt? (Alle Achtung: Schon so gut vor dem dummen End-User versteckt,
dass man es nicht mehr findet:))
- Warum kann ich für die .inc nicht die Property "Language mapping"
konfigurieren. Wegen der Endung?
- Wird der entsprechende MakeFile Eintrag abhängig von dem "Language
Mapping" erzeugt?
Auch die Projekt-Doku hat mir bei diesen Punkten nicht weiter geholfen.
Ich habe nun schon so viele Konfigurationsversuche unternommen und
möchte es wirklich verstehen, aber es ist für mich die Nadel im
Heuhaufen.
Ich hoffe, ihr könnt mir helfen. Wenn noch Infos fehlen, bitte
beschweren :) Ich kann auch noch ein kurzes Code Bsp basteln, wenn
benötigt...
Evtl hab ich auch noch einen Bug gesehen:
Wenn man unter Windows XP
- in den Properties von einem .C File
- in C/C++General->Paths and Symbols
- einen Pfad zu den Includes über hinzufügt
ist der Path separator des neuen Eintrages ein '\'
Die vorhandenen Einträge wie
"c:/programme/atmel/winavr/lib/gcc/4.3.0/include" sind mit einem '/'
dargestellt.
Ist '\' oder '/' oder beides korrekt?
nochmals ein riesen Dankschööön an Thomas und Grüße,
Totti
Hallo Thorsten,
> Wie konfiguriere ich das Eclipse-Projekt, um in einer foo.S Assembler> Datei per .include eine macros.inc Datei einbinden zu können?> Im AVR-Studio konnte ich den Assembler-Code erfolgreich übersetzen.
ich bin kein Experte auf dem Gebiet, aber meines Wissens haben Atmel und
GCC einen unterschiedlichen Assembler Syntax, d.H. sie sind nicht
kompatibel.
Du kannst also nicht eine Datei "macros.inc" (Atmel Syntax) in eine
Datei "foo.S" (GCC Syntax) inkludieren.
Das AVR Eclipse Plugin kann nur GCC Assembler, AVR Studio kann nur Atmel
Assembler - gemischte Projekte gehen m.E. nicht.
> Building file: ../usi_master.S> Invoking: AVR Assembler> avr-gcc -x assembler-with-cpp -I"C:\AVR\workspace\inc" -gstabs> -mmcu=atmega169 -MMD -MP -MF"usi_master.d" -MT"usi_master.d" -c> -o"usi_master.o" "../usi_master.S"> C:\DOKUME~1\TWEI~1\LOKALE~1\Temp/ccU0yqXs.s: Assembler messages:> C:\DOKUME~1\TWEI~1\LOKALE~1\Temp/ccU0yqXs.s:6: Error: can't open> macros.inc for reading: No such file or directory> make: *** [usi_master.o] Error 1>>> Was mir noch unklar ist:> - Warum kommen die avr-gcc Meldungen aus einem temp-Verzeichnis?!?
Auch hier kann ich keine definitive Antwort geben, aber ich vermute,
dass avr-gcc erst mal den Preprocessor über die Sourcedatei laufen lässt
("assembler-with-cpp"), das Zwischenergebnis im Temp-Verzeichnis an den
eigentlichen Assembler (avr-gas) übergibt, der wiederum die
Fehlermeldung ausspuckt.
> - Wo liegt eigentlich das generiere MakeFile? Wird mfile im Hintergrund> genutzt? (Alle Achtung: Schon so gut vor dem dummen End-User versteckt,> dass man es nicht mehr findet:))
Das kann ich beantworten :-)
So sehr versteckt ist das makefile nicht. Es liegt im Projektverzeichnis
in einem Unterordner mit dem Namen der Build Konfiguration (z.B. "Debug"
oder "Release").
Und nein -- mfile wird nicht genutzt und das von Eclipse erzeugte
Makefile hat auch eine ganz andere Struktur.
> - Warum kann ich für die .inc nicht die Property "Language mapping"> konfigurieren. Wegen der Endung?
s.o. .inc Files sind Atmel Assembler Files und damit wird GCC nicht
glücklich werden. Wenn Du unbedingt willst, dann kannst Du Eclipse
sagen, das .inc Files Assembler files sind (Window > Preferences... >
C/C++ > File Types), aber richtig weiterhelfen tut das nicht.
> - Wird der entsprechende MakeFile Eintrag abhängig von dem "Language> Mapping" erzeugt?
Language mappings sind eine Spezialfunktion, die man im normalen Umgang
mit GCC nicht braucht. Die Zuordnung der "Language" erfolgt
normalerweise über die Endung (s.o. "File Types"). Language Mapping
würde man benutzten, wenn die Endung nicht dem Inhalt der Datei
entspricht (z.B. eine C Datei mit der Endung .cpp)
> Evtl hab ich auch noch einen Bug gesehen:> Wenn man unter Windows XP> - in den Properties von einem .C File> - in C/C++General->Paths and Symbols> - einen Pfad zu den Includes über hinzufügt> ist der Path separator des neuen Eintrages ein '\'>> Die vorhandenen Einträge wie> "c:/programme/atmel/winavr/lib/gcc/4.3.0/include" sind mit einem '/'> dargestellt.>> Ist '\' oder '/' oder beides korrekt?
Beides. Bisher konnte ich keine Unterschiede feststellen. Da Eclipse und
Java Platformunabhängig sind werden einfach beide Varianten akzeptiert
und bei der Übergabe an das Betriebssystem entsprechend umgewandelt.
Thomas
Vielen Dank für die Erleuchtung!
ich war ziemlich frustriert und nach 11 Stunden auf der Arbeit vor dem
Bildschirm noch unkonzentriert dazu (hab echt das MakeFile
übersehen...).
Ich bin gerade Weltmeister im "Ich reiße neue Baustellen auf", kriege
aber keine geschlossen :|
Es fing an mit (Neues Testament, das alte möchte ich hier nicht auch
noch schreiben :)
1 Ich möchte lernen, wie ich eine ASM-Routine in C aufrufe (in meinem
Fall USI)
2 Oh, nehme ich Inline ASM oder Standard Assembler. Lesen, lesen, lesen
- ok kein Inline Asm
3 Oh, die Register müssen bei meinem AtMega169 anders angesprochen
werden. OK, dann den ASM-Code überarbeiten
4 Oh, ich muss ja dann das AVR Studio Makefile ständig editieren
(zumindest nach meinem Kenntnisstand)
5 Ach, da hab ich doch mal was von AVR+Eclipse gelesen. Von einer
anständigen IDE träume ich doch schon eine Weile
6 Eclipse eingerichtet, Plugin installiert, Programmer zum Laufen
gebracht, aber wieder diese verdammten Assemblerroutinen die neue
Probleme machen
7 OK, den Wald vor lauter Bäumen nicht gesehen - das die Assembler
Compiler nicht kompatibel sind, ist einleuchtend
8 Den ASM-Code habe ich immer noch nicht getestet und wie gehe ich nun
weiter vor?!?
Tja, mit Inline ASM hätte ich das aktuelle Problem nicht, dafür sicher
aber zig Andere :)
Ich werde mich heute Abend mal den Unterschieden der Compiler widmen.
Was ich schon rausbekommen habe:
1. Der GCC erzeugt die Vektortabelle selbst
2. Die Direktiven sind anders benannt
2.1 AVR Assembler: Start des Codesegmentes mit .CSEG definiert
2.2 GCC Assembler: Start des Codesegmentes mit .text adressiert
Noch habe ich die Hoffnung, dass die Portierung der macros.inc in
GCC-ASM halbwegs erträglich wird...
Wäre es als Zwischenlösung möglich, den ASM-Teil im AVR Studio zu
übersetzten und in Eclipse verwenden?
Ich denke Nein, weil man doch wieder das MakeFile für den Linker
editieren müsste, oder?
Ich hatte mich zwar bemüht, keine dämlichen Fragen zu stellen, aber so
ganz geglückt ist mir das gestern ja nicht mehr :(
Es gab für mich so viele Unbekannte und dann kamen noch die
Konfigurationsmöglichkeiten von Eclipse und deinem Plugin dazu.
Das waren einfach zu viele Baustellen auf einmal...
Was mir jetzt auch klar geworden ist (glaub ich): Das MakeFile wird über
das CDT Plugin generiert
Wäre es ein legitimer Wunsch für Verion 3.14159265... evtl
http://avra.sourceforge.net/ zu unterstützen? Man darf doch noch träumen
:)
- Leuten wie mir würde das den Umstieg auf jeden Fall vereinfachen
- Die AppNotes könnten ohne Anpassungen verwendet werden.
- Man könnte von dem Atmel ASM-Code profitieren, den es massenweise im
Netz gibt
Danke für die schnelle Antwort von gestern,
Totti
Hallo Thorsten
Ich weiss ja nichts über Dein(e) Projekt(e), trotzdem frage ich mich ob
Du wirklich ASM verwenden musst und nicht alles mit C lösen kannst?
C+ASM zu mischen ist immer recht kritisch, Du musst den Compiler sehr
genau kennen und wissen wie er die Register verwendet. Zudem ist so ein
Mischgefüge nicht potrtierbar, es kann womöglich schon mit der nächsten
Compilerversion nicht mehr funktionieren.
Ich habe früher auch ASM programiert, inzwischen löse ich alles in C.
Selbst zeitkritische Funktionen lassen sich mit etwas Übung+Pröbeln in C
nahezu so effizient realisieren wie mit ASM. Nur für ganz wenige
Ausnahmen benutze ich noch Inline-ASM Macros.
MfG Peter
Hi Peter,
danke für deine Antwort. Gut zu wissen, dass man von der Kombination
Asm/C eher Abstand nehmen sollte. Da gibt es sicher einige Fallen, in
die ich stolpern könnte/in die man 1x stolpern muss:)
Ich möchte einen TWI-Drucksensor auslesen. Letztenendes soll vielleicht
mal ein Vario dabei rauskommen. Den konnte ich auch mit einem AtMega8
(Hardware-TWI) erfolgreich auslesen. Nun möchte ich aber gerne das
Butterfly Board (AtMega169p) verwenden, um Display und Sound nutzen zu
können (funktioniert auch schon halbwegs mit simulierten Druckwerten).
Problem: AtMega169p kann nur USI.
Warum Assembler? Eigentlich um zu lernen wie die Asm/C Kombination
funktioniert. Ich denke, dass die Aufgaben für Assembler gut gekapselt
werden können. Es sind hauptsächlich die Funktionen USI_Init und
USI_Master_Read (ließt x Byte vom Bus), die ich benötige
Praktischerweise habe ich auch irgendwann mal einen USI-Master-Asm Code
gefunden.
USI selbst zu implementieren - da wollte ich mich eigentlich vor
drücken. Ich habe auch keine Ausrüstung um die Signale auf dem BUS zu
sehen und alles im Simulator...
Wahrscheinlich ist es wirklich das Beste, den Code nach C zu portieren.
Ich gebe aber nur sehr ungern mitten drin aufgeben :)
Mal sehen, was die Unterschiede zwischen den avr-gas und AtmelAsm sind -
ist noch in Arbeit :)
Warum muss ich eigentlich so genau über die Compilerverwendung Bescheid
wissen? Für mich hat sich das Thema bislang auf die
Parameterübergabe/Rückgabe und Interrupt-Handling beschränkt.
Wenn aber jemand "zufällig" eine USI Master C Implementierung zu Hand
hat, sage ich auch nicht nein ;)
MfG,
Totti
Thorsten Wein wrote:
> [...]> 7 OK, den Wald vor lauter Bäumen nicht gesehen - das die Assembler> Compiler nicht kompatibel sind, ist einleuchtend
Wenn man es weiß ist es einleuchtend, aber ich habe gestern auch 'ne
ganze weile gegooglet, ohne dazu eine klare Aussage zu finden. Auch habe
ich noch keine Seite gefunden, bei der die Unterschiede zwischen den
beiden Assemblern klar beschrieben werden.
> [...]> Wäre es als Zwischenlösung möglich, den ASM-Teil im AVR Studio zu> übersetzten und in Eclipse verwenden?> Ich denke Nein, weil man doch wieder das MakeFile für den Linker> editieren müsste, oder?
Das Problem ist eher, dass der Atmel Assembler kein Format ausspuckt,
dass man mit dem GCC Linker weiterverarbeiten könnte. Wenn ich es
richtig sehe, dann kann avrasm2.exe nur .hex Images und .obj Dateien in
einem Atmel-eigenen Format erzeugen.
Was evtl. gehen könnte ist ein gemeinsames Projektverzeichnis zwischen
Eclipse und AVR Studio. Eclipse dann als etwas aufgeblasener Editor und
AVR Studio zum assemblieren.
Oder in Eclipse avrasm2.exe als "Custom Build Step" für die .asm Datei
definieren.
Beides hat aber den Nachteil, dass der Output von avrasm2.exe in Eclipse
nicht weiterverwendet werden kann.
> Ich hatte mich zwar bemüht, keine dämlichen Fragen zu stellen, aber so> ganz geglückt ist mir das gestern ja nicht mehr :(
Also ich fand Deine Fragen nicht dämlich, sondern durchaus berechtigt.
> Was mir jetzt auch klar geworden ist (glaub ich): Das MakeFile wird über> das CDT Plugin generiert
Ja, und es steckt ein ziemlich komplexer Prozess dahinter, den ich
selbst auch nur zu Teilen verstehe bzw. nachvollziehen kann.
> Wäre es ein legitimer Wunsch für Verion 3.14159265... evtl> http://avra.sourceforge.net/ zu unterstützen? Man darf doch noch träumen> :)
Grundsätzlich eine gute Idee. Avra kann auch COFF obj Dateien erzeugen,
die man in ELF Dateien konvertieren kann, die wiederum vom GCC Linker
gelesen werden können. Nicht unbedingt Trivial, aber vielleicht machbar.
Leider scheint das avra Projekt nicht mehr sonderlich aktiv zu sein.
Seit einem Jahr hat sich dort nichts mehr getan und die Liste der
Bug-Reports ist lang...
> - Leuten wie mir würde das den Umstieg auf jeden Fall vereinfachen> - Die AppNotes könnten ohne Anpassungen verwendet werden.> - Man könnte von dem Atmel ASM-Code profitieren, den es massenweise im> Netz gibt
Ich kenn mich leider zu wenig mit Assembler aus, um zu sagen ob es
wirklich so einfach ist. Wie Du schon selbst geschrieben hast gibt es
auch strukturelle Unterschiede, z.B. die von dir erwähnte Vectortabelle.
> Es sind hauptsächlich die Funktionen USI_Init und> USI_Master_Read (ließt x Byte vom Bus), die ich benötige> Praktischerweise habe ich auch irgendwann mal einen USI-Master-Asm Code> gefunden.> USI selbst zu implementieren - da wollte ich mich eigentlich vor> drücken. Ich habe auch keine Ausrüstung um die Signale auf dem BUS zu> sehen und alles im Simulator...> Wenn aber jemand "zufällig" eine USI Master C Implementierung zu Hand> hat, sage ich auch nicht nein ;)
Versuch doch mal die Frage in einem neuen Thread zu stellen, da ich
nicht glaube das die richtigen AVR Gurus diesen Eclipse Thread hier
lesen.
Liebe Grüße,
Thomas
Thomas Holland wrote:
>> - Warum kommen die avr-gcc Meldungen aus einem temp-Verzeichnis?!?> Auch hier kann ich keine definitive Antwort geben, aber ich vermute,> dass avr-gcc erst mal den Preprocessor über die Sourcedatei laufen lässt> ("assembler-with-cpp"), das Zwischenergebnis im Temp-Verzeichnis an den> eigentlichen Assembler (avr-gas) übergibt, der wiederum die> Fehlermeldung ausspuckt.
Genau so ist es.
>> Ist '\' oder '/' oder beides korrekt?> Beides. Bisher konnte ich keine Unterschiede feststellen. Da Eclipse und> Java Platformunabhängig sind werden einfach beide Varianten akzeptiert> und bei der Übergabe an das Betriebssystem entsprechend umgewandelt.
Es muss gar nicht umgewandelt werden. Selbst MS-DOS hat in den
internen Systemaufrufen schon seit Jahrzehnten den Vorwärtsstrich
als Alternative zum Rückwärtsstrich akzeptiert, und Windows hat das
übernommen. Es war/ist immer nur command.com bzw. cmd.exe, die den
Vorwärtsstrich als Trenner für die Optionen vom ihren CP/M-Vorfahren
übernommen haben und dadurch nicht als Verzeichnistrenner akzeptieren.
Thomas Holland wrote:
> Das Problem ist eher, dass der Atmel Assembler kein Format ausspuckt,> dass man mit dem GCC Linker weiterverarbeiten könnte. Wenn ich es> richtig sehe, dann kann avrasm2.exe nur .hex Images und .obj Dateien in> einem Atmel-eigenen Format erzeugen.
Das Problem ist noch schlimmer: der Atmel-Assembler ist ein reiner
Absolutassembler, der kann gar keine verschieblichen Objekte erzeugen,
die hernach noch ein Linker anfassen kann.
Deren .obj dient lediglich als Speicher für ein paar Debuginformationen,
damit man diese Assemblerprojekte in AVR Studio debuggen kann
(Zeilennummern, Symboltabelle).
> Grundsätzlich eine gute Idee. Avra kann auch COFF obj Dateien erzeugen,> die man in ELF Dateien konvertieren kann, die wiederum vom GCC Linker> gelesen werden können. Nicht unbedingt Trivial, aber vielleicht machbar.
Sonderlich glücklich wird man mit diesem Weg nicht werden. AVR-COFF
war ein ziemlich verhunztes Format (weshalb AVR Studio ja diesen Weg
dann auch aufgegeben hat).
Sinnvoller wäre es, eine Art Präprozessor zu schreiben, der die paar
Elemente, die in der Atmel-Syntax abweichend gegenüber der gas-Syntax
sind, on the fly konvertiert. Abgesehen von ein paar obskuren Dingen
innerhalb von Makros sollte das gar nicht so schwer sein.
Hi Jörg,
ein Präprozessor bzw. einen Konverter finde ich auch sinnvoller, als
sich mit irgendwelchen veralteten Tools rumzuärgern.
Kennst Du irgendeine Seite bei der die Unterschiede zwischen den beiden
Assemblerformaten übersichtlich dargestellt sind, damit ich mal den
Aufwand für so einen Konverter abschätzen?
Thomas Holland wrote:
> Kennst Du irgendeine Seite bei der die Unterschiede zwischen den beiden> Assemblerformaten übersichtlich dargestellt sind, damit ich mal den> Aufwand für so einen Konverter abschätzen?
Leider auch nicht. Müsste man über die jeweilige Doku mal zusammen-
tragen. So von der Erinnerung her sind die größten Unterschiede in
den Makros (bei GNU werden alle Parameter durch Voranstellen eines
Backslashs gekennzeichnet, bei Atmel als "bare words", d. h. man muss
den Makroinhalt parsen).
Hallo zusammen,
ich werde mich mal um eine Zusammenstellung der Unterschiede bemühen, da
mir aber noch die Erfahrung fehlt, wird sie vermutlich nicht vollständig
sein. Jörg hat ja auch schon viele wichtige Infos in andere Threads
gepostet.
Heute wird es nix mehr. An meinem Geburtstag nehme ich mir mal
"computerfrei"
@Thomas Danke für die Links - vielleicht schalte ich heute Abend den
Rechner doch noch an :)
Grüßle,
Thorsten
Hi,
ich habe mein Ecilpse incl AVR Plugin auf einem USB stick, ebenso die
WinAVR dateien. An sich funktioniert auch alles, nur muss ich jedesmal
wenn ich mich an einen anderen rechner setze die AVR-plugin
Pfad-einstellung anpassen. Gibt es eine Möglichkeit die Pfade relativ zu
machen (hab ich versucht, das Plugin frisst das auch, nur compilieren
geht dann nicht), oder weiss jemand wo die Einstellungen gespeichert
werden? Dann könnte ich einfach einen kleines Tool basteln das die Pfade
bei jedem starten automatisch anpasst - finde nur keine Datei mit den
Einstellungen drin.
Aber abgesehen davon funktioniert wirklich alles super, vielen Dank
Thomas für die entwicklung des Plugins!
Hallo Björn,
sorry das ich etwa spät antworte, aber ich war bis gestern im Urlaub.
Die Pfade, die vom AVR Plugin verwaltet werden sind in folgender Datei
gespeichert:
Die "avrpaths/...=" properties enthalten die vom User eingestellten
Pfade,
die "avrpaths//sytempath/...=" properties enthalten die Pfade, die das
Plugin automatisch ermittelt hat.
Das Problem mit relativen Pfaden ist, das die Pfade an zwei
verschiedenen Stellen mit jeweils unterschiedlichen
Ausgangsverzeichnissen verwendet werden.
Zum einen benutzt das Plugin die Pfade um avr-gcc und avrdude direkt zu
starten um u.A. eine Liste mit unterstützten AVR MCUs zu erhalten. Dabei
wird m.W. von Eclipse das Workspace Verzeichnis als Current Working
Directory (CWD) benutzt.
Für einen Build startet Eclipse, bzw. CDT, make und setzt dabei CWD
auf das Build Verzeichnis, also z.B. workspace/ein_projekt/Debug/, damit
alle vom Compiler und den anderen Tools erzeugten Dateien dort landen.
Damit make den richtigen (vom User eingestellten) avr-gcc findet,
fügt das AVR Plugin die eingestellten Pfade an den Anfang der PATH
environment variable ein, die wiederum von Eclipse/CDT genutzt wird um
make zu starten.
Daher sehe ich es als schwierig an, so ohne weiteres relative Pfade zu
unterstützen.
Was Du aber mal probieren könntest ist die PATH Variable zu modifizieren
und Deine relativen Pfade einzufügen. Ich weiß nicht ob es funktioniert,
aber probieren schadet nicht.
Die Idee wäre, in den AVR Plugin Settings die Pfade so einzustellen wie
Du es ja schon gemacht hast damit das Plugin avr-gcc etc. für die
internen Funktionen findet. Anschließend für jedes Projekt den PATH so
zu ergänzen, dass avr-gcc und die anderen Tools auch vom Build
Verzeichnis aus gefunden werden.
Die PATH Variable findest Du unter Project -> Properties -> C/C++ Build
-> Environment.
Damit man das nicht für jedes Projekt machen muss gibt auch globale
Variablen (Window -> Preferences -> C/C++ -> Environment). Hier evtl.
mal ausprobieren eine für Deinen USB-Stick maßgeschneiderte PATH
Variable zu erstellen und als "replace native environment..." zu
deklarieren, da Du vermutlich für CDT gar keine Pfade des Gastsystems
benötigst.
Berichte doch bitte ob Du Erfolg gehabt hast. Dann würde ich die Lösung
in die Tipps & Tricks auf der Projekt Homepage aufnehmen.
Liebe Grüße,
Thomas
@Thomas Holland
Vorab mal vielen Dank für das Plugin, ich übe mich seit gestern mit
Eclipse und WinAvr, das meiste geht schon recht gut.
Eine kleine Frage: Was muss ich machen, damit ich über meinen JTAG-ICE
(mkI) die SW von Eclipse aus auf dem Target debuggen kann? Die
WinAvr-Toolchain müsste ja alle erforderliche Tools bereitstellen.
MfG Peter
@Peter:
Hier im Forum gibt es viele Hinweise. So wie hier z.B.:
Beitrag "Re: Debuggen in Eclipse geht nicht GDB <-> AVaRICE problem"
Aber Du solltest dir den kompletten genannten Thread durchlesen.
Weiter ist es gut wenn man die Parameter für AVaRICE kennt.
Die Kette zum Debuggen:
Eclipse - GDB(Server) - AVaRICE - JTAG ICE
Das in 3 Sätzen zu Beschreiben ist nicht möglich, da zu komplex.
Okey, ich werde mich mal in den entsprechenden Thread knien...
Da das Debuggen offenbar ein komplexes Thema ist, wäre es natürlich
schön wenn ein erfahrener Eclipse-Nutzer das noch fehlende Kapitel
(Debuggen -> Todo) im folgenden Artikel ergänzen könnte.
http://www.mikrocontroller.net/articles/AVR_Eclipse_Windows
Dort wären die Information sicher besser aufgehoben als über
Diskussions-Thread gestreut.
MfG Peter
Am besten wäre es, wenn Du das jetzt machst, da Du es gerade lernst und
dann auch noch alle Fallstricke im Kopf hast und auch noch, wie man es
zum "laufen" bekommt.
Du brauchst Dir jetzt nur Notizen zu machen und diese dann aufbereitet
in den Artikel bringen. :-)
Beim Kompilieren vom Obdev-USB Treiber fällt mir auf, dass du dem AVR
Assembler gar nicht die Taktfrequenz mitteilst (-DF_CPU=...UL). Ist dies
so gewollt?
Habe es manuell hinzugefügt.
Hi Simon,
ich dachte, dass F_CPU auch an den Assembler übergeben wird, aber Du
hast recht - dem ist nicht so. Ob ich dafür einen Grund hatte oder ob
ich es einfach nur vergessen habe weiß ich nicht mehr.
Ich werde es mal als Feature Request für Version 2.4 aufnehmen. Ich
denke dass es mit ein paar Zeilen in der Plugin.xml zu implementieren
ist, möchte es aber wegen nicht auszuschließender Nebenwirkungen nicht
mehr in die 2.3 Beta aufnehmen.
Als halbwegs eleganten Workaround kannst Du folgendes bei den "Other GCC
Flags" unter "AVR Assembler -> General" eingeben:
1
-DF_CPU=${AVRTARGETFCPU}
.
Damit erhält der Assembler dann immer den aktuellen F_CPU Wert.
LG
Thomas
Hi "innot"
Erst mal ne tiefe Verbeugung vor dem Plugin, was Du hier auf die Beine
stellst.
Ich hab als System aufm Rechner Kanotix Thorhammer, ein Debian 4.0
basiertes Linux. Eclipse Plattform ist die Ganymede Version 3.4.1.
1.) Feedback zum AVR-Plugin ver. 2.3beta:
Das 2.3er AVR-Plugin hab ich getestet, da gehen aber einige Optionen
nicht. Unter "Project/Properties/C/C++Build/Settings" erscheinen nur die
Tabs "Binary Parsers" und "Error Parsers". Die anderen wie "Tool
Settings", "Build Steps" und "Buid Artifact" fehlten komplett. Mit Ver.
2.2 sind die fehlenden Tabs aber da.
2.) Frage zum 2.2er Plugin:
In der Auflistung der MCU-Typen unter "Project/Properties/AVR/Target
Hardware" sind bestimmte Typen wie mega1280, mega1281, mega2560,
mega2561 nicht drin, obwohl die in der /etc/avrdude.conf ebenso
aufgeführt sind, wie in /usr/avr/include/avr/io.h. Die Pfade sind in den
"Project/Properties/C/C++General/Paths and Symbols/Includes" mit
"/usr/avr/include/avr/io.h" für "GNU C" auch eingetragen. Nachdem ich
einen mega1281 proggen will, wählte ich mal den mega128 aus und
versuchte unter "Project/Properties/C/C++Build/Settings/Tool Settings"
in den Assembler-, Compiler- und Linkeroptionen den Eintrag
-mmcu=atmega128 in -mmcu=atmega1281 zu ändern. Geht aber ned, die
Einträge sind nicht veränderbar.
Nun, gibts irgend ein config-File, wo man zusärtliche AVRs eintragen
kann, oder gibt's eine Möglichkeit diese Flags alle händisch zu
editieren ?
Soweit ich das als C-Progger ohne Java-Ahnung in deinen Source-Files
finden konnte, scannt das Plugin das "/usr/avr/include/avr/io.h" durch
und ermittelt aus der Auswertung der Strings a la "#elif defined
(_AVR_xxxxxx_)" die verfügbaren Target Devices. Da müsste es doch
eigentlich alle Einträge finden.
Vielleicht kannst Du hier mit einem Tipp weiterhelfen
Danke
Jürgen
Hey J.oe :-)
vielen Dank für die lobenden Worte!
Zu 1.)
Das Verhalten kann ich mir auf Anhieb nicht erklären - habe ich weder so
schon mal gesehen, noch kann ich es reproduzieren.
Tritt das bei einem frischen (unter 2.3 angelegten) Projekt auf oder ist
es ein älteres Projekt (mit 2.2 oder noch älter angelegt)?
Schick mir doch bitte mal die beiden Dateien ".project" und ".cproject"
aus dem Projektverzeichnis ( mailto:thomas@innot.de ), damit ich mal
schauen kann ob der Fehler reproduzierbar ist.
Zu 2.)
Wahrscheinlich benutzt Du eine zu alte Version der avr-gcc toolchain,
welche die Fehlenden MCUs noch nicht unterstützt. Die Liste aller MCUs
erzeugt das Plugin nicht aus der <avr/io.h>, sondern indem es den
Compiler mit "avr-gcc --target-help" startet und den Output auswertet.
Probier mal, den Befehl so in der Shell einzugeben und schau ob im
Output unter "Known MCU names:" atmega1281 und die anderen fehlenden
MCUs auftauchen.
Wenn ja, dann hast Du mehrere Toolchains installiert und das Plugin
benutzt die Falsche (Window -> Preferences... -> AVR -> Paths)
Wenn nein, dann musst Du Dir eine neuere Toolchain besorgen (info u.A.
hier:
http://avr-eclipse.sourceforge.net/wiki/index.php/The_AVR_GCC_Toolchain
oder hier: http://www.mikrocontroller.net/articles/AVR-GCC#Linux.2FUnix
)
<avr/io.h> wird zwar auch ausgewertet, aber nur für den "AVR Device
Explorer" Viewer genutzt.
Liebe Grüße,
Thomas
Hallo Thomas
Na das nenn ich ja eine Reaktionszeit.
Erst mal danke für deine ausfühliche Antwort.
erst mal zu 2.)
Du hattest recht, mein avr-gcc war Version 4.1.0 und unterstützte die
neueren Atmels noch ned. Beim Durchstöbern deiner Java Quelltexte,
dachte ich, der holt sich die unterstützten Prozze aus dem include-file
unter/usr/avr/include/avr/io.h. Das gehört aber zur avr-libc und sagt
richtigerweise nix über den Compiler aus.
Ich hab jetzt die ganze Toolchain aus neuesten Sourcen kompiliert und in
/usr/local/gnuavr/... installiert. War einige Arbeit, aber in debian
stable gibt's nix neueres. Sonst hätte ich ein chroot mit debian testing
oder sid einrichten müssen, und alle bisherigen avr-Anwendungen dorthin
portieren. Denn in nur lenny (testing) und sid gibts die neueren Tools.
Egal, jetzt hab ich avr-gcc 4.3.2 und da passt alles. Es wird auch
korrekt eine liste an Targethardware ausgegeben, unter dem 2.2er plugin.
Danke nochmal, da wär ich selber nie draufgekommen, war mit avrdude und
avr-libc auf der falschen Fährte.
zu 1.) Probleme mit dem 2.3er beta plugin:
Ich muss erst das 2.2er aus dem Plugins-verzeichnis von eclipse nehmen
und das 2.3er wieder rein tun. Dann test ich nochmal und mail die die
gewünschen files zu.
Mach ich vorauss. heut Abend.
Grüße Jürgen
Hallo Thomas
Ja was soll ich sagen ... hab das 2.3 Beta nochmal ins
Plugin-Verzeichnis, das 2.2er raus ... und: es läuft, wie's soll.
Kann nicht nachvollziehen, was beim ersten Anlauf nicht wollte.
Trotzdem mail ich dir die Files .cproject und .project
Grüße Jürgen
Hallo Stefan
Hast du vielleicht zwei Toolchains mit zwei verschiedenen
Compilerversionen auf deinem Rechner ?
Sonst wüsst ich auch keinen Grund, warum ein und derselbe Compileraufruf
verschiedenen Assemblecode erzeugen sollte, wenn der Aufruf ein mal
direkt von der Konsole, einmal von eclipse aus erfolgt.
Mach doch mal folgendes: Kopier den kompletten Compileraufruf mit allen
Parametern aus eclipse in die Konsole und ruf dann aus der Kosole den
Compiler m i t dem Absolutpfad auf, wie er in den Eclipse-Settings
vermerkt ist.
Dann musses wirklich dasselbe Ergebnis sein.
Grüße Jürgen
Hallo!
Danke für die Tipps!!!
Es waren wirklich 2 verschieden Toolchains auf dem Rechner, daher die
unterschiedlichen ergebnisse. Habe das jetzt gerade gezogen. nun habe
ich das Problem, das er in einem Testprojekt was ich gemacht habe immer
noch so viele Register rettet, werde aber dafür einen neuen Thread
aufmachen.
Vielen dank!!!
Stefan
Hi Thomas,
hab auch mal ein Problem ;)
Habe gerade ein neues Projekt erstellt, alles eingestellt und
kompiliert. Danach auf Upload to Device gegangen -> vergessen den
Programmer einzustellen. Also den Programmer ausgewählt und nochmals
Upload gesagt: Keine Reaktion, also nichts auf der Konsole, keine
Fehlerfenster oder sonst irgendwas. Hatte das vor Ewigkeiten schon
einmal, damals aber nach dem Umzug eines Projektes auf ein neues OS,
dachte es hätte daran gelegen. Diesmal ist ja alles ganz frisch und
daher frag ich mich, was da los ist. Habe auch nocheinmal den Programmer
ausgewählt und sogar manuell auf Apply geklickt, keine Änderung.
.cproject ist im Anhang.
Grüße,
Chris
Hallo Chris,
eine direkte Erklärung habe ich im Moment nicht. D.H. wir müssen
versuchen, das Problem einzukreisen. Die .cproject Datei hilft dabei
leider nicht, denn das Projekt wird ja ordentlich compiliert (in der
.cproject stecken die ganzen Einstellungen zum Build des Projektes).
Ich nehme an, Du benutzt das Toolbar Icon um den Upload zu starten.
Geht es auch nicht, wenn Du einen Rechts-Klick auf Dein Projekt machst
und dann "AVR -> Upload to Target Hardware" auswählst?
Eventuell gibt es intern irgendwo einen Fehler, der eine Exception
auslöst, diese aber nicht angezeigt wird. Hier könnte es helfen das
Eclipse Logfile zu öffnen und nach "de.innot.avreclipse" zu suchen.
Das Logfile kannst Du von Eclipse aus öffnen: Help -> About Eclipse SDK
-> Configuration Details -> View Error Log
Um Dein Projekt zumindest kurzfristig auf Deinen AVR zu bekommen kannst
Du bei den Tool Settings (Project properties -> C/C++ Build -> Settings
-> Tool Settings) avrdude bei den Tools aktivieren. Dann wird avrdude
direkt nach dem Compilieren gestartet. Da bei dieser Variante avrdude
direkt ins Makefile eingebaut wird müsste es ohne Probleme gehen.
Cheers,
Thomas
Hi Thomas,
danke für die schnelle Antwort =)
Ich teste immer beides, also sowohl Rechtsklick -> AVR -> Upload als
auch den Toolbarbutton. Normal funktioniert immer beides, bei dem
Projekt weder noch ;)
Das Errorlog enthält zwar einige Fehler, die nach dem Problem aussehen,
allerdings konnte ich Eclipse nicht dazu bringen, noch weitere Fehler
dort reinzuschreiben. Der Angehängte Fehler ist der letzte im Log, habe
es eben aber um 18:53 nochmal probiert und da gab es keine weiteren
Einträge im Log.
Zur Zeit rufe ich avrdude über die Konsole auf, da ich eh meisst vergess
vorher den Bootloader zu starten und ich dann entsprechend nochmal
kompilieren müsste, nur um zu flashen ... Geht halbwegs, aber mit dem
Button ist es halt eigentlich schöner ;)
Grüße,
Chris
Chris, Du hast genau die richtige Fehlermeldung getroffen.
Es ist tatsächlich ein Bug im Plugin, der durch den Namen Deines
Projektes ausgelöst wird.
Ich nehme an, dass Dein Projekt "irgendwas-USART_target" heißt. Das
Problem ist das "-U" in dem Namen, der einen Programmierfehler im Plugin
auslöst.
Genauer gesagt versucht das Plugin beim upload die avrdude Kommandzeile
zu interpretieren um den Fortschritt anzuzeigen. Dazu zerlegt es den
"-U" parameter in seine Teile, beginnend ab dem "-U". Der Fehler liegt
nun darin, dass das Plugin nicht mit dem ersten "-U" anfängt, sondern
mit dem letzten -- dem in Deinem Projektnamen und damit vollkommen
durcheinander kommt.
Der Fehler wird natürlich für die entgültige Version 2.3 behoben. Bis
dahin muss ich Dich leider bitten, Dein Projekt umzubenennen, z.B. indem
Du das "-" durch ein "_" ersetzt.
LG
Thomas
Ah, ok ... Hab mich schon gewundert, warum er genau an der Stelle
abbricht ... macht aber durchaus Sinn =)
USB-USART_target wars. Danke für die Hilfe.
Gibt es eigentlich schon einen Release-Termin für 2.3?
Grüße und einen schönen Abend noch,
Chris
Zur entgültigen Version 2.3 fehlen eigentlich nur noch ein paar Seiten
im User Manual, was ich aber schon seit rund zwei Monaten vor mir
herschiebe. Doku schreiben macht halt bei weitem nicht so viel Spaß wie
Programmieren.
Ich habe aber jetzt beschlossen nur ein bisschen Alibi-Doku zu schreiben
und die V2.3 spätestens nächste Woche rauszuhauen.
Thomas
Mir fällt grad noch ein kleines Features ein, dass nur durch Anpassen
der plugin.xml zu erreichen wäre.
Es sollte auch ein Binary target zur Verfügung stehen, nicht nur ihex
(wichtig für USBprog). Die Frage ist nur ob man eine Option im "Create
Flash" einfügt (dann könnte man nur entweder bin oder hex erstellen)
oder ein zweites Tool erstellt.
Wenn USBProg keine Hexfiles verarbeiten kann, dann ist das Manko von
USBProg und sollte dort behoben werden. Hexfiles sind ja schließlich
ein "Quasi-Standard".
Außerdem sollte es mit Post-Build Optionen möglich sein, automatisch aus
dem Hexfile ein Bin-File zu erzeugen. Muß also nicht ins Plugin
unbedingt.
Meine Meinung
avr-objcopy unterstützt binary, srec und hex. Sind alle gleichermaßen
"Standard". Warum sollte das Plugin nicht auch die möglichen Optionen
von avr-objcopy bereitstellen? Es ist ja kein Bug, sondern nur ein
nettes Feature.
Manuel Stahl wrote:
> Es sollte auch ein Binary target zur Verfügung stehen, nicht nur ihex> (wichtig für USBprog). Die Frage ist nur ob man eine Option im "Create> Flash" einfügt (dann könnte man nur entweder bin oder hex erstellen)> oder ein zweites Tool erstellt.
Hi Manuel,
dazu gibt es schon einen Feature Request:
https://sourceforge.net/tracker2/?func=detail&aid=2179796&group_id=189165&atid=928234
Dort steht auch drin, warum ich etwas unwillig bin, das Feature zu
unterstützen. Leider hat mir der Antragsteller auch nicht meine Frage
beantwortet, wozu er die Formate braucht.
Als kleinen Workaround habe ich gerade mal ausprobiert ein *.bin file
über den Postbuild Step zu erzeugen. Funktioniert gut und ist m.E. eine
elegante Lösung für die paar User, die unbedingt raw binaries brauchen.
(Siehe angehängten Screenshot)
Und hier der Befehl nochmals für Copy & Paste:
Hmm, mit dem Postbuild könnte man beide erzeugen. Normal brauch ich nur
entweder hex oder bin (also der Parameter im avr-objcopy).
Was ich schön fände wär mal ne Wizard-Option "Configure for USBprog".
Der könnte dann alle Einstellungen (Outputformat, Programmer, etc.)
passend konfigurieren. Ich denk, da werd ich mich mal dranmachen.
> avr-objcopy unterstützt binary, srec und hex. Sind alle gleichermaßen> "Standard".
Nein, das Hexformat ist wesentlich weiter verbreitet zum einlesen bei
den Programmiertools. Das können fast alle (außer USBProg, was ich
ziemlich schwach finde).
In dem Plugin V2.3 Beta ist evtl. noch etwas buggy.
Ich habe gerade eine neue WinAVR Version auf meinem Rechner
installiert. Jetzt stimmen die "Standard"-Include-Pfade nicht mehr.
Zu finden unter Project.Properties.C/C++ General.Path and Symbols.
Dort tauchen jetzt die Pfade der neuen Installation auf und auch der
alten.
Die alten sind aber nicht mehr da, also gibt es immer Warnings. Zwar
nicht vom Compiler aber im Problems View von Eclipse.
Delete der alten Pfade ist nicht möglich. :-(
Evtl. hat das schon mal jemand gehabt und weiß wie man das behebt
ohne ein neues Projekt anzulegen.
Oder Thomas weiß was ;-)
Gruß
900ss
>Evtl. hat das schon mal jemand gehabt und weiß wie man das behebt>ohne ein neues Projekt anzulegen.
Das war bei mir auch so. Ich hab halt ein neues Projekt angelegt, das
geht ja relativ fix.
Oliver
Oliver wrote:
> Das war bei mir auch so. Ich hab halt ein neues Projekt angelegt, das> geht ja relativ fix.
Damit verschwinden aber nicht die Bugs. Sollte schon gemeldet werden.
Na gut, dann ist es wohl ein allgemeines Problem. Muß Thomas sich mal
äußern wenn er mal wieder Zeit. Seine Antwortzeiten heben sich von der
Servicewüste Deutschland ja sehr ab, also sind super kurz meine ich ;-)
Hallo Zusammen,
das Eclipse einmal gefundene Pfade nicht mehr vergisst ist ein Bug von
CDT:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=206372
Es gibt übrigens im Zusammenspiel mit dem AVR Plugin das Problem, dass
z.B. bei Änderungen der Target MCU die darauf aufbauenden Preprocessor
Makros im Editor nicht bzw. nicht immer korrekt angezeigt werden (bei
#ifdef werden die falschen Blöcke ausgegraut)
Workaround aus dem o.g. Bugfix:
1
To manually fix the
2
file you need to move/delete the ${projectname}.sc file found under
Wenn ich es richtig verstanden habe soll der Bereich "Discovery" für CDT
6.0 (= Eclipse 3.5) überarbeitet werden. Ich hoffe dass dann auch dieses
Problem behoben wird.
Ich hatte vor einiger Zeit auch schon versucht alte Pfade vom AVR Plugin
löschen zu lassen, aber es fehlen die dazu nötigen API Methoden bei CDT
und ich hätte mehr oder weniger die ganze AutoDiscovery
nachprogrammieren müssen (Copy-and-Paste geht nicht, da die GPL des
Plugins nicht mit dem EPL von CDT kompatibel ist).
Thomas
So, für alle die dieses Forum nur per Email-Benachrichtigung lesen:
Ich habe letzte Nacht Version 2.3 des AVR Eclipse Plugins freigegeben.
Alles weitere im neuen Thread:
Beitrag "AVR Eclipse Plugin 2.3"
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
Hallo, ich versuche schon seit einiger
Zeit das Plugin zu benutzen um damit assembler Programme zu schreiben.
Leider ist es mir jedoch nicht gelungen die richtigen Einstellungen zu
finden um dem Plugin mitzuteilen von die *.inc files zu finden sind.
Kann mir da jemand weiter helfen.
Ich bekomme die Fehlermeldung:
Error: can't open m16def.inc for reading: No such file or directory
Vielen Dank
Torsten
Torsten,
es gibt zwei verschiedene Syntaxen für AVR Assembler.
Zum einen den 'Atmel AvrAssembler' Syntax, der vom AVR Studio benutzt
wird, und zum anderen den 'GNU avr-as' Syntax, welcher von der GCC
Toolchain verstanden wird.
Die beiden Dialekte sind ähnlich, aber nicht kompatibel.
Die '*.inc' Dateien, die Du einbinden möchtest, sind typisch für Atmel
AvrAssembler und daher vermute ich mal, dass Dein Source-Code in diesem
Format vorliegt.
Im 'GNU' Format würde man statt
1
.include "8515def.inc"
z.B.
1
#include<avr/io.h>
benutzen.
Natürlich reicht das noch nicht aus, es müsste wahrscheinlich noch
einiges mehr 'konvertiert' werden. Siehe
Beitrag "Re: [Anfänger-Probleme] Wie assembliere ich Assemblercode bei WinAVR?" ff. und z.B. hier
http://electrons.psychogenic.com/modules/arms/art/3/AVRGCCProgrammingGuide.php#assembly
Ob sich die Arbeit einer Konvertierung lohnt hängt davon ab was Du vor
hast:
Wenn Du nur irgendein Assembler-Programm anpassen und zum Laufen bringen
willst, dann lohnt es sich wahrscheinlich nicht und ich würde zum AVR
Studio raten.
Wenn Du aber größeres vor hast und die Assemblerteile auch mal um Teile
in C ergänzt werden sollen, dann wirst Du nicht um eine Konvertierung
herum kommen. Nur die GNU Toolchain unterstützt eine Mischung aus ASM
und C.
Thomas
Thread beobachten
Seitenaufteilung abschalten