mikrocontroller.net

Forum: Compiler & IDEs AVR Eclipse Plugin 2.2


Autor: Thomas Holland (innot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe jetzt Version 2.2 meines Eclipse plugins für AVR zum Download 
bereitgestellt.

Direkter Download: 
https://sourceforge.net/project/showfiles.php?grou...

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/o...

Viel Spass beim avrdude'n :-)

brgds,

Thomas


********************************************************************************
*                      AVR Eclipse Plugin Change Log                           *
*                                                                              *
* A plugin supporting the development of applications for the AVR series       *
* of Processors.                                                               *
* See details at http://avr-eclipse.sourceforge.net                            *
********************************************************************************
$Id: changelog.txt 481 2008-06-18 13:16:58Z innot $

================================================================================
Version 2.2.0 [18-June-2008]

New:
-----------------------------
* AVRDude support
  - A list of Programmers can be managed via the AVRDude preferences.
  - AVRDude project properties to set all properties.
  - (optional) avrdude tool in toolchain to auto-upload the project whenever the project is build.
  - "Upload Project to Device" action in the project context menu to manually upload with avrdude.
  - Optional upload via toolbar action or hotkey (Ctrl+Alt+U on Windows) (not in 2.2beta1)
    
* Target Hardware properties can now also be defined per build configuration.
  - Enable in the project properties on the AVR page.

* Supported MCU View
  - Show a list of all MCUs supported by the plugin and various subsystems like gcc and avrdude.
  - Clickable hyperlinks to the Atmel datasheets for most MCUs.
  - Open with "Window > Show View -> Other... -> AVR -> AVR Supported MCUs"

Changed / Improved:
-----------------------------
* AVR Device Explorer
  The Device Explorer is now a "Selection Listener" and "Selection Provider".
  When selecting a AVR project or a text which starts with a valid MCU name,
  the associated MCU information is shown in the Device Explorer

* Build variables
  The build variables defined by the plugin (e.g. ${AVRTARGETMCU} and ${AVRTARGETFCPU}) can now 
  have an optional argument to read the value from a different project or build configuration.
  Example: ${AVRTARGETMCU:project01/release} gets the target mcu of the "release" configuration of 
           project "project01".

* Changed since 2.2beta1:
  - Most of the user documentation updated to 2.2 incl. a tutorial on how to use avrdude.
    Some features are still lack a user documentation (will be completed in one of the next releases)
  - List of datasheets, signatures, fusebytes and lockbits updated to AVR Studio Build 589
    (ATXmega MCUs only partially supported -- no fusebytes/Lockbits yet)

Fixes:
-----------------------------
* Windows: Now the last installed version of winAVR is used when multiple winAVR
  versions are installed
  
* Multiple failures when some / all of the paths were invalid. Fixed and replaced by error messages.
  
* Fixed since 2.2beta1:
  - Plugin did not parse programmer ids with "-" or "_" from avrdude output (Bug 1984307)
  - AVR popup menu was not shown in C/C++ Explorer
  

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas Holland (innot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Thomas Holland (innot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas Holland (innot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: sous (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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]

Autor: sous (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!  ;)

Autor: Thomas Holland (innot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

bei mir gab es gerade die selbe Fehlermeldung.

Oliver

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nachtrag:

Jungfräuliches Ganymed, Win XP, SP3

Oliver

Autor: sous (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas Holland (innot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: vistageek (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ATOMLOL

Es lebe das Gefrickel!

Autor: Manuel Stahl (thymythos) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schön, dass es vorwärts geht.

Hab heute auch mal mein Programmer Plugin ins SVN geladen.

Wers ausprobieren will: 
http://avr-eclipse.svn.sourceforge.net/viewvc/avr-...

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Manuel Stahl wrote:
> Schön, dass es vorwärts geht.
>
> Hab heute auch mal mein Programmer Plugin ins SVN geladen.
>
> Wers ausprobieren will:
> 
http://avr-eclipse.svn.sourceforge.net/viewvc/avr-...

Was kann das denn? ;) Ein AVRDude Plugin ist ja schon nativ dabei.

Autor: Manuel Stahl (thymythos) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jetzt hat es geklappt.

Oliver

Autor: Thomas Holland (innot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oliver wrote:
> Jetzt hat es geklappt.
>
> Oliver

Danke für die Info!

Und jetzt hoffe ich mal auf eine erfolgreichere zweite Halbzeit... :-)

Thomas

Autor: Thomas Holland (innot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Und jetzt hoffe ich mal auf eine erfolgreichere zweite Halbzeit... :-)

Nein!

Na dann kann ich mich ja wieder an die Plugin Programmierung machen. :-)

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Manuel Stahl (thymythos) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
udev hilft dir
cat /etc/udev/rules.d/80-usbprog.rules
ATTRS{idVendor}=="1781", ATTRS{idProduct}=="0c65", GROUP="plugdev", MODE="0660"
ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2104", GROUP="plugdev", MODE="0660"

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
danke. Die Datei gabs bei mir nicht. Hab sie erstellt und jetzt gehts

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Thomas Holland (innot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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=deta...

Thomas

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, dann weiß ich zumindest woher es kommt und das Abhilfe in Sicht ist. 
Dann ist das ja ok.

Nochmal dickes Lob für die ganze Mühe

Autor: gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jan, hast Du die Fragen hier im Thread gestellt?

Beitrag "Re: Debuggen in Eclipse geht nicht GDB <-> AVaRICE problem"

Ansonsten mußt Du AVARICE als Suchbegriff nutzen :-)
In dem obigen Link ist ein Anhang mit Screenshots, so funktioniert
es.

Autor: Jan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
danke für den Hinweis. Der Eintrag war nicht von mir.

Autor: Jan (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Jan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich hab mein fehler gefunden, hab mich einfach nur vertippt

Autor: Frank Lorenzen (florenzen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas Holland (innot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Frank Lorenzen (florenzen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank Thomas,
ich werde es heute abend ausprobieren.

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Thomas Holland (innot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.av...

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

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Fettes Merci,
ich werds mal testen.

Autor: Thomas Holland (innot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> ich werds mal testen.

Ich bitte drum :-)

Autor: Thomas Holland (innot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.
make all 
make: Warnung: Datei 'subdir.mk' hat Änderungszeit 2,1 s in der Zukunft
Invoking: Print Size
avr-size --format=berkeley -t Mega8Modul.elf
   text     data      bss      dec      hex  filename
    452        0       93      545      221  Mega8Modul.elf
    452        0       93      545      221  (TOTALS)
Finished building: sizedummy
 
make: Warnung: Mit der Uhr stimmt etwas nicht. 
Die Bearbeitung könnte unvollständig sein.

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas Holland (innot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Thomas Holland (innot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gut, dann kann ich ja ein Haken an den Fix machen. Danke für die Info.

Autor: Julien (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

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

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

Ich habe zum testen eine einfache LED blinken lassen.

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

Gibt es bereits brauchbare Lösungen?

Gruß Julien

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Thomas Holland (innot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Ich habe gerade eine erste Beta der Version 2.3 auf SourceForge bereit
gestellt:

https://sourceforge.net/project/showfiles.php?grou...

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:
********************************************************************************
*                      AVR Eclipse Plugin Change Log                           *
*                                                                              *
* A plugin supporting the development of applications for the AVR series       *
* of Processors.                                                               *
* See details at http://avr-eclipse.sourceforge.net                            *
********************************************************************************
$Id: changelog.txt 614 2008-09-14 18:55:30Z innot $

================================================================================
Version 2.3.0 Beta 1 [15. September 2008]

New:
-----------------------------
* Support for Fuses / LockBits files
  - Two new wizards to create fuse and lockbit files (New -> Other -> AVR -> ....)
  - An editor to edit these files.
  - The files can be selected as the fuses / lockbits source on the AVRDude property
    Fuses / Lockbits pages.

* Detailed preview of the selected fuse bytes on the project 
  AVRDude property Fuses / Lockbits pages. 


Changed / Improved:
-----------------------------
* ATXmega processors are now fully supported. (Except for the upload with 
  avrdude because avrdude does not yet support the ATXmega line.)
  
* The AVRDude project properties now have a new field "other options" to add
  avrdude options not supported by the plugin. (As of version 2.3 the plugin
  supports all options for avrdude version 5.5).

* Improved path handling.
  All system paths are now saved in a persistent cache, so they need to be
  searched only once. 
  By default the plugin will still search all paths at startup, but this can
  be inhibited on the AVR preference page. Once inhibited any system 
  reconfigurations (like a new avr-gcc toolchain in a different directory) 
  are not automatically recognized any more.
  In this case the new "Rescan" button on the AVR path preferences can be 
  used to look for the new path.

Fixes:
-----------------------------

* Bug 1962594: Searching for System Paths slow on Linux.
  See above for a description of the fix.

* Bug 2008171: Build System ignores .c files in C++ project - Fixed.
  
* Bug 2011424: Added a descriptive error message when the build directory is
  not valid.
  
* Bug 2020689: avrdude option -D (Disable auto erase for flash) missing.
  Fixed: added option to inhibit auto erase. 
  
* Bug 2050945: Read Back of "Enable Individual Settings ..."
  Fixed: removed internal caching of project setting.
  
* Bug 2071415: Timing issue on Linux / USB / AVR Dragon
  Fixed by adding a user selectable delay between avrdude programming calls.
  The value is set on the Programmer Configuration dialog
  (Window -> Preferences -> AVR -> AVRDude -> Programmer configurations -> Edit...)


Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Thomas Holland (innot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Thorsten Wein (tottiw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Thomas Holland (innot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Thorsten Wein (tottiw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Thorsten Wein (tottiw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Thomas Holland (innot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas Holland (innot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Thomas Holland (innot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Thorsten
> Wenn aber jemand "zufällig" eine USI Master C Implementierung zu Hand
> hat, sage ich auch nicht nein ;)

habe ich gerade zufällig gefunden: 
http://www.avrfreaks.net/index.php?name=PNphpBB2&f...

Bei der weiteren Suche nach "usi.h" habe ich noch folgendes gefunden:

http://git.b9.com/cgi-bin/gitweb.cgi?p=avr_bc100.g...

vielleicht hilft es Dir weiter.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Thorsten Wein (tottiw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Björn V.d.o. (froghut)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Thomas Holland (innot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
workspace/.metadata/.plugins/org.eclipse.core.runtime/.settings/de.innot.avreclipse.core.prefs

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

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.  :-)

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas Holland (innot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
-DF_CPU=${AVRTARGETFCPU}
.
Damit erhält der Assembler dann immer den aktuellen F_CPU Wert.

LG

Thomas

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alles klar, Danke! :D

Autor: j.oe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Thomas Holland (innot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/... 
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

Autor: j.oe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: j.oe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Ich habe ein Problem beim Compilieren einer Datei mit einem ISR.

es gibt unterschiedliche Ergebnisse, je nachdem ob make vom eclipse oder 
über cmd gestartet wird

der Aufruf des gcc aus eclipse und vom cmd sind komplett identisch.

der aufruf aus Eclipse:

Building file: ../rtc.c
Invoking: AVR Compiler
avr-gcc -I"D:\Daten\Projekte\AVR\APC2\com" -DDEBUG_SOFTFON 
-DDEBUG_SOFTFONT_LINEFEED -DDEBUG_T6963_ -DC -DDEBUG_SENSOR -DMAIN_DEBUG 
-DUART_BAUD_RATE=38400 -DUART_DEBUG -DFLASH_PROG_DEBU 
-DUART_RX_BUFFER_SIZE=256 -DUART_TX_BUFFER_SIZE=256 -DRAMEND=0xFFE 
-DFLASH_PROG_DEBUG_EEPROM -Wall -g3 -gdwarf-2 -Os -fpack-struct 
-fshort-enums -std=gnu99 -funsigned-char -funsigned-bitfields 
-fno-tree-scev-cprop  -ffunction-sections -fno-inline-small-functions 
-fgnu89-inline -mmcu=atmega128 -DF_CPU=16000000UL -MMD -MP -MF"rtc.d" 
-MT"rtc.d" -c -o"rtc.o" "../rtc.c"
Finished building: ../rtc.c

und von cmd:

D:\Daten\Projekte\AVR\APC2\Debug>make all
Building file: ../rtc.c
Invoking: AVR Compiler
avr-gcc -I"D:\Daten\Projekte\AVR\APC2\com" -DDEBUG_SOFTFON 
-DDEBUG_SOFTFONT_LINE
FEED -DDEBUG_T6963_ -DC -DDEBUG_SENSOR -DMAIN_DEBUG 
-DUART_BAUD_RATE=38400 -DUAR
T_DEBUG -DFLASH_PROG_DEBU -DUART_RX_BUFFER_SIZE=256 
-DUART_TX_BUFFER_SIZE=256 -D
RAMEND=0xFFE -DFLASH_PROG_DEBUG_EEPROM -Wall -g3 -gdwarf-2 -Os 
-fpack-struct -fs
hort-enums -std=gnu99 -funsigned-char -funsigned-bitfields 
-fno-tree-scev-cprop
 -ffunction-sections -fno-inline-small-functions -fgnu89-inline 
-mmcu=atmega128
-DF_CPU=16000000UL -MMD -MP -MF"rtc.d" -MT"rtc.d" -c -o"rtc.o" 
"../rtc.c"
Finished building: ../rtc.c

mein Problem ist, das das listfile ja nach Aufruf anders ausschaut.

bei eclipse:

//Interruptroutine für Comparmatch
ISR(TIMER0_COMP_vect){
    2584:  1f 92         push  r1
    2586:  0f 92         push  r0
    2588:  0f b6         in  r0, 0x3f  ; 63
    258a:  0f 92         push  r0
    258c:  0b b6         in  r0, 0x3b  ; 59
    258e:  0f 92         push  r0
    2590:  11 24         eor  r1, r1
    2592:  2f 93         push  r18
    2594:  3f 93         push  r19
    2596:  4f 93         push  r20
    2598:  5f 93         push  r21
    259a:  6f 93         push  r22
    259c:  7f 93         push  r23
    259e:  8f 93         push  r24
    25a0:  9f 93         push  r25
    25a2:  af 93         push  r26
    25a4:  bf 93         push  r27
    25a6:  ef 93         push  r30
    25a8:  ff 93         push  r31

  uint8_t tmp;
  if(USED_TIMER>45)interruptDone = 1;//Timer ist über 255
    25aa:  82 b7         in  r24, 0x32  ; 50
    25ac:  8e 32         cpi  r24, 0x2E  ; 46
    25ae:  18 f0         brcs  .+6        ; 0x25b6 <__vector_15+0x32>
    25b0:  81 e0         ldi  r24, 0x01  ; 1
    25b2:  80 93 7f 0b   sts  0x0B7F, r24
  tmp = load + (uint8_t)TIMER_LOAD;
    25b6:  80 91 aa 05   lds  r24, 0x05AA
    25ba:  87 5f         subi  r24, 0xF7  ; 247
  //load += (uint8_t)TIMER_LOAD;
  if(tmp==255) tmp=0;
    25bc:  8f 3f         cpi  r24, 0xFF  ; 255
    25be:  09 f4         brne  .+2        ; 0x25c2 <__vector_15+0x3e>
    25c0:  80 e0         ldi  r24, 0x00  ; 0
  load = tmp;
    25c2:  80 93 aa 05   sts  0x05AA, r24
  OCR0 = tmp;
    25c6:  81 bf         out  0x31, r24  ; 49
  drehInterrupt();
    25c8:  0e 94 46 09   call  0x128c  ; 0x128c <drehInterrupt>
}
    25cc:  ff 91         pop  r31
    25ce:  ef 91         pop  r30
    25d0:  bf 91         pop  r27
    25d2:  af 91         pop  r26
    25d4:  9f 91         pop  r25
    25d6:  8f 91         pop  r24
    25d8:  7f 91         pop  r23
    25da:  6f 91         pop  r22
    25dc:  5f 91         pop  r21
    25de:  4f 91         pop  r20
    25e0:  3f 91         pop  r19
    25e2:  2f 91         pop  r18
    25e4:  0f 90         pop  r0
    25e6:  0b be         out  0x3b, r0  ; 59
    25e8:  0f 90         pop  r0
    25ea:  0f be         out  0x3f, r0  ; 63
    25ec:  0f 90         pop  r0
    25ee:  1f 90         pop  r1
    25f0:  18 95         reti


bei cmd:
//Interruptroutine für Comparmatch
ISR(TIMER0_COMP_vect){
    2584:  1f 92         push  r1
    2586:  0f 92         push  r0
    2588:  0f b6         in  r0, 0x3f  ; 63
    258a:  0f 92         push  r0
    258c:  11 24         eor  r1, r1
    258e:  8f 93         push  r24

  uint8_t tmp;
  if(USED_TIMER>45)interruptDone = 1;//Timer ist über 255
    2590:  82 b7         in  r24, 0x32  ; 50
    2592:  8e 32         cpi  r24, 0x2E  ; 46
    2594:  18 f0         brcs  .+6        ; 0x259c <__vector_15+0x18>
    2596:  81 e0         ldi  r24, 0x01  ; 1
    2598:  80 93 7f 0b   sts  0x0B7F, r24
  tmp = load + (uint8_t)TIMER_LOAD;
    259c:  80 91 aa 05   lds  r24, 0x05AA
    25a0:  87 5f         subi  r24, 0xF7  ; 247
  //load += (uint8_t)TIMER_LOAD;
  if(tmp==255) tmp=0;
    25a2:  8f 3f         cpi  r24, 0xFF  ; 255
    25a4:  09 f4         brne  .+2        ; 0x25a8 <__vector_15+0x24>
    25a6:  80 e0         ldi  r24, 0x00  ; 0
  load = tmp;
    25a8:  80 93 aa 05   sts  0x05AA, r24
  OCR0 = tmp;
    25ac:  81 bf         out  0x31, r24  ; 49
  drehInterrupt();
    25ae:  0e 94 46 09   call  0x128c  ; 0x128c <drehInterrupt>
}
    25b2:  8f 91         pop  r24
    25b4:  0f 90         pop  r0
    25b6:  0f be         out  0x3f, r0  ; 63
    25b8:  0f 90         pop  r0
    25ba:  1f 90         pop  r1
    25bc:  18 95         reti



Kann mir nun nicht erklären, warum einmal mit den ganzen push/pop, und 
warum dann wieder ohne ...

jemand eine idee?

gruß Stefan

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Evtl. unterschiedliche WinAVR-Versionen benutzt?

Autor: j.oe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christian Illy (alloc)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Thomas Holland (innot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christian Illy (alloc)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Thomas Holland (innot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christian Illy (alloc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Thomas Holland (innot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Manuel Stahl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Meine Meinung (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Manuel Stahl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas Holland (innot)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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=...

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:
avr-objcopy -R .eeprom -O binary ${BuildArtifactFileName}  ${BuildArtifactFileBaseName}.bin

LG

Thomas

Autor: Manuel Stahl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Meine Meinung (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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).

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;-)

Autor: Thomas Holland (innot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
To manually fix the
file you need to move/delete the ${projectname}.sc file found under
${workspace}/.metadata/.plugins/org.eclipse.cdt.make.core

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

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke Thomas, mir ist so, als wenn wir das schon mal hatten.
Ich glaube da hab ich was verdrängt :-(

900ss

Autor: Thomas Holland (innot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hast Du :-) Beitrag "Re: AVR Eclipse Plugin 2.1 Released"

Aber ist schon OK, denn die Frage wird sicher noch öfters aufkommen. Ich 
muss mal ne FAQ machen.

Autor: Thomas Holland (innot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan Kuhne (sk-ac)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: 900ss (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan Kuhne schrieb:
> Kann das jemand reproduzieren?

Nein, aber vielleicht hilft dir das ja.

Beitrag "Re: AVR Eclipse Plugin 2.2"

Autor: Torsten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Thomas Holland (innot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
.include "8515def.inc"
z.B.
#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/...

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

Antwort schreiben

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

Wichtige Regeln - erst lesen, dann posten!

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

Formatierung (mehr Informationen...)

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




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

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