Forum: Mikrocontroller und Digitale Elektronik STM32F4xx / L4xx DMA durch externes Signal triggern


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 Joerg W. (joergwolfram)


Bewertung
0 lesenswert
nicht lesenswert
Kann ich beim STM32F4/L4 die DMA durch ein externes Ereignis triggern? 
D.h. bei jeder LO->HI Flanke an einem Pin sollen die nächsten 16 Bits an 
einem Port ausgegeben oder eingelesen werden. Irgendwie scheint diese 
Möglichkeit nicht vorgesehen zu sein oder ich habe es im Refmanual 
überlesen...
Eine Notlösung könnte sein, mit der doppelten Frequenz auf einen Timer 
zu gehen und dann dessen Überlauf zum triggern verwenden, aber das will 
ich möglichst vermeiden.

Jörg

von avr (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Auf ein Input capture event kann man auch triggern. Eine andere 
Möglichkeit ist mir nicht bekannt.

von Marcus H. (Firma: www.harerod.de) (lungfish) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Joerg W. schrieb:
> Kann ich beim STM32F4/L4 die DMA durch ein externes Ereignis triggern?
> D.h. bei jeder LO->HI Flanke an einem Pin sollen die nächsten 16 Bits an
> einem Port ausgegeben oder eingelesen werden. Irgendwie scheint diese
> Möglichkeit nicht vorgesehen zu sein oder ich habe es im Refmanual
> überlesen...
> Eine Notlösung könnte sein, mit der doppelten Frequenz auf einen Timer
> zu gehen und dann dessen Überlauf zum triggern verwenden, aber das will
> ich möglichst vermeiden.

Interessante Frage, Vorschlag zielt in dieselbe Richtung wie mein 
Vorredner.
Hab grad RM0090 - DMA1 / DMA2 request mapping offen.
Bin am überlegen, was man da am besten verbiegen könnte.

Wie schnell soll es denn laufen? Mit welcher Latenzzeit/Jitter?

F40x:

TIM1 / TIM8
Interrupt/DMA generation on the following events:
– Update: counter overflow/underflow, counter initialization (by 
software or
internal/external trigger)
– Trigger event (counter start, stop, initialization or count by 
internal/external trigger)
– Input capture
– Output compare
– Break input

TIM2 to TIM5
Interrupt/DMA generation on the following events:
– Update: counter overflow/underflow, counter initialization (by 
software or
internal/external trigger)
– Trigger event (counter start, stop, initialization or count by 
internal/external trigger)
– Input capture
– Output compare

: Bearbeitet durch User
von avr (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Als Ergänzung: Ich hatte das schon mal getestet für eine 8/16 bit 
Übertragung zu einem FPGA. Auf github gab es damals auch schon jemand, 
der Übertragungsraten mit so einer DMA-Parallel-Schnittstelle getestet 
hatte. Die Ergebnisse konnte ich damals verifizieren. Ich meine es waren 
zwischen 6-8 Takte/Wort.

von avr (Gast)


Bewertung
0 lesenswert
nicht lesenswert

von avr (Gast)


Bewertung
0 lesenswert
nicht lesenswert

von Marcus H. (Firma: www.harerod.de) (lungfish) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Nett, dass die das mittlerweile in eine Appnote gepackt haben.
Hab grad nochmal nachgeschaut: Als ich 2013 geschnallt habe, dass die 
DMA-Engine Datentransfers in die verschiedensten IO-Register, inkl. 
GPIO-Register erlaubt, habe ich eine bis dato FPGA-basierte Baugruppe in 
eine STM32F4 Baugruppe umgebaut.

Vorher-> http://harerod.de/applications_ger.html#SSI_TOOL1
Nachher-> http://harerod.de/applications_ger.html#SSI_USB
Das oben beschriebene Input Capture erlaubt den SSI-Slave-Betrieb.
SSI-Master geht über einfach über Timer.

Irgendwie schade, ich habe seitdem keine Anwendung mehr gehabt, die ein 
FPGA erfordert hätte. War alles mit STM32-Peripherie zu erledigen.

Interessehalber - kann man diese Funktionen mit den HAL-Oberflächen 
zusammenklicken? Ich habe immer den Eindruck, dass die HAL-Geschichten 
viele spannende Tricks unterbinden.


Nebenbemerkung: kleinere Prozessorfamilien haben mittlerweile 
Logikeinheiten auf dem Chip integriert. Beispiel ATtiny214 CCL.
Das wird dem TO nicht reichen, spart aber bei vielen Anwendungen externe 
Gatter.

von Gerd E. (robberknight)


Bewertung
0 lesenswert
nicht lesenswert
Ganz neue, größere STM32-Serien haben einen DMAMUX, z.B. die STM32L5.

Mit dem kann man direkt EXTI-Lines als DMA-Trigger verwenden.

von Joerg W. (joergwolfram)


Bewertung
0 lesenswert
nicht lesenswert
Ziel der ganzen Sache soll VGA-Ausgabe sein. Ein externes CPLD 
(XC9572XL) habe ich sowieso vorgesehen, schon wegen des Jitter-Problems. 
Dieses CPLD liefert neben den Synchron- auch Word-Trigger-Signale und 
"shiftet" 16 Bits Input nach 4 oder 8 Bits Output.

Ein STM32L496 hat genügend RAM, um 640x400 in 16 Farben und ggf. 2 Pages 
darzustellen, oder 320x200 in 256 Farben. Wenn ich pro DMA-Event 16 Bits 
übertrage, komme ich auf 6,25MHz Triggerfrequenz, was bei 100MHz 
"Übertaktung" 16 AHB-Zyklen je Transfer ergibt. Laut AN4031 würde ein 
Transfer maximal 11 AHB-Zyklen brauchen, womit ich auf der sicheren 
Seite sein sollte. So kann ich mit dem HSYNC einen Interrupt auslösen 
lassen, um die DMA neu "nachzuladen".

Ursprünglich wollte ich das in Software realisieren (das funktioniert 
auch schon), aber es ist schon irgendwie verschwendete Rechenzeit. Wenn 
schon ein AVR (bei 25MHz) VGA-Ausgabe über externes RAM und einfache 
3D-Berechnungen (incl. Z-BUffer) kann, dann sollte sich aus einem STM32 
noch einiges mehr herausholen lassen...

Jörg

von Marcus H. (Firma: www.harerod.de) (lungfish) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Mmmh. Warum möchtest Du externe Synchronisierung für den Bildaufbau?
Wie auch immer, das ist doch eine klassische Datenpumpe, getaktet von 
einem internen Timer. Besser wird der Jitter durch externen Trigger auch 
nicht nicht.

Hobbyprojekt Einzelstück? Dann ist sowieso alles erlaubt was Dir 
gefällt.

von Joerg W. (joergwolfram)


Bewertung
0 lesenswert
nicht lesenswert
Alles über Timer zu machen, war auch meine ursprüngliche Idee, dafür 
gibt es auch genügend Beipiele im Netz. Aber um den Jitter 
auszugleichen, brauche ich einen Puffer zur Synchronisation. Das besagte 
CPLD ist für mich dafür die einfachste Lösung und hat noch genügend 
Platz, um das gesamte Timing zu übernehmen.

Da das CPLD die Daten erst 16 AHB-Zyklen nach dem Auslösen braucht, hat 
der Controller (bzw. seine DMA) 15 AHB-Zyklen Zeit, um das nächste 
Datenwort an den Port zu schaufeln. Das ist selbst in Software 
(zumindest in ASM) problemlos realisierbar.

Bei der vorgesehenen Lösung muss die CPU nur bei jedem HSYNC die DMA neu 
initialisieren (Speicheradresse +genügend großen Counter setzen), 
Zuordnung der Bits zum R-DAC und Blanking übernimmt alles das CPLD. 
Damit bin ich auch flexibler bei der Auflösung.

Und ja, es ist ein reines Hobbyprojekt. Wobei die damit gemachten 
Erfahrungen auch in andere Dinge einfließen können...

Jörg

von Marcus H. (Firma: www.harerod.de) (lungfish) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Joerg W. schrieb:
> Alles über Timer zu machen, war auch meine ursprüngliche Idee, dafür
> gibt es auch genügend Beipiele im Netz. Aber um den Jitter
> auszugleichen, brauche ich einen Puffer zur Synchronisation. Das besagte
> CPLD ist für mich dafür die einfachste Lösung und hat noch genügend
> Platz, um das gesamte Timing zu übernehmen.

Na denne - ich denke das passt für Dich so.

Interessehalber - gemeinsamer Takt für CPLD/MCU?

>
> Da das CPLD die Daten erst 16 AHB-Zyklen nach dem Auslösen braucht, hat
> der Controller (bzw. seine DMA) 15 AHB-Zyklen Zeit, um das nächste
> Datenwort an den Port zu schaufeln. Das ist selbst in Software
> (zumindest in ASM) problemlos realisierbar.

ASM -> seeehr sympathisch. ;)

> Bei der vorgesehenen Lösung muss die CPU nur bei jedem HSYNC die DMA neu
> initialisieren (Speicheradresse +genügend großen Counter setzen),
> Zuordnung der Bits zum R-DAC und Blanking übernimmt alles das CPLD.
> Damit bin ich auch flexibler bei der Auflösung.

klar, sehr einfache Umsetzung im STM32

> Und ja, es ist ein reines Hobbyprojekt. Wobei die damit gemachten
> Erfahrungen auch in andere Dinge einfließen können...

Schon schlimm, gelle? Irgendwann ist alles Arbeit... :D

von Joerg W. (joergwolfram)


Bewertung
0 lesenswert
nicht lesenswert
> Interessehalber - gemeinsamer Takt für CPLD/MCU?

Optional. Das CPLD bekommt seinen Takt aus einem 25MHz Quarzoszillator, 
den Controller versorge ich meist auch damit (evtl. heruntergetaktet) um 
mir den weiteren Quarz einzusparen. Notwendig ist es nicht, da das Ganze 
ja mehr oder weniger asynchron funktioniert. Den Videotakt aus der PLL 
herunterzuteilen halte ich für nicht sinnvoll, zumindest bei anderen 
Controllern (S12XE) gab es dann teilweise deutliche Jitter-Effekte.

ASM bringt halt je nach Anwendung nochmal Einiges an Geschwindigkeit. 
Und mir macht es einfach Spaß... auch wenn ich in den letzten Jahren für 
viele Dinge vermehrt C verwende.

Das CPLD trägt natürlich nicht zur einfachen Nachbaubarkeit bei, aber 
Projekte sind meiner Erfahrung nach heute in den meisten Fällen nur noch 
dann interessant, wenn sie auf BoardXY laufen und sich mit IDEyz unter 
Windows laden und übersetzen lassen. Aber diesen "Markt" überlasse ich 
lieber Anderen.

Jörg

von m.n. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Joerg W. schrieb:
> Ziel der ganzen Sache soll VGA-Ausgabe sein. Ein externes CPLD
> (XC9572XL) habe ich sowieso vorgesehen, schon wegen des Jitter-Problems.

Ich nehme an, Du willst die Daten per FMC ausgeben. Sofern nichts 
Weiteres an diesem Bus angeschlossen ist, würde ich behaupten, daß 
darüber die Daten ohne Jitter erscheinen. Das CPLD wäre damit 
überflüssig.
Die DMA-Übertragung ist recht schnell und kann zudem gepuffert ablaufen. 
Der Flaschenhals bei der Ausgabe ist die Geschwindigkeit des FMC. Und 
dieser "Flaschenhals" synchronisiert die Ausgabe durch das eingestellte 
Timing. Dieses Timing begrenzt die max. Geschwindigkeit, und da immer 
schon neue, gepufferte Daten anstehen, bricht die Geschwindigkeit auch 
zu keinem Punkt ein.
Selber verwende ich diese Art der Ausgabe bei TFTs, die natürlich völlig 
zeitunktitisch arbeiten. Aber Jitter ist mir nie aufgefallen, weshalb es 
auch mit CRTs funktionieren sollte. Im einfachsten Fall kannst Du ja mal 
das Synchronsignal für VGA erzeugen und es mit einem Monitor testen.

von Marcus H. (Firma: www.harerod.de) (lungfish) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Joerg W. schrieb:
>> Interessehalber - gemeinsamer Takt für CPLD/MCU?
>
> Optional. Das CPLD bekommt seinen Takt aus einem 25MHz Quarzoszillator,
> ...

Die STM32F4 PLL hat einen deutlich größeren Jitter als z.B. der F1. Auch 
ohne programmierte Bandspreizung. Das merkt man bei High-Performance 
Ethernet-Anwendungen. Ich weiß nicht, ob man das auf dem Monitor sehen 
würde.

Ich hänge wenn möglich gerne alles auf einen Takt, da dann von der EMV 
her die Effekte besser abzuschätzen sind.


> ASM bringt halt je nach Anwendung nochmal Einiges an Geschwindigkeit.
> Und mir macht es einfach Spaß... auch wenn ich in den letzten Jahren für
> viele Dinge vermehrt C verwende.

Wobei ARM-Thumb-Assembler schon was besonderes ist. Speziell wenn 68k 30 
Jahre und x86 25 Jahre her sind und man zwischendurch bevorzugt auf AVR 
unterwegs war. Allerdings gab es auch immer mal Gründe Z80, 8051, 
PicoBlaze / KCPM3 und anderen Kram zu programmieren.

Selbstverständlich ist C Standard. Aber wenn man in der Serie Material 
und Batteriekapazität sparen kann, dann ist das ein super Vorwand für 
ASM. :)

