Hallo.
Ich habe ein Problem, wo ich selber nicht mehr weiter weiß.
Ich habe meinen Rechner formatiert und auf Windows 11 geupdatet und auch sonst alle veralteten Programme gegen deren Nachfolger ersetzt.
Nun wollte ich nach langem wieder einmal eine kleine Software schreiben, und nun geht das nicht mehr...
Ich habe Studio auf Partition D installiert, wie es vorher auch war.
Der Testweise ASM-Code ist der direkt nach erscheinen der Programmierseite:
start:
inc r16
rjmp start
Nun taucht folgende Fehlermeldung auf, nachdem ich auf "Build" klicke:
------ Build started: Project: Ventilator_Steuerung, Configuration: Debug AVR ------
Build started.
Project "Ventilator_Steuerung.asmproj" (default targets):
Target "PreBuildEvent" skipped, due to false condition; ('$(PreBuildEvent)'!='') was evaluated as (''!='').
Target "CoreBuild" in file "D:\Microchip Studio for AVR and SAM\7.0\Vs\Assembler.targets" from project "E:\AVR_ASM_Projekte_06.2026\Ventilator_Steuerung\Ventilator_Steuerung.asmproj" (target "Build" depends on it):
Using "RunAssemblerTask" task from assembly "D:\Microchip Studio for AVR and SAM\7.0\Extensions\Application\AvrAssembler.dll".
Task "RunAssemblerTask"
D:\Microchip Studio for AVR and SAM\7.0\toolchain\avr8\avrassembler\avrasm2.exe -fI -o "Ventilator_Steuerung.hex" -m "Ventilator_Steuerung.map" -l "Ventilator_Steuerung.lss" -S "Ventilator_Steuerung.tmp" -W+ie -I"D:/Microchip Studio for AVR and SAM\7.0\Packs\Atmel\ATmega_DFP\2.4.522\avrasm\inc" -I"D:/Microchip Studio for AVR and SAM\7.0\Packs\Atmel\ATmega_DFP\2.4.522\include" -I"D:/Microchip Studio for AVR and SAM\7.0\Packs\Atmel\ATmega_DFP\2.4.522\avrasm\inc" -im168def.inc -d "E:\AVR_ASM_Projekte_06.2026\Ventilator_Steuerung\Debug\Ventilator_Steuerung.obj" "E:\AVR_ASM_Projekte_06.2026\Ventilator_Steuerung\main.asm" -I "D:\Microchip Studio for AVR and SAM\7.0\toolchain\avr8\avrassembler\Include"
AVRASM: AVR macro assembler 2.2.8 (build 80 Jan 14 2020 18:27:50)
usage: avrasm2.exe [options] file.asm
Type 'avrasm2 -h' for help.
Copyright (C) 1995-2020 ATMEL Corporation
Done executing task "RunAssemblerTask" -- FAILED.
Done building target "CoreBuild" in project "Ventilator_Steuerung.asmproj" -- FAILED.
Done building project "Ventilator_Steuerung.asmproj" -- FAILED.
Es ist dabei egal, ob ich Leerzeichen im Dateipfad habe oder diese gegen "_" ersetze, ich bekomme keinen Build hin...
Öffne ich nun ein bereits existierendendes Projekt, kann ich dieses Problemlos builden. Nur wenn ich eion komplett neues Projekt erstelle, geht garnichts.
Würde mich echt über Hilfe freuen. Liebe Grüße, Daniel
Bei drei -I-Optionen fehlt das Leerzeichen zwischen -I und dem Pfad, ebenso bei -i
(es geht also um die Zeilen 12 - 15)
Das erste Pfadtrennzeichen ist bei den drei -I-Optionen ohne Leerzeichen auch anders, als unter Windows üblich.
Ein Fehler muss das nicht sein, manche Software kommt mit / statt \ zurecht, aber es könnte helfen, das zu vereinheitlichen.
Hab mich mal angemeldet um Dich von diesem nervigen Problem zu erlösen: Mit der Studio-Installation ist alles in Ordnung, nicht aber mit dem verwendeten Device-Pack: Alles kleiner 2.3 ist nämlich verwendbar :)
...und ein testweise von mir erzeugtes neues Asm-Projekt auch nicht.
Das Problem besteht ja darin, dass sich der avrasm2.exe über die übergebenen Parameter beschwert, allerdings ohne in's Detail zu gehen, was ihm daran nicht gefällt.
Muss man also erst mal herausfinden, was genau davon nicht passt. Habe ich getan und festgestellt: Da werden zwei "-I"-Parameter zu viel übergeben. Und zwar sind das die, deren Pfade auf "" enden.
Der Witz ist dabei: Es genügt bei dem Beispielprojekt (und auch bei meinem Testprojekt), das target device z.B. auf einen AVR128DB64 umzustellen, dann funktioniert alles, wie es soll. Ein ATmega (ich hab's mit einem 1284P versucht) funktioniert allerdings ebenfalls nicht.
Zusammenfassend: Bug im im ATMEGA_DFP-Pack. Ältere Version benutzen. Ich hab's mal mit 2.0.401 probiert (weil die gerade bei mir noch lokal rumhing), damit geht es.
Hallo ihr Lieben.
Ihr habt recht mit dem Device-Pack. Hab jetzt 2.0.401 drauf und klappt tatsächlich. Vielen lieben Dank. Ich hoffe Microchip behebt den Fehler mal, weil nun ständig Updates vorgeschlagen werden beim laden von ATmega Projekten :-D
Auf ein Fehlerhaftes Pack wäre ich so schnell nicht gekommen. Wie hab ihr das festgestellt? Vorahnung aus vorherigen Problemen bei euren Projekten?
Da Microchip Studio schon lange nicht mehr weiterentwickelt wird und Microchip die Leute dazu bringen will, stattdessen MPlab zu verwenden, halte ich das für nicht übermäßig wahrscheinlich.
Es scheint zum Glück folgende Lösungsmöglichkeit zu geben (insbesondere für die neue AVR-LA Serie von Interesse die kein in Studio funktionierendes Device-Pack mehr bietet):
die betreffende ControllerDef .inc ins Projekt aufnehmen/kopieren (im Solution Explorer)
diese .inc Datei anfangs im Code inkludieren
alle Include-Pfade in den Projekteigenschaften (Toolchain/AVRAssembler/General) löschen
Da wurde wohl irgendwas am Pack-Standard verändert.
Das glaube ich nicht. Wäre es so, müsste sich das ja gleichermaßen auf die anderen AVR8-Packs auswirken (ATtiny_DFP, AVR-Dx_DFP usw.). Tut es aber nicht.
Bug ist schon deutlich wahrscheinlicher. Wobei der Bug mit einiger Wahrscheinlichkeit im Studio selber steckt, das Pack ihn also mehr oder weniger nur "exploited".
Beim Vergleich der verschiedenen Versionen des ATmega_DFP habe ich jedenfalls keine wirklich auffälligen strukturellen Unterschiede feststellen können (mal abgesehen vom zusätzlichen Gedöhns für den XC8-Compiler), auch nicht beim Vergleich der aktuellen Version des ATmega_DFP mit der aktuellen Version des ATtiny_DFP.
Auffallend ist jedenfalls, dass genau nur das eine Pack betroffen ist, in dem es seit einer kleinen Ewigkeit keine neuen Devices mehr gab. Zuletzt war das wohl 2019 der Fall.
Wäre es so, müsste sich das ja gleichermaßen auf die anderen AVR8-Packs
auswirken (ATtiny_DFP, AVR-Dx_DFP usw.). Tut es aber nicht.
Doch, tut es.
Sowohl die letzten Device-Packs von AVR-Dx als auch -Ex sowie alle des allerneuesten -LA (wie bereits erwähnt) sind ebenfalls betroffen. An einen Bug in Studio glaube ich bei dieser Chronologie der Ereignisse eher nicht. Es sind nicht irgendwelche Device-Packs, es sind die neuesten. Die beiden letzten Updates für ATmega übrigens von 12/25 und 1/26. Version 2.2.509 von 12/23 funktioniert noch.
Doch, tut es.
Sowohl die letzten Device-Packs von AVR-Dx als auch -Ex sowie alle des
allerneuesten -LA (wie bereits erwähnt) sind ebenfalls betroffen.
Ooops... Hast recht.
Umso interessanter wäre es, herauszubekommen, was genau der Auslöser für das fehlerhafte Verhalten des Studio ist, so dass man das Problem gleich an der Ursache bekämpfen kann. Sprich: durch Patch der Pack-Dateien dafür sorgen, dass das Studio von allein wieder korrekte Projekttemplates generiert.
Ich habe mich daran ja schon ansatzweise, ziemlich unsystematisch und leider erfolglos versucht. Es muß ein wirklich winziges Detail sein, was mir bisher schlicht entgangen ist.
Konkret würde mich vor allem AVR-Dx interessieren. Kannst du zufällig genau sagen, welche Version die letzte ist, mit der es noch geht?
Ja. Nur das letzte 2.8.337 macht beim Dx Probleme. 2.7.321 von 2/25 funktioniert noch.
Ohne daß ich es ausprobiert hätte tippe ich auch auf ein dysfunktionales letztes Update für ATtiny_DFP (2.1.484 von 4/26).
Wie sieht denn der Assembleraufruf bei den "funktionierenden"
Devicepacks aus?
schrieb ich schon weiter oben:
Bei den dysfunktionalen Packs werden zwei zusätzliche -I-Parameter übergeben. Nicht das eine fehlplazierte Leerzeichen ist dabei das Problem, sondern entweder die bloße Existenz dieser zwei überflüssigen Zeilen oder die Tatsache, dass die übergebenen Pfade im Gegensatz zu den ohnehin regulär übergebenen Zeilen auf "" enden.
Jedenfalls ist das Prinzip der Lösung klar: man muss herausfinden, was genau das Studio veranlasst, diese zwei Zeilen überhaupt in die Projektkonfiguration zu schreiben. Wenn man das verhindert, spielt es auch keine Rolle mehr, was genau darin steht.
Nicht das eine fehlplazierte Leerzeichen ist dabei das
Problem, sondern entweder die bloße Existenz dieser zwei überflüssigen
Zeilen oder die Tatsache, dass die übergebenen Pfade im Gegensatz zu den
ohnehin regulär übergebenen Zeilen auf "" enden.
Das lässt sich ja recht leicht herausfinden - man kann den Assembler auch von Hand aufrufen, im Kommandozeilenfenster, und da mit den Argumenten spielen.
Daß mehrere -I-Argumente ein Problem sind, halte ich für unwahrscheinlich, denn wie soll man sonst mehrere Pfade angeben, in denen nach Dateien zu suchen ist?
Das lässt sich ja recht leicht herausfinden - man kann den Assembler
auch von Hand aufrufen, im Kommandozeilenfenster, und da mit den
Argumenten spielen.
Natürlich. Genau das habe ich ja auch getan.
Daß mehrere -I-Argumente ein Problem sind
Sicher nicht pa se. Im konkreten Fall handelt es sich aber um Doppelungen der zwei ohnehin übergebenen Pfade, halt nur mit dem Unterschied, dass hier jeweils ein Backslash am Pfadende ist.
Wie auch immer der Assembler damit umgeht (offensichtlich falsch), die wirkungsvollste Bekämpfung wäre jedenfalls, schon diese unnötige Doppelung zu verhindern.
Jedenfalls ist das Prinzip der Lösung klar: man muss herausfinden, was
genau das Studio veranlasst, diese zwei Zeilen überhaupt in die
Projektkonfiguration zu schreiben
Bei den funktionierenden Versionen ist die Parameterzeile deutlich kürzer (als bei obiger) und es gibt nur einen Include-Pfad. Vorgaben, welche die verwendete DP-Version macht.
Bei den funktionierenden Versionen ist die Parameterzeile deutlich
kürzer und es gibt nur einen Include-Pfad.
Ja klar. Aber warum passiert das?
Das Verhalten muß ja irgendwie durch den Inhalt des Packs ausgelöst werden. D.h.: durch peniblen Vergleich der beiden von dir herausgesuchten Packversionen sollte sich der Auslöser identifizieren lassen.
Bei den funktionierenden Versionen ist die Parameterzeile deutlich
kürzer und es gibt nur einen Include-Pfad.
Ja klar. Aber warum passiert das?
Das Verhalten muß ja irgendwie durch den Inhalt des Packs ausgelöst
werden. D.h.: durch peniblen Vergleich der beiden von dir
herausgesuchten Packversionen sollte sich der Auslöser identifizieren
lassen.
Ich habe zumindest erst mal einen Verdächtigen: die *.pdsc-Datei des Packs.
An sehr vielen Stellen kommt da vor:
(alt)
<file condition="AVRASM" category="include" name="avrasm/inc"/>
vs. neu
<file condition="AVRASM" category="include" name="avrasm/inc/"/>
Wenn's das ist, gibt es wahrscheinlich noch eine zweite, analoge Stelle für den Verweis auf
"C:\Program Files
(x86)\Atmel\Studio\7.0\toolchain\avr8\avrassembler\Include"
Ich habe zumindest erst mal einen Verdächtigen: die *.pdsc-Datei des
Packs.
An sehr vielen Stellen kommt da vor:
(alt)
<file condition="AVRASM" category="include" name="avrasm/inc"/>
vs. neu
<file condition="AVRASM" category="include" name="avrasm/inc/"/>
Das war's erstmal nicht. Auch eine entsprechend gepatchte *.pdsc ändert nix am Verhalten. Ach ist das mühsam...
Alle Include-Pfade in den Projekt-Einstellungen (Toolchain/AVRAssembler/General) löschen und den Pfad zur .inc ohne abschließendes \ neu angeben. Dann funktionierts ebenfalls.
Alle Include-Pfade in den Projekt-Einstellungen
(Toolchain/AVRAssembler/General) löschen und den Pfad zur .inc ohne
abschließendes \ neu angeben. Dann funktionierts ebenfalls.
Ja, das ist doch seit langem klar.
Wirklich schön wäre es halt, die eigentliche Ursache zu finden, die das Studio dazu bringt, diese falschen Projekteinstellungen überhaupt erst zu erzeugen. Und die erzeugt das Studio ja aus dem ganzen Gesolms im DevicePack.
Wirklich schön wäre es halt, die eigentliche Ursache zu finden
Viel Erfolg beim Studium der .pdsc :)
Ein Pack-Standard, welcher sich jederzeit wieder ändern kann.
Ich hab mal bei Microchip angefragt was das Ganze soll.
Die vorgestellte praktische Lösung reicht in der Zwischenzeit!
