Forum: Compiler & IDEs Fork: avr-libc version 3, für xtiny


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Np R. (samweis)


Bewertung
0 lesenswert
nicht lesenswert
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...

von Np R. (samweis)


Bewertung
0 lesenswert
nicht lesenswert
P.S.: Bestimmt kommt jetzt als Antwort: "da musst Du Steven fragen."...

von Np R. (samweis)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Johann L. (gjlayde) Benutzerseite


Bewertung
2 lesenswert
nicht lesenswert

von Np R. (samweis)


Bewertung
0 lesenswert
nicht lesenswert
@ 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.

von Johann L. (gjlayde) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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.

von Np R. (samweis)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Johann L. (gjlayde) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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.

von Johann L. (gjlayde) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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...

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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).

von Johann L. (gjlayde) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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.

von Johann L. (gjlayde) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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.

???

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Hmm, dann hoffen wir mal, dass sie das zeitnah reparieren.

von Johann L. (gjlayde) Benutzerseite


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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
von Np R. (samweis)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Johann L. (gjlayde) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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
von Np R. (samweis)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Np R. (samweis)


Bewertung
0 lesenswert
nicht lesenswert
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...

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Np R. (samweis)


Bewertung
0 lesenswert
nicht lesenswert
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. ;-)

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Johann L. (gjlayde) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Np R. (samweis)


Bewertung
0 lesenswert
nicht lesenswert
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.)

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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".

von Johann L. (gjlayde) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.