von Joerg W. (joergwolfram)


Bewertung
0 lesenswert
nicht lesenswert
> Ich nehme an, Du willst die Daten per FMC ausgeben

Nein. Ich habe einen LQFP64 vorgesehen und da gibt es den m.W. sowieso 
nicht. Ich nehme einfach einen I/O Port (PORT B oder PORT C), die sind 
sowieso einmal da. Außerdem kann der FMC nur 8 oder 16 Bit, für 16 
Farben bräuchte man dann trotzdem eine externe Hardware. Mit CPLD 
sollten eventuell auch 1024x768 monochrom oder gar mit 4 Farben möglich 
sein, dann halt mit 64MHz Pixeltakt. Und da das CPLD das Timing intern 
"abarbeitet", muss der Controller nur innerhalb von 160µs nach dem 
Trigger die neuen Daten an den Port anlegen. Das geht per Software 
problemlos und sollte mit DMA auch unkritisch sein.

> Selbstverständlich ist C Standard. Aber wenn man in der Serie Material
> und Batteriekapazität sparen kann, dann ist das ein super Vorwand für
> ASM. :)

Was heißt "Vorwand"? Ich habe nicht vor, irgendwas in Serie zu bauen. 
Warum sollte ich etwas in C programmieren, wenn ich es in ASM 
effizienter kann? Wobei ich für C mittlerweise meinen eigenen "HAL" in 
Form einer Library geschrieben habe (teilweise in ASM ;-)

