Hallo zusammen Ich habe in der letzten Zeit vermehrt STM32 programmiert. Früher habe ich den Einstieg mit den AVRs gemacht. Damals, hatte ich mir eine Eclipse CDT und die AVR Plugins eingerichtet gehabt. Dies lief immer einwandfrei. Vor etwa 2 Jahre, wollte ich Eclipse mit AVR wieder auf dem neuen Win7 installieren, und bekam beim Kompilieren nur Fehlermeldungen. Diese habe ich auch schon hier im Forum gepostet. Leider konnte niemand eine Lösung finden. Seither, habe ich Eclipse nie mehr mit den Plugins zum laufen bekommen. auch nicht auf anderen Computern. Deshalb habe ich mir dann zwischenzeitlich mit dem Programmers Notepad für AVR beholfen. War ok, aber für grosse Projekte nicht so toll. Nun steht wieder ein etwas grösseres Projekt bevor, welches einen Atmega Controller hat. Das AtmelStudio erscheint mir als Eclipse User nicht extrem angenehm. Deshalb wollte ich euch fragen, ob es entweder a) Inzwischen eine Möglichkeit gibt, Eclipse mit AVR auf Win7 Laufen zu lassen oder b) es eine alternative zum Atmel Studio gibt, welche ähnlichkeiten zu Eclipse aufweist. Ich weiss, es sind details aber was mich z.B. besonders beim Studio stört ist, dass man nicht mit CTRL + Click zur definition springen kann. Danke schonmal
Stefan Us schrieb: > Ich hatte mal Netbeans benutzt. Wie hast du da die Integration von WINAVR hinbekommen?
Eclipse auf Win 7 für AVR ist doch absolut kein Problem. Nutze das schon seit vielen Jahren. Ich nutze außerdem schon lange nicht mehr die winavr Toolchain sondern natürlich die aktuelle von Atmel. Die letzte winavr ist von 2010. Keine Ahnung was da dein Problem ist.
:
Bearbeitet durch User
Claudio H. schrieb: > Seither, habe ich Eclipse nie mehr mit den Plugins > zum laufen bekommen. auch nicht auf anderen Computern. Ich benutze es jeden Tag. In der Firma auf Windows 7 und zuhause auf Kubuntu 14.04. Der Compiler ist in beiden Fällen die Toolchain die es von Atmel als separaten Download gibt, Eclipse ist ein normales Luna CDT mit dem ganz normalen AVR-Plugin und zum Flashen das aktuelle avrdude von dessen offizieller Seite. Keine Probleme. Vielleicht wirst Du mal etwas spezifischer was das "nur Fehlermeldungen" angeht und evtl. schreibst Du auch mal dazu welche Version der Toochain Du verwendest.
:
Bearbeitet durch User
Bernd K. schrieb: > Der Compiler ist in beiden Fällen die Toolchain die es von Atmel als > separaten Download gibt, Eclipse ist ein normales Luna CDT mit dem ganz > normalen AVR-Plugin und zum Flashen das aktuelle avrdude von dessen > offizieller Seite. Keine Probleme. Hallo Bernd Das hört sich doch sehr interessant an. Ich habe damals die letzte Version von WinAVR benutzt. Dies könnte das Problem sein. Die make.exe von winAVR hatte nämlich diverse errors gegeben. Du hast also das AVR-Plugin nach Anleitung vom mikrocontroller forum integriert und dann greift dieses automatisch auf die make.exe der Atmel Toolchain zu? Oder wie bist du hier vorgegangen? Ich bin in dieser hinsicht ein Anfänger, wenn es darum geht Eclipse zu konfigurieren. Deshalb wäre eine kurze Anleitung mit den wichtigsten schritten sehr hilfreich. Wenn es am schluss mit Eclipse läuft, wäre dies genial!
:
Bearbeitet durch User
Ich bekomme immer diesen Fehler:
1 | make: write error: No such file or directory |
Dies geschieht sowohl bei alten wie auch bei gerade neu erstellten Projekten nach dem klicken auf Compile. Eclipse: Helios WinAVR: 20100110 Plugin: 2.4.1
Das bin Verzeichnis deiner Toolchain muss in der PATH Variablen eingetragen sein. Eventuell wird hier eine andere make.exe aufgerufen? Oder erst gar nicht gefunden.
Cyblord ---- schrieb: > Eventuell wird hier eine andere make.exe aufgerufen? Die obig erwähnte Meldung flutet die Konsole. Während dieser Zeit habe ich mit dem TaskManager geprüft, welche make.exe aktiv ist. Es ist jene aus: WinAVR-20100110/utils/bin Somit würde dies stimmen. Es gibt zudem noch folgenden Hinweis von Eclipse: java.lang.NullPointerException Wenn ich das aber richtig verstehe, dann nutzt bernd nicht WinAVR sonder die Toolchain von Atmel zur kompilierung seines Codes. Ich nehme mal an, das dies immer vorteile gegenüber der veralteten WinAVR Toolchain hat oder?
:
Bearbeitet durch User
Claudio H. schrieb: > Es gibt zudem noch folgenden Hinweis von Eclipse: > java.lang.NullPointerException Verdächtig. > Wenn ich das aber richtig verstehe, dann nutzt bernd nicht WinAVR sonder > die Toolchain von Atmel zur kompilierung seines Codes. Die nutze ich auch. > Ich nehme mal an, das dies immer vorteile gegenüber der veralteten > WinAVR Toolchain hat oder? Es ist im Prinzip dieselbe. Nur halt neuer. Du willst ja auch aktuelle Header für neue AVRs und die aktuelleste Compilerversion. Aber das sollte mit deinem Problem nichts zu tun haben. Trotzdem schadet es ja nicht, wenn du dir die aktuelle Toolchein von Atmel saugst und es damit versuchst. Sieht bei dir alles recht ungesund aus, aber die Ursache kann ich dir leider auch nicht verraten. Eventuell mal ein frisches Eclipse mit neuem Plugin versuchen?
Cyblord ---- schrieb: > Sieht bei dir alles recht ungesund aus, aber die Ursache kann ich dir > leider auch nicht verraten. Eventuell mal ein frisches Eclipse mit neuem > Plugin versuchen? Habe ich auch bereits versucht. Das merkwürdige ist, dass ich diesen Fehler nicht nur auf meinem PC sonder auch auf etwa 3 anderen erhalte. Das System ist immer 64bit. Habt ihr 32 oder 64bit Java versionen installiert?
... schrieb: > als administrator ausführen? Habe ich auch schon versucht. Habe auch den Kompatiblitäts mode versucht und das häckchen dort gesetzt. Habe auch mal versuchsweise den UAC Lvel auf 0 gesetzt. Immer das selbe ergebnis. Habe jetzt WinAVR deinstalliert und die Atmel Toolchain ins C:/ entpackt. Nun lade ich mir Luna herunter und installiere dort nochmals das AVR Plugin über deren Seite. Welche Umgebungsvariable muss ich auf welchen Pfad setzen?
... schrieb: > als administrator ausführen? nein. Das ist keine Lösung für irgendwas und war es noch nie.
Hediger C schrieb: > Habt ihr 32 oder 64bit Java versionen installiert? 64 bit, aber das sollte keinen Unterschied machen. Ich habe mir auf Windows den ganzen avr-gcc Ordner geschnappt und nach c:\avr-gcc\ verschoben damit im Pfad keine Leerzeichen sind. Außerdem habe ich auch noch einen c:\bin Ordner der enthält die ganzen gnu tools wie make.exe und Konsorten. Der c:\bin Ordner ist im Pfad, der c:\avr-gcc\bin Ordner glaub ich auch (müsst ich morgen mal nachschauen). Außerdem kann und muss man im Eclipse Avr Plugin die Pfade zur Toolchain und zu make.exe angeben, sonst geht gar nichts. versuch auch mal rauszufinden mit make -v weches make.exe es ist das Du im Pfad hast und vergleiche die Version mit allen anderen make.exe die Du irgendwo noch im Pfad hast denn evtl schwirren da auch noch andere Versionen von anderen Toolchains rum, das ist immer so ein Krampf unter Windows weil diese tools dort immer wie ein Fremdkörper nachträglich angeflanscht werden und da gibt es keine Konvention wo und wie das genau aussehen sollte und so kann es zu Duplikaten und Konflikten kommen. Noch was: Hast Du zufällig git installiert? Wenn ja dann deinstallier es uns installier es erneut aber diesmal ohne die Option mit der fetten Warnung, nimm stattdessen die minimal möglichste Integration, ansonsten spielt auf diesem Rechner alles verrückt was auch nur entfernt mit den gnu tools zu tun hat, auch Eclipse/avr-gcc geht dann nicht mehr vernünftig.
:
Bearbeitet durch User
Bernd K. schrieb: > Noch was: Hast Du zufällig git installiert? Wenn ja dann deinstallier es Ich habe SmartGit installiert :) Soll ich dieses nun also deinstallieren? Bernd K. schrieb: > weches make.exe es ist das Du im Pfad hast und vergleiche die Version > mit allen anderen make.exe die Du irgendwo noch im Pfad hast denn evtl > schwirren da auch noch andere Versionen von anderen Toolchains rum Das ist gut möglich. Habe auch noch Delphi, und eine STM32 Toolchain installiert. Wie kriegt mann denn normalerweise diese alle unter einen hut? Muss man sich Batch.Files erstellen, welche vor dem starten den Pfad entsprechend anpassen?
Claudio H. schrieb: > Wie kriegt mann denn normalerweise diese alle unter einen hut? Du musst halt genau im Griff haben was (und warum) in deiner PATH Variablen drinsteht und in welcher Reihenfolge. Das würd ich nicht dem Zufall überlassen. Ich habs jetzt irgendwie fertig gebracht einen Satz von gnu tools in meinem c:\bin Ordner zu haben bei dem das make mit allem zu funktionieren scheint, sogar mit den Makefiles des FPC compilers (das war immer ein Problem). Ich weiss nicht mehr genau wo die her sind, ich glaub die hab ich aus der Atmel-Installation rausgeholt, die funktionieren aber auch klaglos für meine selbergebauten Arm-Makefiles. Wenn das Problem morgen noch besteht kann ich mal genauer nachschauen.
:
Bearbeitet durch User
Ich hab die AVR-Toolchain nicht im Path, man kann sie in Eclipse eintragen Preferences -> AVR -> Paths GCC: WinAVR\bin Make: WinAVR\utils\bin Header: WinAVR\avr\include AVRDude: WinAVR\bin
Nun habe ich Luna installiert bzw heruntergeladen und das neueste Java Update 64bit installiert. WinAVR ist deinstalliert. Die Atmel Toolchain habe ich heruntergeladen. Das AVR Plugin in Eclipse ist nun installiert. Wenn ich ein neues Projekt erstellen möchte, kommt folgender Fehler:
1 | Could not execute avr-gcc. Please check the AVR paths in the preferences. Cannot run program "avr-gcc": CreateProcess error=2, Das System kann die angegebene Datei nicht finden |
Ich vermute mal, dass dies mit der Fehlenden Pfadangabe zur atmel toolchain zu tun hat. Welche Umgebungsvariable muss ich nun hinzufügen?
Claudio H. schrieb: > Ich vermute mal, dass dies mit der Fehlenden Pfadangabe zur atmel > toolchain zu tun hat. Genau. Gib da den Ordner an der avr-gcc.exe enthält.
Christian K. schrieb: > Preferences -> AVR -> Paths > > GCC: WinAVR\bin > Make: WinAVR\utils\bin > Header: WinAVR\avr\include > AVRDude: WinAVR\bin Danke für den Tipp! Ich möchte hier nun die Atmel Toolchain angeben. Leider irritiert mich die Ordnerstruktur der Atmeltoolchain etwas. GCC fans ich im bin ordner. Doch eine make.exe gibt es nicht....
Bernd K. schrieb: > Claudio H. schrieb: >> Ich vermute mal, dass dies mit der Fehlenden Pfadangabe zur atmel >> toolchain zu tun hat. > > Genau. > > Gib da den Ordner an der avr-gcc.exe enthält. Und bei den headerfiles den <woauchiummer/avr8-gnu-bla-bla>/avr/include
Bernd K. schrieb: > Bernd K. schrieb: >> Claudio H. schrieb: >>> Ich vermute mal, dass dies mit der Fehlenden Pfadangabe zur atmel >>> toolchain zu tun hat. >> >> Genau. >> >> Gib da den Ordner an der avr-gcc.exe enthält. > > Und bei den headerfiles den <woauchiummer/avr8-gnu-bla-bla>/avr/include Es sieht mommentan so aus wie im Anhang Leider weiss ich nicht, wo sich die make befindet.... AVR.Dude werde ich wohl noch runterladen müssen...
Claudio H. schrieb: > Leider weiss ich nicht, wo sich die make befindet.... Muss ich morgen mal nachschauen, hab kein Windows hier, ob ich einen Hinweis darauf finde wo die herstammen. Das ist ein ganzer Ordner mit tools wie ls, cp, mv, rm, make und noch dutzenden anderen. Cygwin wars nicht soweit ich weiß (obwohls die dort auch gibt), aber irgendwo anders waren die alle drin.
Bernd K. schrieb: > Claudio H. schrieb: >> Leider weiss ich nicht, wo sich die make befindet.... > > Muss ich morgen mal nachschauen, hab kein Windows hier, ob ich einen > Hinweis darauf finde wo die herstammen. Das ist ein ganzer Ordner mit > tools wie ls, cp, mv, rm, make und noch dutzenden anderen. Ich habe es inzwischen angepasst. Habe nun ein test gemacht. (siehe anhang) Leider mit errors... Hat jemand eine idee?
1 | 19:19:20 **** Incremental Build of configuration Release for project Test **** |
2 | make all |
3 | Building target: Test.elf |
4 | Invoking: AVR C Linker |
5 | avr-gcc -Wl,-Map,Test.map -mmcu=atmega324p -o "Test.elf" ./main.o |
6 | c:/avr8-gnu-toolchain/bin/../lib/gcc/avr/4.8.1/../../../../avr/lib/avr5/crtm324p.o:(.init9+0x0): undefined reference to `main' |
7 | collect2.exe: error: ld returned 1 exit status |
8 | make: *** [Test.elf] Error 1 |
9 | |
10 | 19:19:20 Build Finished (took 181ms) |
-------------------- Problem gelöst :) Musste die main.c speichern :P
:
Bearbeitet durch User
main muss int sein int main(void) { } aber obs daran liegt, nicht sicher. Stammt das main.o das da gelinkt wird wirklich von der selben main.c? Mach vielleicht noch mal clean vorher.
Claudio H. schrieb: > Musste die main.c speichern :P Das kann man in Eclipse einstellen dass er das automatisch vor jedem build macht.
Bezüglich der make: evtl ist das in mingw32 enthalten, kannst das ja mal bei Gelegenheit installieren und ausprobieren. Da Mingw32 dafür gedacht ist mit gcc und der gnu toolchain Windows-Programme zu schreiben müsste alles enthalten sein was man für ein durchschnittliches Makefile im gcc Umfeld so alles braucht.
Bernd K. schrieb: > Ich habs jetzt irgendwie fertig gebracht einen Satz von gnu tools in > meinem c:\bin Ordner zu haben bei dem das make mit allem zu > funktionieren scheint, sogar mit den Makefiles des FPC compilers (das > war immer ein Problem). Wenn ein make Lauf fehlschlägt, dann ist das fast nie ein Problem der make.exe selber. Viel wahrscheinlicher ist, daß make die aufzurufenden Tools nicht findet. Eine Fehlermeldung
1 | make: write error: No such file or directory |
ist ja eigentlich nicht fehlzuinterpretieren: make hat versucht in ein File zu schreiben und ist dabei gescheitert. Was in 99% der Fälle bedeutet, daß das Verzeichnis nicht existiert in dem das File geschrieben werden sollte. Wenn man jetzt noch wüßte, welchen Befehl im Makefile make gerade ausgeführt hat, dann könnte man das Problem sogar lösen. Dazu müßte man nur den Tab der IDE öffnen, wo es die Ausgaben der Tools sammelt. Viel cleverer wäre freilich, gleich ganz auf eine IDE zu verzichten, wenn die die Arbeit nicht erleichtert, sondern nur verkompliziert. Wenn ich hier in einem xterm "make" sage, dann sehe ich alle Meldungen. Und zwar gleich.
Axel Schwenke schrieb: > Viel cleverer wäre freilich, gleich ganz auf eine IDE zu verzichten, > wenn die die Arbeit nicht erleichtert, sondern nur verkompliziert. > Wenn ich hier in einem xterm "make" sage, dann sehe ich alle Meldungen. > Und zwar gleich. Ja sehr clever wäre auch, den Thread komplett zu lesen. Aber dafür bist du als Nicht-IDE-Nutzer natürlich viel zu clever schon klar. Nur weil eine IDE über deinen intellektuellen Horizont geht, solltest du das anderen nicht unterstellen.
:
Bearbeitet durch User
Claudio H. schrieb: > es eine alternative zum Atmel Studio gibt, welche ähnlichkeiten zu > Eclipse aufweist. Codeblocks unterstützt auch direkt AVR Controller und andere... http://www.codeblocks.org
Axel Schwenke schrieb: > Wenn ich hier in einem xterm "make" sage, dann sehe ich alle Meldungen. > Und zwar gleich. Sieht er in Eclipse auch, und zwar ebenfalls "gleich".
Martin schrieb: > Codeblocks unterstützt auch direkt AVR Controller und andere... > http://www.codeblocks.org Ja, nur ist da leider keine vernünftige IDE dabei. <duck-und-weg>
Vielen herzlichen Dank euch allen! Es funktioniert nun. Leider unterstüttz avrdude meinen Debugger noch nicht richtig. Atmel ICE... Die Device ID findet avrdude anscheinend nicht. Obwohl diese vorhanden ist. Neustart brachte nichts!
Jetzt mal so ne ganz doofe Frage: Was kann Eclipse denn besser als Atmel Studio damit man sich das Leben (unter Windows) so schwer macht?
Claudio H. schrieb: > Die Device ID findet avrdude anscheinend nicht. > Obwohl diese vorhanden ist. Hast Du den Filtertreiber installiert? (Zuerst die normalen Treiber von Atmel und danach noch den libusb Filtertreiber zusätzlich damit avrdude damit zurecht kommt)
Bernd K. schrieb: > Hast Du den Filtertreiber installiert? (Zuerst die normalen Treiber von > Atmel und danach noch den libusb Filtertreiber zusätzlich damit avrdude > damit zurecht kommt) Das ist ein guter hinweis! Gibt es Libusb auch für win7 64bit?
Ingo schrieb: > Was kann Eclipse denn besser als Atmel > Studio damit man sich das Leben (unter Windows) so schwer macht? * Die Möglichkeiten schnell im Code zu navigieren sind bei Eclipse Weltklasse, im Atmel-Studio unterirdisch bis nicht vorhanden. * Code completion funktioniert im Atmel-Studio nur unvollständig. * Die nicht abzustellende Autoformatierung in Atmelstudio hat einen üblen nervigen Bug beim } else { für Leute wie mich die gerne den ägyptischen Klammerstil pflegen (1TBS, K+R, west-coast) dieser Bug allein reicht schon aus um in einem täglich das Bedürfnis zu wecken einen Microsoft-Programmierer zu erwürgen (und das obwohl die selber von der Westküste kommen). * viele Plugins, (Versionskontrolle, Tasklist, etc.) andere Toolchains für andere Platformen, sogar andere Sprachen, alles in ein und der selben IDE. * Performance und Geschwindigkeit (ja, kaum zu glauben, selbst das schwere Eclipse schafft es leichtgewichtiger zu erscheinen als das träge häßliche Atmel-Visual-Monster) * Und zu guter letzt: Eye candy. Ich kenne keine schönere, fürs Auge wohlgefälligere IDE als Eclipse, ich kann es nicht an irgendwas bestimmtem festmachen, ich glaube es hängt auch mit der Editorkomponente zusammen, die strahlt irgendwas aus oder "fühlt" sich irgendwie anders an als andere, ich weiß nicht was das ist aber es ist einfach eine wahre Freude damit zu arbeiten.
Claudio H. schrieb: > Das ist ein guter hinweis! > Gibt es Libusb auch für win7 64bit? Ja. Da ist nach dem Entpacken ein Ordner drin mit amd-64, das ist der richtige (der andere würde sich sowieso weigern zu installieren).
Bernd K. schrieb: > Ja. Da ist nach dem Entpacken ein Ordner drin mit amd-64, das ist der > richtige (der andere würde sich sowieso weigern zu installieren). Ich bin unfähig einen Link zu finden für den Download....
Claudio H. schrieb: > Bernd K. schrieb: >> Ja. Da ist nach dem Entpacken ein Ordner drin mit amd-64, das ist der >> richtige (der andere würde sich sowieso weigern zu installieren). > > Ich bin unfähig einen Link zu finden für den Download.... https://sourceforge.net/projects/libusb-win32/files/latest/download dieses zip enthält trotz des irreführenden Namens auch 64 bit. Siehe Bild, die blau markierte Datei,
Bernd K. schrieb: > dieses zip enthält trotz des irreführenden Namens auch 64 bit. Siehe > Bild, die blau markierte Datei, Vielen Dank!!! Nun gibt es diesen Error:
1 | Output: |
2 | avrdude: usbdev_send(): wrote -22 out of 7 bytes, err = |
3 | avrdude: jtag3_send(): failed to send command to serial port |
4 | avrdude: sign-on command: timeout/error communicating with programmer (status -1) |
5 | avrdude: failed to sync with the JTAGICE3 in ISP mode |
6 | |
7 | avrdude done. Thank you. |
8 | |
9 | avrdude execution aborted |
muss das nicht -c atmelice_isp heißen oder täusch ich mich da? Kanns nicht ausprobieren, hab keinen da, nur nen uralten jtagice in der Firma, mit dem hats mal funktioniert. Also da muss ich passen.
Bernd K. schrieb: > muss das nicht -c atmelice_isp heißen oder täusch ich mich da? > Kanns > nicht ausprobieren, hab keinen da, nur nen uralten jtagice in der Firma, > mit dem hats mal funktioniert. Also da muss ich passen. Das war die standard einstellung von avrdude...
Der Aufruf sieht so aus: avrdude -catmelice_isp [...part specific options...]
Launching C:\avr8-gnu-toolchain\avrdude\avrdude -pm324p -catmelice_isp -Ereset -Uflash:w:Test.hex:a
Claudio H. schrieb: > Launching C:\avr8-gnu-toolchain\avrdude\avrdude -pm324p -catmelice_isp > -Ereset -Uflash:w:Test.hex:a Ja, scheint richtig zu sein auf den ersten Blick (das leerzeichen nach dem c ist nicht erforderlich). Aber wie gesagt: jetzt muss mal irgendjemand anderes was sagen, mir fällt grad nichts mehr ein. Filtertreiber scheint funktioniert zu haben sonst wär gar keine Kommunikation da, aktuelle Version vom avrdude? Evtl vielleicht sogar mal schaun obs ne noch neuere dev-Version vom avrdude gibt?
Bernd K. schrieb: > aktuelle Version vom avrdude? Evtl vielleicht sogar > mal schaun obs ne noch neuere dev-Version vom avrdude gibt? ist 6.1. Ja die neueste Bernd K. schrieb: > jetzt muss mal > irgendjemand anderes was sagen, mir fällt grad nichts mehr ein. Ich danke dir vielmals für deine hilfe!
Claudio H. schrieb: > -Uflash:w:Test.hex:a Wahrscheinlich löst es das Problem nicht, aber sollte man nicht das Intel-Hex-Format wählen (oder gar keines)? Also -U flash:w:Test.hex:i oder -U flash:w:test.hex Hast Du schon mal Teile der Fehlermeldung in eine Suchmaschine eingegeben?
Hallo zusammen Ich konnte das Problem lösen! Wenn man den libusb Device Filter installiert, gibt es 3 Geräte welche die passende PID und VID haben. Jedoch nur das Verbundgerät ist das richtige! Ich habe das Atmel Data Gateway installiert gehabt. Anbei ein Screenshot des richtigen Geräts. Nun funktioniert ISP mit dem AtmelICE und Eclipse einwandfrei!!!! Vielen Dank euch allen für die super unterstützung!
>Wie hast du da die Integration von WINAVR hinbekommen?
Weiss ich nicht mehr im Detail. Ich hatte Makefiles verwendet und
Netbeans so konfiguriert, dass es das Makefile verwendet. Irgendwo
musste ich auch den Pfad zu den *.h dateien von WinAvr einstellen.
Ich habe Dir mal einen Screenshot von meinen Einstellungen in Netbeans gemacht (unter Linux). Nach Installation des C/C++ Plugins gehst du ins Menü auf Tools -> Options -> C/C++. Dann erscheint dieser Dialog. Dort fügst du eine neue tool collection mit Namen "AVR" ein und stellst die Pfade zu den Programmen ein. Die Makefiles, die Netbeans generiert, taugen nicht für AVR. Verwende besser eine Kopiervorlage deines Vertrauens und passe sie an dein Projekt an. Netbeans setzt lediglich voraus, dass (wie üblich) ein Target mit dem Namen "clean" vorhanden ist.
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.