Hallo,
ich habe Microchip Studio 7 (V2542) auf meinem Win10-PC installiert. Der
PC ist Mitglied einer Samba-Domain und Projekte/Files können auf einer
"home-share" (Netzwerk-Laufwerk, z.B. U:) abgespeichert werden.
Als Test habe ich ein simples C-Programm mit einem Modul "main.c" auf
dem Default-Pfad "C:\users\ich\documents.....\ATtiny_Blink" mittels "new
Project" auf der Startseite des AS7 erzeugt und abgespeichert. Anklicken
des "Build"-Buttons -> alles ok, Files erzeugt!
Das selbe Projekt mit gleichem Inhalt in einem Verzeichnis auf einem
Netzlaufwerk abgespeichert ergibt einen "Build failed":
1
Target "CoreBuild" in file "C:\Program Files (x86)\Atmel\Studio\7.0\Vs\Compiler.targets" from project "Q:\mist\ATtiny85Blink\ATtiny85Blink\ATtiny85Blink.cproj" (target "Build" depends on it):
2
Using "RunCompilerTask" task from assembly "C:\Program Files (x86)\Atmel\Studio\7.0\Extensions\Application\AvrGCC.dll".
Wer kennt dieses Verhalten?
Weiß jemand Abhilfe?
PS.: Ich habe schon alles mögliche ausprobiert: main.c in verschiedene
Verzeichnisse gelegt, Pfade in der Konfiguration angepasst, mit externem
Makefile getestet etc.
Danke für eine Lösung schon jetzt, falls es eine gibt!
B. W. H. schrieb:> Wer kennt dieses Verhalten?> Weiß jemand Abhilfe?
Ich kenn ein ähnliches Problem: Wenn das Projekt nicht direkt auf dem
Netzlaufwerk angelegt wurde öffnet es nicht. Vielleicht mal so
probieren.
Hallo,
habe das auch einmal probiert. Ich kann ein einfaches Projekt ohne
zusätzliche Libs auf dem Rechner verschieben, dass klappt.
Verschiebe es auf ein Netzlaufwerk erhalte ich einen Error:
recipe for target 'Test.elf' failed
Lege ich es das Projekt auf dem Netzlaufwerk neu an, erhalte ich den
gleichen Fehler. Include Pfad habe ich absolut, nicht relativ, neu
gesetzt, half auch nicht. Also bei mir gehts nichts im Netz. Schade.
Erhalte nach Anlage auf dem NW beim Wiederöffnen zunächst ein Load
failed im Solution Explorer. Nach einem "Reload project" und erneutem
Abspeichern klappts dann zukünftig mit dem Öffnen und Build. Teil der
.atsln Projekt Datei sind offensichtlich die Pfade. Bei einem der
letzten Updates meiner Fritzbox änderte sich plötzlich der Netzwerkname
meines FB-NAS auf einzelnen PCs. Daraufhin ließ sich das Projekt von
dort wiederum nicht mehr öffnen und musste am "neuen" Netzwerkort auf
beschriebene Art neu angelegt werden.
.... inzwischen habe ich das Problem etwas eingekreist:
Dem Vorschlag von jimih folgend habe ich das Projekt vom lokalen
Laufwerk auf das Netz-Lw. kopiert. Spätestens nach einem reload Projekt
läßt es sich übersetzen. Also ok, aber das kann ja nur eine Notlösung
sein!
Erzeuge ich ein "new Project.." von der Startseite des AS7 und gebe ein
Verzeichnis auf dem Netz-Lw. an, wird es dort angelegt und das Template
von main.c angezeigt. Drücke ich nun F7 (Build Solution), wird es
anstandslos übersetzt und die erzeugten Files finden sich im
Unterverzeichnis /debug.
Ändere ich nur eine Kleinigkeit an dem jungfräulichen main.c oder
speichere ich es mit Ctrl+S (Disketten-Icon) ab ergibt der folgende
Druck auf F7 einen "Build FAILED".
Ich habe auf dem Server auch mal die Benutzer-Rechte für jeweils die
lokalen Dateien und die auf den Netz-Lw. verglichen: kein Unterschied.
Also irgendwo scheint es mit den Zugriffsrechten in Windows und/oder AS7
zu hängen.
Merkwürdig ist auch, daß AS7 beim Reload Project von einem Netzwerk-Lw.
das Fenster mit der Security warning bringt (und dann trotzdem der Build
fail kommt)!
Ich wollte das Thema auch schon im Microchip-Forum bringen, bekomme
jedoch keine Bestätigungsmail auf meinen Anmeldewunsch. :-(((
B. W. H. schrieb:> make: stat: .././main.c: Invalid argument
Das klingt eher nach einem leider typischen Pfad-Bezeichner-Problem
(fehlende Anführungszeichen bei Pfad mit Leerzeichen), nicht nach einem
Problem mit den Benutzerrechten.
Oliver
Haben auf der Arbeit auch Probleme mit Netzlaufwerken, die auf Linus
basierten NAS liegen. Diese sind im ersten Moment nach dem Anlegen oder
bearbeiten nicht direkt wieder zugreifbar.
Scheinbar wird hier im Hintergrund eine Replizierung/Indizierung
durchgeführt, welche die Daten blockiert und dadurch der Zugriff im
ersten Moment nicht gegeben ist. Eventuell macht es im bei deinem
Netzlaufwerken auch Probleme.
Wenn man ein wenig wartet ist alles wieder u.O.
Mit freundlichen Grüßen
Hallo,
@oliverso: prinzipiell hast Du recht!
Ich habe aber inzwischen das jungfräuliche Projekt auch mal auf einem
"sauberen" Verzeichnispfad (also Pfadname ohne Leerzeichen) installiert.
Nach F7 ok.
Nach Abspeichern main.c (ohne Veränderung) -> Build FAILED.
Da "pfuscht" irgendwas von AS7 dazwischen; ist mein Eindruck.
B. W. H. schrieb:> also Pfadname ohne Leerzeichen
Auf einem Betriebssystem mit dem default-Programmordner "program files"
ist das gar nicht so einfach.
Oliver
@oliverso:
es geht darum, wo die Projekt-Files liegen!
Liegen sie auf einem lokalen LW ist alles ok, liegen sie auf einem
Netz-Lw. tritt der Fehler auf.
Also hat es offensichtlich nix damit zu tun, ob AS7 in einem Pfad mit
Leerzeichen liegt oder nicht!
Hallo,
ich vermute ja das liegt an Windows und dem Umgang mit Netzlaufwerken.
Der Datei Explorer findet bei mir zum Bsp. nur ganz schwer Netzlaufwerke
die per Samba auf einem Linuxrechner freigegeben sind. Deswegen habe ich
auf dem Desktop einen Link mit Zugangsdaten angelegt. Drauf klicken und
ich kann alles machen. Das kennt natürlich AS nicht, dem gehts wie dem
nackten Explorer. Zum Projekt öffnen kann ich nachhelfen und gebe den
Pfad von Hand ein. Aber danach ist AS wieder auf sich allein gestellt
und wird wieder scheitern wie der nackte Explorer der nichts findet.
Soweit meine Theorie dazu.
Ich kann jetzt nicht über Microchip-Studio7/Win10 und konkret
referieren, weil ich kein Win10 nutze. Unter AtmelStudio7/Win7 müssen
Netzlaufwerke mit Laufwerksbuchstaben z.B. X:\ eingebunden werden: Win7
-> Start -> Computer -> Netzlaufwerk verbinden -> Laufwerk-Buchstabe
z.B. X:\ mit dem entsprechendem Netzverzeichnis verbinden. Leerstellen
in Pfadnamen sind grundsätzlich zu vermeiden, allenfalls durch
Unterstrich _ zu ersetzen.
Die Toolchain halte ich immer lokal auf
C:\Atmel-Toolchain\AVR8\avr-gcc-xx.x.x-x64-windows verfügbar. Falls ich
mich richtig erinnere, funktioniert eine Toolchain auf einem
Netzverzeichnis nach obenstehenden Kriterien aber ebenfalls.
Veit D. schrieb:> Laufwerksbuchstaben vergeben ist die Top Antwort
Nö. Am Fehlerbild
Jimi H. schrieb:> Erhalte nach Anlage auf dem NW beim Wiederöffnen zunächst ein Load> failed im Solution Explorer. Nach einem "Reload project" und erneutem> Abspeichern klappts dann zukünftig mit dem Öffnen und Build.
ändert das nix.
@jimih: genauso isses, Du hast recht!
Ich habe mich jetzt wieder dem altbewährten AS4.19 zugewendet. Da läuft
alles so, wie erwartet! Also da werden auch Projekte, die sich auf
Netz-Lw. befinden, klaglos übersetzt!
Eigentlich schade, daß eine neue Version von einer doch recht guten
Entwicklungsumgebung einen so einschneidenden Bug hat (wenn ich das
richtig beurteile). Ich hätte gerne AS7 benutzt, weil ich gehofft hatte,
damit in neue "Gefilde" vordringen zu können. Aber so nicht! Ich benutze
verschiedene Rechner für meine Entwicklungen und da ist es einfach
zielführend, die Projekte auf einem Netzlaufwerk zu speichern.
Wenn nicht noch ein "Wunder" geschieht, werde ich AS7 ad acta legen.
Danke für Eure Mithilfe!
B. W. H. schrieb:> werde ich AS7 ad acta legen.
Naja gleich kapitulieren muss man doch auch nicht. Wenn nicht gerade
täglich neue Projekte auf Netzwerklaufwerken angelegt werden müssen. Der
Bug ist da ja immer nur einmalig zu überwinden.
Immerhin unterstützt AS7=MS7 die neuesten Chips und erscheint immer noch
übersichtlicher bedienbar als etwa das MPLAB-X.
Kann sein, dass Win10 zusätzliche Hürden bereit stellt.
Ich habe alle meine AS7-Projekte seit jeher im Verzeichnis
/data/AVR-Proj/ auf einem SYNOLOGY-Netzlaufwerk.
Früher eingebunden in Win7 und jetzt in Mint und Oracle-VM-Win7
