www.mikrocontroller.net

Forum: Compiler & IDEs WinAVR & AVRStudio


Autor: N. N. (drnicolas)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Mit dem nachfolgenden Problem bin ich bereits in AVRFreaks auf etwas 
Unverständnis gestossen. Die tun so, als ob alles kein Problem sei.

Da es aber immer noch ein Problem ist, versuche ich es mal hier - 
vielleicht geht's in deutsch doch leichter.

Ich kompliere mit dem neuesten WinAVR und versuche dann die ELF-Datei in 
AVR STudio 4.18 SP3 zu öffnen.

Bei manchen neuen Projekten oder auch nach Ergänzen von Code (zuletzt 
führte das Benutzen von _delay_ms() dazu) tauchen mehrmals Boxen wie im 
Anhang abfotografiert auf.


Besonders interessant finde ich den Umstand, dass and den 
nachvollziehbaren Pfad ( bis ...\Debug) nochmals ein Netzwerkpfad 
angehängt wird. Den Pfad könnte ich noch halbwegs nach vollziehen.
Dann aber komt's: Nochmals so eine Box mit einem überhaupt nicht 
existenten Pfad.
Danach nochmals 2 weieter Boxen mit ebenfalls nicht existenten Pfaden.

In AVRFreaks war eine Anleitung mit der man wohl überflüssige 
Informationen aus den Bibliotheken entfernen soll - hat aber nicht 
wirklich etwas geholfen.

Ausserdem ist mir schelierhaft, warum nirgend ein Hinweis auftaucht, 
dass jemand diese Arbeit mit Verstand gemacht hat und dann ein 
funktionierendes WinAVR veröffentlicht.


Hat jemand eine Idee ? Ich führe gelegentliche Probleme beim 
Debuggen/Setzen von Breakpoints auf diesen Umstand zurück.

