mikrocontroller.net

Forum: Compiler & IDEs gcc11 könnte das avr Backend verlieren


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.
Autor: dragon (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert

: Verschoben durch Moderator
Autor: 2⁵ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johann hat die Gründe dafür u.a. vor ca. 2 Jahren erläutert: 
Beitrag "Re: newlib fuer AVR?"

Er hat davor angekündigt, seinen Support für das AVR backend 
einzustellen, u.a. auch hier auf µc.net, mit Begründung. Leider finde 
ich den Beitrag nicht mehr.

Autor: Gustav (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Spielt das eine Rolle? Die Binaries werden bei gleichem Code seit der 
4.9.2 eigentlich immer größer. Ich habe immer mal neue Versionen 
getestet, zuletzt die 8.3.0, aber bin immer wieder zurück gegangen.

Autor: Peter D. (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gustav schrieb:
> Spielt das eine Rolle?

Nö.
Ich benutze noch den WINAVR. Der kann alles, was ich brauche und hat mir 
bisher auch noch keine Bugs eingebaut.

Autor: Alfed (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gustav schrieb:

> Spielt das eine Rolle? Die Binaries werden bei gleichem Code seit der
> 4.9.2 eigentlich immer größer.

Stimmt das überhaupt? Eine Tabelle wäre dazu geeignet mich zu 
überzeugen.

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich denke nicht: zwar stelle ich ein gewissen "Atmen" der Codegrößen 
fest, also mal kleiner, mal größer, aber ein genereller Trend zu größer 
kann ich nicht bestätigen. Gefühlt wird es eher kleiner.

Autor: Ver Zweifelter (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
dragon schrieb:
> gcc11 könnte das avr Backend verlieren

Klingt so als ob ich bald keinen Code mehr für einen AVR
erzeugen könnte/dürfte.

Ich glaub ich bring mich um.

Zwanzigster Stock vom Hochhaus ist vermutlich ideal ....

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ver Zweifelter schrieb:
> Zwanzigster Stock vom Hochhaus ist vermutlich ideal ....

MicroChip wird vermutlich ein Sprungtuch spannen.

Autor: Gustav (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hängt natürlich sehr vom Code ab. Aber bei umfangreichen Projekten 
zumindest bei mir ist die Codegröße beim 4.9.2 immernoch am kleinsten. 
Und gerade da stört es ja. Wenn man auf einem ATMega168 (Bootloader 
vorhanden; Code wurde schon extrem optimiert) bei 15358 Bytes ist und es 
muss noch eine Funktion rein und der 4.9.2 schafft einem 400 Byte Platz, 
ist das Gold wert.

Es gibt noch eine ganze Reihe von Optimierungsparametern, welche helfen 
(und auch individuell unterschiedlich sind). Die kann man auch 
durchprobieren. Aber auch der 4.9.2 hat welche und am Ende war der immer 
besser als ein 5er, 6er oder 8er gcc. Leider. Ich hätte ja auch gerne 
noch kleineren Code. ;)

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gustav schrieb:
> Es gibt noch eine ganze Reihe von Optimierungsparametern, welche helfen
> (und auch individuell unterschiedlich sind). Die kann man auch
> durchprobieren. Aber auch der 4.9.2 hat welche und am Ende war der immer
> besser als ein 5er, 6er oder 8er gcc. Leider. Ich hätte ja auch gerne
> noch kleineren Code. ;)

Der wesentliche Faktor ist dabei natürlich Dein C/C++-Code ...

Autor: Gustav (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, genau deswegen war das der erste Satz.

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
3 lesenswert
nicht lesenswert
FYI, the avr backend of GCC (avr-gcc, avr-g++) has been deprecated for 
v10, release schedule spring 2020.


If the backend is not re-written to use a different scheme to model 
condition-code, it will be removed from GCC in v11, release schedule 
spring 2021.


https://gcc.gnu.org/ml/gcc-patches/2019-09/msg01256.html

Autor: TriHexagon (Gast)
Datum:

Bewertung
8 lesenswert
nicht lesenswert
Ziemlich traurig, dass es Atmel nicht geschafft hat wenigstens einen 
einzigen Entwickler einzustellen, der am AVR-Backend arbeitet. Soweit 
hätte es nicht kommen müssen...

Aber gut AVR ist eh auf dem absteigenden Ast, für mich persönlich habe 
ich erst letztes Jahr entschieden keine Hobbyprojekte mehr mit dem AVR 
anzufangen, weil ich mit einem typischen ARM Cortex M0+/M3/M4/M7 
schneller ans Ziel komme. War aber trotzdem eine schöne 
8Bit-Architektur.

Autor: Gustav (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jemand müsste die ganzen rein AVR-optimierenden Verbesserungen, die im 
neuesten GCC existieren, für den 4.9.2 zurück portieren. ;)

Autor: Boris (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
TriHexagon schrieb:

> Aber gut AVR ist eh auf dem absteigenden Ast, für mich persönlich habe
> ich erst letztes Jahr entschieden keine Hobbyprojekte mehr mit dem AVR
> anzufangen, ...

Damit treibst du Microchip/Atmel in den Kokurs. Die sind auf deine 
Hobbyprojekte angewiesen. Kannst du das vor deinem Gewissen 
verantworten?

Autor: Boris (Gast)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
Edit: Konkurs

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Ist schon schade.

Andererseits arbeitet ja nicht nur der GCC recht intesiv an seiner 
eigenen Abschaffung. Firefox und selbst Linux (systemd) tun ja auch in 
letzter Zeit alles Menschnmögliche, um potentielle Nutzer und Entwickler 
möglichst langfristig zu vergraulen.

Hatte Atmel zuletzt eigentlich für AVR mal einen (eigenen) C-Compiler im 
Portfolio? WIMRE haben die doch immer vom avr-gcc gelebt.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Sven P. schrieb:
> WIMRE haben die doch immer vom avr-gcc gelebt.

Nein. Sie haben den GCC viele Jahre lang reichlich ignoriert. Es war 
damals Eric Weddingtons Verdient, mit WinAVR ein brauchbares Package zu 
schaffen, damit auch Windows-Nutzer vom AVR-GCC aufwandsarm profitieren 
konnten (die Nutzer unixoider Systeme konnten das auch davor schon). 
Erst ab dem Moment (und dem Aufstieg von Arduino) rückte der GCC bei 
Atmel allmählich ins Blickfeld.

Davor haben sie jahrelang voll auf ihre Kooperation mit IAR gesetzt.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Sven P. schrieb:
>> WIMRE haben die doch immer vom avr-gcc gelebt.
>
> Nein. Sie haben den GCC viele Jahre lang reichlich ignoriert. Es war
> damals Eric Weddingtons Verdient, [...]
>
> Davor haben sie jahrelang voll auf ihre Kooperation mit IAR gesetzt.
Ahh, das meinte ich. IAR hab ich wohl ganz verdrängt.

Autor: pumuggl (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
> Kooperation mit IAR

Mit IAR macht man ja auch nichts falsch.

Autor: Falk B. (falk)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
pumuggl schrieb:
>> Kooperation mit IAR
>
> Mit IAR macht man ja auch nichts falsch.

Nur daß der gemeine Bastler den Preis für den Comiler nicht zahlen 
will/kann. Was kostet der aktuell?

Autor: Mw E. (Firma: fritzler-avr.de) (fritzler)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
pumuggl schrieb:
> Mit IAR macht man ja auch nichts falsch.

Ich arbeite auf Arbeit mit dem IAR und halte das Ding für den größten 
Dreck überhaupt.
Es ist echt krass, dass dies geschafft haben von v7 auf v8 noch 
schlechter zu werden.

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
5 lesenswert
nicht lesenswert
Ich mache mir da keine allzu großen Sorgen:

Erstens hat der derzeitige AVR-GCC keinen Selbstzerstörungsmechanismus
eingebaut, und der Verschleiß von Software hält sich i.Allg. auch in
Grenzen. Wenn man seinen GCC also gut behandelt, wird er auch in 10 oder
20 Jahren noch treu seinen Dienst tun.

Zweitens wird derzeit an einem AVR-Backend für LLVM gebaut. Vielleicht
wird es ja rechtzeitig bis Mai 2021 fertig.

Und falls alle Stricke reißen: Die GNU Binutils werden den AVR sicher
bis an sein Lebensende (und noch länger) unterstützen, so dass man immer
die Möglichkeit hat, den verzuckerten Assembler¹ durch unverzuckerten zu
ersetzen (die Ärzte warnen ja sowieso vor zu viel Zucker) ;-)

Und für die Schleckermäuler, die auf den Zucker nicht verzichten wollen
(ich selber gehöre auch dazu): Es gibt neben dem AVR weitere günstige
Mikrocontroller, die auch von GCC 11+ unterstützt werden.

——————————
¹) das ist C, nach Aussage von Niklaus Wirth :)

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Mw E. schrieb:
> Ich arbeite auf Arbeit mit dem IAR und halte das Ding für den größten
> Dreck überhaupt.

Verwechsle bitte nicht den Compiler mit der IDE. Wir vergleichen 
schließlich hier mit GCC, nicht mit Eclipse, Arduino-IDE, Atmel Studio 
oder dergleichen.

Den Compiler von IAR fand ich zu der Zeit, als ich ihn hin und wieder 
benutzt habe, wirklich gut. Das Einzige, was ich am GCC-Port Mist fand 
ist, dass er nur deren blödes proprietäres Binärformat unterstützt hat, 
obwohl sie ansonsten für viele andere Targets ELF in der Tasche haben 
und auch hätten den AVR-Teil auf ELF setzen können. Dann gäbe es 
plötzlich wieder viel mehr Ökosystem. Das zweite, was natürlich an IAR 
Mist ist, dass sie, obwohl der reine Compiler als Kommandozeilenprogramm 
ja nun so gut wie keine OS-Abhängigkeit hat, ihn immer nur für Windows 
gebaut haben. Ein Linux-Binary wäre mir dazumals deutlich lieber 
gewesen.

Aber inzwischen habe ich ihn schon eine ganze Weile nicht mehr benutzen 
müssen.

Falk B. schrieb:
> Nur daß der gemeine Bastler den Preis für den Comiler nicht zahlen
> will/kann.

Selbst in der Industrie ist der Preis durchaus ein Punkt. Als ich damals 
bei Atmel war, kam mir mal eine Support-Anfrage eines FAE rein, dessen 
(deutsche, große) Kunden von IAR auf GCC umstellen wollten: sie wollten 
eine große Build-Farm für nightly builds aufbauen (was man heute wohl so 
"Continuous Integration" nennen würde), und die wäre mit IAR schlicht 
nicht finanzierbar gewesen.

Autor: pumuggl (Gast)
Datum:

Bewertung
-4 lesenswert
nicht lesenswert
> IAR und halte das Ding für den größten Dreck überhaupt.

Auch wenn man es ostinat wiederholt wird es nicht wahrer.

Funfact:
Eine Software mit überwiegendem Anteil an Gleitkommarechnung
(ARM M4/Float) läuft mit IAR übersetzt ca. 50 % schneller als
mit MDK/Keil oder GCC.
Und ja, die entsprechenden Schalter sind bei allen Compilern an.

Aber du darfst das ja gerne weiterhin als Dreck bezeichnen.

LED-Blinker profitieren eben eher nicht vom IAR-Compiler.

Autor: Vincent H. (vinci)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
pumuggl schrieb:
>> IAR und halte das Ding für den größten Dreck überhaupt.
>
> Auch wenn man es ostinat wiederholt wird es nicht wahrer.
>
> Funfact:
> Eine Software mit überwiegendem Anteil an Gleitkommarechnung
> (ARM M4/Float) läuft mit IAR übersetzt ca. 50 % schneller als
> mit MDK/Keil oder GCC.

Bench or GTFO.

Autor: Mw E. (Firma: fritzler-avr.de) (fritzler)
Datum:
Angehängte Dateien:

Bewertung
2 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Verwechsle bitte nicht den Compiler mit der IDE. Wir vergleichen
> schließlich hier mit GCC, nicht mit Eclipse, Arduino-IDE, Atmel Studio
> oder dergleichen.

Nunja, das ist ein System. Bei Arduino redet man ja auch nicht nur von 
den Platinen.
Zum IAR gehört nunmal einiges dazu.
Den Debugger will man ja auch nutzen?
Inzwischen schaffts der IAR sogar, dass die Breakpoints verrutschen beim 
hinzufügen von Codezeilen.

Aber der Compiler selbst ist auch verbuggt.
Bei einem großen mbedTLS struct hat er andere Adressen ausgerechnet beim 
Zugriff über . und ->
Da sah aus als hätt der da ein alignment vergeigt.
ssl_p ist der Pointer mit Zugriff über -> und sslvars direkt das struct 
mit Zugriff über .
Die Adressen sind anders...
Dementsprechend hat der TLS Stack nicht funktioniert.
(Siehe Anhang)
Den Support kannste in der Pfeife rauchen, der wurde zu einem humanen 
RSS Feed, aber in den Changelogs tauchte nie was auf was das Problem 
anging.
Während der embeddet war der Support nicht erreichbar und wir brauchten 
ein Plugin für nen neuren SoC für den v7.

Also ja, der IAR IST! scheisse.

pumuggl schrieb:
> Auch wenn man es ostinat wiederholt wird es nicht wahrer.

Sagt der IAR Mitarbeiter ;) ?
So oft wie du das hier einstreust kann ichs mir nicht wirklich anders 
vorstellen.
Fix mal lieber den Bug im Anhang.

Vincent H. schrieb:
> pumuggl schrieb:
>>> IAR und halte das Ding für den größten Dreck überhaupt.
>>
>> Auch wenn man es ostinat wiederholt wird es nicht wahrer.
>>
>> Funfact:
>> Eine Software mit überwiegendem Anteil an Gleitkommarechnung
>> (ARM M4/Float) läuft mit IAR übersetzt ca. 50 % schneller als
>> mit MDK/Keil oder GCC.
>
> Bench or GTFO.

DITO

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Mw E. schrieb:
> Jörg W. schrieb:
>> Verwechsle bitte nicht den Compiler mit der IDE. Wir vergleichen
>> schließlich hier mit GCC, nicht mit Eclipse, Arduino-IDE, Atmel Studio
>> oder dergleichen.
>
> Nunja, das ist ein System.

Sehe ich nicht so.

Du kannst den IAR-Compiler komplett auf der Kommandozeile benutzen (den 
ganzen Lizenzsalat musst du natürlich laufen haben). Haben wir jahrelang 
gemacht.

> Den Debugger will man ja auch nutzen?

Das ist der Punkt mit dem für AVR nicht unterstützten ELF-Format: würden 
sie ELF als Objektformat auch bei AVR unterstützen, wäre man nicht auf 
deren Debugger angewiesen, sondern könnte jeden anderen Debugger 
(einschließlich Atmel Studio) ebenfalls nehmen.

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Für m68k wird gerade Geld gesammelt, um jemand für die cc0 -> cc_mode 
Taransition anzuheuern :-/

http://gcc.gnu.org/ml/gcc/2019-10/msg00132.html

Autor: Veit D. (devil-elec)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

sagt mal Leute könnt ihr alle nicht lesen?

Wo steht hier das AVR komplett aus dem Support rausfliegt?
https://www.phoronix.com/scan.php?page=news_item&px=GCC-11-Dropping-CC0

Es geht erstens um alte µC wie der 68000 (Amiga und Atari Generation) 
und paar andere sehr alte Teile die bestimmt schon lange nicht mehr 
produziert werden. Also erzählt bitte keinen Mist.

Jörg W., irgendwie solltest du das doch besser wissen wenn du in der 
Materie tiefer drin steckst als Entwickler.

Ich vergleiche das mit der Linuxkernelentwicklung. Hornalte Hardware 
fliegt irgendwann raus. Es muss dann ein Entwickler geben der sich um 
die betagten Teile kümmert oder die Community.

Also bitte nicht immer gleich absolute Weltuntergangspanik verbreiten.

Edit:
Jörg und Johann könnten ja einmal bitte auflisten welche alten AVR µC 
das betrifft damit die Leute hier wieder beruhigt schlafen können.  :-)

: Bearbeitet durch User
Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
5 lesenswert
nicht lesenswert
Veit D. schrieb:
> Wo steht hier das AVR komplett aus dem Support rausfliegt?

Er fliegt aus der weiteren Entwicklung raus, nicht mehr, aber auch nicht 
weniger.

Johann hat die Gründe bereits dargelegt.

Wie Yalu schon nannte, deshalb verrottet der alte (Compiler-)Code nicht. 
Es gibt ja einige Leute (auch hier im Thread), die mit mittlerweile sehr 
betagten Compilerversionen durchaus sehr zufrieden sind. Andererseits, 
von neueren Entwicklungen (wie Johanns Arbeiten für 64-bit-Gleitkomma) 
ist man eben mit alten, "abgehangenen" Versionen abgekoppelt. Irgendwann 
werden auch die Compilerversionen, für die man überhaupt noch Patches 
anbringen darf oder Bugs melden, dann end of life sein. Dann kann man 
entweder mit dem leben, was existiert, oder es braucht eine andere 
Plattform (LLVM …).

Autor: Veit D. (devil-elec)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

muss nochmal nachfragen. Ich lese in dem Link nichts davon das der 
gesamte AVR Support rausfliegt. Ich lese das nur alte Targets, also alte 
µC rausfliegen. Reden wir aneinander vorbei oder verstehe ich das falsch 
oder ist der Artikel unvollständig?

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
5 lesenswert
nicht lesenswert
Veit D. schrieb:
> Ich lese in dem Link nichts davon das der gesamte AVR Support
> rausfliegt.

Dann lies doch einfach mal Johanns Erläuterungen, die im zweiten Beitrag 
verlinkt worden sind.

Autor: 2⁵ (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Ein "Target" ist die komplette Unterstützung für eine CPU Familie. Also 
der gesamte AVR Support!

Autor: Veit D. (devil-elec)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich möchte ja nicht meckern. Aber Johanns Beitrag/der Thread ist von 
2017. Seitdem wird viel passiert sein. Und Atmel hat viele AVR 
Controller Familien und nicht nur Eine. Ich kann nicht glauben das 
Gesamt AVR aus dem GCC rausfliegt. Warum auch. Die werden doch in 
Millionen von Geräten eingebaut und es gibt unzählige Programmierer die 
das alles tagtäglich nutzen. Also entweder bin ich total bekloppt und 
verstehe absolut nichts oder hier gibt es ein riesengroßes 
Missverständnis.

Autor: Veit D. (devil-elec)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich glaube ich habe das doch missverstanden. Habe das hier inkl. Link
https://gcc.gnu.org/ml/gcc-patches/2019-09/msg01256.html
gelesen und glaube jetzt besser zu verstehen um was geht. Es geht nicht 
darum alte µC rauszuwerfen sondern das gesamte AVR Grundgerüst ist 
hoffnungslos veraltet und müsste auf den neuesten Stand gebracht werden. 
Das wäre natürlich Schade wenn das versauern würde.

Großes Entschuldigung für mein Missverständnis!!!

Auf der anderen Seite folgt daraus die Frage wäre es so schlimm wenn es 
nicht mehr der GCC wäre den wir dann irgendwann nutzen? Für mich als 
Anwender der ja nur an der Oberfläche kratzt vom gesamten Toolchain 
Softwarepaket wenn ich C/C++ programmiere, spielt es doch im Grunde 
keine Rolle was da unten drunter ackert und compliert. Hauptsache C ist 
C und C++ ist C++. Oder fällt damit auch unser C/C++ hinten runter? Wenn 
ja würde ich mir vielleicht überlegen zu spenden. Wobei daran eigentlich 
ganze Firmen ein Interesse haben sollten.

Autor: Ntldr -. (ntldr)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Richtig verstanden. Das Problem ist, dass damit für AVR auch keine neuen 
gcc Compilerversionen mehr geben wird. Im Backend ist das anscheinend 
weniger ein Problem, aber das gemeinsame Frontend (von dem alle 
Prozessorarchitekturen profitieren) wird dadurch dann auch nicht mehr 
aktualisiert. Das betrifft dann sowohl Bugfixes als auch neue Features 
(z.B. C++23 und C2x Unterstützung). Dadurch entfällt natürlich auch 
jeglicher traditioneller gcc Support für AVR. Langfristig  wird man 
dadurch auch inkompatible Libraries haben, die einfach einen moderneren 
Compiler voraussetzen die damit auf AVR nicht mehr nutzbar sind.

Wie relevant das für einen ist, ist letztlich sehr individuell. Für mich 
persönlich ist das ein absolutes Ausschlusskriterium für AVR, andere 
hier im Thread sind anscheinend auch mit dem mitlerweile antiken gcc 4.9 
glücklich. Den gcc10 wird man natürlich unabhängig davon ganz normal 
weiter für AVR nutzen können.

Autor: Peter D. (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> (wie Johanns Arbeiten für 64-bit-Gleitkomma)

Ab welcher Version ist denn das enthalten?

Autor: Michael F. (michaelfu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mw E. schrieb:
> Aber der Compiler selbst ist auch verbuggt.
> Bei einem großen mbedTLS struct hat er andere Adressen ausgerechnet beim
> Zugriff über . und ->
> Da sah aus als hätt der da ein alignment vergeigt.
> ssl_p ist der Pointer mit Zugriff über -> und sslvars direkt das struct
> mit Zugriff über .
> Die Adressen sind anders...
> Dementsprechend hat der TLS Stack nicht funktioniert.
> (Siehe Anhang)

Moin,

was war denn die Antwort von IAR bezüglich dieses Compiler Bugs?

Autor: Experte (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Wie Yalu schon nannte, deshalb verrottet der alte (Compiler-)Code nicht.

Oh doch, genau so verrottet Software, und zwar schneller als einem lieb 
ist. Zwei, drei Jahre ohne Support und Weiterentwicklung bedeuten den 
Tod für Software. Bei einem Compiler bedeutet das auch zwangsweise den 
Tod der Plattform.

Ist ja auch logisch: Es kommt kein neuer Nutzer zu einer Plattform dazu, 
wenn er feststellt dass es keinen aktuellen Compiler gibt. Und die 
Altbenutzer suchen Alternativen für die sterbende Plattform. So 
beschäftigen sich immer weniger Menschen damit, und das Ding 
verschwindet in der Versenkung. Ein ganz normaler Prozess in der 
Software.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Experte schrieb:
> Bei einem Compiler bedeutet das auch zwangsweise den
> Tod der Plattform.
>
> Ist ja auch logisch: Es kommt kein neuer Nutzer zu einer Plattform dazu,
> wenn er feststellt dass es keinen aktuellen Compiler gibt.

Silabs baut heute noch 8051 und liefert mit deren IDE zusammen einen 30 
Jahre alten Keil Compiler aus! Da kann man heute noch die Nostalgie von 
C89 genießen und man muss shiften und Bytes einzeln tauschen anstatt 
einfach durch ne Zweierpotenz zu dividieren und auch die ganzen anderen 
Tricks die man früher gelehrt hat um dem Compiler zu helfen muss man 
anwenden weil der Compiler so simple Optimierungen noch nicht auf die 
Reihe bekommt. Dennoch erfreut der BusyBee sich größter Beliebtheit weil 
er so konkurrenzlos billig ist, daß der Compiler 30 Jahre alt ist, damit 
dürfen sich dann die Entwickler rumschlagen nachdem ihre Bosse 
beschlossen haben diesen Chip zu verwenden, das spielte bei der 
Entscheidung keine Rolle.

Über den Preis geht alles.

Und genau da muss Microchip dran arbeiten, sonst will bald wirklich 
keiner mehr AVR kaufen, nicht etwa weil der Compiler alt ist (danach 
fragt niemand, ein passender Compiler ist im Atmelstudio immer 
automatisch enthalten, auch in 30 Jahren noch, wie alt der ist 
interessiert die Entscheider nicht) sondern das 
Preis/Leistung-Verhältnis der Hardware entscheidet das.

Autor: Rudolph R. (rudolph)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Experte schrieb:
> Ist ja auch logisch: Es kommt kein neuer Nutzer zu einer Plattform dazu,
> wenn er feststellt dass es keinen aktuellen Compiler gibt.

Naja, wann war der mit AS7 ausgelieferte GCC denn mal wirklich aktuell?

Microchip liefert immer noch GCC 5.4.0 aus.
Der ist aber auch erst etwas über drei Jahre "alt".

Und der ARM GCC 6 ist etwas über zwei Jahre "alt".


Nur, was Major Releases angeht dreht man bei GCC sowieso seit GCC 5 viel 
stärker am Rad als je zuvor:

https://gcc.gnu.org/develop.html


Der XC8 Compiler von Microchip basiert für AVR übrigens auf dem GCC, 
schauen wir mal, ob aus der Richtung was kommt.

Autor: Veit D. (devil-elec)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter D. schrieb:
> Jörg W. schrieb:
>> (wie Johanns Arbeiten für 64-bit-Gleitkomma)
>
> Ab welcher Version ist denn das enthalten?

Hallo Peter,

noch ist es nicht enthalten. Johann und andere arbeiten daran.
Beitrag "64 Bit float Emulator in C, IEEE754 compatibel"

Autor: Veit D. (devil-elec)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ntldr -. schrieb:
> Richtig verstanden.
> ...

Alles klar.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Experte schrieb:
>> Wie Yalu schon nannte, deshalb verrottet der alte (Compiler-)Code nicht.
>
> Oh doch, genau so verrottet Software, und zwar schneller als einem lieb
> ist. Zwei, drei Jahre ohne Support und Weiterentwicklung bedeuten den
> Tod für Software.

Das erzähle jetzt mal bitte denen, die hier bekundet haben, dass sie 
nach wie vor für AVR am liebsten GCC 4.9.2 benutzen. Der ist vor 5 
Jahren herausgegeben worden.

Ganz offensichtlich ist er alles andere als "tot".

Autor: 900ss D. (900ss)
Datum:

Bewertung
5 lesenswert
nicht lesenswert
Beruflich muss ich mit GCC 3.x.x arbeiten :) Allerdings nicht für AVR. 
Ist auch wurscht.

Aber ausgeleierte Bits produziert der nicht ;)

Autor: Mw E. (Firma: fritzler-avr.de) (fritzler)
Datum:
Angehängte Dateien:

Bewertung
-1 lesenswert
nicht lesenswert
Michael F. schrieb:
> was war denn die Antwort von IAR bezüglich dieses Compiler Bugs?

Das hatte ich wohl nicht genau genug beschrieben.
Diesen Bug hab ich reported über den Emailsupport (wegen Screenshots und 
Codezeilen). Danach gabs erst ne Mail zurück, dass das Pointerproblem 
angepackt wird. Danach kamen nur mails zurück, dass eine neue Version 
raus ist. (was ich als human RSS Feed bezeichnet hatte)
Aber in den Changelogs stand nie was über das Problem.
Nach ein paar Iterationen hatte ich keine Lust mehr und habs per 
Workaround gelöst.

Sehr geil war bei einer Neuinstallation auch die Lahmlegung meines 
Rechners durch das unendlich erstellen desselben Prozesses beim 
Installer.
doinst ein Treiberinstaller, sehr oft gestartet vom IAR installer.
(siehe Anhang)

@Jörg W.
Jagut, da haben wir andere Ansichten was da zusammengehört und was 
nicht.

Autor: Philipp Klaus K. (Firma: Albert-Ludwigs-Universität) (pkk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Silabs baut heute noch 8051 und liefert mit deren IDE zusammen einen 30
> Jahre alten Keil Compiler aus! Da kann man heute noch die Nostalgie von
> C89 genießen und man muss shiften und Bytes einzeln tauschen anstatt
> einfach durch ne Zweierpotenz zu dividieren und auch die ganzen anderen
> Tricks die man früher gelehrt hat um dem Compiler zu helfen muss man
> anwenden weil der Compiler so simple Optimierungen noch nicht auf die
> Reihe bekommt. Dennoch erfreut der BusyBee sich größter Beliebtheit weil
> er so konkurrenzlos billig ist, daß der Compiler 30 Jahre alt ist, damit
> dürfen sich dann die Entwickler rumschlagen nachdem ihre Bosse
> beschlossen haben diesen Chip zu verwenden, das spielte bei der
> Entscheidung keine Rolle.

Es gibt ja noch andere Compiler für MCS-51. Wer SiLabs einsetzt, ist 
nicht auf Keil angewiesen.

Autor: Karl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
900ss D. schrieb:
> Beruflich muss ich mit GCC 3.x.x arbeiten :) Allerdings nicht für AVR.
> Ist auch wurscht.

Lass mich raten: Tricore für ASIL Anwendung?

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl schrieb:
> Lass mich raten

SPARC V8 :)

Es gibt auch neuere GCC dafür. Aber ich darf als OS RTEMS  verwenden 
welches samt Toolchain genau in dieser Version vorgegeben ist.
Aber der alte GCC tut seinen Dienst. Weshalb sollte er auch nicht.
Kann die Bedenken da oben nicht verstehen. Klar kann man die "neuen 
Features" oder was auch immer nicht verwenden. Ist aber kein Drama.

: Bearbeitet durch User
Autor: Gustav (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Was für Vorgaben. xD Musst du zusätzlich noch im ungeheizten Keller im 
Stehen programmieren oder so? ;)

Autor: Larry (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> doinst ein Treiberinstaller, sehr oft gestartet vom IAR installer.

Das wird wohl die Version fuer AVR gewesen sein?
Solchen (Jungo-)Treibermurks kenne ich nur von Atmel.
Da musste man das haendisch im Nachgang mit:
wdreg.exe -inf windrvr6.inf install reparieren.

Ein Headerproblem hatte ich mal fuer STM32L053.
Aber die wurden, so wurde mir versichert, auch nur automagisch
aus den SVF-Dateien von ST generiert.
Und das Problem konnte ich natuerlich selber fixen.

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Rudolph R. schrieb:
> Nur, was Major Releases angeht dreht man bei GCC sowieso seit GCC 5
> viel stärker am Rad als je zuvor:

Nö, in jedem Frühjahr gibt es eine neue Major Release wie eh und je. 
Einzig das Versionierungsschema wurde umgestellt.

Peter D. schrieb:
> Jörg W. schrieb:
>> (wie Johanns Arbeiten für 64-bit-Gleitkomma)
>
> Ab welcher Version ist denn das enthalten?

Zunächst müssen Hindernisse aus dem Weg geräumt werden, d.h. dass 
avr-gcc 64-Bit (long) double unterstützt.  Das sind 2 Zeilen im Compiler 
und dann mehr als 400 Zeilen drumrum...

https://gcc.gnu.org/PR92055

Und die avr-libc muss etwas dynamischer werden.  Angefangen damit, 
dass Alias-Symbole für double nur dann definiert werden, wenn 
double=float ist.

https://savannah.nongnu.org/bugs/?57071

Wann und wo welche double-Routinen hinzukommen ist auch noch nicht klar. 
Die obigen Patches enthalten keine einzige double-Funktion, ist alles 
nur Vorgeklimper.

Autor: Mw E. (Firma: fritzler-avr.de) (fritzler)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Vincent H. schrieb:
> pumuggl schrieb:
>>> IAR und halte das Ding für den größten Dreck überhaupt.
>>
>> Auch wenn man es ostinat wiederholt wird es nicht wahrer.
>>
>> Funfact:
>> Eine Software mit überwiegendem Anteil an Gleitkommarechnung
>> (ARM M4/Float) läuft mit IAR übersetzt ca. 50 % schneller als
>> mit MDK/Keil oder GCC.
>
> Bench or GTFO.

Natürlich kommt da nix mehr vom pro IAR Troll.
Die genannten fuckups kann er auch nicht entkräften.

Larry schrieb:
>> doinst ein Treiberinstaller, sehr oft gestartet vom IAR installer.
>
> Das wird wohl die Version fuer AVR gewesen sein?
> Solchen (Jungo-)Treibermurks kenne ich nur von Atmel.
> Da musste man das haendisch im Nachgang mit:
> wdreg.exe -inf windrvr6.inf install reparieren.

Der IAR installiert normalerweise u.a. was für Atmel ARMs (ist der ARM 
IAR), aber das hatte ich abgewählt.
J-Link reicht ;)
Der IAR Support meinte dann "ihre installation ist kaputt", NO SHIT 
SHERLOCK!

Autor: Markus M. (mmvisual)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Gustav schrieb:
> Hängt natürlich sehr vom Code ab. Aber bei umfangreichen Projekten
> zumindest bei mir ist die Codegröße beim 4.9.2 immernoch am kleinsten.
> Und gerade da stört es ja. Wenn man auf einem ATMega168 (Bootloader
> vorhanden; Code wurde schon extrem optimiert) bei 15358 Bytes ist und es
> muss noch eine Funktion rein und der 4.9.2 schafft einem 400 Byte Platz,
> ist das Gold wert.
>
> Es gibt noch eine ganze Reihe von Optimierungsparametern, welche helfen
> (und auch individuell unterschiedlich sind). Die kann man auch
> durchprobieren. Aber auch der 4.9.2 hat welche und am Ende war der immer
> besser als ein 5er, 6er oder 8er gcc. Leider. Ich hätte ja auch gerne
> noch kleineren Code. ;)

"Code wurde schon extrem optimiert"

Völlig falscher Ansatz, da wurde wohl im Vorfeld das Projekt völlig 
falsch eingeschätzt und der falsche µC für die geforderte Aufgabe 
verwendet.

Autor: Gustav (Gast)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
Das Projekt ist stetig gewachsen und begann in einer Zeit, als der 
Mega328 noch nicht erhältlich war. Der 168er reichte anfangs auch 
völlig, aber durch neue Features, Lokalisation, Dinge, die erst gar 
nicht geplant waren, wuchs es immer weiter, was nicht zuletzt an der 
guten Kundenresonanz lag. Irgendwann kommt man nunmal an eine Grenze.

Wir gehören nicht zu den Firmen, die ihre alte Hardware vernachlässigen 
und bieten auch nach Jahren noch Updates an, sofern möglich. Ich 
persönlich finde es auch peinlich, wie Unterhaltungsgerätehersteller das 
heutzutage handhaben.

Autor: Markus M. (mmvisual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gustav schrieb:
> Das Projekt ist stetig gewachsen und begann in einer Zeit, als der
> Mega328 noch nicht erhältlich war. Der 168er reichte anfangs auch
> völlig, aber durch neue Features, Lokalisation, Dinge, die erst gar
> nicht geplant waren, wuchs es immer weiter, was nicht zuletzt an der
> guten Kundenresonanz lag. Irgendwann kommt man nunmal an eine Grenze.

Ich hatte auch schon mal ein ähnliches Problem. Der Kunde wollte immer 
mehr, dann habe ich ihm ein Redesign verkauft. Wenn sich da der Aufwand 
in Grenzen hält (z.B. nur größeren µC vom gleichen Hersteller), dann ist 
das schlussendlich kostengünstiger und hat selbst als Entwickler wieder 
mehr Freiheiten um das Produkt noch besser hin zu bekommen.

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Johann L. schrieb:
> Peter D. schrieb:
>> Jörg W. schrieb:
>>> (wie Johanns Arbeiten für 64-bit-Gleitkomma)
>>
>> Ab welcher Version ist denn das enthalten?
>
> Zunächst müssen Hindernisse aus dem Weg geräumt werden, d.h. dass
> avr-gcc 64-Bit (long) double unterstützt.

Ist upstream, siehe

https://gcc.gnu.org/install/configure.html#avr

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Cool!

Ich bau bei nächstbester Gelegenheit deinen Patch in die avr-libc ein.

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Ich bau bei nächstbester Gelegenheit deinen Patch in die avr-libc ein.

Hast du eine Idee, wo / wie man -print-multi-lib und 
-print-multi-directory in avr-libc unterstützen könnte?

: Bearbeitet durch User
Autor: Veit D. (devil-elec)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Cool!
>
> Ich bau bei nächstbester Gelegenheit deinen Patch in die avr-libc ein.

Würdest du das kundtun wenn eingebaut damit ich eine neue Toolchain 
bauen kann? Falls du die Versionsnummer änderst sehe ich das auch. Danke 
euch Fleißmeisen.

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Veit D. schrieb:
> Jörg W. schrieb:
>> Cool!
>>
>> Ich bau bei nächstbester Gelegenheit deinen Patch in die avr-libc ein.
>
> Würdest du das kundtun wenn eingebaut damit ich eine neue Toolchain
> bauen kann? Falls du die Versionsnummer änderst sehe ich das auch. Danke
> euch Fleißmeisen.

Mit der Toolchain kannst du dann aber nicht viel anfangen, es sei denn 
du willst selber an den Tools weiterentwickeln.  Oder du machst 
configure wie gehabt, aber dann wirst du kein Unterschied merken.

Autor: Veit D. (devil-elec)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Johann,

das las sich jetzt so als wenn du mit "64Bit float" fast fertig bist und 
Jörg die derzeit funktionierende Fassung allen zur Verfügung stellen 
könnte. Weiter dachte ich dann das ich mit neu gebauter Toolchain dann 
64bit float einmal ausprobieren könnte. So weit meine Gedankengänge. 
Alles ein Missverständnis?

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johann L. schrieb:
> Hast du eine Idee, wo / wie man -print-multi-lib und
> -print-multi-directory in avr-libc unterstützen könnte?

Nicht so richtig. :(

Ich weiß, dass du das immer wieder erwähnst, kannst du mal erläutern, 
was es dafür genau bräuchte?

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Veit D. schrieb:
> das las sich jetzt so als wenn du mit "64Bit float" fast fertig bist und
> Jörg die derzeit funktionierende Fassung allen zur Verfügung stellen
> könnte.

Wishful thinking.  Zu allererst müssen ein paar Steinchen aus dem Weg 
geräumt werden.  Steinchen No. 1 war

http://gcc.gnu.org/r277908

Jörg bezog sich auf Steinchen No. 2

https://savannah.nongnu.org/bugs/?57071#comment0

@Jörg: Wenn schon, könnte man auch gleich Protos und symbole für long 
double bereitstellen. Also
.macro  ENTRY_LONG_DOUBLE32  name
#if (__SIZEOF_LONG_DOUBLE__ == __SIZEOF_FLOAT__)
  .global  _U(\name)
_U(\name):
#endif /* long double = float */
.endm

...

ENTRY asinf
ENTRY_DOUBLE32 asin
ENTRY_LONG_DOUBLE_DOUBLE32 asinl

Steinchen No. 3 ist avr-libc -print-multi-directory und -print-multi-lib 
beizubringen.  Konkrete Vorschläge, wie das praktikabel umzusetzen ist, 
werden gerne entgegengenommen.

Autor: Veit D. (devil-elec)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

aha. Tut mir leid, aber davon habe ich keinen blassen Schimmer. Wenn ich 
helfen könnte würde ich es tun. Bin weder Mathematiker noch 
Informatiker. Ich kann nicht einmal den Aufwand abschätzen welches 
Wissen dazugehört um überhaupt die Tools zu programmieren zum 
programmieren. Deswegen sei mir nicht böse. Ihr einsamen Ritter im 
Hintergrund.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Veit D. schrieb:
> Bin weder Mathematiker noch Informatiker.

Wenn es dich beruhigt: ich auch nicht. ;-) (Bin Elektroniker.)

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Gescheiterter Physiker :-)

Autor: Veit D. (devil-elec)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bin gelernter Industrieelektroniker und als Instandhalter tätig. :-)

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Jörg W. schrieb:
> kannst du mal erläutern, was es dafür genau bräuchte?

Für libc/libm:

Jede Zeile von -print-multi-lib beschreibt eine multilib-Variante
avr25/tiny-stack;@mmcu=avr25@msp8

Links vom ; steht der relative Pfad zur Multilib-Variante, und rechts 
davon stehen die Multilib-Options, mit der die Quellen zu übersetzen 
sind.  Hier also -mmcu=avr25 -msp8.  Dazu können natürlich noch andere, 
non-multi Options wie -Os kommen.

Das build-System der avrlibc verwendet bootstrap -> gen-avr-lib-tree.sh, 
d.h. Erzeugung der Verzeichnisstruktur müsste durch -print-multi-lib 
getrieben sein statt hardcodiert.  Und natürlich müssen alle 
Multilib-Optionen aus gen-avr-lib-tree.sh:CFLAGS rausfliegen.  Dazu 
müsste bootstrap den Compiler kennen, denn -print-multi-lib ist abhängig 
von Compilerversion und -konfiguration.

Für Devicelib und Crt gilt das gleiche, nur das es da etwas 
komplizierter ist, die Multilib-Pfade zu eruieren, z.B. wie folgt:
PML=`$CC -print-multi-lib`
foreach MCU
    PMD=`$CC -print-multi-directory -mmcu=$MCU`
    # Map -mmcu=$MCU to -mmcu=$ARCH
    for LINE in $PML
        if LINE.startswith("$PMD;")  # Exactly 1 line must match here.
            ARCH=LINE.extract.mmcu() # May be "" for the avr2 default.

    for LINE in $PML
        if LINE.contains("@mmcu=$ARCH@")
                or LINE.endswith("@mmcu=$ARCH")
                or ($ARCH=="" and not LINE.contains("@mmcu=")
            PATH=LINE.getpath()
            MOPTS=LINE.getoptions().filter-out("-mmcu=...")
            # avr-gcc will patch some multi-opts to align with $MCU,
            # hence the path migh also change.
            PATH=`$CC -mmcu=$MCU $MOPTS -print-multi-directory`
            # Build $PATH/crt$MCU.o
            if not exists $PATH/crt$MCU.o
                $CC -mmcu=$MCU $MOPTS $CFLAGS crt1.S -o $PATH/crt$MCU.o
            if not exists $PATH/lib$MCU.a
                # Builf lib$MCU.a using -mmcu=$MCU $MOPTS $CFLAGS

Gleiches gilt für configure.ac:  Einträge wie die folgenden
AC_CONFIG_FILES([
          avr/lib/avr2/tiny-stack/Makefile
          avr/lib/avr2/tiny-stack/at90s2313/Makefile
müssen generiert werden, die einzige Info die dazu verwendet wird:  Es 
gibt ein Device "at90s2313" und die Infos auf $CC -print-multi-*.  Hier 
könnte man ein m4 generieren; aclocal läuft ja eh schon.

Die Multilib-Variabten für die Devices auszuarbeiten funktioniert, weil 
avr-gcc falsche Optionen korrigiert, weshalb der selbe PATH mehrfach 
auftreten kann; daher das "if not exists".

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johann L. schrieb:
> Das build-System der avrlibc verwendet bootstrap -> gen-avr-lib-tree.sh,
> d.h. Erzeugung der Verzeichnisstruktur müsste durch -print-multi-lib
> getrieben sein statt hardcodiert.  Und natürlich müssen alle
> Multilib-Optionen aus gen-avr-lib-tree.sh:CFLAGS rausfliegen.

Das klingt zumindest machbar. Dieses gen-avr-lib-tree.sh ist ja auch 
eher ein Hack.

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.