mikrocontroller.net

Forum: Compiler & IDEs GCC für STM32F103


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: ARMer (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Unter Windows schreibe ich Programme für AVR-Controller mit dem 
"Programmer's Notepad 2" und compiliere sie mit der Toolchain 
"avr8-gnu-toolchain".

Nun möchte ich eine Toolchain für STM32F-Controller, insbesondere den 
103er. Welche Toolchain kann ich installieren?

[Mod: Betreff angepasst]

: Bearbeitet durch Moderator
Autor: Pete K. (pete77)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

: Bearbeitet durch Moderator
Beitrag #5414959 wurde von einem Moderator gelöscht.
Beitrag #5414974 wurde vom Autor gelöscht.
Beitrag #5414978 wurde von einem Moderator gelöscht.
Autor: Til S. (Firma: SEGGER) (til_s)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Embedded Studio:
https://www.segger.com/products/development-tools/embedded-studio/

Passendes Embedded Betriebssystem (ich weiß, wurde nicht nach gefragt, 
aber bei über 80 BSPs enthaltenen sollte für die gewünschte Hardware was 
passendes dabei sein. Dann hat man gleich ein funktionierendes Projekt 
und kann das embOS ja auch gerne raus schmeißen ;-) )
https://www.segger.com/downloads/embos/embOS_CortexM_EmbeddedStudio_Trial

Autor: Curby23523 N. (nils_h494)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Atollic truestudio oder STM32 Workbench.

