..zum installieren für einen "unbedarften" Nutzer? Die Links im Wiki hier auf der Seite führen seit Microchip scheinbar ins Leere. Nein, kein AVRstudio, das hat der Mann bereits. Gruß, Holm
Auch als unbedarfter Nutzer sollte man es hinbekommen, ein make zu installieren, ganz unabhängig von irgendwelchen toolchains. http://gnuwin32.sourceforge.net/packages/make.htm Oliver
:
Bearbeitet durch User
Holm T. schrieb: > ..zum installieren für einen "unbedarften" Nutzer? > "unbedarften Nutzer"? Da musst ich jetzt trotz Grippe mal lächeln Aber ich bin mal auf die Antworten gespannt, interessiert mich Gruss Walter
Oliver S. schrieb: > http://gnuwin32.sourceforge.net/packages/make.htm Das hatte bei mir irgendwelche Probleme verursacht... Wenn ich mich recht erinnere ist es stecken geblieben wenn man "-j" benutzt oder so. Am besten hat bei mir immer das funktioniert: https://github.com/gnu-mcu-eclipse/windows-build-tools/releases Das ist eine Kombination aus make, sh, busybox. Ist zwar ursprünglich für Eclipse+ARM/RISC-V, hat aber technisch nichts damit zu tun und funktioniert komplett unabhängig.
Oliver S. schrieb: > Auch als unbedarfter Nutzer sollte man es hinbekommen, ein make zu > installieren, ganz unabhängig von irgendwelchen toolchains. Bei einem richtigen Betriebssystem muss man make noch nicht mal installieren;-) Zu einer tool-chain gehört aber nicht nur der Aufruf von Compiler und Linker, sondern auch die Übertragung des Maschinencodes zum µC ... das hat dann mit make recht wenig zu tun!
Walter K. schrieb: > Bei einem richtigen Betriebssystem muss man make noch nicht mal > installieren;-) Sag doch gleich: "Ätsch, ich hab Linux. Ihr nicht!" Was soll das Gebashe?
Huh schrieb: > Walter K. schrieb: >> Bei einem richtigen Betriebssystem muss man make noch nicht mal >> installieren;-) > > Sag doch gleich: "Ätsch, ich hab Linux. Ihr nicht!" > Was soll das Gebashe? Ich hab kein Linux Was für eine Antwort erwartest du, wenn jemand nach ner Tool-Chain fragt und dbekommt dann als Antwort:" Auch als unbedarfter Nutzer sollte man es hinbekommen, ein make zu installieren" hingerotzt!?
:
Bearbeitet durch User
Dr. Sommer schrieb: > Am besten hat bei mir immer das funktioniert: > > https://github.com/gnu-mcu-eclipse/windows-build-tools/releases Die Erfahrung habe ich auch gemacht. Eine make.exe kann man sich aus gefühlt 100 verschiedenen Quellen laden, allerdings kann man da auch sein blaues Wunder erleben. Bei oben genannten binaries funtionieren auch die mit darin enthaltenen tools wie rm,sh,mkdir und echo richtig. Schwätzer die die Probleme nicht kennen haben es nie verwendet und haben deshalb große Klappe. Es interessiert hier auch nicht die Bohne dass es in andern Betriebsystemen meistens schon enthalten ist. Das gemeine an den vielen verschiedenen Versionen die im Umlauf sind ist, dass es bei Problemen nie eine Fehlermeldung gibt mit der man etwas anfangen kann. Ganz besonders wenn verschiedenen Versionen von make,rm,mkdir und echo zusammengewürfelt werden kann man die schönsten Überraschungen erleben. Wichtig ist auch, dass diese Tools im Pfad vor allem andern stehen. Ich mache mir für diese Zwecke immer ein buildbatch wo ein angepasster Pfad gleich mit drin steht. Für den "unbedarften Anwender" ohne Ahnung ist es auch noch wichtig zu wissen, dass das enthaltene busybox auch einen Sack voll andere Kommandos kann:
1 | |
2 | [, [[, ar, ash, awk, base64, basename, bash, bbconfig, bunzip2, bzcat, bzip2, cal, cat, catv, chmod, cksum, |
3 | clear, cmp, comm, cp, cpio, cut, date, dc, dd, df, diff, dirname, dos2unix, dpkg-deb, du, echo, ed, egrep, env, |
4 | expand, expr, false, fgrep, find, fold, ftpget, ftpput, getopt, grep, groups, gunzip, gzip, hd, head, hexdump, |
5 | id, ipcalc, kill, killall, logname, ls, lzcat, lzma, lzop, lzopcat, man, md5sum, mkdir, mktemp, mv, nc, od, |
6 | patch, pgrep, pidof, printenv, printf, ps, pwd, rev, rm, rmdir, rpm2cpio, sed, seq, sh, sha1sum, sha256sum, |
7 | sha3sum, sha512sum, shuf, sleep, sort, split, stat, strings, sum, tac, tail, tar, tee, test, touch, tr, true, |
8 | truncate, uname, uncompress, unexpand, uniq, unix2dos, unlink, unlzma, unlzop, unxz, unzip, usleep, uudecode, |
9 | uuencode, vi, wc, wget, which, whoami, xargs, xz, xzcat, yes, zcat |
Unter Windows muss man das zwar durch Kopieren erzeugen, aber das macht den Kohl auch nicht mehr fett.
Holm T. schrieb: > Nein, kein AVRstudio, das hat der Mann bereits. AS bzw. Arduino sind aber genau für den "unbedarften User" gedacht. Man kann den AVR-GCC aber auch auf der Kommandozeile aufrufen. Oder den Aufruf in eine Batch, wenn man nicht soviel tippen will.
temp schrieb: > Unter Windows muss man das zwar durch Kopieren erzeugen, aber das macht > den Kohl auch nicht mehr fett. Ja, oder durch "sh mkdir" o.ä. aufrufen. Innerhalb eines Makefile sind die ohnehin direkt verfügbar, da hier die Busybox-Shell aufgerufen wird. temp schrieb: > Die Erfahrung habe ich auch gemacht. Ein Leidensgenosse :-) ... Dieses Pakat passt (dafür ist es ja da) genau um mit Eclipse CDT generierte Makefiles zu kompilieren, ohne sich gleich das ganze MSys oder Cygwin ans Bein zu binden. Funktioniert aber halt auch ohne Eclipse.
Ich hatte damals auf allen Windowsrechnern grundsätzlich ein cygwin installiert (Nur Grundinstallation + make + python) und alle Makefiles und sonstige Scripte wurden dann von allen Windows-Extrawürsten und Verrenkungen befreit und in einer Cygwin shell gestartet wo sie tun konnten als befänden sie sich nativ auf nem vollwertigen Betriebssystem und nicht unter Windows. Das war schonmal eine enorme Erleichterung und Vereinfachung und auch auf nem frisch aufgesetzten Rechner im Handumdrehen und exakt reproduzierbar wieder eingerichtet ohne die ganzen Einzeltools aus zig Quellen manuell zusammenzusuchen und händisch zu implantieren. Die IDE (Eclipse) ließ sich problemlos so konfigurieren daß sie beim Build das Cygwin make in der Cygwin-Umgebung verwendet. Die GNU-Compiler Toochain war weiterhin die Windows-Variante aber die kann auch aus Cygwin heraus ganz normal aufgerufen werden und verhält sich völlig normal als ob sie nativ dazugehört. Der spätere Umstieg auf Linux für die Entwicklerarbeitsplätze funktionierte dann reibungslos, alles funktionierte, alle Scripte liefen auf Anhieb out-of-the-box. Eventuell kann man heutzutage eine ähnlich brauchbare und kompatible Buildumgebung auch mit dem neuen Linux-Subsystem für Windows aufsetzten aber so weit ist es hier nicht mehr gekommen da Windows 10 aus verschiedenen anderen Gründen keine akzeptable Option mehr war.
:
Bearbeitet durch User
Hallo, Holm T. schrieb: > Nein, kein AVRstudio, das hat der Mann bereits. Ich stand (stehe) vor dem gleichen Problem, da ich ich im nächsten Jahr vorhabe von Windows nach Linux zu wechseln und es AVR-Studio eben nur für Windows gibt. Nach Ausprobieren diverser IDEs habe ich mich für eine Minimallösung auf Basis von Geany entschieden. Das hat den Vorteil das ich mit Geany sowohl einen Editor als auch eine einfache Entwicklungsoberfläche habe, die unter beiden Betriebssystemen läuft. Ich habe es mit Geany innerhalb kürzester Zeit geschafft Python, normale C-Programme als auch "AVR-C-Code" zu schreiben und jeweils auszuführen. Für den AVR-Teil benötigt man dazu ein Makefile, das neben dem Übersetzen des Quellcodes auch das Flashen des Baustein übernimmt. Nach einigem Suchen habe ich die folgende Quelle für ein Makefile gefunden das genau das macht: https://github.com/hexagon5un/AVR-Programming/blob/master/Chapter02_Programming-AVRs/blinkLED/Makefile Ich habe dazu folgende Softwarepakete installiert, b.z.w. heruntergeladen: - GNU-AVR - Geany - avrdude - obiges Makefile Das sieht auf den ersten Blick ein bisschen kompliziert aus, ist aber eigentlich recht einfach aufgebaut und zu handhaben. Die Handhabung mal im Groben: - Als erstes kopierst du das Makefile in das Verzeichnis in dem dein Quellcode steht - Danach musst du im Prinzip nur die Werte für MCU, F_CPU und BAUD setzen (hinter LIBDIR kannst du noch einen Pfad zu zusätzlichen z.B Quellcode-Libarys angeben) und einmalig den Programmer-Typ und die Programmer-Argumente angeben. - Innerhalb von Geany kannst jetzt ein Projekt anlegen und dann unter dem Menuepunkt "Erstellen" die einzelnen Make-Varianten aufrufen um z.B. nur den Quellcode zu übersetzen, direkt den Prozessor zu beschreiben oder Fuses zu setzen. Besonders angenehm finde ich, das das Makefile automatisch alle im Verzeichnis gefundenen Quellcodes übersetzt. Man muss also nicht immer wieder das Makefile editieren wenn irgend ein neues Quellcodemodul dazu kommt. Zusätzlich erhält das "Endprodukt" automatisch den Namen des jeweiligen Arbeitsverzeichnisses (kann man unter "TARGET" weiter unten im Makefile ändern). Man kann natürlich auch auf Geany verzichten und irgend einen anderen Editor verwenden, ich habe mich für Geany entschieden weil klein und übersichtlich ist und ich sofort damit klar kam. Wie gesagt, im ersten Moment wirkt das ein wenig kompliziert. Das Schwierigste war eigentlich die einmalige Installation und Konfiguration der Softwarepakete. Wenn das aber erstmal funktioniert, ist das Ganze wirklich einfach zu benutzen. Selbst ich als eher Gelegenheitsprogrammierer und großer Fan von kompletten Entwicklungswerkzeugen habe das in kurzer Zeit zu Laufen gebracht. rhf
> Unter Windows muss man das zwar durch Kopieren erzeugen, aber das macht > den Kohl auch nicht mehr fett. Jaja, wieder ein ahnungsloser: ln.cmd: fsutil hardlink create %2 %1
CMD.EXE schrieb: > Jaja, wieder ein ahnungsloser: > > ln.cmd: > > fsutil hardlink create %2 %1 ne Willenloser. 1. gibt es dafür mklink 2. Links die keiner als solche erkennt sind mir suspekt. Angenommen find.exe ist ein Hardlink auf busybox.exe. Daneben gibt es noch 20 andere Hardlinks mit busybox.exe. Da weder der Explorer noch der TotelCommander o.ä. einen Hardlink als solchen anzeigen ist es gefährlich z.B. eine andere find.exe in das Verzeichnis zu kopieren. Damit ist das Desaster perfekt. Dann schon lieber Symlinks, die gehen auch in W10. Allerdings bleiben beide Varianten irgendwie Fremdkörper unter Windows. Da opfere ich lieber mal 50Mb für Kopien.
Walter K. schrieb: > Oliver S. schrieb: >> Auch als unbedarfter Nutzer sollte man es hinbekommen, ein make zu >> installieren, ganz unabhängig von irgendwelchen toolchains. > > Bei einem richtigen Betriebssystem muss man make noch nicht mal > installieren;-) > > Zu einer tool-chain gehört aber nicht nur der Aufruf von Compiler und > Linker, sondern auch die Übertragung des Maschinencodes zum µC ... das > hat dann mit make recht wenig zu tun! ..geht aber in die Richtung in die ich möchte. Der Man hat fassungslos beobachtet wie das auf einem Dragonfly BSD mit avrdude so funktioniert..und will nun auch haben. Er bekommt von mir normalerweise die Binaries gemailt um einen XMega zu programmieren und findet die Variante mit der Mausschubserei und Avrstudio mittlerweile ätzend. Gruß, Holm
pegel schrieb: > Alt, aber alles was man braucht: > > https://github.com/james-martinez/winavr-portable ..5 Jahre alt, bist Du sicher das der damit Code geändert bekommt den ich unter avr-gcc 5.4.0 schreibe und compiliere? Gruß, Holm
Roland F. schrieb: > Hallo, > > Holm T. schrieb: >> Nein, kein AVRstudio, das hat der Mann bereits. > > Ich stand (stehe) vor dem gleichen Problem, da ich ich im nächsten Jahr > vorhabe von Windows nach Linux zu wechseln und es AVR-Studio eben nur > für Windows gibt. Nach Ausprobieren diverser IDEs habe ich mich für eine > Minimallösung auf Basis von Geany entschieden. Das hat den Vorteil das > ich mit Geany sowohl einen Editor als auch eine einfache > Entwicklungsoberfläche habe, die unter beiden Betriebssystemen läuft. > Ich habe es mit Geany innerhalb kürzester Zeit geschafft Python, normale > C-Programme als auch "AVR-C-Code" zu schreiben und jeweils auszuführen. > Für den AVR-Teil benötigt man dazu ein Makefile, das neben dem > Übersetzen des Quellcodes auch das Flashen des Baustein übernimmt. Nach > einigem Suchen habe ich die folgende Quelle für ein Makefile gefunden > das genau das macht: > > https://github.com/hexagon5un/AVR-Programming/blob/master/Chapter02_Programming-AVRs/blinkLED/Makefile > Ähäm.... Ein Problem mit Makefiles habe ich i.A. nicht, die mache ich selber nach meinen Vorstellungen. Viel interessanter fände ich ein Paket das die notwendigen Binaries und Libs enthält, ohne das man den Interessenten erst über das Basteln und Installieren von Cygwin schickt. > Ich habe dazu folgende Softwarepakete installiert, b.z.w. > heruntergeladen: > - GNU-AVR > - Geany > - avrdude > - obiges Makefile > > Das sieht auf den ersten Blick ein bisschen kompliziert aus, ist aber > eigentlich recht einfach aufgebaut und zu handhaben. Die Handhabung mal > im Groben: > - Als erstes kopierst du das Makefile in das Verzeichnis in dem dein > Quellcode steht > - Danach musst du im Prinzip nur die Werte für MCU, F_CPU und BAUD > setzen (hinter LIBDIR kannst du noch einen Pfad zu zusätzlichen z.B > Quellcode-Libarys angeben) und einmalig den Programmer-Typ und die > Programmer-Argumente angeben. > - Innerhalb von Geany kannst jetzt ein Projekt anlegen und dann unter > dem Menuepunkt "Erstellen" die einzelnen Make-Varianten aufrufen um z.B. > nur den Quellcode zu übersetzen, direkt den Prozessor zu beschreiben > oder Fuses zu setzen. Besonders angenehm finde ich, das das Makefile > automatisch alle im Verzeichnis gefundenen Quellcodes übersetzt. Man > muss also nicht immer wieder das Makefile editieren wenn irgend ein > neues Quellcodemodul dazu kommt. Zusätzlich erhält das "Endprodukt" > automatisch den Namen des jeweiligen Arbeitsverzeichnisses (kann man > unter "TARGET" weiter unten im Makefile ändern). ...falsche Baustelle.. aber trotzdem THX. > > Man kann natürlich auch auf Geany verzichten und irgend einen anderen > Editor verwenden, ich habe mich für Geany entschieden weil klein und > übersichtlich ist und ich sofort damit klar kam. > Wie gesagt, im ersten Moment wirkt das ein wenig kompliziert. Das > Schwierigste war eigentlich die einmalige Installation und Konfiguration > der Softwarepakete. Wenn das aber erstmal funktioniert, ist das Ganze > wirklich einfach zu benutzen. Selbst ich als eher > Gelegenheitsprogrammierer und großer Fan von kompletten > Entwicklungswerkzeugen habe das in kurzer Zeit zu Laufen gebracht. > > rhf Die Probleme die wir haben sind nicht identisch. Gruß, Holm
Ich dachte immer, dass diese Betriebssysteme für IT-technisch eher minderbemittelte Anwender, ohne make daherkommen: weil dort -wenn überhaupt- die „Poweruser“ eher in Basic programmieren;-) Duck & weg !!!
Bernd K. schrieb: > Ich hatte damals auf allen Windowsrechnern grundsätzlich ein cygwin > installiert (Nur Grundinstallation + make + python) und alle Makefiles > und sonstige Scripte wurden dann von allen Windows-Extrawürsten und > Verrenkungen befreit und in einer Cygwin shell gestartet wo sie tun > konnten als befänden sie sich nativ auf nem vollwertigen Betriebssystem > und nicht unter Windows. Das war schonmal eine enorme Erleichterung und > Vereinfachung und auch auf nem frisch aufgesetzten Rechner im > Handumdrehen und exakt reproduzierbar wieder eingerichtet ohne die > ganzen Einzeltools aus zig Quellen manuell zusammenzusuchen und händisch > zu implantieren. > Kenne ich..seit vielen Jahren, hatte ich mit irgend einem X11 Server laufen.. > Die IDE (Eclipse) ließ sich problemlos so konfigurieren daß sie beim > Build das Cygwin make in der Cygwin-Umgebung verwendet. Die GNU-Compiler > Toochain war weiterhin die Windows-Variante aber die kann auch aus > Cygwin heraus ganz normal aufgerufen werden und verhält sich völlig > normal als ob sie nativ dazugehört. Nein, es geht mir ausdrücklich nicht um die/eine IDE. Der Mann will meistens von mir geschickte Binaries nur in die Chips programmieren. Das geht zwar chick mit Maus umherfahren und klickern, er interessiert sich aber für meine Variante "make program". > > Der spätere Umstieg auf Linux für die Entwicklerarbeitsplätze > funktionierte dann reibungslos, alles funktionierte, alle Scripte liefen > auf Anhieb out-of-the-box. > > Eventuell kann man heutzutage eine ähnlich brauchbare und kompatible > Buildumgebung auch mit dem neuen Linux-Subsystem für Windows aufsetzten > aber so weit ist es hier nicht mehr gekommen da Windows 10 aus > verschiedenen anderen Gründen keine akzeptable Option mehr war. Das wollte ich vermeiden. Ich mache Firmware..habe aber nicht vor Linux Telefonsupport zu liefern, weil ich selbst kein Linux sondern BSDs benutze und die BSDs würde ich nicht unbedingt Neulingen empfehlen wollen. (Linux ist für Windows-Hasser, BSD für Unix-Liebhaber..habe ich mal gelernt) Der Mann will nur bei Bedarf an den Quelltexten etwas herumschrauben und selbst mal ein Binary machen. Dafür reicht ein beliebiger Editor, von mir aus Notepad. Gruß, Holm
Peter D. schrieb: > Holm T. schrieb: >> Nein, kein AVRstudio, das hat der Mann bereits. > > AS bzw. Arduino sind aber genau für den "unbedarften User" gedacht. > > Man kann den AVR-GCC aber auch auf der Kommandozeile aufrufen. Oder den > Aufruf in eine Batch, wenn man nicht soviel tippen will. Jetzt mußt Du nur noch mich überzeugen das ich unter FreeBSD Code für diese Sülze schreibe. Gibts Arduino für Xmegas? Tschulliung, aber ich schrieb doch nach was ich suche, nicht das ich in Richtung Arduino beraten werden möchte... Gruß, Holm
Huh schrieb: > Walter K. schrieb: >> Bei einem richtigen Betriebssystem muss man make noch nicht mal >> installieren;-) > > Sag doch gleich: "Ätsch, ich hab Linux. Ihr nicht!" > Was soll das Gebashe? Hallo Basher: Ich habe auch kein Linux..ätsch? Gruß, Holm
Walter K. schrieb: > Holm T. schrieb: >> ..zum installieren für einen "unbedarften" Nutzer? >> > > "unbedarften Nutzer"? Da musst ich jetzt trotz Grippe mal lächeln > > Aber ich bin mal auf die Antworten gespannt, interessiert mich > > Gruss Walter ...Du vertust Dich. Ich bin Entwickler, der Kunde sitzt in H und hat Windows... Gruß, Holm
Holm T. schrieb: > Walter K. schrieb: > Holm T. schrieb: > ..zum installieren für einen "unbedarften" Nutzer? > > "unbedarften Nutzer"? Da musst ich jetzt trotz Grippe mal lächeln > Aber ich bin mal auf die Antworten gespannt, interessiert mich > Gruss Walter > > ...Du vertust Dich. Ich bin Entwickler, der Kunde sitzt in H und hat > Windows... > > Gruß, > > Holm Ja ... ich hatte mich auch schon etwas über die Fragestellung gewundert - aber jetzt ist es klar
:
Bearbeitet durch User
die nackte avr-Toolchain gibts doch hier: https://www.microchip.com/mymicrochip/filehandler.aspx?ddocname=en607654 dazu noch das was ober verlinkt war: https://github.com/gnu-mcu-eclipse/windows-build-tools/releases Mehr braucht man doch nicht wenn es nur um das Bilden mit makefiles geht.
Holm T. schrieb: > 5 Jahre alt, bist Du sicher Das dürfte aber bei allen Varianten die Winavr-2010 benutzen das gleiche Problem sein.
temp schrieb: > die nackte avr-Toolchain gibts doch hier: > > https://www.microchip.com/mymicrochip/filehandler.aspx?ddocname=en607654 > > dazu noch das was ober verlinkt war: > > https://github.com/gnu-mcu-eclipse/windows-build-tools/releases > > Mehr braucht man doch nicht wenn es nur um das Bilden mit makefiles > geht. ..das sieht gar nicht schlecht aus...gcc ist zwar 5.3.0 aber das sollte zu verkraften sein. Ich werde es ausprobieren (lassen). Gruß und Dank, Holm
Das letzte mal, als ich die Toolchain von Atmel herunterlud, fehlte darin die make.exe. Nachtrag: Ja, ist immer noch so. Als IDE empfehle ich Qt Creator. Diese IDE analysiert den Quelltext viel umfangreicher, als die Eclipse Plugins die ich bisher gesehen habe. Die IDE weist auf einige mögliche Probleme hin, die der Compiler selbst mit -Wall nicht erkennt.
für Win32/64 ************ top aktuell und mit make.exe **************************** avr-gcc-8.2.0-x64-mingw *********************** http://blog.zakkemble.net/avr-gcc-builds/ abspeichern in C:\Atmel_Toolchain\AVR8_GCC\avr-gcc-8.2.0-x64-mingw
Holm T. schrieb: > ..zum installieren für einen "unbedarften" Nutzer? Was ist an "sudo apt install ....." so schwierig?
> 2. Links die keiner als solche erkennt sind mir suspekt.
Dafür hat Mann ja noch ein richtiges ls in der Hinterhand.
Das kann auch -i.
Hallo Holm,
> Die Probleme die wir haben sind nicht identisch.
Ja, das sehe ich auch gerade, ich habe das irgend wie falsch verstanden.
Entschuldigung für den "Roman", den ich dir geschrieben habe.
rhf
Holm T. schrieb: > ..das sieht gar nicht schlecht aus...gcc ist zwar 5.3.0 aber das sollte > zu verkraften sein. Ich werde es ausprobieren (lassen). Für einen Kunden aber sicher die beste Alternative das von der Herstellerseite zu verwenden. Du weisst doch was bei neuen Versionen vor allem neu ist: die Fehler
Dako schrieb: > Holm T. schrieb: >> ..zum installieren für einen "unbedarften" Nutzer? > > Was ist an "sudo apt install ....." so schwierig? Deine Frage geht mir auf die Eier. Lies im ersten Posting nach warum. Gruß, Holm
Roland F. schrieb: > Hallo Holm, > >> Die Probleme die wir haben sind nicht identisch. > > Ja, das sehe ich auch gerade, ich habe das irgend wie falsch verstanden. > Entschuldigung für den "Roman", den ich dir geschrieben habe. > > rhf Keine Ursache, Du wolltest auch nur behilflich sein. Gruß, Holm
temp schrieb: > Holm T. schrieb: >> ..das sieht gar nicht schlecht aus...gcc ist zwar 5.3.0 aber das sollte >> zu verkraften sein. Ich werde es ausprobieren (lassen). > > Für einen Kunden aber sicher die beste Alternative das von der > Herstellerseite zu verwenden. Du weisst doch was bei neuen Versionen vor > allem neu ist: die Fehler ..irrelevant, es muß kompatibel zu dem sein was ich verwende denn hier spielt die Musik. Gruß, Holm
Holm T. schrieb: > ..irrelevant, es muß kompatibel zu dem sein was ich verwende denn hier > spielt die Musik. Dann bau ihm doch einen Installer mit genau einem Button "<hier klicken>".
Bernd K. schrieb: > Dann bau ihm doch einen Installer mit genau einem Button "<hier > klicken>". Endlich mal nutzerfreundliche Software! Genau eine Funktion, keine Möglichkeit etwas anzupassen und damit falsch zu machen, keine verwirrenden Beschriftungen. Einfach überall "Hier klicken" dranschreiben, es könnte so einfach sein!
Dr. Sommer schrieb: > keine > Möglichkeit etwas anzupassen und damit falsch zu machen Genau. Was will man auch anpassen? Die Firmware soll installiert werden oder eben lieber doch nicht. Das ist binär. Ein Button reicht.
Dr. Sommer schrieb: > Bernd K. schrieb: >> Dann bau ihm doch einen Installer mit genau einem Button "<hier >> klicken>". > > Endlich mal nutzerfreundliche Software! Genau eine Funktion, keine > Möglichkeit etwas anzupassen und damit falsch zu machen, keine > verwirrenden Beschriftungen. Einfach überall "Hier klicken" > dranschreiben, es könnte so einfach sein! Das gibts schon, heißt IMHO Xbill oder Xlennart.. Gruß, Holm
MitLeserin schrieb: > für Win32/64 > ************ > top aktuell und mit make.exe > **************************** > avr-gcc-8.2.0-x64-mingw > *********************** > > http://blog.zakkemble.net/avr-gcc-builds/ > > abspeichern in C:\Atmel_Toolchain\AVR8_GCC\avr-gcc-8.2.0-x64-mingw Stefanus F. schrieb: > http://gnutoolchains.com/avr/ > > Die haben auch für viele andere Mikrocontroller fertige Toolchains. Diese beiden Quellen wären auch meine Wahl. Erstere für eine aktuelle, letztere für eine stabile Version. Dr. Sommer schrieb: > https://github.com/gnu-mcu-eclipse/windows-build-t... Das wäre auch meine erste Wahl für ein schnörkelloses make mit ein bisschen drum herum. Wenn man auf dem neuesten Stand sein möchte und einen Paketmanager zu schätzen weiß, dann wäre msys2 durchaus einen Blick wert.
Holm T. schrieb: > Jetzt mußt Du nur noch mich überzeugen das ich unter FreeBSD Code für > diese Sülze schreibe. Gibts Arduino für Xmegas? > > Tschulliung, aber ich schrieb doch nach was ich suche, nicht das ich in > Richtung Arduino beraten werden möchte... Nur so am Rande: Früher™ (als die Gummistiefel noch aus Holz waren, etc. pp.) da kam Arduino auch unter Windows mit einer make.exe daher und den avr-gcc hat es sogar heute noch. Die beiden Programme waren natürlich auch ohne Arduino nutzbar und damit natürlich auch für xmega und co.
ich habe mein Makefile (BSD Make) mal mit Gnu Make ausprobiert und war erfreut das das zumindest auf meinem BSD System anstandslos klappt. Ich schminke mir aber von vornherein ab zu denken das das ohne Änderungen auf dem Windows funktionieren wird.. da werde ich wohl sed o.ä. sowieso noch bemühen müssen. Der Mann hat erst mal die hier Beitrag "Re: gibts irgendwo eine fertige AVR-GCC Toolchain mit Make fertig.." vorgeschlagenen Dinge auf dem Rechner, weiter probieren werde ich da nächste Woche. Gruß, Holm
Holm T. schrieb: > Ich schminke mir aber von vornherein ab zu denken das das ohne > Änderungen auf dem Windows funktionieren wird.. Was machst du denn da für komplizierte Dinge? Portable Makefiles sind durchaus möglich
Da drin gibts Targets wie "make dist" was im Endeffekt dann curl anwirft und das Ganze irgendwo hoch lädt. Dr. Sommer erklärt mir bestimmt gleich was daran falsch ist.. Gruß, Holm
Holm T. schrieb: > Dr. Sommer erklärt mir bestimmt gleich was daran falsch ist.. Tja, ich würde so etwas nicht in ein makefile packen. Soll jeder, der das makefile bekommt, hochladen können? Oder nur du? Ich hoffe mal, dass da keine Zugangsdaten für den Server drin stehen... Für solche Sonderwünsche gibt's bestimmt auch eine curl.exe.
Dr. Sommer schrieb: > Holm T. schrieb: >> Dr. Sommer erklärt mir bestimmt gleich was daran falsch ist.. > > Tja, ich würde so etwas nicht in ein makefile packen. Soll jeder, der > das makefile bekommt, hochladen können? Oder nur du? Ich hoffe mal, dass > da keine Zugangsdaten für den Server drin stehen... Für solche > Sonderwünsche gibt's bestimmt auch eine curl.exe. Du kannst alternativ nochmal von oben her lesen, aber ich kanns Dir auch nochmal erklären: Ich entwickle hier. Die Makefiles sind für mich. Kunde wünscht auf seinem Windows mal was frickeln zu können. Es gibt keinen "Jeder". Möglicherweise gibts für Windows eine curl.exe, bezahlst Du mich dafür das beim Kunden zum Laufen zu bekommen? Gruß, Holm
Holm T. schrieb: > Die Makefiles sind für mich. Kunde wünscht auf seinem Windows mal was > frickeln zu können. Es gibt keinen "Jeder". Und der Kunde muss auch hochladen können? Holm T. schrieb: > bezahlst Du mich dafür das beim Kunden zum Laufen zu bekommen? Wieso ich? Du hast doch Sonderwünsche.
Für hat es sich bewährt, unter Windows CygWin zu installieren und dann dort alle weiteren Kommandos (make, curl, usw). Ausnahmen: MySQL und MariaDB installieren ich als reguläres Windows Programm. Achtung: Der Windows Client von MySQL funktioniert in der CygWin Shell nicht richtig. Man sieht teilweise einfach keine Ausgaben. Apache und PHP installiere ich mit Xampp, in CygWin hat das nicht geklappt. Ansonsten bin ich mit CygWin sehr zufrieden. Komme damit besser klar, als mit dem Linux Subsystem von Windows.
Dr. Sommer schrieb: > Holm T. schrieb: >> Die Makefiles sind für mich. Kunde wünscht auf seinem Windows mal was >> frickeln zu können. Es gibt keinen "Jeder". > > Und der Kunde muss auch hochladen können? Nein. > > Holm T. schrieb: >> bezahlst Du mich dafür das beim Kunden zum Laufen zu bekommen? > > Wieso ich? Du hast doch Sonderwünsche. Nein. Ich habe angemerkt das ich ändern müssen werde, Du fragtest was ich den so für komplizierte Dinge machen würde und ich habs erklärt. Gruß, Holm
Stefanus F. schrieb: > Für hat es sich bewährt, unter Windows CygWin zu installieren und dann > dort alle weiteren Kommandos (make, curl, usw). Ausnahmen: > > MySQL und MariaDB installieren ich als reguläres Windows Programm. > Achtung: Der Windows Client von MySQL funktioniert in der CygWin Shell > nicht richtig. Man sieht teilweise einfach keine Ausgaben. > > Apache und PHP installiere ich mit Xampp, in CygWin hat das nicht > geklappt. > > Ansonsten bin ich mit CygWin sehr zufrieden. Komme damit besser klar, > als mit dem Linux Subsystem von Windows. Ich würde das evtl. genauso machen wie Du, aber ich bin in FG, der Kunde in H. Ich werde nicht verlangen das der cygwin installiert und das Environment anpaßt. Gruß, Holm
Würde ich an deiner Stelle auch nicht tun. Du kannst ja alle (oder einige) Unterprogramme, die mit make aufgerufen werden, zusammen mit dem Quelltext mitliefern, in einem Ordner build-tools. Man muss sie ja nicht unbedingt mit einem Installer installieren.
Stefanus F. schrieb: > Du kannst ja alle (oder > einige) Unterprogramme, die mit make aufgerufen werden, zusammen mit dem > Quelltext mitliefern, in einem Ordner build-tools. Man muss sie ja nicht > unbedingt mit einem Installer installieren. Dann sind sie aber nicht im Pfad was bedeutet daß zusätzliches Gefrickel allein dafür nötig wird das (temporär oder permanent) zu beheben. Es hat schon seinen Grund warum ernsthafte Softwareentwicklung nicht auf Windows stattfindet, weil selbst die simpelsten Sachen dort ein nicht enden wollendes Gefrickel heraufbeschwören welches seinerseits noch mehr Gefrickel heraufbeschwört etc. Dieser ganze Thread hier gibt Zeugnis davon.
:
Bearbeitet durch User
Bernd K. schrieb: > Dann sind sie aber nicht im Pfad Entschuldige, aber wer damit ein Problem hat, sollte seine Zeit weder mit Softwareentwicklung noch mit Systemadministration vergeuden.
Stefanus F. schrieb: > Bernd K. schrieb: >> Dann sind sie aber nicht im Pfad > > Entschuldige, aber wer damit ein Problem hat, sollte seine Zeit weder > mit Softwareentwicklung noch mit Systemadministration vergeuden. Das sehe ich nicht so und zwar genau deshalb weil die Entwicklung der Software und die Bekämpfung unangenehmer Windows-Befindlichkeiten 2 verschiedene Dinge sind. Klar geht das, aber ich habe i.A. Anderes zu tun als Zeit auf Nebenschauplätzen zu verplempern. Gruß, Holm
Bernd K. schrieb: > Dann sind sie aber nicht im Pfad was bedeutet daß zusätzliches Gefrickel > allein dafür nötig wird das (temporär oder permanent) zu beheben. Es hat > schon seinen Grund warum ernsthafte Softwareentwicklung nicht auf > Windows stattfindet, weil selbst die simpelsten Sachen dort ein nicht > enden wollendes Gefrickel heraufbeschwören welches seinerseits noch mehr > Gefrickel heraufbeschwört etc. Dieser ganze Thread hier gibt Zeugnis > davon. Ich frage mich wieso das alle Welt so verkompliziert. Bei mir reicht ein einfaches build.bat da wo das Projekt übersetzt werden soll: PATH=i:\gnuarm\bin;i:\tools;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\sy stem32\WBEM; make -j4 i:\gnuarm ist der Compiler hier für cortexe und i:\tools alles das was ich an bin-Utilities (make u.s.w) brauche. Da muss nichts in Windows installiert sein und ein ellenlanger Pfad ist nur eine Fehlerquelle. Im übrigen stimme ich Stefanus F. zu, wer solche trivialen Sachen nicht hinbekommt sollte lieber Brötchen verkaufen aber nicht hier rumjammern.
temp schrieb: > Ich frage mich wieso das alle Welt so verkompliziert. Bei mir reicht ein > einfaches build.bat da wo das Projekt übersetzt werden soll: > > PATH=i:\gnuarm\bin;i:\tools;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\sy > stem32\WBEM; > make -j4 Also MAXIMAL umständlich, redundant, fragil und unportabel. Ist das die Art wie sich Windowser vorstellen daß etwas vernünftig funktionieren soll? Ich fürchte die Antwort lautet "Ja". Das deckt sich mit meinen Beobachtungen. Einfach nur traurig soviel Elend sehen zu müssen ohne Chance auf Besserung.
:
Bearbeitet durch User
Bernd K. schrieb: > Also MAXIMAL umständlich, redundant, fragil und unportabel. Entweder stellt man die Pfade in der Systemsteuerung ein oder man stellt sie in einem Script ein. Irgendwo muss man sie aber einstellen. Du kannst nicht verlangen, dass Windows schon irgendwie ganz automatisch die gerade gewünschte Versionen der Programme auf sämtlichen Speichermedien findet. Und erst Recht kannst du es nicht den Entwicklern der µC Firmware ankreiden, wenn das alles nicht nach Plug&Play so funktioniert, wie du es gerne hättest. Die Welt ist nämlich noch etwas größer, da gibt es mehr als nur DEINE Bedürfnisse.
Stefanus F. schrieb: > Bernd K. schrieb: >> Also MAXIMAL umständlich, redundant, fragil und unportabel. > > Entweder stellt man die Pfade in der Systemsteuerung ein oder man stellt > sie in einem Script ein. Irgendwo muss man sie aber einstellen. Hm... im eigenen .profile? > > Du kannst nicht verlangen, dass Windows schon irgendwie ganz automatisch > die gerade gewünschte Versionen der Programme auf sämtlichen > Speichermedien findet. Von Windows sollte man besser überhaupt nichts verlangen, das ist doch meine Rede. Make und der gcc sind Unix-Tools, kein Wunder also das die da "einfach funktionieren". > Und erst Recht kannst du es nicht den Entwicklern > der µC Firmware ankreiden, wenn das alles nicht nach Plug&Play so > funktioniert, wie du es gerne hättest. ..aber bitte so wie ich es gerne hätte, ich bin der TO... > > Die Welt ist nämlich noch etwas größer, da gibt es mehr als nur DEINE > Bedürfnisse. Du magst Recht haben, aber versuchst Du auch Schrauben mit dem Lötkolben in die Wand zu drehen und kannst nicht verstehen warum Andere das nicht für das Nonplusultra halten? Gruß, Holm
Holm T. schrieb: > Hm... im eigenen .profile? Was natürlich für den oben angenommen Super-DAU viel einfacher zu editieren wäre, als eine mit dem Compiler gelieferte build.bat ;) Man muß Windows nicht mögen, aber wer Kunden hat, die damit arbeiten, muß damit umgehen können. OliveR P.S. Kann Spuren von Ironie enthalten
Holm T. schrieb: > Hm... im eigenen .profile? Das ist für diesen Zweck schlicht und ergreifend Schwachsinn. Bei mir tummeln sich eine ganz Menge verschiedene Versionen des gcc für die unterschiedlichsten Plattformen bzw. mehrerer Versionen für die gleiche Plattform. Wenn ich alle mit einem schönen msi installieren würde, und jede meint im Pfad ganz vorne stehen zu müssen, dann wundert das niemanden wenn keiner mehr durch sieht. Das ist aber unter anderen Betriebsystemen nicht anders. Wenn man für mehrere Compiler-Versionen und mehreren Zielsysteme Programme schreibt, muss man sich schon Gedanken über die Buildumgebung machen. Aber das "Gedanken machen" ist ja heute nicht mehr in Mode.
Holm T. schrieb: > Du magst Recht haben, aber versuchst Du auch Schrauben mit dem > Lötkolben in die Wand zu drehen und kannst nicht verstehen warum > Andere das nicht für das Nonplusultra halten? So ähnliche Dummheiten mache ich auch ab und zu. Irren ist menschlich.
Oliver S. schrieb: > Holm T. schrieb: >> Hm... im eigenen .profile? > > Was natürlich für den oben angenommen Super-DAU viel einfacher zu > editieren wäre, als eine mit dem Compiler gelieferte build.bat ;) > > Man muß Windows nicht mögen, aber wer Kunden hat, die damit arbeiten, > muß damit umgehen können. > > OliveR > P.S. Kann Spuren von Ironie enthalten Du erzählst mir nichts grundsätzlich Neues, siehe Eingangspost. Gruß, Holm
temp schrieb: > Holm T. schrieb: >> Hm... im eigenen .profile? > > Das ist für diesen Zweck schlicht und ergreifend Schwachsinn. Ja klar... > Bei mir > tummeln sich eine ganz Menge verschiedene Versionen des gcc für die > unterschiedlichsten Plattformen bzw. mehrerer Versionen für die gleiche > Plattform. Das tun sie bei mir auch, deshalb brauche ich für die Executables aber nicht unbedingt verschiedene Pfade, für make schon gar nicht. >Wenn ich alle mit einem schönen msi installieren würde, und > jede meint im Pfad ganz vorne stehen zu müssen, dann wundert das > niemanden wenn keiner mehr durch sieht. Das ist aber unter anderen > Betriebsystemen nicht anders. Doch. Du verbreitest Fake-News! msi verhält sich auch meinen FreeBSD vollständig anders. > Wenn man für mehrere Compiler-Versionen > und mehreren Zielsysteme Programme schreibt, muss man sich schon > Gedanken über die Buildumgebung machen. Aber das "Gedanken machen" ist > ja heute nicht mehr in Mode. Zumindest mach ich mir nicht Deine Gedanken, vertraue mir, ist auch besser so. Gruß, Holm
Ach Holm, wie sind wir doch heute wieder auf Krawall gebürstet. Holm T. schrieb: > temp schrieb: >> die nackte avr-Toolchain gibts doch hier: >> >> https://www.microchip.com/mymicrochip/filehandler.aspx?ddocname=en607654 >> >> dazu noch das was ober verlinkt war: >> >> https://github.com/gnu-mcu-eclipse/windows-build-tools/releases >> >> Mehr braucht man doch nicht wenn es nur um das Bilden mit makefiles >> geht. > > ..das sieht gar nicht schlecht aus...gcc ist zwar 5.3.0 aber das sollte > zu verkraften sein. Ich werde es ausprobieren (lassen). > > Gruß und Dank, > > Holm Ich hatte dir versucht zu helfen, aber du bist so was von arrogant und großkotzig dass ich das schon bereue. Holm T. schrieb: > Doch. Du verbreitest Fake-News! msi verhält sich auch meinen FreeBSD > vollständig anders. Hast du nicht oben gesagt das soll für deinen Kunden unter Windows sein? ne,ne Leute gibts....
temp schrieb: > Bei mir > tummeln sich eine ganz Menge verschiedene Versionen des gcc für die > unterschiedlichsten Plattformen bzw. mehrerer Versionen für die gleiche > Plattform. Sollten die sich nicht am Namen unterscheiden lassen? gcc-5 arm-none-eabi-gcc-6 avr-gcc-7 usw.? PS: Ist das schön bei clang... :-)
Dr. Sommer schrieb: > Sollten die sich nicht am Namen unterscheiden lassen? Bei einer Version pro Zielsystem schon. Bei mehreren ist das nicht so eindeutig.
temp schrieb: > Ach Holm, wie sind wir doch heute wieder auf Krawall gebürstet. > > Holm T. schrieb: >> temp schrieb: >>> die nackte avr-Toolchain gibts doch hier: >>> >>> https://www.microchip.com/mymicrochip/filehandler.aspx?ddocname=en607654 >>> >>> dazu noch das was ober verlinkt war: >>> >>> https://github.com/gnu-mcu-eclipse/windows-build-tools/releases >>> >>> Mehr braucht man doch nicht wenn es nur um das Bilden mit makefiles >>> geht. >> >> ..das sieht gar nicht schlecht aus...gcc ist zwar 5.3.0 aber das sollte >> zu verkraften sein. Ich werde es ausprobieren (lassen). >> >> Gruß und Dank, >> >> Holm > > Ich hatte dir versucht zu helfen, aber du bist so was von arrogant und > großkotzig dass ich das schon bereue. Du bist Niemand der in meinem Kopf ein Bild erzeugen würde, Du bist ein durchlaufender Posten. Danke hatte ich schon gesagt. Wenn Du Dankbarkeit für länger möchtest, dann lege Dir einen Namen zu,. und nicht ein extrem temporäres Mnemonik. > > Holm T. schrieb: >> Doch. Du verbreitest Fake-News! msi verhält sich auch meinen FreeBSD >> vollständig anders. > > Hast du nicht oben gesagt das soll für deinen Kunden unter Windows sein? > ne,ne Leute gibts.... Ich zitiere Deinen Schrieb nochmal: >Wenn ich alle mit einem schönen msi installieren würde, und > jede meint im Pfad ganz vorne stehen zu müssen, dann wundert das > niemanden wenn keiner mehr durch sieht. Das ist aber unter anderen > Betriebsystemen nicht anders. Du redest von msi. Gruß, Holm
temp schrieb: > Dr. Sommer schrieb: >> Sollten die sich nicht am Namen unterscheiden lassen? > > Bei einer Version pro Zielsystem schon. Bei mehreren ist das nicht so > eindeutig. ..ergo muß man das Problem beheben. Es gibt 2 Möglichkeiten: 1. die Dinger erhalten aussagekräftige unterschiedliche Namen damit die unterscheidbar werden. 2. man nennt die Alle gcc und richtet jede Menge unterschiedlicher Verzeichnisse ein was jedes Mal zu dem Kuddelmuddel mit den Pfaden führt. Gruß, Holm
Dr. Sommer schrieb: > temp schrieb: >> Bei mir >> tummeln sich eine ganz Menge verschiedene Versionen des gcc für die >> unterschiedlichsten Plattformen bzw. mehrerer Versionen für die gleiche >> Plattform. > > Sollten die sich nicht am Namen unterscheiden lassen? > gcc-5 > arm-none-eabi-gcc-6 > avr-gcc-7 > usw.? > > PS: Ist das schön bei clang... :-) nicht wirklich..die spinnen die Römer..
1 | $ ls /usr/local/bin/clang* |
2 | /usr/local/bin/clang++37 |
3 | /usr/local/bin/clang++39 |
4 | /usr/local/bin/clang++40 |
5 | /usr/local/bin/clang++50 |
6 | /usr/local/bin/clang++60 |
7 | /usr/local/bin/clang-apply-replacements37 |
8 | /usr/local/bin/clang-apply-replacements39 |
9 | /usr/local/bin/clang-apply-replacements40 |
10 | /usr/local/bin/clang-apply-replacements50 |
11 | /usr/local/bin/clang-apply-replacements60 |
12 | /usr/local/bin/clang-change-namespace40 |
13 | /usr/local/bin/clang-change-namespace50 |
14 | /usr/local/bin/clang-change-namespace60 |
15 | /usr/local/bin/clang-check37 |
16 | /usr/local/bin/clang-check39 |
17 | /usr/local/bin/clang-check40 |
18 | /usr/local/bin/clang-check50 |
19 | /usr/local/bin/clang-check60 |
20 | /usr/local/bin/clang-cpp37 |
21 | /usr/local/bin/clang-cpp39 |
22 | /usr/local/bin/clang-cpp40 |
23 | /usr/local/bin/clang-cpp50 |
24 | /usr/local/bin/clang-cpp60 |
25 | /usr/local/bin/clang-format37 |
26 | /usr/local/bin/clang-format39 |
27 | /usr/local/bin/clang-format40 |
28 | /usr/local/bin/clang-format50 |
29 | /usr/local/bin/clang-format60 |
30 | /usr/local/bin/clang-func-mapping60 |
31 | /usr/local/bin/clang-import-test40 |
32 | /usr/local/bin/clang-import-test50 |
33 | /usr/local/bin/clang-import-test60 |
34 | /usr/local/bin/clang-include-fixer39 |
35 | /usr/local/bin/clang-include-fixer40 |
36 | /usr/local/bin/clang-include-fixer50 |
37 | /usr/local/bin/clang-include-fixer60 |
38 | /usr/local/bin/clang-modernize37 |
39 | /usr/local/bin/clang-modernize39 |
40 | /usr/local/bin/clang-modernize40 |
41 | /usr/local/bin/clang-modernize50 |
42 | /usr/local/bin/clang-modernize60 |
43 | /usr/local/bin/clang-offload-bundler40 |
44 | /usr/local/bin/clang-offload-bundler50 |
45 | /usr/local/bin/clang-offload-bundler60 |
46 | /usr/local/bin/clang-query39 |
47 | /usr/local/bin/clang-query40 |
48 | /usr/local/bin/clang-query50 |
49 | /usr/local/bin/clang-query60 |
50 | /usr/local/bin/clang-rename37 |
51 | /usr/local/bin/clang-rename39 |
52 | /usr/local/bin/clang-rename40 |
53 | /usr/local/bin/clang-rename50 |
54 | /usr/local/bin/clang-rename60 |
55 | /usr/local/bin/clang-reorder-fields40 |
56 | /usr/local/bin/clang-reorder-fields50 |
57 | /usr/local/bin/clang-reorder-fields60 |
58 | /usr/local/bin/clang-tblgen37 |
59 | /usr/local/bin/clang-tblgen39 |
60 | /usr/local/bin/clang-tidy37 |
61 | /usr/local/bin/clang-tidy39 |
62 | /usr/local/bin/clang-tidy40 |
63 | /usr/local/bin/clang-tidy50 |
64 | /usr/local/bin/clang-tidy60 |
65 | /usr/local/bin/clang37 |
66 | /usr/local/bin/clang39 |
67 | /usr/local/bin/clang40 |
68 | /usr/local/bin/clang50 |
69 | /usr/local/bin/clang60 |
70 | /usr/local/bin/clangd50 |
71 | /usr/local/bin/clangd60 |
Gruß, Holm
Holm T. schrieb: > nicht wirklich..die spinnen die Römer.. Wieso, von jeder Version eines jeden Tools eine Datei. Soweit beim GCC nicht anders. Warum du die alle installiert hast ist natürlich eine andere Frage. Beim GCC hättest du das jetzt noch für jede Plattform; beim Clang gilt das für alle.
Dr. Sommer schrieb: > Holm T. schrieb: >> nicht wirklich..die spinnen die Römer.. > > Wieso, von jeder Version eines jeden Tools eine Datei. Soweit beim GCC > nicht anders. Warum du die alle installiert hast ist natürlich eine > andere Frage. Beim GCC hättest du das jetzt noch für jede Plattform; > beim Clang gilt das für alle. Clang ist der System C-Compiler von FreeBSD und nicht ich habe all diese Varianten installiert, sondern FreeBSDs Ports System bei der Installation irgendwelcher Pakete weil die diese Versionen in den Abhängigkeiten definiert haben. HTH, Holm
Versuch mal spaßeshalber die alten Versionen zu deinstallieren, vielleicht reicht es den anderen Paketen ja wenn die aktuelle drauf ist.
Ja..ich weiß, dazu muß man aber Zeit und Lust haben. Mich hat aber der Versionswahnsinn auch schon eher angekotzt, da ist nix von wegen "mal schnell einen Port installieren..".. Kaffee trinken reicht da nicht. Gruß, Holm
..war vorige Woche beim Kunden und habe einen avrgcc 5.4.0 und diese build-tools samt libusb-win32/avrdude auf einem Windows8 und testweise zu Hause auf einem Vista zum Laufen bekommen. Bei einem Windwos10 des Kunden stellte sich libUSB/avrdude quer. Ich hatte nicht die Zeit mich bis zur Funktion um diesen Mist zu kümmern (..wer tut sich das freiwillig an?). Ich muß freie Kapazitäten haben, dann ziehe ich mir das evtl. nochmal auf den Tisch. Danke einstweilen, Holm
Holm T. schrieb: > ..war vorige Woche beim Kunden und habe einen avrgcc 5.4.0 und diese > build-tools samt libusb-win32/avrdude auf einem Windows8 und testweise > zu Hause auf einem Vista zum Laufen bekommen. Bei einem Windwos10 des > Kunden Sowas macht man auch nicht beim Kunden. Wenn man dort mit Schweißperlen auf der Stirn anfängt mit irgendwelchen Windows-Treibern und Konfigurationsänderungen auf dessen Windows rumzufrickeln und noch ein halbes Dutzend Abhängigkeiten installieren und konfigurieren muß bis es vielleicht (so ähnlich) funktioniert wie auf dem Entwicklerarbeitsplatz zuhause lässt einen das höchst unprofessionell erscheinen. Das hat man auf seinem Laptop den man mitnimmt wenn man zum Kunden fährt als fertig eingerichtete VM mit allen Tools und Treibern fix und fertig installiert in der alles funktioniert und die man dann binnen weniger Minuten beliebig duplizieren und ganz entspannt dem Kunden aushändigen kann zusammen mit dem Sourcecode, wohlwissend daß alles auf Anhieb sauber funktionieren wird und überhaupt kein Windows-Streß auftreten kann.
Bernd K. schrieb: > wohlwissend daß alles auf Anhieb > sauber funktionieren wird und überhaupt kein Windows-Streß auftreten > kann. Hehe, besonders bei USB-Durchreichung in die VM kann auch überhaupt nichts schiefgehen.
Dr. Sommer schrieb: > Hehe, besonders bei USB-Durchreichung in die VM kann auch überhaupt > nichts schiefgehen. Weniger als mit dem vermurksten AvrISP-Atmel-Treiber-libusb-Filtertreiber-avrdude-Gemurkse auf ner Windows-Büchse die vorher noch nie Atmelstudio gesehen hat auf jeden Fall. Viel weniger.
Bernd K. schrieb: > Viel weniger. So zu hoffen :) Wenn da schon irgendein Treiber drauf ist der sich für das Gerät anmeldet könnte es sein dass die VM da keinen Zugriff drauf bekommt...
Dr. Sommer schrieb: > Wenn da schon irgendein Treiber drauf ist der sich für > das Gerät anmeldet könnte es sein dass die VM da keinen Zugriff drauf > bekommt... Hab ich noch nie erlebt. In Virtualbox setzt man einen Haken dann bekommt der Host das USB-Gerät unter dem Hintern weggezogen (Pling-Plong als ob man es ausgestöpselt hätte) und es erscheint im Gast.
Mit der USB Weiterleitung hatte ich noch nie Probleme, außer in Kombination mit AVR und Atmel Studio. Dann debugge ich halt nicht mehr, avrdude läuft immer. Ich komme notfalls auch mit seriellen Logmeldungen zurecht. Komisch, das das alles bei STM32 kein Problem macht. Eigentlich sind mir die AVRs wegen ihrer geringeren Komplexität und den verständlicheren Datenblättern lieber, aber die anhaltenden Probleme und Kosten mit dem Debugging ist schon ein starkes Argument, zu wechseln.
Bernd K. schrieb: > Holm T. schrieb: >> ..war vorige Woche beim Kunden und habe einen avrgcc 5.4.0 und diese >> build-tools samt libusb-win32/avrdude auf einem Windows8 und testweise >> zu Hause auf einem Vista zum Laufen bekommen. Bei einem Windwos10 des >> Kunden > > Sowas macht man auch nicht beim Kunden. Wenn man dort mit Schweißperlen > auf der Stirn anfängt mit irgendwelchen Windows-Treibern und > Konfigurationsänderungen auf dessen Windows rumzufrickeln und noch ein > halbes Dutzend Abhängigkeiten installieren und konfigurieren muß bis es > vielleicht (so ähnlich) funktioniert wie auf dem Entwicklerarbeitsplatz > zuhause lässt einen das höchst unprofessionell erscheinen. > > Das hat man auf seinem Laptop den man mitnimmt wenn man zum Kunden fährt > als fertig eingerichtete VM mit allen Tools und Treibern fix und fertig > installiert in der alles funktioniert und die man dann binnen weniger > Minuten beliebig duplizieren und ganz entspannt dem Kunden aushändigen > kann zusammen mit dem Sourcecode, wohlwissend daß alles auf Anhieb > sauber funktionieren wird und überhaupt kein Windows-Streß auftreten > kann. ..nein. Ich habe keinen Laptop mit Windows8 oder 10. Da sBenutzen eines Solchen hinterläßt einen sehr unprofessionellen Eindruck beim Kunden, u.A. weil dessen Daten dann auch bei Microsoft und der NSA sind. Gruß, Holm
Dr. Sommer schrieb: > Bernd K. schrieb: >> Viel weniger. > > So zu hoffen :) Wenn da schon irgendein Treiber drauf ist der sich für > das Gerät anmeldet könnte es sein dass die VM da keinen Zugriff drauf > bekommt... Kann es vielleicht sein das dieses Betriebssystem einfach für die Aufgabe nicht geeignet ist? Gruß, Holm
Holm T. schrieb: > Ich habe keinen Laptop mit Windows 8 oder 10. Das Benutzen eines > Solchen hinterläßt einen sehr unprofessionellen Eindruck beim Kunden, > u.A. weil dessen Daten dann auch bei Microsoft und der NSA sind. Nach diesem Kommentar bin ich endgültig der Meinung, dass jede weitere Hilfestellung oder der Versuch von Hilfe vergeudete Zeit ist. Ich verfolge das Thema ja schon länger und bin zum Schluss gekommen, das der Holm sich selbst blockiert. Egal, was wir ihm vorschlagen, es ist ihm alles nicht gut genug.
Stefanus F. schrieb: > Holm T. schrieb: >> Ich habe keinen Laptop mit Windows 8 oder 10. Das Benutzen eines >> Solchen hinterläßt einen sehr unprofessionellen Eindruck beim Kunden, >> u.A. weil dessen Daten dann auch bei Microsoft und der NSA sind. > > Nach diesem Kommentar bin ich endgültig der Meinung, dass jede weitere > Hilfestellung oder der Versuch von Hilfe vergeudete Zeit ist. Genau..zumal die "Fertigmeldung" von mir ja schon weiter oben kam.. > > Ich verfolge das Thema ja schon länger und bin zum Schluss gekommen, das > der Holm sich selbst blockiert. Egal, was wir ihm vorschlagen, es ist > ihm alles nicht gut genug. :-) Ich blockiere mich selbst? Vergiß es. Ich gehöre simpel zur selten werdenden Spezies der selbständig denken Könnenden.. dadurch kommt es ab und an vor das ich zu Ergebnissen komme, die Andere einfach nicht wahr haben wollen. (Du kennst das mit den Milliarden Fliegen..) Was ist los Stefan? Hast Du den Mist selber geschrieben oder was? ...warum mußt Du das Zeuch dann unter allen Umständen verteidigen? Gruß, Holm
Holm T. schrieb: >> Das hat man auf seinem Laptop den man mitnimmt wenn man zum Kunden fährt >> als fertig eingerichtete VM > ..nein. Ich habe keinen Laptop mit Windows8 oder 10. Wo schrieb ich was von Windows auf dem Laptop? Lesebrille verlegt und stattdessen anhand der Grauabstufungen den Text versucht zu entziffern oder was?
:
Bearbeitet durch User
Bei mir installierte ich Mint in einer VM. Damit kompiliere ich mittels make AVR Projekte mit makefile. Als Beipiel führe ich zur Zeit Custom Bootloader für Arduino an. Das funktioniert total problemlos. Da die AVR Toolchain durch vorherige Linux Arduino schon fix und fertig installiert war, mußte ich mich nicht darum kümmern. Die Mint schläft bei mir im gebooteten Zustand in der VM. Das einzige Manko ist, daß ich bei jedem Gebrauch von Mint das Datum neu eingeben muß weil im Augenblick NTP update nicht funktioniert und es beim compilieren ohne diese Korrektur einen Clock skew Fehler gibt. Wie gesagt für das ab und zu kompilieren mottels make, gebügt mir das vollständig. Die Sourcen jommen einfach auf einen USB Memory Stick der dann ohne Probleme von Mint montiert wird.
Bernd K. schrieb: > Holm T. schrieb: >>> Das hat man auf seinem Laptop den man mitnimmt wenn man zum Kunden fährt >>> als fertig eingerichtete VM > >> ..nein. Ich habe keinen Laptop mit Windows8 oder 10. > > Wo schrieb ich was von Windows auf dem Laptop? Lesebrille verlegt und > stattdessen anhand der Grauabstufungen den Text versucht zu entziffern > oder was? Wo ist der Unterschied betreffs der Daten bei Microsoft oder NSA zwischen Windows auf dem Toplappen oder in der VM? Gruß, Holm
Gerhard O. schrieb: > Bei mir installierte ich Mint in einer VM. Damit kompiliere ich mittels > make AVR Projekte mit makefile. Als Beipiel führe ich zur Zeit Custom > Bootloader für Arduino an. Das funktioniert total problemlos. Da die AVR > Toolchain durch vorherige Linux Arduino schon fix und fertig installiert > war, mußte ich mich nicht darum kümmern. > > Die Mint schläft bei mir im gebooteten Zustand in der VM. Das einzige > Manko ist, daß ich bei jedem Gebrauch von Mint das Datum neu eingeben > muß weil im Augenblick NTP update nicht funktioniert und es beim > compilieren ohne diese Korrektur einen Clock skew Fehler gibt. Also Läuft Linux Mint bei Dir problemlos. Bleibt die Frage warum man das dann in einer VM betrieben sollte.. > > Wie gesagt für das ab und zu kompilieren mottels make, gebügt mir das > vollständig. > > Die Sourcen jommen einfach auf einen USB Memory Stick der dann ohne > Probleme von Mint montiert wird. ..ups? Was hast Du zwischen 1. und 2. Textteil geraucht? :-) Gruß, Holm
Hallo Holm, Holm T. schrieb: > Gerhard O. schrieb: >> Bei mir installierte ich Mint in einer VM. Damit kompiliere ich mittels >> make AVR Projekte mit makefile. Als Beipiel führe ich zur Zeit Custom >> Bootloader für Arduino an. Das funktioniert total problemlos. Da die AVR >> Toolchain durch vorherige Linux Arduino schon fix und fertig installiert >> war, mußte ich mich nicht darum kümmern. >> >> Die Mint schläft bei mir im gebooteten Zustand in der VM. Das einzige >> Manko ist, daß ich bei jedem Gebrauch von Mint das Datum neu eingeben >> muß weil im Augenblick NTP update nicht funktioniert und es beim >> compilieren ohne diese Korrektur einen Clock skew Fehler gibt. > > Also Läuft Linux Mint bei Dir problemlos. Bleibt die Frage warum man das > dann in einer VM betrieben sollte.. Bei mir ist W7 König. Mint verwende ich nur ab und zu für Spezialzwecke. Deshalb ist ein VM Betrieb nützlich um gleichzeitig in beiden BSen operieren zu können. Ich wollte mir Optiboot Bootloader für 1-4Mhz machen und das geht in W7 angeblich sauschlecht. In Linux geht das problemlos. >> >> Wie gesagt für das ab und zu kompilieren mottels make, gebügt mir das >> vollständig. >> >> Die Sourcen jommen einfach auf einen USB Memory Stick der dann ohne >> Probleme von Mint montiert wird. > > ..ups? Was hast Du zwischen 1. und 2. Textteil geraucht? Da schiebe ich die Schuld auf die iPad Softtastatur. Manchmal tippe ich daneben und merke es nicht gleich. Zum Nachlesen hatte ich keine Gelegenheit mehr weil ich gleich darauf einen langen Tel. anruf bekam der mich aufhielt und danach die Editmöglichkeit um drei Minuten vorüber war. Ich bin unschuldig! Das nur, falls Du mir zufäääällig unterstellen willst, daß ich in den frisch legalisierten Gefielden des "Unkrauts" mein Unweisen treibe:-) Gruß, Gerhard > > :-) > > Gruß, > > Holm
:
Bearbeitet durch User
Holm T. schrieb: > Wo ist der Unterschied betreffs der Daten bei Microsoft oder NSA > zwischen Windows auf dem Toplappen oder in der VM? Wo schrieb ich was von Windows in der VM? Was hast Du immerzu mit Deinem Windows? Wozu soll das überhaupt gut sein, das ist doch nur hinderlich?
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte 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.