Hallo zusammen, vor kurzem hatte in einem anderen Thread Jörg erklärt, dass er mit dem Einpflegen der Patches bei der avr-libc nicht nach kommt und sich Unterstützung gewünscht: Beitrag "Re: Atmel-ICE mit AVR unter Linux / atprogram.exe-Ersatz" Nun gibt es offenbar schon so jemanden, der sich der Arbeit annehmen will. Freut mich. Aber leider macht der einen Fork: avr-libc3 https://github.com/stevenj/avr-libc3 Gibt's einen Grund dafür, dass Steven sich nicht einfach bei savannah.gnu.org einbringt? Ich fände es schade, wenn das jetzt in so viele Versionen zerfranselt...
P.S.: Bestimmt kommt jetzt als Antwort: "da musst Du Steven fragen."...
Np R. schrieb: > dass er mit dem > Einpflegen der Patches bei der avr-libc nicht nach kommt Oh, sorry, da habe ich falsch assoziiert: Dort ging es um avrdude, nicht um die libc. Aber das Problem scheint ja dasselbe: Die "Originale" sind nicht mehr aktuell, Unterstützung für die neueren Attiny fehlt. Also bildet sich ein Fork.
@ Johann L. (gjlayde): Danke für den Link. Da ist auch der ganze War. Schade, dass man sich nicht zusammenraufen kann. Ein Lizenzproblem sehe ich jedenfalls nicht. So aber ist zu befürchten, dass die alte avr-libc nicht mehr gepflegt wird und Steven sich tot läuft. Am Ende bleiben zwei Code-Leichen.
Np R. schrieb: > @ Johann L. (gjlayde): > Danke für den Link. > Da ist auch der ganze War. Ja, irgendwie hat der ganze Thread einen ziemlich aggressiven Unterton, nicht wirklich förderlich. > So aber ist zu befürchten, dass die alte avr-libc nicht mehr gepflegt > wird und Steven sich tot läuft. Am Ende bleiben zwei Code-Leichen. Support ist eben mehr als irgendwelche Patches reinzukloppen... Wenn ich mich recht erinnere hab's auch das Angebot, bei avr-libc mitarbeiten zu können, aber dem Interessenten war SVN nicht genehm und er wollte lieber GIT — weiß aber nicht mehr, ob das Steven war.
Na klar, wenn jemand neu zu einem Projekt hinzu stößt, kann er nicht erwarten, dass alle anderen nun nach seiner Pfeife tanzen. Wenn jemand diesen Anspruch hat, dann macht er am besten einen Fork und arbeitet als Ein-Mann-Projekt. Ob dies nun auf Steven zutrifft, weiß ich aber nicht. Als langjähiger FOSS-Nutzer, der nur gelegentlich mal aktiv beigetragen hat (d.h. nur hier und da mal einen Patch und nie "fest" in einem Projekt war), kann ich mir natürlich die Illusion erlauben, dass alle Menschen im Open-source Bereich Idealisten und nette Leute sind. ;-) Also gehe ich auch hier zunächst mal davon aus und suche nach Sachgründen. Ich bin (noch bis Weihnachten) unterwegs und kann daher nur eingeschränkt testen, aber ich habe mal Stevens git-Repo probiert. Es baut bei mir gcc 9.1.0 und eine libc mit Support für attiny212 attiny214 attiny412 attiny414 attiny416 attiny417 attiny814 attiny816 attiny817 attiny1614 attiny1616 attiny1617 attiny3214 attiny3216 attiny3217. Ob der damit generierte Code dann auch läuft, weiß ich ohne µC natürlich nicht. 1. Wie genau müsste ich mit avr-gcc/avr-libc von http://www.nongnu.org/avr-libc/ vorgehen, um auf den neuen Attiny lauffähigen Code zu erzeugen? (D.h.: Löst Steven hier ein reales Problem oder gibt es bereits eine Lösung?) 2. Spricht etwas (z.B. lizenzrechtlich) gegen Stevens Lösung? Oder ist eine Alternativ-Lösung, die sich besser in das vorhandene Konzept einfügt, fast fertig? Denn wenn es 1. ein Problem gibt und 2. noch keine andere Lösung, dann könnte man sich ja einfach eine Eigenschaft von FOSS zu Nutze machen. Man könnte forken, rückportieren... Pragmatismus bedeutet ja keinen Gesichtsverlust, und vielleicht könnte man auf diese Weise einen Fork auch wieder "einfangen" und die Kräfte bündeln.
Np R. schrieb: > Ich bin (noch bis Weihnachten) unterwegs und kann daher nur > eingeschränkt testen, aber ich habe mal Stevens git-Repo probiert. Es > baut bei mir gcc 9.1.0 und eine libc mit Support für attiny212 attiny214 > attiny412 attiny414 attiny416 attiny417 attiny814 attiny816 attiny817 > attiny1614 attiny1616 attiny1617 attiny3214 attiny3216 attiny3217. > Ob der damit generierte Code dann auch läuft, weiß ich ohne µC natürlich > nicht. Dafür gibt's Simulatoren, die auch für's Testing verwendet werden. simulavr für avr-libc und avrtest für avr-gcc. > 1. Wie genau müsste ich mit avr-gcc/avr-libc von > http://www.nongnu.org/avr-libc/ vorgehen, um auf den neuen Attiny > lauffähigen Code zu erzeugen? Das übliche Vorgehen ist, Device-Packs zu verwenden; i.d.R. bereitgestellt vom Hardware-Hersteller. > (D.h.: Löst Steven hier ein reales Problem oder gibt es bereits eine > Lösung?) Es gibt die Lösung mit Device-Packs; aber natürlich ist es wesentlich angenehmer, wenn alles Out-of-the-Box läuft und man nicht auf die Suche nach Packs gehen muss. Das Gros der Anwender verwendet wohl auch IDEs vom Hersteller, und da ist der Support schon drinne: Ob der Support dann von avr-libc kommt oder von der IDE macht dann kein Unterschied, weder von der Funktionalität noch von der Usability. Und welche Änderungen Steven vorgenommen hat, sieht man in den Commit-Logs. Und werden im README.md aufgezählt. > Denn wenn es 1. ein Problem gibt und 2. noch keine andere Lösung, dann > könnte man sich ja einfach eine Eigenschaft von FOSS zu Nutze machen. > Man könnte forken, rückportieren... Geforkt wurde ja auch... Wie viel Aufwand es ist, die Patches zu integrieren — keine Ahnung. Die Device-Beschreibungen sind ja riesig, und die daraus generierten Dateien (wie io.h) auch. Sinnvoll reviewen kann man das m.E. eh nicht. > Pragmatismus bedeutet ja keinen Gesichtsverlust, und vielleicht könnte > man auf diese Weise einen Fork auch wieder "einfangen" und die Kräfte > bündeln. Mir ist nicht bekannt, ob jemand dazu bereit ist, langfristig beim avr-libc Maintaining zu unterstützen oder gar zu übernehmen, und auch nicht, welche Kriterien man dafür mitbringen muss. Bei GCC werden Patches abgelehnt, die nicht den Coding-Rules entsprechen, nicht getestet sind, keine ChangeLogs haben, oder die fragwürdige[tm] Dinge tun. Bedeutet für die GCC-Maintainer, dass es wesentlich einfacher und weniger Arbeit ist, Patches zu integrieren — und für avr-gcc kommt hinzu, dass eh niemand Patches vorschlägt. avr-libc hat den zusätzlichen "Service", dass erstmal die Patches überarbeitet und getestet werden, etc. Was aber nartütlich für nen Maintainer einen nicht unerheblichen Mehraufwand bedeutet. Was dann im Endeffekt dazu führt, dass Patches auch mal längere Zeit liegen bleiben, was gerne mal entsprechenden Unmut auslöst.
Np R. schrieb: > Support für attiny212 attiny214 attiny412 attiny414 attiny416 > attiny417 attiny814 attiny816 attiny817 attiny1614 attiny1616 > attiny1617 attiny3214 attiny3216 attiny3217. Zusätzlich gibt es Support für ATtiny* mit * = 202, 204, 402, 404, 406, 804, 806, 807, 1604, 1606, 1607. Der allerdings nicht aktiv ist, weil die Devices nicht von avr-gcc unterstützt werden und daher von configure ignoriert werden. Interessantes Aside: Gibt bereits Bug-Reports gegen avr-libc3 (z.B. Probleme mit den ATDF) und Patches, die aber auch liegen bleiben...
Johann L. schrieb: > Ja, irgendwie hat der ganze Thread einen ziemlich aggressiven Unterton, > nicht wirklich förderlich. Sehe ich auch so. Kann mich auch nicht dran erinnern, dass er an mich herangetreten wäre mich zu fragen, wie er denn im Projekt mitarbeiten könnte (ganz zu schweigen von den vielen anderen Dingen, die du angesprochen hast). Wenn ich demnächst den von dir präferierten Multilib-Umbau mache (einschließlich der Sachen für 64-bit-FP), möchte ich die major version number der avr-libc hochziehen. Es ist zwar streng genommen theoretisch keine API-Änderung damit verbunden (für die wir eigentlich die major # mal vorgesehen hatten), aber ich halte die damit erfolgenden Änderungen (insbesondere auch den Aufbau des Baums während configure statt bereits im bootstrap) für tiefgreifend genug, den Schritt zu rechtfertigen. Wäre dann die Frage, ob ich die nächste avr-libc nun 3.x nennen sollten (was logisch wäre, aber wohl die Konfusion mit jener "version 3" riskiert) oder gleich 4.x. Windows konnte sich ja auch keine Version 9.x leisten. :-)
:
Bearbeitet durch Moderator
Np R. schrieb: > Spricht etwas (z.B. lizenzrechtlich) gegen Stevens Lösung? Lizenzrechtlich ganz sicher nicht, aber ich fände es natürlich schon sinnvoller, wenn mehrere an einem Strang ziehen, statt dass sich jeder eine Faser aus dem Seil rauspickt und dann in seine Lieblingsrichtung zieht (das schließt auch Microchip mit ein, die ja auch nur noch darauf setzen, ihre Devicepacks zusammenzunageln, aber nichts mehr selbst in avr-libc mitmachen).
Jörg W. schrieb: > Wenn ich demnächst den von dir präferierten Multilib-Umbau mache > (einschließlich der Sachen für 64-bit-FP), Hast du mal in das Patch reingeschaut (bei #57071)? Das einzige, was sich ändert, ist ja welche Symbole definiert werden und dass es korrekte Prototypen in math.h gibt — abgesehen von Kleinvieh wie Build-Warnings beheben etc. Die 64-Bit Funktionen selbst würde ich in libgcc einbauen, ist einfacher für mich. > (insbesondere auch den Aufbau des Baums während configure statt bereits > im bootstrap) Momentan wird der Baum immer noch in bootstrap aufgebaut, allerdings ist er flach (avr/lib/<multi> und avr/devices/<device>) und hat eine andere Struktur als install. Die Devices sind von den C-Libs entkoppelt. Momentan wird ein imaginärer Compiler vorausgesetzt, der eine Obermenge aller möglichen Multilib-Layouts (95 Stück) implementiert. Ob eine Variante / ein Device tatsächlich verfürgbar ist, entscheidet configure und füllt entsprechende <device> und <multi> aus oder ignoriert sie. Ist zum einen bedingt dadurch, dass man Devices und Multis kennen muss, da evtl. per gen-avr-lib-tree.sh spezielle Optionen gesetzt werden können, und zum anderen weil configure.ac nur eingeschränkte Dynamik hat, z.B. bei AC_CONFIG_FILES. Die am-Templates mit <<var>> gibt's folglich immer noch. Hättest du denn mal Zeit das Zeug anzuschauen und Rückmeldung zu geben? Gibt sonst niemand, mit dem ich sowas diskutieren könnte. > 4.x +1
:
Bearbeitet durch User
Johann L. schrieb: > Hättest du denn mal Zeit das Zeug anzuschauen und Rückmeldung zu geben? > Gibt sonst niemand, mit dem ich sowas diskutieren könnte. Wird vermutlich wirklich erst nach Weihnachten, da habe ich einige Tage frei.
Jörg W. schrieb: > Johann L. schrieb: > >> Hättest du denn mal Zeit das Zeug anzuschauen und Rückmeldung zu geben? >> Gibt sonst niemand, mit dem ich sowas diskutieren könnte. > > Wird vermutlich wirklich erst nach Weihnachten, da habe ich einige Tage > frei. Irgendwas stimmt mit Savannah nicht, für alle Attachments gibt's: >> Error: No access to the file. https://savannah.nongnu.org/support/?110158#comment1 > All attachment files in Savannah moved to a different directory > on the server, they weren't lost. ???
Hmm, dann hoffen wir mal, dass sie das zeitnah reparieren.
Jörg W. schrieb: > Hmm, dann hoffen wir mal, dass sie das zeitnah reparieren. Scheint wieder zu funktionieren. Anbei eine erste Draft-Version.
:
Bearbeitet durch User
Hallo zusammen, nach langer Reise gleich in den Weihnachtsstress... aber vorher noch einmal zurück zum Thema: Jörg W. schrieb: > ich fände es natürlich schon > sinnvoller, wenn mehrere an einem Strang ziehen, statt dass sich jeder > eine Faser aus dem Seil rauspickt und dann in seine Lieblingsrichtung > zieht (das schließt auch Microchip mit ein, die ja auch nur noch darauf > setzen, ihre Devicepacks zusammenzunageln, aber nichts mehr selbst in > avr-libc mitmachen) Genau darum ging es mir. Ich finde es eben schade, dass da keine (zumindest keine für mich als Außenstehenden erkennbare) Kooperation stattfindet. Steven macht jetzt sein eigenes Ding. Beim "offiziellen" avr-gcc tut sich seit langem nichts, bei der avr-libc sieht es (von außen) ähnlich aus. Für mich sind die Beiträge in diesen Threasd oder auch in Beitrag "Näherung für ArcusTangens?" ja schon wertvolle Lebenszeichen. Und Microchip scheint sowieso allem erst einmal seine Marke aufdrücken zu wollen und kämpft lieber allein. Wenn man MPLABX (Linux) herunterlädt, dann findet man in der Kompatibilitäts-Tabelle, dass der "XC8" Compiler nur die neuen (0er, 1er) Attiny und die 0er Atmega supporten soll. De facto ist der neue "XC8" aber nichts anderes als der steinalte avr-gcc 5.4.0 mit sämtlichen DevicePacks, einschließlich der 0er Attiny. Die kennt aber der avr-gcc nicht... Dazu scheinen die DevicePacks noch mit der heißen Nadel gestrickt zu sein: Beitrag "ATmega809 Timer CMP Interrupt funktioniert nicht" Johann L. schrieb: > Zusätzlich gibt es Support für ATtiny* mit * = 202, 204, 402, 404, 406, > 804, 806, 807, 1604, 1606, 1607. Der allerdings nicht aktiv ist, weil > die Devices nicht von avr-gcc unterstützt werden und daher von configure > ignoriert werden. Wäre das denn großer Aufwand, die dem avr-gcc beizubringen? Unterscheiden die sich überhaupt von den 212, 214,... so dass der Compiler etwas davon merkt? Johann L. schrieb: > Dafür gibt's Simulatoren, die auch für's Testing verwendet werden. > simulavr für avr-libc und avrtest für avr-gcc. Und die simulieren den Attiny 804 oder 814? Johann L. schrieb: > Das übliche Vorgehen ist, Device-Packs zu verwenden Das scheint mir eher eine Erleichterung für den Hersteller, der sich so auf das absolute Minimum beschränken kann. Integration in bzw. Weiterentwicklung von avr-gcc und avr-libc haben für Microchip offenbar keine Priorität. Wichtiger ist dem Marketing, dass man das alles als eigenes Produkt "XC8" verkauft. Und avr-gcc und avr-libc scheinen auf Microchip zu warten. Mikado. Wer sich zuerst bewegt, hat verloren.
Np R. schrieb: > Hallo zusammen, > > nach langer Reise gleich in den Weihnachtsstress... aber vorher noch > einmal zurück zum Thema: > > Jörg W. schrieb: >> ich fände es natürlich schon >> sinnvoller, wenn mehrere an einem Strang ziehen, statt dass sich jeder >> eine Faser aus dem Seil rauspickt und dann in seine Lieblingsrichtung >> zieht (das schließt auch Microchip mit ein, die ja auch nur noch darauf >> setzen, ihre Devicepacks zusammenzunageln, aber nichts mehr selbst in >> avr-libc mitmachen) > > Genau darum ging es mir. Ich finde es eben schade, dass da keine > (zumindest keine für mich als Außenstehenden erkennbare) Kooperation > stattfindet. > > Steven macht jetzt sein eigenes Ding. Beim "offiziellen" avr-gcc tut > sich seit langem nichts, bei der avr-libc sieht es (von außen) ähnlich > aus. > Für mich sind die Beiträge in diesen Threasd oder auch in > Beitrag "Näherung für ArcusTangens?" ja schon wertvolle > Lebenszeichen. > Und Microchip scheint sowieso allem erst einmal seine Marke aufdrücken > zu wollen und kämpft lieber allein. > Wenn man MPLABX (Linux) herunterlädt, dann findet man in der > Kompatibilitäts-Tabelle, dass der "XC8" Compiler nur die neuen (0er, > 1er) Attiny und die 0er Atmega supporten soll. De facto ist der neue > "XC8" aber nichts anderes als der steinalte avr-gcc 5.4.0 mit sämtlichen > DevicePacks, einschließlich der 0er Attiny. Die kennt aber der avr-gcc > nicht... v5 ist die erste Version, die Device-Specs unterstützt; folglich kann sich der Hardwarehersteller bequem auf die faule Haut legen und braucht keine irrsinnigen Aufwände in die Entwicklung der Tools zu investieren — im Compiler immerhin eine ganze Zeile C-Code pro neuem Device. Bis v7 kann man Devices der 0- und 1-Series in avrxmega2 einsortieren; avrxmega3 wurde erst mit v8 eingeführt. > Dazu scheinen die DevicePacks noch mit der heißen Nadel gestrickt zu > sein: > Beitrag "ATmega809 Timer CMP Interrupt funktioniert nicht" Nicht nur Device-Packs; die Datenblätter stimmen offenbar nicht mit der Hardware überein, so dass ATmega808/809 im Compiler momentan noch falsch beschrieben sind bzw. im falschem Mulilib-Set. Und für die Vectab werden dementsprechend falsche 2-Byte Einträge anstatt der korrekten 4-Byte Einträge erzeugt. > Johann L. schrieb: >> Zusätzlich gibt es Support für ATtiny* mit * = 202, 204, 402, 404, 406, >> 804, 806, 807, 1604, 1606, 1607. Der allerdings nicht aktiv ist, weil >> die Devices nicht von avr-gcc unterstützt werden und daher von configure >> ignoriert werden. > Wäre das denn großer Aufwand, die dem avr-gcc beizubringen? Ist schon drin: http://gcc.gnu.org/onlinedocs/gcc/AVR-Options.html > Unterscheiden die sich überhaupt von den 212, 214,... so dass der > Compiler etwas davon merkt? Der Compiler merkt nix davon, natürlich unter der Voraussetzung, dass der Herstellen nicht mal wieder Datenblätter verbockt hat. Der eigentliche Aufwand der Device-Unterstützung ist in der avr-libc und den avr/io*.h Headern. > Johann L. schrieb: >> Dafür gibt's Simulatoren, die auch für's Testing verwendet werden. >> simulavr für avr-libc und avrtest für avr-gcc. > Und die simulieren den Attiny 804 oder 814? In der GCC Testsuite sind nur "normale" Programme, d.h. normale Algorithmen etc. die keine (interne) I/O brauchen. Folglich reicht für diese Testsuite ein Core-Simulator wie avrtest vollkommen aus. Der Fokus bei diesem Simulator liegt auf Speed. Und dem Simulator kann man auch mehr RAM oder Flash geben als manchen realen Devices, so dass möglichst wenig Tests wegen zu kleinem Speicher failen. > Johann L. schrieb: >> Das übliche Vorgehen ist, Device-Packs zu verwenden > Das scheint mir eher eine Erleichterung für den Hersteller, der sich so > auf das absolute Minimum beschränken kann. Integration in bzw. > Weiterentwicklung von avr-gcc und avr-libc haben für Microchip offenbar > keine Priorität. Ist wohl so. Für die ultimative Leichtigkeit des Seins muss Microchip aber bis 2020 warten, wenn AVR aus dem GCC rausfliegt. https://gcc.gnu.org/PR92729 Oder das tut ein neues Geschäftsfeld für Microchip auf: Optimierungen deaktivieren, und für ein paar armselige Kröten Freischaltungen für die Optimierungen verticken. > Und avr-gcc und avr-libc scheinen auf Microchip zu warten. Da wartet keiner. Es ist einfach nicht immer Zeit dafür da. Is ja alles nur Hobby... > Mikado. Wer sich zuerst bewegt, hat verloren.
:
Bearbeitet durch User
Johann L. schrieb: > Oder das tut ein neues Geschäftsfeld für Microchip auf: Optimierungen > deaktivieren, und für ein paar armselige Kröten Freischaltungen für die > Optimierungen verticken. Irgendwie drängt sich dieser Eindruck auf... quelloffene Software "annektieren" und mit eigenem Branding als Microchip-Produkt verkaufen. Na, wenn sie meinen, dass sie damit mehr Geld verdienen als mit ihrer Hardware, dann ist es wohl Zeit sich von AVR (und PIC) zu verabschieden und in MCHP short zu gehen. Johann L. schrieb: > Ist wohl so. Für die ultimative Leichtigkeit des Seins muss Microchip > aber bis 2020 warten, wenn AVR aus dem GCC rausfliegt. Richtig. Aber wäre das alles nicht genau ein Grund für die Community, die freie Toolchain auf die letzte Version hochzuziehen und sich zumindest softwareseitig davon unabhängig zu machen, welches Bäuerchen Microchip gerade macht? Wenn die Community nicht mehr genug "Dampf" dafür hat, dann ist IMHO AVR ein Auslaufmodell. Trotz der neuen µCs, die ich sehr interessant finde. Gerade deshalb wäre es doch wichtig, die Kräfte zu bündeln. Das kann doch nicht daran scheitern, welches Tool zur Versionsverwaltung benutzt wird... Johann L. schrieb: > Es ist einfach nicht immer Zeit dafür da. Is ja > alles nur Hobby... Ja, klar, verstehe ich. Und irgendwann ist man aus dieser "Phase" ja auch raus. Wenn niemand nachkommt, dann bindet man sich ja nicht ewig daran, vor allem, wenn "nichts los" ist und der Hersteller einen hängen lässt. Die STM32G0 sind ja auch sehr interessant, mit sehr gutem Preis/Leistungs-Verhältnis und FOSS Toolchain und mehreren FOSS IDEs (was STM auch nicht zu verbergen versucht). NXP dito.
Np R. schrieb: > Wenn die Community nicht mehr genug "Dampf" dafür hat, dann ist IMHO AVR > ein Auslaufmodell. So wird es über kurz oder lang wohl sein. Bei ARM ist das Theater toolmäßig besser, da alle Spezifikationen (auch Debug) offen sind. Allderdings gibt's dort dafür nicht so eine schöne Rundum-Sorglos-Lösung, bei der Startup-Code, Linkerscripts, Vektortabellen und Headerfiles „aus der Dose raus“ in allen Tools schon enthalten sind und miteinander spielen, dass du so einfach "*gcc -mmcu=xxx -O -o foo.elf foo.c" schreiben könntest und allein davon zu einer lauffähigen Firmware kommst. Dort strickt dann wieder jeder sein eigenes Süppchen – teils mit eigenen Bugs, logisch.
Jörg W. schrieb: > Bei ARM ist das Theater toolmäßig besser, da alle Spezifikationen (auch > Debug) offen sind. Und die Community ist inzwischen größer und aktiver als AVR, und ARM hat hohe Priorität bei Linus selbst und auch im gcc. AVR fliegt da bald raus... Klar gibt's auch dort Bugs. Rundum-Sorglos-Lösungen gibt's aber auch, die man sogar überraschend schmerzfrei aufgesetzt bekommt. Mit IDE und allem drumherum. Da ist eher das "Problem" (wie so oft bei FOSS), dass es "zu viele" Alternativen gibt und man sich entscheiden muss. Aber damit kann ich leben. Störender finde ich, wenn ich z.B. hier lese https://www.avrfreaks.net/comment/2717726#comment-2717726 dass Microchip die Quellen "ihres" gcc nicht herausrückt. Das alleine wäre eigentlich für mich schon ein Grund, dem Hersteller den Rücken zu kehren, egal was sie für tolle neue µCs haben. Trotzdem schade. Zumal ich für meine Anwendungen nun wirklich keinen Cortex M7 brauche...
Np R. schrieb: > Rundum-Sorglos-Lösungen gibt's aber auch, die man sogar überraschend > schmerzfrei aufgesetzt bekommt. Mit IDE und allem drumherum. Leider gibt's die eben nur im Zusammenhang mit der IDE, und jeder macht dann was anderes. Beim AVR war das tatsächlich einfacher: da war die IDE nur ein Wrapper um die Kommandozeilen, und nicht noch der Generator für Startup-Code und Linkerscript und all so'n Kram. Dass sie sich zu blöd anstellen, ihren Opensource-Kram rauszurücken, ist natürlich beschämend.
Jörg W. schrieb: > da war die IDE nur ein Wrapper > um die Kommandozeilen, und nicht noch der Generator für Startup-Code und > Linkerscript und all so'n Kram. OK, das stimmt natürlich. Aber: Jörg W. schrieb: > Beim AVR war das tatsächlich einfacher: Ich sehe, Du hast Dich auch schon innerlich verabschiedet. Imperfekt. Du sprichst wie über einen kürzlich Verstorbenen. ;-)
Np R. schrieb: >> Beim AVR war das tatsächlich einfacher: > Ich sehe, Du hast Dich auch schon innerlich verabschiedet. Jein. Dienstlich haben wir uns, privat benutze ich sie schon noch. Außerdem bin ich ja nach wie vor in den diversen Projekten involviert.
Np R. schrieb: > Jörg W. schrieb: >> Bei ARM ist das Theater toolmäßig besser, da alle Spezifikationen (auch >> Debug) offen sind. > Und die Community ist inzwischen größer und aktiver als AVR, und ARM hat > hohe Priorität bei Linus selbst und auch im gcc. AVR fliegt da bald > raus... Dass ARM bei GCC "Priorität" hat, liegt daran, dass ARM und auch ST aktiv entwickeln und maintainen: Von den 4 ARM-Maintainern beim GCC sind 3 von ARM (oder haben zumindest E-Mail Adresse @arm.com), von den 4 AArch64-Maintainern sind es 4. Bei Write-After-Approval sind 29 Entwickler von ARM und 6 von ST. Vermutlich sind nicht mehr alle davon aktiv, aber die Zahlen zeigen eindrücklich , dass ARM und ST der Tool-Entwicklung adäquat Resourcen zukommen lassen. Und wie sieht es für AVR aus? 0 Entwickler von Atmel und 0 Entwickler von Microchip während der letzten 20 Jahre. Zwar hatte Atmel schließlich einige Entwickler für die GNU-Tools, deren Zahl kam aber vor allem durch die kurzen Standzeiten zustande. 6 Monate bis 1 Jahr, und danach waren sie wieder weg. Spricht zudem nicht wirklich für den Arbeitgeber... Einzig Senthil war noch etwas in die Tools involviert nachdem er Atmel verlassen hatte. Np R. schrieb: > Störender finde ich, wenn ich z.B. hier lese > https://www.avrfreaks.net/comment/2717726#comment-2717726 dass Microchip > die Quellen "ihres" gcc nicht herausrückt. Das alleine wäre eigentlich > für mich schon ein Grund, dem Hersteller den Rücken zu kehren, egal was > sie für tolle neue µCs haben. Hier schießt sich Microchip m.E. ins eingene Knie. Es herrscht die Mantalität vor, jede in Tool-Entwicklung geflossen Mann-Minute mit Gewinn aus den Tools selbst zu finanzieren. Mit seltsamen Blüten wie der genannten, jede Zeile an Inteleectual Property bärbeißig zu "verteidigen" statt es als Mittel zum Zweck zu erkennen, um Controller zu supporten. Man stelle sich vor, ab 2020 gäbe es keine Open-Source Tools mehr für ARM: kein GCC, kein LLVM. Hier kann sich jeder selbst ausmalen, in welche Richtung die Verkaufszahen für betroffene Controller gehen würden... Ob so etwas die eine AVR-Communits wirklich existiert oder ob es ein rein imaginäres Konstrukt ist, wird auch anhand der avr-gcc Bounty klar werden.
Johann L. schrieb: > 6 Monate bis 1 Jahr, und danach waren sie wieder weg. Spricht zudem > nicht wirklich für den Arbeitgeber. Ist mehr oder weniger typisch für indische IT, habe ich mir damals sagen lassen. Da herrscht keine großartige mentale Bindung an den Brötchengeber. Wenn die Firma in der Etage darüber mehr zahlt als die aktuelle, sind die Leute wieder weg. Kann man ihnen natürlich nicht verübeln, aber ist natürlich für langfristiges Arbeiten tödlich. Immer dran denken: das sind Aktiengesellschaften, die werden praktisch ausschließlich vom "shareholder value" getrieben. Wenn der (gefühlt, für die shareholder) fehlt, halten die shareholder ihre shares eben nicht mehr, und die nächsten kommen und legen fest, was weiter passiert. Siehe eben auch die Übernahme von Atmel durch Microchip. Langfristige Firmenausrichtungen kann man damit nur schwer organisieren.
Johann L. schrieb: > Es herrscht die > Mantalität vor, jede in Tool-Entwicklung geflossen Mann-Minute mit > Gewinn aus den Tools selbst zu finanzieren. Naja, Microchip wird ja wohl nicht ernsthaft glauben großen Mehrwert geschaffen zu haben mit dem Wrapper, den sie für den gcc geschrieben haben, um ihn als "neuen" Compiler XC8 und Bestandteil ihrer "neuen" IDE zu verkaufen. Johann L. schrieb: > Ob so etwas die eine AVR-Communits wirklich existiert oder ob es ein > rein imaginäres Konstrukt ist, wird auch anhand der avr-gcc Bounty klar > werden. Oh, das hatte ich noch gar nicht gesehen. Das bisherige Ergebnis ist allerdings auch etwas ... ernüchternd. Seit Anfang/Mitte Dezember hat sich nichts mehr getan. Ihr müsstet da vielleicht etwas mehr Werbung machen. - Andererseits weiß ich ja nicht, wie traurig Ihr seid, wenn Euch die Feierabend-Arbeit erspart bleibt... ;-) Und bei mir bleibt irgendwie das Geschmäckle, damit eine Firma zu unterstützen, die zwar gerne nimmt aber nicht gibt. (Jetzt komme mir keiner mit "Firmen sind ja keine Wohltätigkeits-Vereine sondern die wollen Geld verdienen." Das wäre eine mittelalterliche Trump-Vorstellung von Wirtschaft. Ein Geschäft hat immer zwei Gewinner, oder es findet nicht statt.)
Np R. schrieb: > Und bei mir bleibt irgendwie das Geschmäckle, damit eine Firma zu > unterstützen, die zwar gerne nimmt aber nicht gibt. Sagen wir mal so: zu tiefsten Atmel-Zeiten haben sie zumindest einige Jahre lang Eric Weddington durchgefüttert. Seither aber eben nichts mehr groß in der Richtung getan, und auch er wurde damals von der Toolchain-Arbeit immer weiter weg "dirigiert".
Jörg W. schrieb: > Np R. schrieb: >> Und bei mir bleibt irgendwie das Geschmäckle, damit eine Firma zu >> unterstützen, die zwar gerne nimmt aber nicht gibt. > > Sagen wir mal so: zu tiefsten Atmel-Zeiten haben sie zumindest einige > Jahre lang Eric Weddington durchgefüttert. Meine Wahrnehmung war, dass Eric wichtige Arbeit für Atmel / AVR geleistet hat, nicht dass er sich hat durchfüttern lassen.
Sollte heißen: sie haben ihn dafür bezahlt, dass er das, was er zuvor für WinAVR gemacht hat, bei ihnen integrieren hilft. Er durfte damit auch einen Teil seiner Zeit in sowas wie avr-libc stecken. Ist aber eben nun auch eine Weile her.
Np R. schrieb: > Naja, Microchip wird ja wohl nicht ernsthaft glauben großen > Mehrwert geschaffen zu haben mit dem Wrapper, den sie für > den gcc geschrieben haben, um ihn als "neuen" Compiler XC8 > und Bestandteil ihrer "neuen" IDE zu verkaufen. Das ist eine Mentalitätsfrage. Solche Fragen werden z.B. an unserem Standort anders gesehen als im Hauptquartier in Japan. Heißt natürlich auch, dass sinnvolle Betätigung nur in den Bereichen passiert, wo wir die Hoheit haben - und nur in einem Maß, dass wir sie auch behalten. Wie das bei Microchip ist, keine Ahnung.
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.