Autor: W.S. (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
ARMer schrieb:
> Nun möchte ich eine Toolchain für STM32F-Controller, insbesondere den
> 103er. Welche Toolchain kann ich installieren?

In der Reihenfolge der Relevanz:

1. den Keil (32K Code frei)
ST hat da mit Keil und Segger ein paar Extrawürste gebraten, nützt dir 
vielleicht was.
Derzeit die MDK-ARM Version 5.25
https://www.keil.com/demo/eval/arm.htm

2. IAR (ebenso 32K Code frei)
Derzeit die Version 8.22
https://www.iar.com/iar-embedded-workbench/#!?currentTab=free-trials


3. GCC - was da an aktuellen Versionen vorhanden ist, mußt du selber 
herausfinden. Ich hatte vor Jahren die "yagarto" benutzt, aber die ist 
wohl mittlerweile ausgestorben.

Ähem.. nochwas: Toolchain und IDE sind zwei verschiedene Dinge. Aber bei 
Keil und IAR ist jeweils eine IDE mit dabei.

W.S.

Autor: STK500-Besitzer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
W.S. schrieb:
> 1. den Keil (32K Code frei)
> ST hat da mit Keil und Segger ein paar Extrawürste gebraten, nützt dir
> vielleicht was.
> Derzeit die MDK-ARM Version 5.25

Und jamnert gerne, dass neuere Chips noch nicht unterstützt werden, weil 
sie nur ein kleines Entwickler-Team haben.

Privat verwende ich Truestudio, da Atollic inzwischen zu STM gehört.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
ARMer schrieb:
> Welche Toolchain kann ich installieren?

Die hier, das ist die offizielle: 
https://developer.arm.com/open-source/gnu-toolchain/gnu-rm/downloads

Autor: Sempfdazugeber (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
> Die hier, das ist die offizielle:

Wenn schon ARM verlinkt wird, dann ist ARM-DS5 das offizielle Teil
von ARM.

Und da werkelt kein GCC.

Autor: nfet (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sempfdazugeber schrieb:
>> Die hier, das ist die offizielle:
>
> Wenn schon ARM verlinkt wird, dann ist ARM-DS5 das offizielle Teil
> von ARM.
>
> Und da werkelt kein GCC.

Der GCC ist schon auch offiziell:
"The GNU Embedded Toolchain for Arm is a ready-to-use, open source suite 
of tools for C, C++ and Assembly programming targeting Arm Cortex-M and 
Cortex-R family of processors. It includes the GNU Compiler (GCC) and is 
available free of charge directly from Arm for embedded software 
development on Windows, Linux and Mac OS X operating systems."

Zum Thema:
http://www.st.com/en/development-tools/stm32-ides.html?querycriteria=productId=LN1200

Hat ST nicht erst Atollic und damit das True Studio gekauft? Das ist 
jetzt glaube auch kostenlos und gut.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Sempfdazugeber schrieb:
>> Die hier, das ist die offizielle:
>
> Wenn schon ARM verlinkt wird, dann ist ARM-DS5 das offizielle Teil
> von ARM.

Er hat nach ner Toolchain gefragt und nicht nach ner IDE. Und gcc ist 
nun mal die mit großem Abstand am weitesten verbreitete Toolchain dafür 
(somit findet man überall Leute die sich damit auskennen und helfen 
können) und wird auch vom ARM offiziell unterstützt.

Autor: W.S. (Gast)
Datum:

Bewertung
-5 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Und gcc ist
> nun mal die mit großem Abstand am weitesten verbreitete Toolchain

Sag's mal lieber präzise: GCC als solcher - für Linux und Konsorten, 
sowie für viele andere Architekturen - ist weiter verbreitet als 
spezielle Compiler für ihre jeweiligen Architekturen. So herum.

Der Rat zu Keil und IAR hat einen Grund: die sind deutlich besser als 
der entsprechende Gcc.

STK500-Besitzer schrieb:
> Und jamnert gerne, dass neuere Chips noch nicht unterstützt werden, weil
> sie nur ein kleines Entwickler-Team haben.

Wer jammert denn da? Niemand. Der Keil-MDK funktioniert für alle 
ARM-Geschmacksrichtungen, für die er konzipiert ist. Den ARM-DS5 braucht 
man für einen Cortex M3 nicht. Aber wer will, kann sich ja davon die 
Community-Edition herunterladen...

W.S.

Autor: Vincent H. (vinci)
Datum:

Bewertung
6 lesenswert
nicht lesenswert
W.S. schrieb:
> Der Rat zu Keil und IAR hat einen Grund: die sind deutlich besser als
> der entsprechende Gcc.
> W.S.

Benchmarks or gtfo.

Autor: Christopher J. (christopher_j23)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
W.S. schrieb:
> Der Keil-MDK

... ist kein Compiler. Genauso wenig wie es

> Den ARM-DS5

als Compiler gibt.


W.S. schrieb:
> Der Rat zu Keil und IAR hat einen Grund: die sind deutlich besser als
> der entsprechende Gcc.

"Besser" muss man schon irgendwie definieren. Der C++-Support bei den 
beiden war beispielsweise bis vor kurzem so desaströs, dass ARMs eigenes 
mbed-Framework - aus Rücksichtnahme auf Keil und IAR - komplett im 
völlig rückständigen C++03 geschrieben ist. Weitere "Features" des ARMCC 
wären der Zwang zu Windows sowie furchtbare Kompilierzeiten. Mit Version 
6 des ARM Compilers sieht die Sache zwar schon deutlich besser aus aber 
es gibt meiner Meinung nach nichts was den gegenüber dem GCC jetzt so 
viel besser macht.

Autor: Nop (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Ein Beispiel, wo Keil besser ist: Stack-Analyse. Das wirft einem Keil 
für jede Funktion inkl. Calltree aus, während GCC das nur pro Funktion 
ohne deren Calls kann - und nicht einmal das funktioniert zusammen mit 
FLTO.

Für Hobbygebastel ist das egal, aber nicht für professionelles Arbeiten. 
Eine ausgelassene Stackanalyse entspricht Verletzung der Sorgfaltpflicht 
und dürfte von daher fahrlässig bis grob fahrlässig sein. Das wird im 
Ernstfall teuer für so eine Pfuschbude, besonders wenn es zu 
Folgeschäden kommt.

Autor: Nase (Gast)
Datum:
Angehängte Dateien:

Bewertung
-1 lesenswert
nicht lesenswert
Nop schrieb:
> Ein Beispiel, wo Keil besser ist: Stack-Analyse. Das wirft einem Keil
> für jede Funktion inkl. Calltree aus, während GCC das nur pro Funktion
> ohne deren Calls kann - und nicht einmal das funktioniert zusammen mit
> FLTO.

Du meinst so wie im Anhang?

Autor: Christopher J. (christopher_j23)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nase schrieb:
> Du meinst so wie im Anhang?

Er meint die Analyse zur Compile-Zeit, nicht zur Laufzeit. Außerdem ist 
das nur der Call-Tree, keine Stack-Analyse.

Autor: Christopher J. (christopher_j23)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nop schrieb:
> Ein Beispiel, wo Keil besser ist: Stack-Analyse. Das wirft einem Keil
> für jede Funktion inkl. Calltree aus, während GCC das nur pro Funktion
> ohne deren Calls kann - und nicht einmal das funktioniert zusammen mit
> FLTO.

Ok, eine gute Stack-Analyse lasse ich mal als Vorteil gelten. Beim GCC 
geht das aber auch mit -flto, dann allerdings nur in Kombination mit 
-save-temps. Siehe dazu auch Johanns Antwort hier: 
Beitrag "Re: GCC -fstack-usage"

Autor: Nop (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Christopher J. schrieb:

> Ok, eine gute Stack-Analyse lasse ich mal als Vorteil gelten. Beim GCC
> geht das aber auch mit -flto, dann allerdings nur in Kombination mit
> -save-temps. Siehe dazu auch Johanns Antwort hier:
> Beitrag "Re: GCC -fstack-usage"

Gerade mal probiert: nein, geht nicht. Die .su-Files sind dann immer 
noch leer. Ist natürlich möglich, daß er das stattdessen irgendwo anders 
in irgendwelche temporären Dateien hinwirft, aber sorry, das ist als 
Feature zum realen Arbeiten unbrauchbar.

Wenn man den Frickelfaktor einrechnet und den mit üblichen Stundensätzen 
bepreist (also Brutto + AG-Anteil + Anteilig Miete, Verwaltung HR usw.), 
dann ist GCC schlicht zu teuer. GCC ist hingegen durchaus gut, wenn man 
kein Geld ausgeben kann oder will, aber Zeit hat.

Siehe auch hier: 
https://embeddedgurus.com/stack-overflow/2010/02/is-gcc-a-good-compiler/

Autor: Christopher J. (christopher_j23)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Nop schrieb:
> Gerade mal probiert: nein, geht nicht. Die .su-Files sind dann immer
> noch leer. Ist natürlich möglich, daß er das stattdessen irgendwo anders
> in irgendwelche temporären Dateien hinwirft, aber sorry, das ist als
> Feature zum realen Arbeiten unbrauchbar.

Was für eine GCC-Version hast du denn im Einsatz? Bei mir gibt es mit 
-flto genau eine .su-Datei. Wenn deine .elf etwa foo.elf heißt, dann 
sollte es eine foo.elf.ltrans.ltrans0.su geben. Aus welchen .c-Dateien 
die jeweilige Funktion stammt, steht dann in der .su. Nutze den GCC 
7.2.1 von Launchpad.

Nop schrieb:
> Siehe auch hier:
> https://embeddedgurus.com/stack-overflow/2010/02/is-gcc-a-good-compiler/

Das mit dem Support ist natürlich so eine Sache. Direkten Support von 
den GCC-Autoren wird man wohl nicht bekommen aber das hat doch nichts 
mit der Qualität des Compilers an sich zu tun. Es ist auch nicht so, 
dass der GCC jetzt voller Bugs wäre oder nur halbgar funktionieren 
würde. Der Artikel ist von 2010 vielleicht war es damals anders aber das 
interessiert jetzt auch nicht mehr. Hier im Forum jedenfalls sind 99,5% 
aller gemeldeten Compiler-Bugs eben keine solchen und das Problem sitzt 
in der Regel vor dem Bildschirm.

Autor: W.S. (Gast)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
Christopher J. schrieb:
> "Besser" muss man schon irgendwie definieren. D

Na denn: schnellerer und kompakterer Code. Wenn ich mich recht erinnere 
(ist ja schon ne Weile her) war der Code beim GCC selbst in der höchsten 
Optimierungsstufe noch immer rund 30% größer als beim Keil in Default.

Die Assembler-Notation ist ebenso grauselig und den Stress mit .thumb 
und .thumbfunc möchte man nicht noch mal erleben müssen, ist aber seit 
Cortex und Thumb2 wohl nicht mehr gar so signifikant. Ein Ähnliches gilt 
für Interrupt-Handler im zugehörigen Treiber. Das war ne klassische 
Krätze beim GCC.

Obendrein kann der GCC keine SVC's - aber da er sowas nicht kann, kennen 
sowas seine Benutzer auch nicht.

So, das waren mal ein paar Beispiele, es gibt aber noch mehr. Man muß 
kommerzielle Software nicht mögen, schließlich ist es für 
OpenSource-Fans weitaus wichtiger, daß man damit eine Art Robin Hood 
Gefühl oder Asterix&Obelix-Gefühl hat (Rebellion gegen das Kommerzielle) 
- auch wenn gerade beim GCC als Universal-Compiler die 
plattformspezifischen Dinge eher schlecht oder eben garnicht umgesetzt 
werden als bei einem plattformspezifischen Compiler wie eben dem Keil.

W.S.

Autor: Carl D. (jcw2)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
W.S. schrieb:
> Ein Ähnliches gilt für Interrupt-Handler im zugehörigen Treiber.
> Das war ne klassische Krätze beim GCC.
>
> Obendrein kann der GCC keine SVC's - aber da er sowas nicht kann, kennen
> sowas seine Benutzer auch nicht.

Schön daß der hier benutzt M3 seine Interrupt-Functionen nach 
C-Calling-Convention aufruft. Da hat der Compiler überhaupt kein Problem 
mit.

Autor: Christopher J. (christopher_j23)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
W.S. schrieb:
> Christopher J. schrieb:
>> "Besser" muss man schon irgendwie definieren. D
>
> Na denn: schnellerer und kompakterer Code. Wenn ich mich recht erinnere
> (ist ja schon ne Weile her) war der Code beim GCC selbst in der höchsten
> Optimierungsstufe noch immer rund 30% größer als beim Keil in Default.

Lassen wir doch mal ein paar Zahlen sprechen:
https://devzone.nordicsemi.com/b/blog/posts/comparing-compilersides-for-development-with-nrf5x

Die Unterschiede bei Code der für Größe optimiert ist (-Os) sind absolut 
zu vernachlässigen. Bei Code der für Geschwindigkeit optimiert ist 
liegen die Unterschiede vor allem in der Größe des Binary. Am 
signifikantesten ist wohl der Unterschied beim statischen RAM-Verbrauch, 
wobei ich da mal sehr stark die unterschiedlichen Standard-Libraries im 
Verdacht habe. Da kann natürlich jeder nach belieben die Newlib(-Nano) 
durch eine andere ersetzen, was ja durchaus auch in manchen GCC-IDEs von 
Segger über Atollic und Co. gemacht wird und dann natürlich auch die 
entsprechenden Effekte hat.


Carl D. schrieb:
> W.S. schrieb:
>> Ein Ähnliches gilt für Interrupt-Handler im zugehörigen Treiber.
>> Das war ne klassische Krätze beim GCC.
>>
>> Obendrein kann der GCC keine SVC's - aber da er sowas nicht kann, kennen
>> sowas seine Benutzer auch nicht.
>
> Schön daß der hier benutzt M3 seine Interrupt-Functionen nach
> C-Calling-Convention aufruft. Da hat der Compiler überhaupt kein Problem
> mit.

So ist es. Wenn man denn unbedingt eine Funktion __svc(x) haben will, 
kann man sich ganz einfach eine zusammenbauen: 
https://falstaff.agner.ch/2013/02/18/cortex-m3-supervisor-call-svc-using-gcc/


W.S. schrieb:
> So, das waren mal ein paar Beispiele, es gibt aber noch mehr. Man muß
> kommerzielle Software nicht mögen, schließlich ist es für
> OpenSource-Fans weitaus wichtiger, daß man damit eine Art Robin Hood
> Gefühl oder Asterix&Obelix-Gefühl hat

Es geht hier nicht um Robin Hood oder um Asterix und Obelix, sondern 
darum dass der GCC einfach ein sehr ordentlicher Compiler ist, der einem 
Keil durchaus ebenbürtig ist. Ich kann einfach die Kommentare vom Typ 
"verzichte lieber auf drei viertel des Flash und nimm einen 
32kB-limitierten Keil, der ist sooo viel besser" einfach nicht 
verstehen.

Autor: Nop (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christopher J. schrieb:

> Was für eine GCC-Version hast du denn im Einsatz?

6.3. Den 7er GCC werde ich nicht verwenden, solange nicht das erste 
Update durch ist, und da es nur noch halbjährliche Releases gibt, dauert 
das noch bis Jahresmitte.

> Bei mir gibt es mit -flto genau eine .su-Datei.

Jedenfalls ist da nichts im Objektverzeichnis, wo die .su-Dateien landen 
sollten. Also, es sind .su-Dateien da, aber leer, sofern ich mit -flto 
compiliere.

Gut, -flto wäre aber ohnehin unbrauchbar, weil die Stackanalyse des GCC 
auch viel schlechter als bei Keil ist. Beim GCC muß man sich den 
Calltree selber zusammenfummeln, aber LTO kann einem den Calltree völlig 
umkrempeln. Insofern schützt ein fast unbrauchbares Feature des GCC 
automatisch vor der Anwendung eines anderen fast unbrauchbaren Features. 
;-)

> Das mit dem Support ist natürlich so eine Sache. Direkten Support von
> den GCC-Autoren wird man wohl nicht bekommen aber das hat doch nichts
> mit der Qualität des Compilers an sich zu tun.

Es hat aber was damit zu tun, wie schnell man Support bekommt, denn 
professionell ist Zeit gleichbedeutend mit Geld. Insbesondere, wenn man 
es nicht für akzeptabel hält, Firmencode ins Forum oder auf 
Stackoverflow zu posten.

Autor: Carl D. (jcw2)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Nop schrieb:
> Christopher J. schrieb:
>
>> Was für eine GCC-Version hast du denn im Einsatz?
>
> 6.3. Den 7er GCC werde ich nicht verwenden, solange nicht das erste
> Update durch ist, und da es nur noch halbjährliche Releases gibt, dauert
> das noch bis Jahresmitte.
>
Der 7er GCC steht momentan bei 7.3
Der wird "vermutlich" schon funktionieren.

Autor: Nop (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christopher J. schrieb:
> Ich kann einfach die Kommentare vom Typ
> "verzichte lieber auf drei viertel des Flash und nimm einen
> 32kB-limitierten Keil, der ist sooo viel besser" einfach nicht
> verstehen.

Ich auch nicht. Für professionelle Anwendung hat man eh eine richtige 
Lizenz, so daß keine Limitierung drin ist.

Aber für Hobby schaffe ich mir doch keinen Lock-In, bei dem ich früher 
oder später entweder eine Menge Geld ausgeben oder auf eine andere 
Toolchain umstellen muß. Die Gratis-Version würde ich nur zu dem Zweck 
installieren, zu dem sie auch gedacht ist - zur Evaluierung, ob ich die 
Lizenz kaufen will oder nicht. Wenn ich von vornherein angesichts des 
Preisniveaus schon entschieden habe, daß ich keine Lizenz kaufen will, 
brauche ich auch nichts zu evaluieren.

Autor: Nop (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Carl D. schrieb:

> Der 7er GCC steht momentan bei 7.3

Die Baremetal-Version ist aber im Dezember 2017 als das erste Release 
aufgetaucht, und ich rechne eben damit, daß none-eabi Bugs hat, die 
Mainline nicht hat. Deswegen verwende ich keine none-eabi vor deren 
ersten Update und bleibe lieber bei der 6er. Beim Update von 5 auf 6 
habe ich das natürlich auch schon so gemacht.

Autor: W.S. (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Christopher J. schrieb:
> Die Unterschiede bei Code der für Größe optimiert ist (-Os) sind absolut
> zu vernachlässigen.

Wo hast du den DAS her? Einfach so trocken glaub ich dir kein Wort 
davon.

Meine Erfahrungen mit dem Gcc für ARM7TDMI sind zwar schon etwas älter, 
aber sie waren signifikant. Allerdings hab ich in den letzten Jahren den 
Gcc nicht wieder angefaßt, weil ich beruflich mit dem Keil arbeite.

Ach ja, ich hatte hier ja vor einiger Zeit mal ein kleines Projekt mit 
dem STM32F103C8T6 gepostet. Da ist die fertige Firmware auch im .bin 
Format drin (11508 Bytes). Wäre ja mal interessant, wenn jemand, der den 
Gcc benutzt, das Zeugs damit übersetzt. Einfach um mal zu sehen, wie 
groß die Binärdatei beim Gcc wird.

W.S.

Autor: TriHexagon (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
W.S. schrieb:
> Christopher J. schrieb:
>> Die Unterschiede bei Code der für Größe optimiert ist (-Os) sind absolut
>> zu vernachlässigen.
>
> Wo hast du den DAS her? Einfach so trocken glaub ich dir kein Wort
> davon.

Die Quelle hat er doch gepostet.

Christopher J. schrieb:
> Lassen wir doch mal ein paar Zahlen sprechen:
> 
https://devzone.nordicsemi.com/b/blog/posts/comparing-compilersides-for-development-with-nrf5x

Autor: Carl D. (jcw2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
W.S. schrieb:
> Ach ja, ich hatte hier ja vor einiger Zeit mal ein kleines Projekt mit
> dem STM32F103C8T6 gepostet. Da ist die fertige Firmware auch im .bin
> Format drin (11508 Bytes). Wäre ja mal interessant, wenn jemand, der den
> Gcc benutzt, das Zeugs damit übersetzt. Einfach um mal zu sehen, wie
> groß die Binärdatei beim Gcc wird.
>
> W.S.

Hat das Projekt einen Namen?

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.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

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