Autor: Bernhart (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich habe die meldung auch gerade mal bekommen. die erhaelt man, wenn man 
ein update der programmiersoftware macht und sich dabei irgrendwelche 
pfade zu irgendwelchen verzeichnissen aendern.

im prinzip musst du im "ordner suchen dialog" nur den ordner auswaehlen, 
an dem sich vorher bestimmte daten befunden haben. Der Ordner um den es 
sich handelt steht im dialog.

Wenn das nichts hilft würde ich einfach die ganze software neu 
installieren.
Wenn das auch noch nichts hilft, verwende statt einer RC version eine 
Release version. könnte ja ein Bug sein.

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich zitiere einfach mal ein paar Beiträge aus deinem letzten Thread
Beitrag "Projektweite Include-Datei einstellen"



... schrieb im Beitrag #1837793:
> Wenn Du den Krempel schon in zwei Foren postest, gib wenigstens einen
> entsprechenden Link mit an!
>
> http://www.avrfreaks.net/index.php?name=PNphpBB2&f...
>
> BTW. Hier Netzwerpfade zu verwenden ist eine ganz schlechte Idee.
> Make/GCC und alles was sonst noch dazu gehöhrt stammt aus dem
> Unix-Umfeld und da gibt es sowas nicht.
> Hat Dir aber auf AvrFreaks auch schon jemand gesagt!
> Und die Schreibweise "//SERVER..." ist auch verkehrt, die funktioniert
> generell nicht.



Nicolas Nickisch schrieb im Beitrag #1837807:
> Danke. Aber wie sieht die "saubere" Lösung üfr Netzwerke aus ?

... schrieb im Beitrag #1837822:
> Auch die Antwort gabs schon auf AvrFreaks:You could try mapping the network 
>drive to a local drive and then include the local drive path.
> Ok, statt "you could" sollte da eher "you should" stehen und statt
> "network drive" wäre "network path" die bessere Wortwahl gewesen.
>
> Weitere Alternative: Direkt auf dem Server arbeiten
> (Telnet/SSH/VNC/wasauchimmer).
>
>
> Warum liegt der Sourcecode überhaupt auf einem Server?

... schrieb im Beitrag #1837825:
> Eine "saubere" Lösung wäre eine passende Verwaltungssoftware (SVN/Git/MS
> Team irgendwas/diverse weitere) auf dem Server und dann den Code lokal
> bearbeiten und kompilieren.

In diesem Sinne...

Oliver

Autor: Reiner Franke (reiner)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

mit dem Fenster "please browse the present location for files originally 
found..." habe ich mich auch schon herumgeschlagen und habe leider keine 
zufriedenstellende Lösung gefunden.
Das Verhalten ist auch bei mir (wie im Thread ganz oben beschrieben) nur 
bei Verwendung von _delay_ms() aufgetreten. Den Verdacht, dass mit dem 
"Update der Programmiersoftware" zusammenhängt, kann ich nicht 
bestätigen.

Deshalb auch von mir nochmal die Frage, hat noch jemand eine Idee?

Reiner

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Erzähl dochmal genauer:
Was ist auf dem Netz und was ist lokal (WINAVR, AVRStudio, das Projekt)?
Womit compilierst Du?
Wenn Du eh mit AVRStudio debuggst, kannst Du doch gleich damit 
compilieren.


Peter

Autor: N. N. (drnicolas)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich persönlich habe WinAVR lokal, AVRStudio lokal.
Die Projektdaten liegen hingegen auf Netzwerkfreigaben.

Die Verwendung von Netzwerkpfaden scheint bei WinAvr und / oder Eclipse 
generell keine glückliche Lösung zu sein.
Möglicherweise rühren die Schwierigkeiten daher.

Auf der anderen Seite würde das bedeuten, dass ich eine ganze Reihe von 
Laufwerksbuchstaben für Verweise auf Projektordner, Bibliotheken mit 
Routinen für Hardwareansteuerung etc. bereitstellen müsste.

Ich würde ja den Aufwand alle Projekte umzuändern machen, wenn damit 
wenistens gewährleistet wäre, dass dann die Probleme beim Debuggen mit 
AVRSTudio aufhören.

Die Ordner-Such-Boxen habe ich gelegentlich mangels Ideen welchen Ordner 
ich angeben soll einfach weggeklickt - Debuggen kann ich trotzdem; auf 
den ersten Blick ohne Probleme. Dennoch scheine ich nicht immer einen 
Breakpoint auf eine beliebige Zeile setzen (trotz -O0) zu können.
Besonders übel sind die Boxen, die nach einem Verweis auf 
nicht-existente WinAVR-Verzeichnisse verlangen.

Immerhin, scheint ja noch jemand auf diesem Planeten den Umstand 
nachvollziehen zu können , dass die Boxen auftauchen, sobald man 
erstmals delay_ms  verwendet.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nicolas Nickisch schrieb:
> Die Projektdaten liegen hingegen auf Netzwerkfreigaben.

Wir arbeiten mit SVN, daher sind die Projekte immer aufm Netz und haben 
damit keine Probleme festgestellt.

> Die Verwendung von Netzwerkpfaden scheint bei WinAvr und / oder Eclipse
> generell keine glückliche Lösung zu sein.

Wir arbeiten nicht mit Eclipse, sondern compilieren mit WINAVR unter 
AVRStudio.
Auch da gibts keinerlei Probleme.

Wichtig ist, beim WINAVR installieren das Kästchen mit Pfad anlegen 
aktivieren, damit dann AVRStudio weiß, woher es den WINAVR starten soll.


Peter

Autor: Reiner Franke (reiner)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

zu dem Originalthread kann ich natürlich nichts sagen, aber vielleicht 
hilft die Beschreibung meiner Konfiguration weiter.

Ich bin noch Anfänger und mit kleinen Übungen beschäftigt. Also LED an, 
delay, LED aus...
Der Rechner läuft unter Windows 7. Compilieren und Debuggen geschieht im 
AVRStudio (WINAVR). Es liegt kein Netzwerk vor, so dass alle Daten lokal 
im Projektverzeichnis liegen. Vor einigen Tagen ist dann sporadisch das 
im Thread beschriebene Fenster "please browse the present..." 
erschienen. Aktuell kann ich aber den Fehler nicht reproduzieren.

Das Einbinden der delay.h Datei scheint aber trotzdem nicht problemlos 
zu funktionieren. Der Build läuft noch ohne Fehler und Warnungen durch. 
Öffnet man dann aber beim Debuggen das Disassembler Fenster, sind darin 
u.a. folgende Meldungen zu sehen:

D@00000000: _delay_ms
---- UNKNOWN_FILE

oder auch:
---- 
D:\projekte_avr\avr_gcc_tutorial\Delay_Test2\default/c:/winavr/lib/gcc/. 
./../avr/include/util/delay_basic.h
105: File not found

Vielen Danke für jede Unterstützung
Reiner

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn du das Problem mal eingekreist hättest, wäre die Fehlersuche 
einfacher.

Ich habe jetzt spaßeshalber mal ein Minimal-Projekt erstellt.
#include <avr/io.h>
#include <util/delay.h>

int main(void)
{
  while(1)
  _delay_ms(50);
}

Alles lokal auf Laufwerk C, aktueller WinAVR, AVRStudio 4.18, kompiliert 
für Mega128, als Debugger AvrSimulator.

Kompiliert man mit -O0, kommt da beim Start des Debuggers tatsächlich 
das Suchfenster mit dem Pfad aus dem ersten Beitrag oben rechts. Klickt 
man das weg, kommen noch zwei andere hinterher, mit anderen Pfaden.

Bei eingeschalteter Optimierung (die es für die delay-Funktionen ja 
braucht) passiert das nicht.

Das hat also anscheinend nichts mit den Netzwerkpfaden zu tun. 
Vermutlich hat das Studio Probleme mit Sourcecode in Headerdateien, oder 
da ist irgend etws mit der avrlibc seltsam.

Oliver

Autor: N. N. (drnicolas)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Interessant, dass sich das Problem mehr und mehr auf die 
delay-Funktionen konzentriert.

In der Tat benutze ich meist beim Debuggen -O0.
Mir ist die Warnung bekannt, delay nicht mit -O0 zu benutzen, ich habe 
aber die Warnung eher auf mögliche Ungenauigkeiten der delay-Schleifen 
zurückgeüfhrt.

Sei's drum, aus irgendeinem Grunde muss WinAVR doch diese fehlerhaften 
Pfadangaben 'C:\avrdev...' in die -elf-Datei einpflegen. Die denkt sich 
WinAVR doch nicht einfach aus Quantenfluktuationen heraus hinzu !


Beim Debuggen ist mir -O<>0 suspekt, da ich immer glaube, der Compiler 
könnte letztlich Teile des Programms wegoptimieren oder ändern, sodass 
mein Debugging nicht mehr gescheit funktioniert.

So habe ich immer wieder Probleme beobahctet, dass meine Software 
scheinbar in der Delay-Schleife festhängt (trotz oder wegen -O0 ?)
Ausserdem kann ich oft in AVRStudio den Befehl "Run to Cursor" nicht 
benutzen, oder Breakpoints werden nicht auf die markierte Zeile gesetzt 
sondern 1 oder mehr Zeilen dahinter.

Ich benutze seit einigen Wochen einen AVR Dragon, da mein JTAGICE mkII 
defekt ist.

Hier beobachte ich auch, dass single-step z.B auf einer Zeile mit memcpy 
das gelbe Dreieck nicht unbedingt direkt eins weiter bewegt.
Stattdessen muss ich teilweise 5-10x F10 drücken bevor die gelbe 
Markierung weiterrückt - wie als bewege sich der Debugger auf dem 
Assemblercode anstatt auf dem C-Code - das betrifft übirgens nicht nur 
delay.

Dieses Verhalten habe ich bei dem JTAGICE mkII wie auch einem alten 
Olimex JTAGICE nie beobachtet.

Autor: Reiner Franke (reiner)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

danke für das Nachstellen und das "Einkreisen". Oliver, gab es bei Dir 
auch die "File not found"-Ausgaben im Disassembler Fenster? Die 
erscheinen bei unabhängig vom eingestellten Grad der Optimierung.

Kann mir aber nicht vorstellen, dass das ein generelles AVRStudio 
Problem ist. Müssten das dann nicht mehr Leute beobachtet haben?

Reiner

Autor: N. N. (drnicolas)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
P.S.: Meine ELF-Dateien enthalten den c:\avrdev-Pfad - warum auch immer.

Autor: ... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der ganz oben im rechten Bild angegebene Fehler ("Please browse to the 
present location for files originally found at c:\avrdev\gcc\...") liegt 
einfach daran, daß beim Erstellen der AVR Libc teilweise vergessen wurde 
die Debug-Symbole zu entfernen. Das läßt sich jedoch problemlos 
nachholen. Auf der Kommandozeile in das Installationsverzeichnis von 
WinAvr wechseln und folgendes Kommando ausführen:
for /R %a in (*.a *.o) do bin\avr-strip -g %a

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also, ca. 5 Minuten weiteres testen, mit folgender (danach nicht weiter 
überraschender) Erkenntnis:

Es liegt

a) an der fehlenden mathe-lib. Die linkt das Studio bekanntermaßen nicht 
automatisch dazu. Wird die dazu gelinkt, verschwinden die Suchdialoge. 
Ohne Optimierung benötigen die delay-Routinen nun mal 
float-Berechnungen.

b) an der Studio-bekannten Schwierigkeit, Source-Code aus headerdateien 
richtig anzuzeigen. Auch mit Mathelib lässt sich der Sourcecode nicht 
auf C-Level durchsteppen, aber im Assembler.