Jörg

von Joerg W. (joergwolfram)


Bewertung
0 lesenswert
nicht lesenswert
Auch wenn es nur indirekt zum Thema gehört, mit z.B. dem STM32H743 
sollte es doch eigentlich möglich sein, einen IBM PC oder Atari ST 
komplett zu emulieren. Aber dafür müsste halt das 
"Video-Ausgabe-Problem" gelöst sein, wobei bei den Textmodi DMA auch 
nicht weiter hilft.

Jörg

von m.n. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Wo siehst Du denn das Problem beim STM32H743? Dieser hat einen 
TFT-Controller, der doch eigentlich passende Synchronimpulse erzeugen 
sollte.
Ich frage mal anders: Welche Monitore möchtest Du denn überhaupt 
betreiben?

Die H7xx haben 512 KB RAM an einem Stück, wenn man nicht ext. Speicher 
verwenden möchte. Das dürfte die max. Auflösung begrenzen. Für 
monochrome Bildschirme wird man eher eine Pixelausgabe per SPI 
anstreben, da damit der höchste Pixeltakt möglich ist.
Bei wenigen Farben <= 256 kann man per CLUT + TFT-Controller sich sein 
Spektrum selber zusammenstellen oder per DMA bis zu 8 Bit parallel per 
FMC ausgeben. Was sinnvoll sein kann, hängt von den übrigen 
Anforderungen und vom konkreten Monitor ab. Die Lösung für diverse 
Monitore wird es nicht geben.

