Ich fange gerade erst an, mich mit WinAVR zu beschäftigen, habe vorher aber bereits mit dem MSPGCC zu tun gehabt. Meine ersten Gehversuche scheitern bereits, dass der Compiler offensichtlich versucht, seine Ergebnisse irgendwohin loszuwerden - nur wohin? Es erscheint jedesmal die gleiche Fehlermeldung (siehe Anhang). Wo muss denn der entsprechende Pfad festgelegt werden, damit die Dateien auch dort landen, wo ich sie gern hätte?
Du hast irgendeinen Laufwerksbuchstaben, den du gelegentlich für einen beweglichen Datenträger (Zip, USB-Stick, ...) benutzt und der dummerweise vom Compiler referenziert wird. Vielleicht kannst du ja diese vermaledeiten ,,Laufwerks''buchstaben irgendwie umsortieren.
Theoretisch könnte ja auch derjenige, der das Binärpaket dieses Compilers produziert, mal seine Entwicklungsumgebung in Ordnung bringen und die Verwendung absoluter Pfade aus seinem Compilat entfernen ... aber da predigt man ja wohl gegen Wände.
Ich glaube nicht, daß WINAVR was dafür kann. Schuld sind alle möglichen und unmöglichen Programme, die den Pfad total vollmölen. Ich schaue da jedesmal nach, wenn ich was neu installiert habe und lösche den ganzen Schrunz wieder. Windows-Programme benötigen in der Regel nämlich gar keinen Pfadeintrag, sie werden ja aus Start oder einer Verknüpfung aufgerufen und dort zeigt der Eintrag schon ins richtige Verzeichnis. Und für die Programme in der DOS-Box schreibt man eben eine Batch, die den Pfad nur für diese eine Anwendung am Anfang setzt. Hier mal der Pfad, wie er bei mir ist: PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\BATCH; Und unter C:\BATCH stehen dann die ganzen Batches für die einzelnen DOS-Programme. Peter
> Theoretisch könnte ja auch derjenige, der das Binärpaket dieses > Compilers produziert, mal seine Entwicklungsumgebung in Ordnung > bringen und die Verwendung absoluter Pfade aus seinem Compilat > entfernen ... We're working on it[TM]. ;-) Unix-Programme benutzen in aller Regel absolute Pfadnamen, heutzutage sehr oft von einem gemeinsamen Präfix (/usr oder /usr/local) abgeleitet, um all ihre Komponenten zusammenzusuchen. Dieser Präfix wird zur Konfigurationszeit eingestellt, und das Paket dann so installiert. Das ist unter Unix alles überhaupt kein Thema, da man ja 1.) den Kram auch selbst compilieren kann, wenn einem das nicht gefällt und 2.) es keine dummen ,,Laufwerks''buchstaben gibt, so dass das dann auch wirklich passt. Die Dateisystemhierarchie bei Unixen folgt einem (mittlerweile recht gut standardisierten) Layout, das völlig unabhängig von der Aufteilung der physischen Datenträger ist. Nun hat zwar GCC im Laufe der Zeit sehr viele (alle wichtigen) seiner Zugriffe auf relative Pfadangaben umgestellt, aber der Präfix und die Suche nach den Includes unterhalb ${prefix}/include steckt da immer noch drin. Eric Weddington ist sich wohl mit dem Maintainer des GCC einig, dass man das beseitigen kann und sollte, aber verständlicher- weise ist es an ihm, das dann auch zu tun -- die Unixer haben da keine Motivation, das zu ändern. Es ist einzig und allein, dass die Include-Dateien (und möglicherweise die Bibliotheken) dort gesucht werden, wo man ihm das konfiguriert hat. Wenn das nun E:/WinAVR als Präfix, dann fällt man eben noch dummerweise darüber, wenn bei einem anderen Windows E: mal irgendwann als Wechselmedium bekannt war, dass das danach sofort nach seinem verschwundenen Datenträger kräht... Man könnte natürlich genauso gut auf die Idee kommen, dass die CP/M-Laufwerksbuchstaben im Jahr 2005 keinen Sinn mehr haben, ,,aber da predigt man ja wohl gegen Wände''. ;-) (Kennt hier noch jemand außer Peter überhaupt CP/M?) Mein Vorschlag an Eric für die nächste WinAVR-Version war, dass er als Präfix einfach sowas wie C:/adfasdfasdfasdpf3289qer9sda benutzen soll. :) Das Laufwerk C: hat wohl hoffentlich wirklich jeder als Festplatte, und das Verzeichnis adfasdfasdfasdpf3289qer9sda wird genauso hoffentlich bei keinem existieren, sodass da nicht aus Versehen was Falsches gefunden wird.
Sorry Leute, aber irgendwie ist da was nicht so ganz koscher! Ich habe folgende Aufteilung auf meinem PC: C: Systempartition Windows D: DVD-R E: DVD-RW F: Partition auf der , soweit möglich alle Programme installiert werden G: Partition, auf der die Spiele der Kinder landen H: Partition für sämtliche Nutzdaten I: und aufwärts sind Wechselmedien (SD-Karten etc.) Ich habe jetzt bewusst WinAVR, sowie noch vorhandene Installationen von MSPGCC (da dort auch CYGWIN drinsteckt) deinstalliert. Danach WinAVR neuinstalliert und den Haken, ob die Pfadangaben angepasst werden sollen, gesetzt. Das Ergebnis ist noch immer das Gleiche: Es wird versucht, auf einen Datenträger zuzugreifen, der nicht vorhanden ist. Wo genau sind die Pfadfestlegungen von WinAVR? Oder kann WinAVR nur unter C:\WinAVR installiert werden? Wenn das so ist, sollte die freie Installationsverzeichnisangabe weggelassen werden. Bei MSPGCC trat dieses Phänomen nicht auf, obwohl auch MSPGCC unter F:\ installiert wurde.
Mit FileMon (http://www.sysinternals.com/Utilities/Filemon.html) kannst Du herausfinden, auf exakt welchen Pfad/welche Datei da zugegriffen wird.
Hi hast du Jörgs Posting aufmerksam gelesen? In die Executables des AVRGCC sind Pfadangaben fest eincompiliert (bedingt durch den Bauprozess von Eric, dem Maintainer von WinAVR). Eric baut den GCC wohl irgendwie so das da ein Pfad (IIRC E:\...) drin ist. Hast du jetzt ein Laufwerk E: wo kein Datenträger drinliegt kommt die genannte Fehlermeldung. Legst du jetzt einen Datenträger in dieses Laufwerk ist das Symptom behoben, Die Ursache jedoch noch nicht. Für den MSPGCC verwendet der Maintainer eben eine etwas anderen Bauprozess os das das Problem bei dir nicht auftritt. An dem Problem wird, wie Jörg schreibt, gearbeitet. Bis es behoben wurde muß man damit leben. Matthias
Ich habe jetzt einerseits Filemon verwendet, konnte dort aber eigentlich keine Zugriffe auf Laufwerksbuchstaben von Wechselmedien entdecken. Das Einlegen einer CD in das Lauf E: half auch nicht, so dass laut Jörg vermutlich Laufwerk M: der Übeltäter ist. Ich habe jetzt den Laufwerksbuchstaben von M: auf N: geändert und die Fehlermeldung ist endlich verschwunden. Vielen Dank für Eure Unterstützung. Sorry, wenn ich zwischenzeitlich etwas begriffsstutzig war. @Jörg: Übrigens entsinne ich mich, zum Ende meines Physikstudiums noch CP/M-Rechner (mit 8"-Disketten) gesehen zu haben, habe allerdings nicht mehr aktiv damit gearbeitet, denn es kamen die ersten PCs auf (IBM und Commodore 10, 20 und sogar erste Clone).
Ich glaube, Eric hatte früher E:/WinAVR als --prefix beim Konfigurieren angegeben. Da damit viele Leute Probleme berichtet haben, ist er bei der letzten Version ,,ein paar Buchstaben weiter'' gegangen und hat M: genommen -- in der Hoffnung, dass das nun wirlich keiner mehr in der realen Welt benutzt. Wie du siehst, die Hoffnung trügt. > Übrigens entsinne ich mich, zum Ende meines Physikstudiums noch > CP/M-Rechner (mit 8"-Disketten) gesehen zu haben, habe allerdings > nicht mehr aktiv damit gearbeitet, ... OK, 8"-Disketten sind mir praktisch nicht mehr an CP/M-Rechnern untergekommen, dafür dann in meinem ersten Job, da sie in der Textilindustrie wohl bis heute noch zum Speichern von Mustern benutzt werden. Durch die geringe Datendichte sind sie wenig staubanfällig, das ist dort wichtig. Mein Eigenbau-CP/M-Rechner hatte zuerst nur Tonband und RAM-Disks, danach dann eine 5,25"-Floppy. Die Laufwerksbuchstaben und die Schrägstriche für die Kommando- Optionen sind die beiden Dinge von CP/M, mit denen Microsoft noch bis heute seine Kunden beglückt. Naja, und das 8.3-Dateinamensschema ist auch gerade mal gestern abgelegt worden, auch das ist noch von CP/M...
Ich habe auch mal unter CP/M mit Turbo-Pascal angefangen, war richtig komfortabel. Der Rechner hatte 4 * 5,25" Floppys und ne 256kB RAM-Disk. Programmiert habe ich auf der RAM-Disk und wenn ich mal Mist programmiert hatte und das Programm hängen geblieben ist, kein Problem, einfach den Resetknopf gedrückt. Dann kam nämlich ne Abfrage, ob die RAM-Disk neu formatiert werden soll oder nicht und schon konnte man weiter machen. Erst wenn das Programm lief oder Feierabend war, mußte man es wieder auf die Floppy kopieren. Peter
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.