Oliver

Autor: ... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
OK, das oben angegeben Kommando produziert einige Fehlermeldungen.
Besser sind stattdessen die folgenden zwei:
for /R avr\lib\ %a in (*.a *.o) do bin\avr-strip -g %a
for /R lib\gcc\avr\ %a in (*.a *.o) do bin\avr-strip -g %a

Autor: ... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oliver hat natürlich Recht, die libm.a sollte man auf jeden Fall dazu 
linken.
Das verhindert jedoch nicht unter allen Umständen die lästigen 
Suchdialoge.

Autor: bkiepke (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Hab genau den gleichen Fehler mit einer am 16.07.2012 runtergeladenen 
AVR Toolchain:

http://www.atmel.com/tools/atmelavrtoolchainforwindows.aspx

Am besten setzt man die zweiten
%a
 in "" dann hat man keine Probleme mit Leerzeichen in Windows Pfaden.

Also so
for /R avr\lib\ %a in (*.a *.o) do bin\avr-strip -g "%a"
for /R lib\gcc\avr\ %a in (*.a *.o) do bin\avr-strip -g "%a"

Autor: Thomas Messmer (zumax) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich aktualisiere den Thread mal da ich auch die selben Probleme mit dem 
AVR Studio 4.18 Build 716 (4.18 + SP3) und der AVR Toolchain 3.4.1-1195 
unter Windows 7 64Bit hatte und per google auf diesen Thread aufmerksam 
geworden bin.

Beim Beginnen des Debug-Vorgangs stützt AVR Studio mit (MFC Application 
has stopped working) ab.

Das Hinzufügen des Flags:
 -gstrict-dwarf 
behebt das Problem wie hier schön beschrieben:
Beitrag "Avr Studio 4 und die neue AVR Toolchain - So funktionierts!"

Anschließend kommt nun der berühmte "Hudson" Fehler den man dann so löst 
wie mein Vorredner bereits beschrieben hat.
for /R avr\lib\ %a in (*.a *.o) do bin\avr-strip -g "%a"
for /R lib\gcc\avr\ %a in (*.a *.o) do bin\avr-strip -g "%a"
Warum ich trotz der neuen AVR Studio Version 6 im Jahre 2014/15 immer 
noch Version 4 nutze kann man hier schön nachlesen:
http://www.kanda.com/blog/microcontrollers/avr-mic...


Beste Grüße,
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.