mikrocontroller.net

Forum: Compiler & IDEs C++17 IDE für STM32


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

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute,
Grundannahmen:
- Codevervollständigung zum Code-Schreiben ist bequem.
- Debugging ist essentiell.
- C++17 hat seine Daseinsberechtigung.

Im Moment finde ich keine IDE, die mich bei allen Grundannahmen 
Unterstützt.
Mein letztes Projekt habe ich mit Eclipse durchgezogen. Aber Codan von 
Eclipse ist wohl bei C++14 stehengeblieben.

Kennt ihr Alternativen?

Autor: Vincent H. (vinci)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja Codan is defakto tot. VSCode und dessen language-server 
Implementierung hat gezeigt wohin der Weg geht. Aktuell benutz ich auch 
hauptsächlich VSCode in Kombination mit dem Cortex-Debug Plugin zur 
Entwicklung... Problematisch is das ganze nur wenn man sich den 
Assembler anschaun muss, dann schaut man in VSCode momentan nämlich 
durch die Finger.

Autor: Programmierer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hmmh. Assembler gehört zum Debuggen schon sehr stark dazu.

Autor: Michael F. (michaelfu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die IAR Embedded Workbench für Arm unterstützt in den neuesten Versionen 
C++17. Ist aber ein kommerzielles Tool, bei dem nur eine auf 32kB 
limitierte Version kostenlos ist.

Dafür bekommt man einen recht leistungsfähigen Debugger (ordentliche 
Probe vorausgesetzt) inklusive Simulator.

Autor: Programmierer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Redest du da nur vom Compiler oder wirklich von der von der 
Code-Completion?

Mich wundert es etwas, dass die nicht generell den neusten GCC 
einsetzen. Der GCC9.1 hat ja nun schon Anfänge von C++20.

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

Bewertung
-3 lesenswert
nicht lesenswert
Aber wer tut sich denn den IAR freiwillig an?
Der war in v7 schon komplett grottenschlecht und in v8 habenses echt 
noch schlimmer gemacht.
Ich dacht echt das geht nicht mehr...

VSCode wollt ich auch mal ausprobieren, aber als ich las, dass das in 
JavaScript geschrieben ist dachte ich:
NEIN! einfach NEIN!

Daher häng ich mich hier mal ran, mal gucken was für IDE/Edeitoren hier 
vorgeschlagen werden.

Privat Code ich in Notepad++.
Debuggt wird mit Segger Ozone.

Autor: Programmierer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bzgl Eclipse und C++17 ist hier nochmal ein schöner Artikel:
https://www.eclipse.org/community/eclipse_newsletter/2017/april/article5.php

...aus 2017. Aber da haben es welche eingesehen, dass es beim 
Fortschritt von C++ (alle 3 Jahre eine neue Version) mit Eigenbauten 
nicht weitergehen kann.
Wenn Codan tot ist, ist das ja gut. Aber ich hätte da gehofft, dass man 
in 2 Jahren  schon irgendwie auf Clang umgestiegen ist. hmmmh.

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
VS Code, cpp mode, language/debug server, jlink zum debuggen. Cmake oder 
Makefile zum bauen!

Autor: Vincent H. (vinci)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mw E. schrieb:
> VSCode wollt ich auch mal ausprobieren, aber als ich las, dass das in
> JavaScript geschrieben ist dachte ich:
> NEIN! einfach NEIN!

Die Befürchtung hatte ich erst auch aber was MS da auf Electron Basis 
gezimmert hat ist richtig flott und fühlt sich immer responsive an.

Autor: Donni D. (donnidonis)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Vincent H. schrieb:
> Mw E. schrieb:
>> VSCode wollt ich auch mal ausprobieren, aber als ich las, dass das in
>> JavaScript geschrieben ist dachte ich:
>> NEIN! einfach NEIN!
>
> Die Befürchtung hatte ich erst auch aber was MS da auf Electron Basis
> gezimmert hat ist richtig flott und fühlt sich immer responsive an.

VSCode ist in TypeScript geschrieben, nicht JavaScript. Am Ende kommt 
JavaScript raus, ja, aber man hat mit TypeScript viel mehr 
Möglichkeiten.

Zustimmen kann ich aber, es ist verdammt flott, hatte noch nie Probleme 
damit. Warum man es nicht nutzen möchte, nur weil es auf einer 
bestimmten Programmiersprache basiert, will mir nicht in den Kopf.

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

Bewertung
-5 lesenswert
nicht lesenswert
Weil JS einfach zu einem Krebsgeschwür wird (oder schon lange ist).
JS wurde als Gluecode für HTML Seiten erfunden um Intraktionen zu
ermöglichen ohne jedesmal die Seite vom Server neuladen zu müssen.
Selbst da wird mit Megabytes großen Frameworks, die einfach nur die CPU
sinnlos belasten total übertrieben. Inzwischen schreiben die Webhipster
ja schon das Serverbackend mit JS (NodeJS), wofür es NIE gedacht war!

Also ihr meint VSScode ist nicht so schlimm, ich habs mal in meiner VM
installiert und sofort beim installer fliegen nicht nur .js Dateien
durch die Gegend, sondern auch .node
Das ist ja noch mehr ein nogo als js.
Bei node und seinem aketmanager npm hat ja nun jeder jeglichen Überblick
verloren und dadurch wurde schon oft genug bösartiger Code
eingeschleust.
https://www.heise.de/developer/meldung/JavaScript-Sicherheitsluecke-im-Node-js-Paketmanager-NPM-3152199.html
https://www.zdnet.de/88348273/hacker-manipuliert-javascript-bibliothek-und-stiehlt-bitcoins/
(und weitere lassen sich leicht finden)
Inzwischen blendet npm ja auch schon Werbung ein, mal gucken ab wann die
von externen Servern kommt und was nachladen kann ;)