Mit einem Nucleo-H7xx-Board könntest Du kostengünstig Testsignale 
erzeugen.

von Marcus H. (Firma: www.harerod.de) (lungfish) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Joerg W. schrieb:
> Auch wenn es nur indirekt zum Thema gehört, mit z.B. dem STM32H743
> sollte es doch eigentlich möglich sein, einen IBM PC oder Atari ST
> komplett zu emulieren. Aber dafür müsste halt das
> "Video-Ausgabe-Problem" gelöst sein, wobei bei den Textmodi DMA auch
> nicht weiter hilft.
...
Atari ST? Das wäre ja Nostalgie pur. Weiß gar nicht, ob meine Ataris 
noch laufen würden. Die wollte ich schon lange in gute Hände abgeben.


@ m.n.
Mein erster 260ST hatte 192kB ROM-TOS und 512kB RAM.
Das ist schon sehr nahe STM32H743.
Bis auf die Rechenleistung, da hinkt die 8MHZ 68k doch etwas hinterher.

Bin gespannt, ob hier jemand gelegentlich einen Atari ST Emulator 
vorstellt.

: Bearbeitet durch User
von Joerg W. (joergwolfram)


Bewertung
0 lesenswert
nicht lesenswert
> Welche Monitore möchtest Du denn überhaupt betreiben?

