Hi, bisher habe ich mir das Leben einfach gemacht und bin mit der veralteten WINAVR2010 ausgekommen. Doch nun will/musste ich auch auf Windows 10 wechseln und durchforste das Internet nach dem bekannten makefile Fehler, der bei MIR NICHT durch das Ersetzen der "msys-1.0.dll" in WINAVR gelöst werden konnte. Daher meine Frage: Wie und woher erhalte ich eine ständig aktuelle Toolchain, die ich mit dem Eclipse ARV-Plugin einbinden kann? Alternative Nr 1: https://infernoembedded.com/products/avr-tools/release ist auch bereits von 2013, von wann ist der aktuellste gcc? Also dachte ich mir Alternative Nr 2: Selber bauen mit Cygwin. Doch leider kam ich mit folgenden (veralteten) Tutorials nicht auf einen grünen Zweig: http://preshing.com/20141108/how-to-install-the-latest-gcc-on-windows/ (soweit einfach) Beitrag "Update von Winavr2010 auf gcc 4.8 Howto" http://andybrown.me.uk/2012/04/28/avr-gcc-4-7-0-and-avr-libc-1-8-0-compiled-for-windows/ http://andybrown.me.uk/2015/03/08/avr-gcc-492/ Hat Jemand infos für mich Parat? Grüße Oekel PS: Wir sollten dann auch das Wiki entsprechend erweitern, denn an Windows 10 werden wir wohl dauerhaft nicht ohne Linux vorbei kommen.
Hallo, wenn du ein Linux hast oder dir ein in einer virtuellen Maschine einrichtest kannst du dir hiermit relativ schnell und einfach den aktuellsten AVR-GCC bauen: https://www.mikrocontroller.net/articles/AVR-GCC#Selbst_bauen Beachte dabei auch diesen Thread: Beitrag "avr-gcc 6.1 unter Windows" mfG N.G.
?? Wo ist das Problem an der AVR-GCC toolchain von Atmel? (Außer, dass sie nicht ganz so aktuell ist wie Studio 7)
Gast
#4596546
avr-gcc-6-1-0 von ***************************************** http://blog.zakkemble.co.uk/avr-gcc-6-1-0/ ***************************************** lässt sich problemlos in AtmelStudio 6.2 integrieren. avr-gcc-6-1-0 in separates Verzeichnis abspeichern. Unter Projekteigenschaften->Advanced den vorbereiteten Link wählen: "Tools->Options>->Toolchain->Flavour" Unter Toolchain: [Atmel AVR 8-Bit C oder CPP] auswählen. Mit [Add Flavour] einen Namen und den Pfad eintragen. Unter Projekteigenschaften Advanced Toolchain Flavour: die neue [Toolchain] auswählen.
Gast
#4752329
Das Problem an Atmels Toolchain ist, dass da die make.exe fehlt. Und auch bei dieser Alternative fehlt die make.exe. Ich brauche eine AVR Toolchain mit Make für Windows 10! Wo kann ich sie finden?
Gast
#4752343
Stefan U. schrieb: > Ich brauche eine AVR Toolchain mit Make für Windows 10! Wo kann ich sie > finden? Kann man nicht irgendein (gnu-)make nehmen das auf W10 läuft und das mit einer avr-toolchain nach gusto kombinieren?
Gibt es nicht als Rundum-Sorglos-Paket. Besorg dir halt irgend ein gnu-make aus irgend einer toolchain, welches unter Windows 10 läuft, und dazu den dir am genehmsten erscheinenden avr-gcc mit Zubehör. Eclipse und auch dem avr-gcc ist die Herkunft und auch Alter des make ziemlich egal, es sollte halt keine uralt-Vwrsion sein. Oliver
Gast
#4752367
Eine dauerhaft aktuelle Toolchain bekommst Du, indem Du den Compiler benutzt und sonst gar nichts. Keine IDE. Und auch kein Make, sondern Buildscripte/Batchdateien. Mikrocontroller sind eh so klein, daß nur recht kleine Programme draufpassen, so daß man auch einfach das Projekt bei jedem Build komplett übersetzen kann.
Gast
#4752394
> Kann man nicht irgendein (gnu-)make nehmen das auf W10 läuft > und das mit einer avr-toolchain nach gusto kombinieren? Das dachte ich auch. Aber ich habe keinen Download gefunden. Nur eine uralte Version aus dem Jahr 2006, die ich nicht einmal starten kann. Ich muss doch nicht etwa CygWin oder Qt Creator installieren, nur um an eine funktionierende make.exe zu kommen, oder doch? > Eine dauerhaft aktuelle Toolchain bekommst Du, > indem Du den Compiler benutzt und sonst gar nichts. Tja, die Toolchain von Atmel hat bei mir schon mehrfach kaputte Programme erzeugt (je nach Version). Dann haben sie avrdude weg gelassen und jetzt fehlt auch noch make. Was kommt als Nächstes? Ich will dieses Atmel Studio nicht benutzen, denn dann müsste ich einen neuen viel teureren Computer kaufen und habe dann kein Geld mehr für Bauteile. Nun soll ich also Shell-Scripte für Linux und Batch-Dateien für Windows nutzen? Nein, so gefällt mir das nicht.
Stefan U. schrieb: > Nun soll ich also Shell-Scripte für Linux und Batch-Dateien für Windows > nutzen? Nein, so gefällt mir das nicht. Musst du auch nicht. Die Antwort von Nop ist nämlich ... nicht so richtig. Nop schrieb: > Eine dauerhaft aktuelle Toolchain bekommst Du, indem Du den Compiler > benutzt und sonst gar nichts. Keine IDE. Und auch kein Make, sondern > Buildscripte/Batchdateien. Was hat die IDE mit dem im Hintergrund werkelnden Compiler zu tun? Ich kann mir (wenn ich so schmerzbefreit wär) auch jeden Tag einen neuen gcc aus den Sourcen bauen und diese Tagesaktuelle Toolchain mit einer Uraltversion von Windows notepad.exe benutzen. Selbiges gilt für make: seit wann interessiert sich make für die Compilerversion? Wo du denn nun ein aktuelles make herbekommst kann ich dir nicht sagen. Cygwin willst du nicht? Ansonsten kannst du doch das make aus WINAVR2010 benutzen, aber einen aktuelleren avr-gcc benutzen?
Gast
#4752478
Le X. schrieb: > Was hat die IDE mit dem im Hintergrund werkelnden Compiler zu tun? Sie ruft ihn auf, nehme ich mal an. Der wesentliche Unterschied ist, daß der Compiler ein Commandline-Tool ist. Folglich hat man damit nicht so die üblichen Windowsprobleme nach Wechsel der Windowsversion. > Selbiges gilt für make: seit wann interessiert sich make für die > Compilerversion? Das ist nicht das Problem. Das Problem ist: > Wo du denn nun ein aktuelles make herbekommst kann ich dir nicht sagen. Und dieses Problem hat man nicht, wenn man make nicht verwendet, sondern sich einfach eine Batchdatei/Shellscript baut.
Gast
#4752497
> Wo du denn nun ein aktuelles make her bekommst kann ich dir nicht sagen. > Cygwin willst du nicht? Ich mag Cygwin und nutze es selbst täglich. Ich möchte aber nicht die Nachahmer meiner Projekte dazu drängen. Denn die meisten haben keine Ahnung von Linux und dann kommen Fragen auf, die ich vermeiden möchte. > Ansonsten kannst du doch das make aus WINAVR2010 benutzen, > aber einen aktuelleren avr-gcc benutzen? Schön, wenn es so wäre. Aber dieses make scheitert schon am "rm" Befehl seit Windows 10.
Gast
#4752566
Stefan U. schrieb: > Schön, wenn es so wäre. Aber dieses make scheitert schon am "rm" Befehl > seit Windows 10. Es ist ja auch kein rm in make eingebaut. Da musst du schon ein rm bereitstellen.
Gast
#4752597
Ich benutze die GNU ARM Eclipse Windows Build Tools um die passenden Tools für eine gcc tool chain unter Windows zu haben: https://github.com/gnuarmeclipse/windows-build-tools/releases Das enthält ein funktionierendes make, rm und eine Shell (sh). Die Tools sind auch recht aktuell und benötigen kein Cygwin. Der Download ist zwar ein Installer, aber ich extrahiere einfach die Tools mit 7-Zip ohne Installation und kopiere die Programme in ein Verzeichnis, das sich im Pfad befindet.
Gast
#4752600
Was spricht dagegen, das AVR-gcc-Backend aus dem Arduino-Projekt zu nehmen und make aus MinGW? MinGW hat den Vorteil, dass man nicht auf Cygwin angewiesen ist. Cygwin hat zwar viele Vorteile, aber nur wegen make ist es etwas Overkill. Den Rest von MinGW kann man ja wieder entsorgen, wenn nur die make.exe (konkret die mingw32-make.exe) nötig ist.
Gast
#4752606
ich nehme die win32 binaries immer von hier: http://gnuwin32.sourceforge.net/downlinks/make-bin-zip.php http://gnuwin32.sourceforge.net/downlinks/coreutils-bin-zip.php http://gnuwin32.sourceforge.net/downlinks/coreutils-dep-zip.php damit gehen meine makefile unter w10. Was hast du denn für ein Problem mit make?
Gast
#4752623
Stefan U. schrieb: > Tja, die Toolchain von Atmel hat bei mir schon mehrfach kaputte > Programme erzeugt (je nach Version). Dann haben sie avrdude weg gelassen > und jetzt fehlt auch noch make. Was kommt als Nächstes? Vielleicht will ja Atmel aka Microchip dir den Atmel madig machen. Weil PIC wohl doch der bessere Microcontroller ist ;)
Gast
#4752661
SF schrieb: > ch benutze die GNU ARM Eclipse Windows Build Tools um die passenden > Tools für eine gcc tool chain unter Windows zu haben: > > https://github.com/gnuarmeclipse/windows-build-tools/releases Danke für den Tip. Sieht auch sehr gut aus. Das besteht ja eigentlich nur aus busybox und make. Fehlende Kommandos aus der Liste: [, [[, ar, ash, awk, base64, basename, bash, bbconfig, bunzip2, bzcat, bzip2, cal, cat, catv, chmod, cksum, clear, cmp, comm, cp, cpio, cut, date, dc, dd, df, diff, dirname, dos2unix, dpkg-deb, du, echo, ed, egrep, env, expand, expr, false, fgrep, find, fold, ftpget, ftpput, getopt, grep, groups, gunzip, gzip, hd, head, hexdump, id, ipcalc, kill, killall, logname, ls, lzcat, lzma, lzop, lzopcat, man, md5sum, mkdir, mktemp, mv, nc, od, patch, pgrep, pidof, printenv, printf, ps, pwd, rev, rm, rmdir, rpm2cpio, sed, seq, sh, sha1sum, sha256sum, sha3sum, sha512sum, shuf, sleep, sort, split, stat, strings, sum, tac, tail, tar, tee, test, touch, tr, true, truncate, uname, uncompress, unexpand, uniq, unix2dos, unlink, unlzma, unlzop, unxz, unzip, usleep, uudecode, uuencode, vi, wc, wget, which, whoami, xargs, xz, xzcat, yes, zcat kriegt man durch einfaches Kopieren. Oder man definiert es gleich im Makefile z.B. "MKDIR=busybox mkdir", dann spart man sich das Kopieren.
Gast
#4752705
> Schön, wenn es so wäre. Aber dieses make scheitert schon am "rm" Befehl > seit Windows 10. > Was hast du denn für ein Problem mit make? Make kann rm nicht ausführen. Das Programm bricht mit einer nichtssagenden Fehlermeldung ab, in der nur ein Hex-Code steht. Danach Googeln hat mich nicht weiter gebracht. Bei anderen Leuten scheitert es an anderen Unterprogrammen, zum Beispiel objcopy oder sh. Die Programme sind da und ich kann sie manuell in der cmd Shell ausführen. Aber nicht aus einem Makefile heraus. Die Version auf der gnuwin32 Seite ist von 2006, also noch älter als WinAVR und ich kann sie auf meinem Laptop gar nicht starten. Ich habe die Fehlermeldung gerade nicht im Kopf. > Es ist ja auch kein rm in make eingebaut. Da musst du schon ein rm > bereitstellen. Das ist mir schon klar. Der Tip mit der GNU Arm Eclipse Toolchain sieht vielversprechend aus. Allerdings finde ich es ehrlich gesagt unschön, wenn man sich die Binaries alle einzeln zusammen suchen muss. WinAVR war genau richtig, ist nur leider nicht mehr weiter gepflegt worden.
Gast
#4752716
> Wo ist das Problem an der AVR-GCC toolchain von Atmel?
Das darin make und avrdude fehlen.
Stefan U. schrieb: > Ich muss doch nicht etwa CygWin Musst Du nicht, ist aber auf lange Sicht empfehlenswert, da kommen auch andere schöne Goodies mit wie zum Beispiel ein funktionierendes Konsolenfenster, eine Shell, alle Kommandozeilentools wie sie in *nix üblich sind, es ermöglicht ohne Klimmzüge die selben Scripte und Makefiles die unter *ix laufen unverändert auch unter Windows zu verwenden sobald sie mal etwas umfangreicher werden und so Sachen wie mkdir und rm drin vorkommen sollen. Seit ich in der Firma auf allen Windows Arbeitsplätzen auf denen mit gcc entwickelt werden soll ein vorhandenes Cygwin als Grundsystem voraussetze bin ich alle Sorgen los, alles ist auf allen Maschinen einheitlich und einfacher aufzusetzen und zu pflegen als das manuelle Zusammenklauben einzelner Tools aus verschiedenen Quellen und händisches Pfadgefrickel ist es allemal.
Gast
#4752786
Wem sagst du das? Cygwin ist ein tägliches Arbeitsmittel für mich. Aber sage mal einem durchschnittlichen Windows Benutzer, dass er so etwas ähnliches wie einen Linux Emulator installieren soll, damit er ein klitzekleines Programm auf den ATtiny laden kann. Selbst wenn es der einfachste und schnellste Weg ist, man muss dann immer wieder den Linux Prediger raushängen lassen, und das tue ich nicht so gerne. Der einfachste Weg ist tatsächlich, Linux zu verwenden. Mir muss das niemand erklären.
Stefan U. schrieb: > Selbst wenn es der einfachste und schnellste Weg ist, man muss dann > immer wieder den Linux Prediger raushängen lassen, Du musst doch nicht predigen bei der Installation. Die Installation ist eine Sammlung von Softwaretools die benötigt werden mit einem Installer der das alles schön installiert, Punkt. Wozu über Betriebssysteme predigen, hat doch mit Betriebssystemen gar nix zu tun? Und mit Linux schon dreimal nicht.
Stefan U. schrieb: >> Wo ist das Problem an der AVR-GCC toolchain von Atmel? > > Das darin make und avrdude fehlen. Ich habe mir die Atmel-Toolchain installiert und das neueste Avrdude auch in das bin Directory kopiert. Make + andere Tools aus dem Utils-Verzeivhnis von WinAVR-Version dahin kopiert. Läuft ohne Probleme unter W8.1, 64bit.
Gast
#4752997
Ich kann mich erinnern, dass das alte make ein Problem mit sh.exe hat. Das ist aber für make in den meisten Fällen nicht nötig. Bei mir hat damals geholfen sh.exe umzubenennen. Oft ist die einzige Stelle wo make eine sh.exe braucht ein Konstrukt wie das hier: -include $(shell mkdir .dep 2>/dev/null) $(wildcard .dep/*) das sollte aber auch anders zu lösen sein.
Gast
#4753015
> Die Installation ist eine Sammlung von Softwaretools die > benötigt werden mit einem Installer > der das alles schön installiert, Punkt. Das wäre schön. Aber leider ist es seit Windows 8 nicht mehr so einfach. Mein Szenario ist: Ich werde beauftragt Firmware für AVR Mikrocontroller zu schreiben. Die Kunden wollen die Lieferung in Quelltext-Form bekommen, für Windows Arbeitsplätze unterschiedlicher Version. Sie wollten selbst compilieren und flashen. Das ist kein erfundenes Szenario, sondern realität. Ich hatte noch nicht viele Aufträge (6, falls ich mich recht erinnere) aber alle hatten diese Anforderung und die kamen von 5 unterschiedlichen Auftraggebern. Bisher ging es immer um Windows XP bis Windows 7. Windows 8 konnte ich vor einem Jahr noch als "zu neu" ablehnen. Das geht jetzt aber nicht mehr. Ich sehe momentan 4 Alternativen: 1) Atmel Studio installieren. Ist aber gewaltig viel, nur um mal eben ein eigentlich fertiges Programm zu compilieren. 2) WinAVR. Da muss man nach der Installation die msys-1.0.dll, avrdude und die libusb auswechseln. Das verunsichert den Kunden möglicherweise, er könnte es für gefrickel halten. Vor allem, weil die Herkunft dieser dll unbekannt ist. 3) Atmel Toolchain + CygWin. Wenn ich den Kunden auffordere, CygWin zu installieren, komme ich in Erklärungsnot. Denn er hat im Auftrag geschrieben, dass die Software unter Windows laufen soll und CygWin sieht für ihn wie ein Linux Emulator aus. 4) Eine ARM Toolchain installieren um "make" zu erhalten und mit der Atmel AVR Toolchain kombinieren. Auch das dürfte Misstrauen erwecken. Warum sollte der Kunde Software für ARM installieren? Die Sache mit der Treibersignatur für USB Programmer ist auch nicht gerade hilfreich, den Eindruck von "gefrickel" zu zu verhindern. Eigentlich brauchen wir eine aktuelle Variante von WinAVR. Dann hätten wir wieder "einen Installer der das alles schön installiert". Danach suche ich.
Gast
#4753018
> Make + andere Tools aus dem Utils-Verzeivhnis von WinAVR-Version > dahin kopiert. Läuft ohne Probleme unter W8.1, 64bit. Hast du mal einen rm Befehl im Makefile probiert? Oder irgend einen anderen Shell-Befehl? Da wird es dann spannend.
Gast
#4753044
Langsam wird es albern. Du willst mit freien Tools Geld verdienen und beschwerst dich dass die nicht das machen was du willst? Wir haben dir ein paar Möglichkeiten gezeigt wie es geht und wie wir es machen, jeder auf seine Art. Wenn du was für die Kunden willst, dann stell es so zusammen dass es passt. Dazu muss genau nichts "installiert" werden. Ein einfaches Kopieren in ein Verzeichnis reicht. Das kannst du dann deinen Kunden mitgeben und eine Info woher die binaries stammen. Damit stellst du auch sicher, dass alles auf den Systemen läuft die du dafür vor siehst, unabhängig davon wie die Entwicklung der Tools weiter geht. Aber machen musst du das schon selbst. Natürlich helfen wir hier gern wenn es um konkrete Probleme geht. Dann bitte aber das Problem auch konkret beschreiben.
temp schrieb: > Wenn du was für die Kunden willst, dann stell es so zusammen dass es > passt. Dazu muss genau nichts "installiert" werden. Ein einfaches > Kopieren in ein Verzeichnis reicht. Genau das hätte ich jetzt auch geschrieben. Eine eigene Installation in einem Ordner zusammenstellen. Genau diese dem Kunden geben. Oder mit mehreren Ordnern und einen eigenen Installer schreiben. Sebst entpackendes ZIP tut es da ja auch schon. Ansonsten Atmel-Studio oder auch IAR kaufen. Sollte bei einem Auftrag drin sein. Jetzt mach dir eine Tabelle und schreibe für und wider der einzelnen Möglichkeiten auf und entscheide, was der beste Kompromiss ist.
Stefan U. schrieb: > dass die Software unter Windows laufen soll und CygWin sieht für ihn wie > ein Linux Emulator aus. Cygwin läuft unter Windows. Auftrag erfüllt. Ich verstehe nicht wo das Problem sein soll.
Stefan U. schrieb: > Hast du mal einen rm Befehl im Makefile probiert? Oder irgend einen > anderen Shell-Befehl? Da wird es dann spannend. Du hast dir den Utils-Order von WinAVR überhaupt nicht angesehen!! DAS finde ich spannend.
Stefan U. schrieb: > Ich sehe momentan 4 Alternativen: Es gibt nur eine Alternative: such dir einen anderen Job. Das, was du da zu machen versuchst, übersteigt deine Fähigkeiten. Und ganz ehrlich, ein "Kunde", der selber die Sourcen kompilieren und Flaschen will, aber zu blöd ist, sich die passende toolchain zu besorgen, ist genauso überfordert. Das einzige, was der hinbekommt, ist doch, in den Sourcen Chaos anzurichten. Mein Vorschlag zur Güte: Steig auf Bascom um. Da gibt's alles im Paket. Oliver
900ss D. schrieb: > Du hast dir den Utils-Order von WinAVR überhaupt nicht angesehen!! Also gut, rm und andere Shell-Kommandos sind im Ordner utils/bin enthalten und funktionieren. Versuch macht klug.
Gast
#4753240
> Du hast dir den Utils-Order von WinAVR überhaupt nicht angesehen!! Doch, das habe ich. Ich kann all diese Programme einzeln im cmd Fenster ausführen, jedoch nicht aus einem Makefile heraus aufrufen. Es geht nicht darum, dass er die Dateien nicht findet. Nein, sie fallen beim Start auf die Nase! Es erscheint nur ein Fehlercode: 0xC0000142 Ich bin da nicht der Einzige, das Thema wurde sowohl hier als auch in Arduino Foren als auch in Microsoft Support-Foren diskutiert. Es betrifft nicht nur make, sondern auch andere Programme. Manchen Leuten half ein Austausch der Datei msys-1.0.dll, aber nicht allen. Ich suche nach einer zuverlässigen Lösung. > Und ganz ehrlich, ein "Kunde", der selber die Sourcen kompilieren > und Flaschen will, aber zu blöd ist, sich die passende toolchain zu > besorgen, ist genauso überfordert. Sagst du das demjenigen, der dein täglich Brot bezahlt?
D a v i d K. schrieb: > Doch nun will/musste ich auch auf Windows 10 wechseln und durchforste > das Internet nach dem bekannten makefile Fehler Welcher Fehler ist das denn? Ich benutze auch noch den WINAVR, er tut das, was er soll. Ein Make ist mir aber zu kompliziert, daher habe ich ne einfache Batch geschrieben. Mit *.c als Sourcefile compiliert der GCC alle *.c im aktuellen Projektordner, mehr brauche ich nicht. Beim Entwickeln starte ich in der Batch oft gleich die STK500.exe zum Brennen in den Chip.
Gast
#4753249
> such dir einen anderen Job. Das, was du da > zu machen versuchst, übersteigt deine Fähigkeiten. Nun übertreibe mal nicht. Du hast doch meine Auflistung mit 4 Alternativen gelesen, mit denen ich zurecht komme. Wie gesagt ICH komme zurecht, nur meine Kunden sind unzufrieden. Die, die ich zufrieden stellen muss, weil sie das Geld haben dass ich bekommen will. > Welcher Fehler ist das denn? Es erscheint Fehlercode 0xC0000142, wenn make Unterprogramme aus dem utils Verzeichnis aufruft (zum Beispiel rm).
Gast
#4753264
Da du ja nicht auf unsere Vorschläge eingehen willst habe ich jetzt mal die utils/bin eines frisch geladenen winavr probiert. Es ist so wie ich es oben schrieb. Das Problem ist sh.exe. Wenn im makefile rm oder mkdir steht, ruft make die sh.exe auf und die dann rm.exe oder mkdir.exe. Wenn es keine sh.exe im Pfad findet, wird rm.exe bzw. die anderen Befehle ohne zwischengeschaltetest sh.exe aufgerufen und das geht auch unter w10. Das einzige Problem sind dann explizite Aufrufe der SHELL im makefile wie ich oben beschrieben habe. Das braucht aber niemand wirklich. Also: lösch die sh.exe oder benenn sie um. Dann geht auch der Rest.
Gast
#4753270
> Wenn du was für die Kunden willst, dann stell es so > zusammen dass es passt. Darf ich das? Diese langen Lizenztexte verstehe ich nicht, daher die Frage.
Gast
#4753286
> Da du ja nicht auf unsere Vorschläge eingehen willst
Das ist nicht wahr. Ich bin auf die Vorschläge eingegangen. Ich habe sie
auch alle ausprobiert.
Stimmt, ich habe die msys-dll auch getauscht. Hatte ich schon verdrängt. Aber damit läuft es auch. Unter Windows 10 scheint es damit aber auch zu gehen, jedenfalls berichten hier http://smallshire.org.uk/sufficientlysmall/2013/10/31/arduino-avr-gcc-eclipse-and-windows-8-1/ etliche davon. Unten In den Postings lesen, dort berichten einige, dass es geht. Also WinAVR-utils Ordner nehmen, msys-dll tauschen und probieren.
Stefan U. schrieb: >> Wenn du was für die Kunden willst, dann stell es so >> zusammen dass es passt. > > Darf ich das? > > Diese langen Lizenztexte verstehe ich nicht, daher die Frage. Oliver S. schrieb: > such dir einen anderen Job. Das, was du da > zu machen versuchst, übersteigt deine Fähigkeiten. Oliver
Gast
#4753303
Ja, bei mir hat der Austausch der DLL geholfen. Habe ich auch schon geschrieben. Ich glaube wir drehen uns hier im Kreis.
Stefan U. schrieb: > Ja, bei mir hat der Austausch der DLL geholfen. Habe ich auch schon > geschrieben. Warum machst es dann nicht so? 900ss D. schrieb: > Eine eigene Installation in einem Ordner zusammenstellen. Der Kunde will das nicht? Er hat viel Vertrauen zu deiner Arbeit ;-)
Bei uns hat eigentlich auch jeder Cygwin installiert um gleiche Vorraussetzungen zu schaffen. Allerdings haben wir unser Framework immer öfter an Kunden ausgeliefert. Ich vermute zwar dass der Kunde in der Lage ist ein Cygwin zu installieren, aber muss ja nicht sein. Deswegen haben wir make und andere relevante GNU-Tools in einem tools-Ordner innerhalb unserer Projektstruktur abgelegt. D.h. der Kunde hat alle notwendigen Tools und dlls durch unsere Auslieferung auf der Platte, die Pfade werden im make bzw. im Batch dass make aufruft angepasst. Die Tools musst du dir halt einmalig aus einem aktuellen MinGW klauben. Allerdings kann ich nicht für Win8/10-Fähigkeit garantieren. Wer benutzt denn das professionell? ;-)
Gast
#4753333
>> Eine eigene Installation in einem Ordner zusammenstellen. > Der Kunde will das nicht? Leute, ihr reißt Sätze aus dem Zusammenhang und konstruiert damit neue Aussagen, die falsch sind. Ich habe nicht geschrieben, dass der Kunde keine eigene Installation haben will! Ich habe gefragt, ob ich eigene Zusammenstellungen weiter geben darf. Eben weil ich das für einen sinnvollen Kundenfreundlichen Weg halte. >> Diese langen Lizenztexte verstehe ich nicht, daher die Frage. > such dir einen anderen Job. Super, muss man jetzt schon Rechtsgelehrter sein, um zu programmieren? Oder was willst du mir damit mitteilen?
Man muß kein Rechtsgelehrter sein, um zu verstehen, was die in dem Umfeld übliche GPL u.ä. besagen. Dazu gibt's nun wirklich ausführlichste und einsteigerfreundliche Darstellungen im Netz. Deine Hausaufgaben musst du allerdings schon selber machen. Oliver
Stefan U. schrieb: > Da muss man nach der Installation die msys-1.0.dll, avrdude und die > libusb auswechseln. Das verunsichert den Kunden möglicherweise, er > könnte es für gefrickel halten. Vor allem, weil die Herkunft dieser dll > unbekannt ist. Und weitere solche Aussagen sind zu finden. Ich sehe nicht, dass ich etwas aus dem Zusammenhang gerissen habe. Stefan U. schrieb: > Leute, ihr reißt Sätze aus dem Zusammenhang und konstruiert damit neue > Aussagen, die falsch sind. Edit: wenn du eine Lösung hast, dann lass es uns hier bitte wissen. Ich bin da gespannt.
Gast
#4753348
Peter D. schrieb: [..] > Ein Make ist mir aber zu kompliziert, daher habe ich ne einfache Batch > geschrieben. Peter, bei aller Liebe..das halte ich für totalen Quatsch. Ich weiß nicht warum Du make vor Dir her schiebst aber "zu kompliziert" für Dich ist es auf keinen Fall. Gruß, Holm
Gast
#4753366
Peter D. schrieb: > Ein Make ist mir aber zu kompliziert, daher habe ich ne einfache Batch > geschrieben. Exakt so mache ich das auch. Dann braucht man nämlich außer dem Compiler, dessen Pfad an einer Stelle im Batchfile hinzuschreiben ist, überhaupt keine weiteren Tools mehr. Make kann sinnvoll sein, wenn man ein großes Projekt hat, welches man im Entwicklungszyklus oftmals compiliert. Dann will man nicht hunderte von Dateien compilierne, nur weil ein c-File sich verändert hat. Aber fürs Final Release muß man ohnehin alles komplett durchcompilieren, und dann kann man auch gleich eine Batch nehmen. Die läuft dann auch überall, auch beim Kunden. Aber diese denkbar einfach Lösung will Stefan ja nicht ausprobieren und rödelt lieber lagelang herum. :-)
"Eben weil ich das für einen sinnvollen Kundenfreundlichen Weg halte." nicht nur Du, jeder klar denkende Mensch würde das so sehen. Dummerweise bekommen die "Nerds" es nicht auf die Kannte, das ein normalo sich damit nicht rumschlagen will. Und beschweren sich dann über ständige Anfängerfragen
Na ja, hier nölt aber ein "Normalo", der das als Dienstleistung oder so verkaufen möchte. Da hält sich mein Mitleid arg in Grenzen... Oliver
Die Anforderung von Kunden, die gelieferten Quelltexte auch selbst kompilieren zu können, ohne hierfür eine Installations- und Konfigurationsorgie zu veranstalten, ist durchaus üblich und absolut nachvollziehbar. Ich sehe es sogar als seine unternehmensinterne Pflicht an, dafür zu sorgen, dass er alle wichtigen Komponenten seines eigenen Produktes noch über längere Zeiträume selbst pflegen kann, und dies betrifft in erheblichem Maße auch seine Software/Firmware. Es gibt schließlich genügend viele Fälle, in denen eigentlich erfolgreiche Produkte weggeschmissen und nachentwickelt werden müssen, weil Bauteile abgekündigt werden oder Softwarebugs mangels Quellcode oder Kenntnisse nicht behoben werden können. Man sollte nicht davon ausgehen, dass der Kunde die zu liefernden Quelltexte zeitnah selbst kompilieren will. Vielmehr geht es darum, sie in fünf oder zehn Jahren aus der Schublade zu holen und ohne große forensische Studien einen Fehler beheben und die Software neu zu kompilieren. Wenn es aber schon bei der heutigen Lieferung massive Probleme bei der Installation/Konfiguration/Modifikation der Toolchain gibt, kann man als Kunde nicht davon ausgehen, dass es in den o.a. fünf oder zehn Jahren einfacher wäre. Der sinnvollste Weg besteht aber auch heutzutage darin, dem Kunden eine vorkonfigurierte VM zu liefern, in der alle Werkzeuge funktionsfähig sind. Damit spart man sich auf allen Seiten sehr viel Aufwand. Insbesondere ist auf diese Art und Weise sichergestellt, dass man nach langer Zeit noch ein System vorfindet, auf dem sich nichts geändert hat. Bei der Auswahl des Betriebssystems dieser VM sollte man nur darauf achten, dass es später gleich funktionieren wird, ohne als Erstes beim Hersteller anzurufen und sich ungefragt Unmengen an Update reinzulöten. Windows 10 wäre also eine schlechte Wahl. Windows XP wäre sogar ganz gut, da man hierfür keine neue Lizenz kaufen muss und es auch ohne Dauerverbindung zu Microsoft überlebt. Bezüglich des Virtualisierungsproduktes sollte man auch eher wählerisch und konservativ sein, d.h. z.B. VMware verwenden und die VM so aufsetzen, dass sie sowohl mit VMware Workstation als auch mit VMware Player nachweislich(!) funktioniert. Für die VM sollte insbesondere auch die Nutzung von Peripherie und fremden Diensten (USB-Geräte, Soundkarte, Netzwerk, Netzwerklaufwerke, Domänenanmeldung, usw.) weitestmöglich eingeschränkt werden, damit der Start auf fremden Rechnern reibungslos funktioniert. Wichtig ist aber auch, dass die Treiber für irgendwelche Programmierschniepel schon installiert sind und nicht erst aus dem Netz nachgeladen werden müssen. Abgesehen von einem einzigen Fall(*) hat sich diese Vorgehensweise doch sehr bewährt, und zwar in beiden Richtungen: Bereitstellung der VM durch unseren Kunden und Lieferung einer VM an den Kunden. Und noch ein anderer Aspekt ist nicht zu vergessen: in etlichen Unternehmen können sogar die Entwickler keine Konfigurationsänderungen an ihren PCs vornehmen, sondern die zentralen IT-Abteilungen sind hierfür zuständig. Und die Mitarbeiter dieser Abteilungen sind dann auch nicht bereit, einfach ein paar Dateien zu kopieren und womöglich installierte Bibliotheken händisch zu ersetzen, sondern verlangen, dass nur fertige Installationspakete namhafter Hersteller eingesetzt werden, für die ggf. sogar noch eine Stellungnahme der IT-Sicherheitsabteilung vorliegen muss. Als "kleiner" Lieferant selbst zusammengestellter Toolchains wird man da nur ausgelacht. Zu (*): Es handelte sich um einen externen Mitarbeiter, der massive Probleme bei der Arbeit mit einer von mir bereitgestellten VM hatte, die ich mir überhaupt nicht erklären konnte. Dort war auch eine VPN-Verbindung vorkonfiguriert, mit der dieser Mitarbeiter direkt auf unseren SVN-Server zugreifen sollte. Ich verbrachte etliche Stunden damit, sein Problem zu analysieren und zu prüfen, warum unsere Firewall keine Verbindungen seiner VM mochte. Nach langer Fehlersuche stellte sich dann heraus, dass derjenige als Erstes ohne große Not eine komplett neue Linuxdistribution in der VM installiert und vorher nur ein paar Quelltexte gesichert hatte. Damit waren natürlich auch die Zertifikate für seine VPN-Verbindung verloren gegangen. Natürlich hatte er auch keine Kopie der Original-VM angelegt, denn so etwas belegt ja nur unnötig Speicherplatz. :-/ Und dann wunderte sich derjenige darüber, dass ich nicht bereit war, die Rechnung für seinen Pfusch zu bezahlen, insbesondere weil ja die von ihm zu erstellende Software auch niemals fertig wurde...
Andreas S. schrieb: > VM Oder ganz neumodisch Docker. Nur wird das den TO und seine Kundschaft endgültig und vollständig überfordern. Abgesehen von den angesprochenen Lizenzproblemen, mal eben in der VM ein komplettes Windows einfach so weiterzugeben... Oliver
Gast
#4753410
So ein Käse. Gestern lief mein WinAVR wieder, nachdem ich diese msys-1.0.dll ausgetuscht hatte. Und heute geht es nicht mehr. Ich bekomme wieder diesen Fehlercode. Ich werde noch bekloppt. Am Ende wird es wohl tatsächlich darauf hinaus laufen, dass ich eine komplette VM mit ausliefere.
Angehängte Dateien:
-
screenshot1.png
8,3 KB
http://stackoverflow.com/questions/2463037/calling-windows-commands-e-g-del-from-a-gnu-makefile Oliver
Oliver S. schrieb: > Oder ganz neumodisch Docker. Nur wird das den TO und seine Kundschaft > endgültig und vollständig überfordern. Ist bei Docker mit hinreichend großer Sicherheit davon auszugehen, dass auch in fünf oder zehn Jahren der Build für heutige Softwarestände funktionieren wird? Falls es da Zweifel gibt, scheidet Docker damit aus. Bei VMware funktionieren schon seit etlichen Versionen auch uralte VMs völlig problemlos. VMware ist auch als namhafter Hersteller im IT-Umfeld anerkannt. > Abgesehen von den angesprochenen > Lizenzproblemen, mal eben in der VM ein komplettes Windows einfach so > weiterzugeben... Wieso Lizenzprobleme? Für Windows XP benötigt man mittlerweile keine neuen Lizenzen mehr, sondern kann es frei (=kostenlos) verwenden. Die Beschaffung von Lizenzen für neuere Windowsversionen ist doch kein Problem, sondern ein ganz normaler Beschaffungsvorgang, da es sich um ein billiges Standardprodukt handelt. VMs mit nicht lizensierten Windows 7 starten ganz normal und weisen einen nur auf den Umstand der nicht vorhandenen Lizenz hin. Aber solch eine VM funktioniert ansonsten uneingeschränkt. Wenn man sich also zehn VMs mit unterschiedlichen Versionsständen hinlegt und davon gleichzeitig maximal eine verwendet, sollte eine gemeinsame Lizenz völlig ausreichen.
Andreas S. schrieb: > .... Es gibt > schließlich genügend viele Fälle, in denen eigentlich erfolgreiche > Produkte weggeschmissen und nachentwickelt werden müssen, weil Bauteile > abgekündigt werden oder Softwarebugs mangels Quellcode oder Kenntnisse > nicht behoben werden können. Genau deswegen habe ich schon 1/2 Jahr "nebenberufliche-Freizeit" geopfert, um mal ein praktisches Beispiel zu nennen. Wollte an dieser Stelle nur anmerken/nachfragen ob die CygWin-Lösung in einem hiesigen Wikiartikel durchgekaut wurde bzw. ggf. niedergeschrieben werden könnte? (Dann bin ich auch schon wieder still und lass euch diskutieren) Grüße Oekel
Andreas S. schrieb: > zentralen IT-Abteilungen sind > hierfür zuständig. Und die Mitarbeiter dieser Abteilungen sind dann auch > nicht bereit, einfach ein paar Dateien zu kopieren und womöglich > installierte Bibliotheken händisch zu ersetzen, sondern verlangen, dass > nur fertige Installationspakete namhafter Hersteller eingesetzt werden, > für die ggf. sogar noch eine Stellungnahme der IT-Sicherheitsabteilung > vorliegen muss. Natürlich funktioniert das mit dem Windows in der VM, aber du solltest dich schon für eine Zielgruppe entscheiden. Die o.a. Unternehmen werden mit Sicherheit keine unlizensierten Windows-Kopien akzeptieren. Macht aber sowieso alles nichts, da der TO augenscheinlich eine andere Kundschaft hat. Da wird der Preis für eine Windowslizenz den gesamten Auftragswert übersteigen. Andreas S. schrieb: > Für Windows XP benötigt man mittlerweile keine > neuen Lizenzen mehr, sondern kann es frei (=kostenlos) verwenden. Auch da dürfte es einen signifikanten Unterschied zwischen können und dürfen geben. Oliver
Gast
#4753449
> Natürlich funktioniert das mit dem Windows in der VM
Ich würde natürlich Linux in einer VM verwenden. Unter Linux funktoniert
das alles auch "einfach so" ohne diese Fummeleien.
Gast
#4753456
@Oliver: Danke für den Link. Ich denke, damit kann ich arbeiten.
... und dann WinAVR unter Linux? Oder können deine Kunden auf einmal doch Linux? Stefan U. schrieb: > Ich möchte aber nicht die > Nachahmer meiner Projekte dazu drängen. Denn die meisten haben keine > Ahnung von Linux und dann kommen Fragen auf, die ich vermeiden möchte. Weiterhin alles unklar... Oliver
Holm T. schrieb: > Peter, bei aller Liebe..das halte ich für totalen Quatsch. Genauer gesagt, es ist mir zu umständlich, immer alle Sourcen dort händisch eintragen zu müssen. "*.c" kann das make nicht expandieren.
Gast
#4753475
> und dann WinAVR unter Linux?
Natürlich nicht.
Anstatt herum zu frickeln, werde ich den Kunden künftig vorschlagen, die
Entwicklung unter Linux in einer VM zu machen. Mit Tools, die zur Linux
Distribution gehören.
Das klingt vernünftig. Oliver
Gast
#4753505
Peter D. schrieb: > Genauer gesagt, es ist mir zu umständlich, immer alle Sourcen dort > händisch eintragen zu müssen. "*.c" kann das make nicht expandieren. Hallo Peter, du verspielst gerade dein Ansehen.... Hier ein Schnipsel aus einem makefile SRCPP += $(wildcard ./libs/*.cpp) SRC += $(wildcard ./libs/*.c) SRC += $(wildcard ./libs/freertos/*.c) SRCPP_DBG += ./src/main.cpp geht problemlos auch mit den alten make Varianten aus 2006 oder so.
Oliver S. schrieb: > Natürlich funktioniert das mit dem Windows in der VM, aber du solltest > dich schon für eine Zielgruppe entscheiden. Die o.a. Unternehmen werden > mit Sicherheit keine unlizensierten Windows-Kopien akzeptieren. Doch, das tun sie, weil sie entsprechende Windows-Lizenzen bei Bedarf selbst beschaffen oder entsprechende Volumenlizenzen haben. Meine Aufgabe ist die Lieferung der VM, nicht deren anschließender Betrieb.
temp schrieb: > SRCPP += $(wildcard ./libs/*.cpp) Wildcards in Makefiles sind für die Erstellung von Quelltextlisten eine ganz schlechte Idee! Sie sind nur sinnvoll für Aufräumregeln, z.B. "make clean". Ansonsten handelt man sich sehr, sehr üble Seiteneffekte ein.
Andreas S. schrieb: > Ansonsten handelt man sich sehr, sehr üble > Seiteneffekte ein. Offtopic: Kannst du bitte ein Beispiel nennen?
Gast
#4753538
Andreas S. schrieb: > Wildcards in Makefiles sind für die Erstellung von Quelltextlisten eine > ganz schlechte Idee! Sie sind nur sinnvoll für Aufräumregeln, z.B. "make > clean". Ansonsten handelt man sich sehr, sehr üble Seiteneffekte ein. für "make clean" braucht man das in der Regel nicht. Um was für Seiteneffekte soll es sich dabei handeln? Rekursiv ist das ganze eh nicht und Quelldateien kommen auch nicht irgendwie von Geisterhand in die Verzeichnisse. Ob etwas sinnvoll ist oder nicht lasse ich in der Regel mich selbst entscheiden und nicht einen der meint die Weisheit mit Löffeln gefressen zu haben. Es stand auch nicht der Sinn zur Debatte sondern ob es geht oder nicht.
temp schrieb: > Hallo Peter, du verspielst gerade dein Ansehen.... Naja, jeder nimmt vorzugsweise das Tool, was er am besten kennt. Anbei mal meine Batch. Bisher habe ich in Makefiles immer nur das hier gesehen:
1 | |
Gast
#4753712
Bitte auch nur als Spaß verstehen!
Gast
#4753758
Ich habe einen würdigen Nachfolger für WinAvr gefunden!!!! Toolchain: http://gnutoolchains.com/avr/ Und die ist Blitz-Aktuell, mit avr-gcc Version 5.3. Darin ist make enthalten. Zusätzlich braucht man eventuell noch avrdude: Avrdude: http://download.savannah.gnu.org/releases/avrdude/ LibUSB: https://sourceforge.net/projects/libusb-win32/files/libusb-win32-releases/1.2.6.0/ Anleitung, wie man Windows 8-10 dazu bringt, unsignierte Treiber zu akzeptieren: http://stefanfrings.de/avr_tools/libusb.html Damit ich in Makefiles unter Windows den rm Befehl (z.B.: rm -f *.o driver/*.o) nutzen kann, lege ich noch das angehängte Batch-File zu meinen Projekten. Man kann die Projekte dann wahlweise unter Linux und Windows compilieren.
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
Falls man aus irgendeinem Grund eine vollständigere Unix Umgebung mit Shell und allem PiPaPo braucht, empfiehlt sich CygWin oder eine Linux VM.
Gast
#4754125
In mein Batch File hat sich ein Leerzeichen zu viel hereingeschlichen. So eine Frechheit :-) Falsch:
1 | |
Richtig:
1 | |
Stefan U. schrieb: > Toolchain: http://gnutoolchains.com/avr/ Danke für den Hinweis. Ich werde das auch mal probieren da deren "verbauter" GCC recht neu ist. Ich kenne die Toolchain für den Raspberry Pi von denen, die hab ich verwendet und hat gut funktioniert. Dass sie jetzt auch AVR im Programm haben ist mir neu, war damals noch nicht der Fall.
Gast
#4754654
Peter D. schrieb: > Holm T. schrieb: >> Peter, bei aller Liebe..das halte ich für totalen Quatsch. > > Genauer gesagt, es ist mir zu umständlich, immer alle Sourcen dort > händisch eintragen zu müssen. "*.c" kann das make nicht expandieren. Evtl. hilft ja ein :r! ls -1 *.c ? Wie oft ändern sich die Sources Deiner Projekte während Du daran arbeitest? Das ist doch kein realer Aufwand. Komm mir nicht damit das Dein Editor den Befehl von mir nicht versteht, benutze halt brauchbare Werkzeuge... In Subdirectories mit Libs etc. gehört jeweils ein eigenes Makefile. Bei mir liegen übrigens ab und an Sourcen von Testprogrammen oder "Feldgeneratoren" als C Quelle mit im Verzeichnis herum die mit dem Programm an sich nichts zu tun haben und die möchte ich beim Build auch nicht neu gebaut haben. "*.c" ist also nicht so der Bringer Gruß, Holm
Stefan U. schrieb: > Ich habe einen würdigen Nachfolger für WinAvr gefunden!!!! > > Toolchain: http://gnutoolchains.com/avr/ > > Und die ist Blitz-Aktuell, mit avr-gcc Version 5.3. Blitz-Aktuell? Naja: https://sourceforge.net/projects/mobilechessboar/files/avr-gcc%20snapshots%20%28Win32%29/ Ist eine Toolchain mit avr-gcc 6.1.1, ist aber ohne make & Co. Dafür läuft diese mit WinAvr 4.18 - jedenfalls bis Win7.
Gast
#4754750
Frank M. schrieb: > https://sourceforge.net/projects/mobilechessboar/files/avr-gcc%20snapshots%20%28Win32%29/ > > Ist eine Toolchain mit avr-gcc 6.1.1, ist aber ohne make & Co. Dafür > läuft diese mit WinAvr 4.18 - jedenfalls bis Win7. Wenn man für Kunden was macht finde ich das aber mutig irgendwoher irgendwelche Compiler zu verwenden. Außer man hat wirklich einen triftigen Grund auf einen gcc 5xx oder 6xx zu wechseln. Ansonsten gibts die avrtoolchain auch ohne Atmel Studio direkt bei Atmel. Auch die Linux Variante: http://www.atmel.com/tools/atmelavrtoolchainforwindows.aspx http://www.atmel.com/tools/ATMELAVRTOOLCHAINFORLINUX.aspx
temp schrieb: > Wenn man für Kunden was macht finde ich das aber mutig irgendwoher > irgendwelche Compiler zu verwenden. Das sind nicht "irgendwelche" Compiler, das sind die von Johann (gjlay, dem eigentlichen "Maintainer" des avr-gcc) höchstpersönlich dort abgelegten Toolchains. Von daher sehe ich das nicht nur gelassen, sondern ich sehe die Links zudem als höchst vertrauenswürdig an. Johann selbst hatte damals den Link zum avr-gcc 4.7.2 hier veröffentlicht. Seitdem schaue ich da regelmäßig immer mal wieder rein. Und wenn Du dort mal auf "Summary" klickst, findest Du auch gjlay wieder, inkl. Link. > Ansonsten gibts die avrtoolchain auch ohne Atmel Studio direkt bei Atmel. Das ist - soviel ich weiß - eine Toolchain der Atmel-Entwickler selbst. Einige Bugfixes, Verbesserungen bzw. Neuerungen von Johann (und Jörg) sind dort wohl nicht eingeflossen, weil die Atmel-Entwickler da ihr eigenes Süppchen kochen. Ich kann mich auch täuschen, meine das aber aus einigen von Jörgs und Johanns Beiträgen hier in diesem Forum mehrfach herausgelesen zu haben. Ich nehme jedenfalls lieber "das Original" - und das ist nicht von Atmel.
Frank M. schrieb: > Das sind nicht "irgendwelche" Compiler, das sind die von Johann (gjlay, > dem eigentlichen "Maintainer" des avr-gcc) höchstpersönlich dort > abgelegten Toolchains. Von daher sehe ich das nicht nur gelassen, > sondern ich sehe die Links zudem als höchst vertrauenswürdig an. Früher hatte ich mich immer gefragt, wie es solche Läden wie Wind River und Konsorten schaffen, sich einfach den großen Open-Source-Projekten wie z.B. Linux zu bedienen und den Kunden teilweise völlig veraltete Versionen für irrsinnig viel Geld weiterzuverkaufen. Bei Gesprächen mit manchen Kunden habe ich dann gelernt, dass es nur darum geht, irgendjemanden verklagen zu können, falls das Projekt in Schieflage gerät. Im Zweifelsfall wirft man dann einfach dem Compiler-"Hersteller" vor, der Compiler hätte den Code nicht wunschgemäß kompiliert. Dass der Anbieter natürlich in seinen Vertragsbedingungen entsprechende Schadensersatzansprüche ausschließt, steht dann auf einem anderen Blatt. Es gibt auch hinreichend viele Entwickler, die sagen: "Wir verwenden doch nicht einfach irgendwelchen Programmcode 'aus dem Internet', sondern kaufen unseren Linux-Kernel natürlich nur bei Profis ein." Auf den dezenten Hinweis, dass diese "Profis" sich letztendlich auch nur bei den freien Kerneln 'aus dem Internet' bedienen, wird dann bestritten und behauptet, es handele sich um einen separat entwickelten Linux-Kernel. Denn schließlich sei er ja teuer... Und nein: es ist nicht sinnvoll, mit solchen Leuten auf einer technischen Ebene zu argumentieren.
Andreas S. schrieb: > ... dass es nur darum geht, irgendjemanden verklagen zu können, falls > das Projekt in Schieflage gerät. Sie wollen jemanden haben, der motiviert ist, den Support zu machen. Und wie jeder weiß, funktioniert das nur, wenn derjenige von den Zahlungen des Kunden abhängig ist. (Wenn es zu einer Klage kommt, wäre es viel zu spät.)
Andreas S. schrieb: > Im Zweifelsfall wirft man dann einfach dem Compiler-"Hersteller" > vor, der Compiler hätte den Code nicht wunschgemäß kompiliert. Da stellt sich doch gleich die Frage, welche Compiler VW wohl verwendet?
Gast
#4755372
> Ich werde das auch mal probieren da deren > "verbauter" GCC recht neu ist. Ja. Ich habe zur Probe meinen Embedded Webserver compiliert. Das war bisher mein größtes µC Projekt und zugleich das empfindlichste. Zwei bestimmte Versionen der Atmel Toolchain erzeugten damit ein nicht funktionierendes Binary. Jedenfalls funktioniert das Teil und der Code ist 10% kleiner, als mit WinAVR und mehr als 5% kleiner als mit meiner aktuellen Ubuntu Version. Meinen Test hat die Toolchain bestanden.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.