Sowas will ich einfach nicht auf meinem Rechner haben!
Welchen Grund gibts denn eine Desktopawendung mit einer Websprache zu
bauen?

Autor: Til S. (Firma: SEGGER) (til_s)
Datum:

Bewertung
1 lesenswert
nicht lesenswert

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Vincent H. schrieb:
> Die Befürchtung hatte ich erst auch aber was MS da auf Electron Basis
> gezimmert hat ist richtig flott und fühlt sich immer responsive an.

Microsoft hat es geschafft sowohl den schlechtesten Editor des 
Universums (notepad.exe) als auch den mit weitem Abstand besten der 
Menschheit momentan bekannten Editor (code) herauszubringen, das ist 
schon ein recht bemerkenswerter Umstand welches Spektrum da mit nur 2 
Produkten aufgespannt wird.

Wenn sie nur in allen anderen Bereichen ebensolche Fortschritte machen 
würden...

: Bearbeitet durch User
Autor: Roland D. (roland_d829)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hat jemand von euch mal das mbed studio ausprobiert? bin gerade erst 
darüber gestolpert (https://os.mbed.com/studio/)
es sieht aus wie das VS Code,
soll wohl den ARM Compiler 6 mitbringen, da er auf llvm+clang basiert 
dürfte er auch ganz gut C++17 unterstützen.

Autor: Johannes S. (jojos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ja, aber noch nicht sehr ausgiebig. Wenn man ein unterstütztes Board hat 
ist alles sehr einfach, es muss nicht wie VSCode PlugIns zusammengesucht 
werden und es ist fertig konfiguriert.
Bezüglich Fehler- und Warnmeldungen hat sich der ARM Compiler etwas 
anders verhalten als der gcc, aber das war schnell zu korrigieren.
Leider werden im Moment noch nicht viele Boards vom Debugger unterstützt 
und auch für das ältere mbed2 ist es nicht gemacht. Aber gerade da wäre 
es interessant, der ARM compiler erzeugt für die Cortex-M0 wesentlich 
kompakteren Code.

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

Bewertung
-2 lesenswert
nicht lesenswert
Da hat sich ja eine interessante Anzahl an Minussen eingefunden.
Aber ich würde gerne mal Argumente FÜR Javascript als Desktop Progamme 
Programmiersprache hören.
Aber bitte welche die nicht auf Java selbst zutreffen wie Multi OS, da 
kannste dann auch das geringere Übel nehmen, nämlich Java ;)

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mw E. schrieb:
> FÜR Javascript als Desktop Progamme
> Programmiersprache hören.
> Aber bitte welche die nicht auf Java selbst

Was hat das eine mit dem anderen zu tun?

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

Bewertung
-2 lesenswert
nicht lesenswert
Bei dem anti JS rant da oben fühlen sich wohl ein paar JS Kiddies 
gekränkt.
Für Argumente bin ich ja immer zu haben, aber ich sehe keine pro JS als 
Desktopprogrammiersprache.

Oder willste darauf hinaus wieso ich Java erwähne?
Naja falls das Hauptargument "läuft auf jedem OS" ist.
Das kann Java auch und ist dafür entwickelt um Programme zu schreiben 
und nicht nur um am HTML DOM etwas rumzuspielen.

Autor: Johannes S. (jojos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mit der Einstellung bist du leider in den 80ern stehen geblieben.

Autor: temp (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Mw E. schrieb:
> Bei dem anti JS rant da oben fühlen sich wohl ein paar JS Kiddies
> gekränkt.
> Für Argumente bin ich ja immer zu haben, aber ich sehe keine pro JS als
> Desktopprogrammiersprache.

Ich sehe js mittlerweile auch als gefährlich an. Das liegt aber nicht an 
js selbst sondern an dem was daraus gemacht wird. Mal nur ein Beispiel. 
Man nehme eine aktuelle nodejs Version und will damit ein paar Byte über 
UART austauschen. Also mal schnell: "npm install serialport" getippt. 
Geht ja so einfach. Leider landen dann sofort 616 Dateien in 133 
Verzeichnissen auf der Platte die ab sofort zum Projekt gehören. Das 
wird von den node-Jüngern dann so einfach unkommentiert hingenommen. Mir 
wird davon schlecht.
Eine kleine App unter cordova für iOS und Android bringt es auf 1965 
Dateien in 822 Verzeichnissen mit Code aus allen Herren Ländern dessen 
Abhängigkeiten niemand verifiziert. Glaubt denn wirklich jemand, dass da 
noch einer durchsteigt und dass das in 2 Jahren auch noch läuft? Wie 
will man da verhindern dass beim automatischen Zusammenschaufeln von 
Code aus tausenden Projekten nicht doch irgendwann mal ein faules Ei 
darunter ist?
Schöne neue Welt.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Mw E. schrieb:
> aber ich sehe keine pro JS als Desktopprogrammiersprache

Viele Programmierer können es, damit wird die Entwicklung billiger. Mit 
welcher Sprache sonst kann man so komfortabel (und damit billig) Web 
Apps, Smartphone Apps, Server Backends und Desktop Apps schreiben?

Es gibt eine Riesen Menge an Tools und Bibliotheken, was die Entwicklung 
weiter vereinfacht & verbilligt. Oder würdest du lieber extra zahlen für 
eine IDE die in deiner Lieblingssprache geschrieben ist...? Was 
interessiert dich die Sprache einer Anwendung, die du nicht selbst 
modifizieren musst? Einfach nicht nach schauen und benutzen. Ich kann 
dir verraten dass im Backend mancher Web Apps sogar noch Fortran 
werkelt...

temp schrieb:
> Leider landen dann sofort 616 Dateien in 133 Verzeichnissen auf der
> Platte die ab sofort zum Projekt gehören. Das wird von den node-Jüngern
> dann so einfach unkommentiert hingenommen. Mir wird davon schlecht

Dir wird von Dateien schlecht? Dann schau besser mal nicht in die 
Verzeichnisse z.B. vom GCC oder den üblichen C Libraries wie HAL oder 
SPL, oder dem unsäglichen TI PDK Monstrum. Was man in modernen Sprachen 
wie JS in 3 Zeilen macht braucht in C 100, das sorgt allein schon für 
geringe Code Density...

Autor: Micha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
https://www.st.com/en/development-tools/stm32cubeide.html
Hab ich allerdings noch nicht getestet und bzgl. C++17 hab ich auch nix 
gefunden.

Autor: Johannes S. (jojos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
und zum Vergleich mit Java: hat hier schonmal jemande versucht 
durchzusteigen wie die Eclipse Erweiterungen funktionieren? Da sind 
erstmal zig Verwaltungsdateien, der Code liegt irgendwo kompiliert vor. 
Bei VS Code sind die Erweiterungen natürlich auch in JS/TS, da kann man 
bei Bedarf sogar mit VSCode direkt rein debuggen und Sachen 
korrigieren/ändern.
Das Persistenzformat der Einstellungen in .cproject bei Eclipse ist 
eklig und obwohl fast jeder µC Hersteller eine Eclipse Variante anbietet 
sind die Projekte in keiner Weise kompatibel. Bei VSCode ist alles gut 
lesbar in JSON gespeichert und leicht per Code zu bearbeiten.
Eclipse ist ein extrem gewachsener Moloch, das kann sehr sehr viel aber 
die Realisierung ist viel zu kompliziert.
Ich habe Kollegen die wollen von C++ nichts mehr wissen und machen alles 
nur noch in JS/TS. Neulinge von der Uni zaubern in wenigen Wochen Sachen 
da hätten die C++ Leute ein Jahr und länger dran gesessen.

Autor: temp (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Dr. Sommer schrieb:
> Dir wird von Dateien schlecht? Dann schau besser mal nicht in die
> Verzeichnisse z.B. vom GCC

Wie war das doch gleich mit Äpfeln und Birnen? Der GCC ist ein Projekt 
in sich. Sicher kein kleines aber von einer Community in sich gepflegt. 
Da wird nicht wie beim npm alles erst zusammengetragen. Und ja mir wird 
vor dem Wildwuchs schlecht.

> oder den üblichen C Libraries wie HAL oder
> SPL, oder dem unsäglichen TI PDK Monstrum.

Meine Meinung darüber habe ich auch schon oft geäußert. Selber schuld 
wer das verwendet.

> Was man in modernen Sprachen
> wie JS in 3 Zeilen macht braucht in C 100, das sorgt allein schon für
> geringe Code Density...

aber nicht wenn für diese 3 Zeilen 20 verschiedene Module mit ein paar 
100 Dateien nötig sind, die zusammenhanglos von irgendwo her ins Projekt 
installiert werden. Das ist leider bei python genauso wie bei nodejs die 
Regel.

Johannes S. schrieb:
> Ich habe Kollegen die wollen von C++ nichts mehr wissen und machen alles
> nur noch in JS/TS. Neulinge von der Uni zaubern in wenigen Wochen Sachen
> da hätten die C++ Leute ein Jahr und länger dran gesessen.

Zaubern ist hier wirklich das Schlüsselwort. Nichts dagegen wenn man 
sich für ein paar schnelle Sachen für den schnellen Weg entscheidet. 
Trotzdem kommt am Ende nur ein Müllhaufen aus wenig eigenem und viel 
fremden Code raus der eventuell heute funktioniert, aber keiner weiß wie 
und warum.
Wie gesagt ich habe nichts gegen js. Wir embedden die V8 selbst in 
eigenen Produkten. Auch nodejs an sich will ich nicht schlecht machen. 
Aber die Art und Wiese wie es am Ende zu fertigen Applikationen kommt 
und wie die Codebestandteile zusammengetragen werden ist einfach nur 
krank.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
temp schrieb:
> Sicher kein kleines aber von einer Community in sich gepflegt.

Nur dass der GCC alleine eben nicht zu gebrauchen ist. Da kommen dann 
noch binutils und diverse andere Bibliotheken wie newlib zu.

temp schrieb:
> Da wird nicht wie beim npm alles erst zusammengetragen.

Nur weil ARM das freundlicherweise alles in ein großes ZIP packt. Wären 
das einzelne Pakete in einem Paketmanager à la npm könnte man die auch 
einzeln aktualisieren - schön wär's!

temp schrieb:
> aber nicht wenn für diese 3 Zeilen 20 verschiedene Module mit ein paar
> 100 Dateien nötig sind, die zusammenhanglos von irgendwo her ins Projekt
> installiert werden.

Die meisten Programmierer haben zum Glück keine Modul-Allergie. Ich 
find's super einfach ein paar Pakete zu importieren und komplexe 
Aufgaben im Nu umzusetzen. Im Embedded-Bereich ist diese Mentalität auch 
vorhanden, aber kurioserweise disjunkt von textbasierter Programmierung: 
Das Hauptargument von Simulink und Konsorten ist es, dass es bereits 
viele Komponenten wie PID-Regler oder Verzögerungsglieder usw. 
integriert hat - das grafische Zusammenklicken selbiger kommt erst an 2. 
Stelle. Wie schön es wäre, in C(++) entsprechende Module kombinieren zu 
können! Aber die wären dann wieder in vielen Dateien abgelegt...

temp schrieb:
> Trotzdem kommt am Ende nur ein Müllhaufen aus wenig eigenem und viel
> fremden Code raus der eventuell heute funktioniert, aber keiner weiß wie
> und warum.

Es weiß auch kein einzelner Mensch wie ein Computer oder der 
Linux-Kernel funktioniert. Code, der sich auf fremde Komponenten stützt, 
ist noch lange kein "Müllhaufen". Das ist absolut gang und gäbe - jedes 
Rad für jedes Projekt in jeder Firma neu zu erfinden ist ziemlich irre! 
Nur Embedded-C-Programmierer haben da irgendwie Probleme mit.

Autor: temp (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Dr. Sommer schrieb:
> Es weiß auch kein einzelner Mensch wie ein Computer oder der
> Linux-Kernel funktioniert. Code, der sich auf fremde Komponenten stützt,
> ist noch lange kein "Müllhaufen". Das ist absolut gang und gäbe - jedes
> Rad für jedes Projekt in jeder Firma neu zu erfinden ist ziemlich irre!
> Nur Embedded-C-Programmierer haben da irgendwie Probleme mit.

Im Fall von nodejs aber schon. Bei einer normalen 
Applikationsentwicklung verwendet man natürlich Libs da wo es angebracht 
ist. Und versteht auch nicht den gesamten Code. Soweit so gut. Trotzdem 
nimmt man eine bestimmte Version dieser Lib, die auch nicht immer die 
neueste sein muss, und hat unter Kontrolle welche Bestandteile man in 
welcher Version benutzt und woher sie kommen. Man kann auch gezielt 
Updates einzelner Bestandteile machen und behält auch die Kontrolle.
Um beim Beispiel mit nodejs zu bleiben. Ein "npm install serialport" 
installiert aber Unmengen von modulen unbekannter Versionsstände auf die 
man damit keinen Einfluss hat. Mache ich das gleiche in 2 Wochen oder 
Jahren oder nur auf einer anderen Maschine landet nie der gleiche Code 
auf der Platte. Und keiner hat eine Übersicht darüber oder kann es 
beeinflussen.

Das dich das nicht interessiert ist mir klar. Der Satz sagt alles:
Dr. Sommer schrieb:
> Einfach nicht nach schauen und benutzen.

Dr. Sommer schrieb:
> Die meisten Programmierer haben zum Glück keine Modul-Allergie.

Das habe ich auch nicht. Jedenfalls solange ich die Kontrolle darüber 
habe welche Module und in welchen Versionen. Wenn dich das nicht 
interessiert ist es grob Fahrlässig und ich bin froh dass du nicht auf 
Flugzeuge oder der gleichen los gelassen wirst.

Autor: Johannes S. (jojos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Thema der vielen verteilten Komponenten kommt aber aus der massiv 
eingesetzten OpenSource Software. Da gibt es nicht den einen der alles 
am Stück liefert, es hat sich ein Sammelsurium an guten Komponenten 
etabliert und die werden von verschiedenen Leuten gepflegt. Den Software 
Dinosaurieren wie MS und Co. war das auch nicht recht, die hätten die 
Fäden lieber selber alle in der Hand und möchten nur das Interface, 
nicht aber die Implementierung liefern. Viele Programmierer wollen das 
aber nicht und dieses Geflecht an Komponenten hat sich entwickelt. Bei 
JS Anwendungen ist aber ein einfach durchschauberes System der 
Paketverwaltung dahinter und Pakete sind üblicherweise alle als 
Quellcode vorhanden. Das es teilweise viel ist kommt auch von dem 
Komfort den diese bieten. Ein einfaches OS API hat im Hintergrund 
üblicherweise auch viele verzahnte Komponenten. Ein OS unabhängiges 
Paket muss nun vieles wieder neu erfinden wenn es sich nicht auf 
Features eines OS verlassen will. Und das funktioniert bei NodeJS auch 
erstaunlich gut, selbst grosse Dinger wie NodeRed laufen unter Windows 
genauso wie auf dem RPi.
Und Alternativ muss man ja nicht grosse Frameworks benutzen, gerade mit 
NodeJS hat man eine gute Basis für einfache eigene Anwendungen.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
temp schrieb:
> Das ist leider bei python genauso wie bei nodejs die
> Regel.

Da sind mindestens zwei Größenordnungen dazwischen. Wofür man bei node 
600 Pakete braucht reichen bei Python vielleicht 6 und dann ist es schon 
vergleichsweise viel und bei 4 von den 6 kann man sich mindestens dunkel 
an deren Namen erinnern weil es halbwegs bekannt ist und oft erwähnt 
wird.

Ja, node ist vollkommener Wahnsinn. JavaScript ist ok aber Node ist die 
Manifestation des blanken Irrsinns. Den ganzen Scheiß müsste man um den 
Faktor 100 verringern und zusammenfassen um es auf das Level von Python 
zu bringen und wieder halbwegs beherrschbar zu machen.

: 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.