In erster Linie VGA und wenn RGB (Scart) mit abfällt, ist das nur recht. 
Für die kleinen TFT gibt es bereits genügend vorhandene Lösungen, aber 
das ist für mich nicht interessant.

Für eine reine "Grafikkarte" ist der STM32H7xx meiner Meinung nach 
oversized, der wäre halt als Emulator-Basis interessant. Dann aber mit 
eigenem Board. Bei den Disco-Boards habe ich die Erfahrung gemacht, dass 
das Ganze schnell in wackelige Provisorien ausartet und man teilweise 
erst mal Onboard-Komponenten entfernen muss, um alle Signale 
störungsfrei nutzen zu können. Da ist mir eine selbst geätzte 
Leiterplatte mit ein paar Drahtbrücken lieber, aber das muss jeder für 
sich entscheiden...

> Bin gespannt, ob hier jemand gelegentlich einen Atari ST Emulator
> vorstellt.

Es ist mir zumindest die eine oder andere Überlegung wert und ein 
5120STF sollte eigentlich möglich sein. Der Monochrom-Modus ließe sich 
via SPI oder I2S realisieren, für die Farbmodi wird es aber "haarig", da 
der ST hier Bitplanes verwendet und DMA nicht weiterhilft. Ich habe mir 
zwar schon eine Lösung ausgedacht, die nur einen externen R2R DAC 
braucht, während der Bildausgabe ist aber keine Emulation möglich. 
Alternativ könnte man die Videoausgabe in einen zweiten Controller 
verlagern und beide via SPI oder parallel verbinden, welche die 32K 
Videospeicher+Palettenregister zyklisch überträgt. Im Moment steht da 
noch nicht viel bis gar nichts fest, es geht erst mal nur um Konzepte, 
und da gehört der externe DMA-Trigger einfach mit dazu...

