mikrocontroller.net

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
0 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

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.