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.
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.
Ich zitiere einfach mal ein paar Beiträge aus deinem letzten Thread
Beitrag "Projektweite Include-Datei einstellen"... schrieb:> 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:> Danke. Aber wie sieht die "saubere" Lösung üfr Netzwerke aus ?... schrieb:> 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:> 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
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
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
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.
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
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
Wenn du das Problem mal eingekreist hättest, wäre die Fehlersuche
einfacher.
Ich habe jetzt spaßeshalber mal ein Minimal-Projekt erstellt.
1
#include<avr/io.h>
2
#include<util/delay.h>
3
4
intmain(void)
5
{
6
while(1)
7
_delay_ms(50);
8
}
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
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.
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
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:
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
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.
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:
AVRSTudio_Probleme.PNG
(33 KB)
AVR_2.JPG
(14 KB)