Jörg

von m.n. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich verstehe garnichts!

Marcus H. schrieb:
> @ m.n.
> Mein erster 260ST hatte 192kB ROM-TOS und 512kB RAM.
> Das ist schon sehr nahe STM32H743.
> Bis auf die Rechenleistung, da hinkt die 8MHZ 68k doch etwas hinterher.

Atari, Amiga und Mac haben mich nicht interessiert - eher etwas für 
"Spieler". Aber 68k war natürlich auch angesagt.
Der Vergleich der Rechenleistung ist etwas schwierig. Ich würde hier 
mindestens den Faktor 100 ansetzen, obwohl die Taktfrequenz ja nur 
Faktor 50 höher liegt ;-)

von Joerg W. (joergwolfram)


Bewertung
0 lesenswert
nicht lesenswert
Ich denke, er hatte mich gemeint...

Jörg

von Marcus H. (Firma: www.harerod.de) (lungfish) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
m.n. schrieb:
...
> Atari, Amiga und Mac haben mich nicht interessiert - eher etwas für
> "Spieler".
...
Au ja, ich hätte nach fast dreißig Jahren mal wieder Lust darüber zu 
diskutieren, ob man mit einem Atari ST arbeiten kann. lol
68k Maschinensprache habe ich gelernt, um ein Speicheroszilloskop zu 
bauen. ADC am ROM-Port. Generell hat man mit GALs und PALs am ROM-Port 
schon viele Spiele treiben können.

Joerg:
Man muss halt überlegen, wie man den Shifter nachbaut.
Grundsätzliche Varianten:
- Mit Farbtabellen-LUT im externen CPLD.
- zusätzlich zum eigentlichen 32kB Bildschirmspeicher schon fertig von 
der Emulatorfirmware aufgebaut im Speicher. Das sind dann aber 192kB 
(320*200*3 Byte RGB). Da man aber sowieso externen RAM setzen wird, 
warum denn nicht?
- wie Du schon geschrieben hast: zweiter STM32 als Graka. Dadurch sind 
Emulation und Video weitgehend getrennt.


Generell ist halt die Frage, wie gut man emulieren möchte. 
Softwareemulatoren sind ja schon sehr gut. Mit einem Hardwareemulator 
gewinnt man nichts, außer dass man es gekonnt hat. Wie auch immer, bin 
gespannt, ob wir von Deinem Projekt in der Zukunft was lesen werden.

von Joerg W. (joergwolfram)


Bewertung
0 lesenswert
nicht lesenswert
> Au ja, ich hätte nach fast dreißig Jahren mal wieder Lust darüber zu
> diskutieren, ob man mit einem Atari ST arbeiten kann. lol

Ich hatte jahrelang einen MegaST mit Nova-Grafikkarte und später 
PAK68/3, danach einen TT und auch einen Zeit lang einen Falcon030, für 
den ich das erste Public Domain "Videoschnittprogramm" geschrieben 
hatte...

Externen Speicher versuche ich zu vermeiden, weil sich das meist mit 
einseitigem Layout "beißt".

> Mit einem Hardwareemulator
> gewinnt man nichts, außer dass man es gekonnt hat.

Das reicht doch, der Weg ist das Ziel... Und man lernt meist eine Menge, 
sowohl über das zu emulierende System als auch über den 
"Host-Controller". Danach verschwindet es irgendwo im "Archiv" oder wird 
"recycled", es ist halt ein Hobby. Für die "praktischen Dinge" haben bei 
mir hingegen meist weit kleinere Controller genügt.

Jörg

von Marcus H. (Firma: www.harerod.de) (lungfish) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Joerg W. schrieb:
...
> erste Public Domain "Videoschnittprogramm"
...
Coolest. Ich bin zwischenzeitlich auf Premiere umgestiegen. ;)

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]
  • [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.