mikrocontroller.net

Forum: FPGA, VHDL & Co. ADC liefert nur gerade Werte.


Autor: Gustl B. (-gb-)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Hallo,

ich habe eine Platine mit LTC2325 entworfen, bestückt und funktioniert 
eigentlich ganz so wie sie soll. Drauf ist auch ein FPGA-Modul von 
Trenz.

Jetzt hat der ADC ein SPI Interface (ich verwende SDR CMOS) und gibt 
auch eine Clock aus mit deren steigender Flanke ich die Daten eintakten 
kann. Also Schieberegister das das schön weiter schiebt und wenn gerade 
nicht geschoben wird (Ruhephase wenn nCNV high ist) wird der Inhalt als 
fertiges Sample übernommen. Soweit so gut. Jetzt bekomme ich aber nur 
gerade Werte vom ADC. Im Datenblatt steht Zweierkomplement, in VHDL 
wandele ich das so um:
output <= std_logic_vector(unsigned(not(input)) +1);

Habt ihr irgendeine Idee was falsch laufen könnte? Wenn ich Statt der 
ADC-Werte einen Zähler im FPGA verwende und dessen Wert zum PC schicke 
funktioniert das wunderbar.

Was ich auch nicht verstehe ist wieso
output <= std_logic_vector(to_unsigned(to_integer(signed(input)),16));

Zweierkomplement nicht umwandelt. Ich verstehe das so, dass mit signed() 
der std_logic_vector "Kabelbaum" betrachtet wird als Zahl im 
Zweierkomplement. Dann wird daraus eine Integer und diese mit 
to_unsigned() in eine Bitrepräsentation ohne Zweierkomplement. Wo ist 
mein Fehler?

Autor: Lothar M. (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gustl B. schrieb:
> Habt ihr irgendeine Idee was falsch laufen könnte?
Falscher SPI Mode?
Ein Bit zu wenig oder eins zu viel eingelesen...

Autor: Gustl B. (-gb-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dachte ich auch aber in der Simulation gehen 16 Takte raus und sollten 
auch mit etwas Latenz auf Clockout vom ADC zurückkommen. Vor allem mache 
ist das mit einem Schieberegister, wenn ich also eins zu oft oder zu 
selten schiebe, dann sollte nach ein paar Zyklen Müll drin stehen aber 
die Samples sehen grob betrachtet gut aus, man sieht das Signal sauber 
nur sind die Werte eben immer gerade.

Wie macht man das eigentlich sauber?! Ich will 5MSample/s und habe 
100MHz als Takt im FPGA. Jetzt habe ich einen Zähler 0 bis 19 der mit 
den 100MHz läuft und nCNV erzeuge ich dann daraus und SCK auch.
begin

LTC2325_SCK <= clk100 when counter > 3 else '0';

process begin
  wait until rising_edge(clk100);
  counter <= counter +1;
  if counter = 19 then
    counter <= 0;
  end if;
  
  LTC2325_nCNV <= '0';
  if counter < 2 or counter > 18 then
    LTC2325_nCNV <= '1';
  end if;
end process;

Das macht also 30ns nCNV und danach 16 Takte auf SCK. Ist das OK so oder 
macht man das anders?

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

Bewertung
0 lesenswert
nicht lesenswert
Clock Signale nicht kombinatorisch erzeugen.  Kuck  doch mal auf des 
Meisters Seite.

Gruß j

Autor: Gustl B. (-gb-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, ist mir klar, aber wie sonst? Ich soll die Clock ja nicht dauerhaft 
laufen lassen laut Datenblatt. Also möchte ich die irgendwie abschalten 
können zwischendurch.

Autor: fpga (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bist du sicher? Warum sollte man die clock abschalten?

Autor: -gb- (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Steht jedenfalls da im Datenblatt.
http://www.linear.com/docs/56677

Ich mach das bisher bei ADCs immer so mit der Clock, funktioniert ja 
auch. Das ist jetzt das erste Mal dass ich da länger dran sitze. Morgen 
geh ich mal mit dem Oszi an die Signale.

Autor: Lothar M. (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Wird hier wieder mal der eine einzige FPGA Takt des gesamten Designs mit 
einem Signal namens SCLK verwechselt?
Oder andersrum: im und für das FPGA ist SCLK kein Takt.

Gustl B. schrieb:
> Ja, ist mir klar, aber wie sonst?
Ich mach das so:
http://www.lothar-miller.de/s9y/categories/45-SPI-Master
Und offenbar funktioniert das auch bei anderen... 😉

: Bearbeitet durch Moderator
Autor: Gustl B. (-gb-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du erzeugt die Clock also selber. Ja wird funktionieren, aber für 100MHz 
SCK bräuchte ich dann 200MHz im FPGA. Ich will eigentlich auch kein 
volles SPI bauen, bei den ADCs bisher hat ein einfaches Schieberegister 
genügt. Das war sehr übersichtlich.

Mir ist klar dass SCK bei mir kein Takt ist im Sinne von Taktnetze im 
FPGA. Aber bei Dir doch auch nicht das SCLK?

Und was ist daran schlecht wenn das Signal sonst im FPGA nicht verwendet 
wird? Das geht doch nur raus zum ADC und muss nicht intern im FPGA FFs 
erreichen.

Also eigentlich müsste ich einen BUFMRCE verwenden, also einen Clock 
Buffer mit Enable Eingang.

: Bearbeitet durch User
Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schlimm ist dass der CLK100 dann global auf einem Logik Netz laufen 
muss, und nicht auf einem Taktnetzwerk innerhalb des FPGA. Nimm ein DDR 
Out Flipflop und gib den Takt damit aus wenn es unbedingt notwendig ist. 
Dann bist du sauber und kannst auch sehr bequem die Phase und die 
Freigabe steuern.

Autor: Lothar M. (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Gustl B. schrieb:
> Du erzeugt die Clock also selber. Ja wird funktionieren, aber für 100MHz
> SCK bräuchte ich dann 200MHz im FPGA.
Bei 100MHz SPI-Takt wirst du in der Tat ganz genau aufs Timing schauen 
müssen. Aber in der Tat: da kommst du mit dem "traditionellen" 
SPI-Ansatz nicht weiter. Da geht es um einzelne ns...

> Ich will eigentlich auch kein volles SPI bauen, bei den ADCs bisher hat
> ein einfaches Schieberegister genügt.
"SPI" und "Schieberegister" sind eh' nur die beiden Seiten der selben 
Medaille.

-gb- schrieb:
> Morgen geh ich mal mit dem Oszi an die Signale.
Das erscheint mir als die richtige Herangehensweise...
Nimmst du den CLKOOUT des ADC zum Eintakten der Daten? Das wäre der 
richtige Ansatz, denn nur der CLKOUT ist im Bezug zu den Daten 
ausreichend genau spezifiziert:
CLKOUT  (Pin  33): Serial  Data  Clock  Output. 
CLKOUT provides a skew-matched clock to latch the SDO output 
at the receiver (FPGA). ...
This pin echoes the input at SCK with a small delay. 

: Bearbeitet durch Moderator
Autor: Gustl B. (-gb-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank! Jetzt mit ODDR2 sieht die Post Implementation Timing 
Simulation schon besser und vor allem glitchfrei aus.

Christian R. schrieb:
> Schlimm ist dass der CLK100 dann global auf einem Logik Netz laufen
> muss, und nicht auf einem Taktnetzwerk innerhalb des FPGA.

Das verstehe ich nicht, also ja, kann ich nachgucken und ist so, aber 
wieso wird nicht lokal an nur dieser einen Stelle die Clock vom globalen 
Taktnetz abgezweigt und auf die LUT gegeben die zum Ausgang führt?

Und irgendwie ist das Datenblatt seltsam:
http://cds.linear.com/docs/en/datasheet/232516fa.pdf

Auf Seite 26 unten ist das Timing eingezeichnet. Für mich besteht ein 
t_CYC also aus t_CNVH + t_CONV + t_READOUT.
Auf Seite 5 ist t_CYC aber beschrieben als t_CNVH + t_CONV mit minimalen 
200ns was für 5MSample/s passt. Nur t_READOUT fehlt.
Mir geht es um t_CONV, wie groß muss die mindestens sein? Ein 
Minimalwert steht nicht im Datenblatt.

Autor: Gustl B. (-gb-)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
So, hab das jetzt mit Oszi angeguckt, das Timing sieht schön aus, auf 
CLOCKOUT kommen auch 16 Takte zurück, aber die Daten sind seltsam. Bei 
der letzten steigenden Flanke von CLOCKOUT ist SDO immer Low egal 
welches Signal ich in den ADC reinfütttere.

Bei den Bildern ist der gelbe Kanal immer nCNV also ein FPGA Ausgang.
In Bild 2 und 3 ist der grüne Kanal CLOCKOUT, also das kommt aus dem 
ADC.
In den Bildern 4 und 5 ist der gründe Kanal ein SDO Ausgang vom ADC. Man 
sieht da schön die einzelnen Bits, aber das letzte Bit ist immer LOW. 
Die Marker zeigen das Maximum des ersten und letzten Taktes von 
CLOCKOUT.

Edit: Bei den Bildern 2 und 3 sieht man die Clock auch im gelben Kanal, 
das ist aber nur der Fall wenn ich mit dem Oszi auch ein Taktsignal 
messe. Ich vermute daher das ist von mir messtechnisch unsauber, leider 
habe ich nicht viele Stellen an denen ich an die Masse komme.

Jetzt bin ich mal so frei und lege einen 17. Takt an.
Hat auch nichts gebracht. Man sieht weiterhin 15 Bits die sich 
verändern, dann eines das immer Low ist und jetzt ein 17tes dahinter das 
immer High ist.

Und nochmal Datenblatt:
Seite 25:
> In SDR mode (SDR/DDR Pin 23 = GND), the falling edge
> of this clock shifts the conversion result MSB first onto
> the SDO pins.

Aber im Bildchen Seite 26 ist D15 schon vor der SCK da, also die erste 
fallende Flanke von SCK schiebt D14 auf SDO.

: Bearbeitet durch User
Autor: Christian K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sicher das ein 2325-16 eingelötet ist und kein LTC2325-14 ?

Autor: Gustl B. (-gb-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hab ich auch schon nachgeguckt, mehrfach. Aber steht wirklich auf dem IC 
richtig drauf.

Autor: Achim S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gustl B. schrieb:
> Mir geht es um t_CONV, wie groß muss die mindestens sein? Ein
> Minimalwert steht nicht im Datenblatt.

Und wenn du ihm mal die 170ns gönnst, die als Maximalwert angegeben 
sind, bevor du mit dem Austakten des Ergebnis beginnst? (entsprechend 
Fig. 21 im Datenblatt).

Vielleicht meint die Datenblattlogik, dass der ADC maximal 170ns braucht 
(und du frühestens nach 170ns mit dem Auslesen anfangen solltest).

Autor: Gustl B. (-gb-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kann ich machen, aber ... mit den 30ns nCNV bin ich doch dann schon bei 
200ns. Also das glaube ich einfach nicht, dass das dann als 5MSample/s 
ADC verkauft wird wenn da nicht alle 200ns ein neues Sample rausfällt.

Autor: Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gustl B. schrieb:
> Hab ich auch schon nachgeguckt, mehrfach. Aber steht wirklich auf dem IC
> richtig drauf.

Hast Du den Baustein über einen der offiziellen Händler/Distributoren 
bezogen oder über einen Händler bei Alibaba, Ebay o.ä.?

Autor: Lattice User (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schau ma da rein:

http://www.linear.com/docs/57696

Ist zwar Verilog und für einen Cyclone III, das sollte aber keine grosße 
Hürde sein.

Autor: Gustl B. (-gb-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, über den HBE Shop.

Wie soll ich das überhaupt verstehen. D15 ist da vor der ersten SCK. Und 
D15 wird am Ende mit der letzten SCK rausgeschoben - gehört dann das D15 
am Anfang noch zum vorherigen Sample? Stelle ich mich gerade unfassbar 
dumm an und jage ein Gespenst oder ist das einfach schlecht 
dokumentiert?

@ Lattice User:
Das hatte ich schonmal gesehen als ich mich über den ADC informierte vor 
dem Kauf, aber damals hab ich das ignoriert, es sieht doch recht 
kompliziert aus und so einen eigentlich einfachen Signalverlauf aus dem 
Datenblatt konnte ich bisher auch selber mit wenig VHDL nachbauen.

Edit:

Wenn ich mehr Zeit lasse zwischen fallender Flanke von nCNV und dem 
Auslesen bleibt das letzte Bit weiterhin Low. Bin nachher wieder da.

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

Bewertung
0 lesenswert
nicht lesenswert
Gustl B. schrieb:
>
> @ Lattice User:
> Das hatte ich schonmal gesehen als ich mich über den ADC informierte vor
> dem Kauf, aber damals hab ich das ignoriert, es sieht doch recht
> kompliziert aus und so einen eigentlich einfachen Signalverlauf aus dem
> Datenblatt konnte ich bisher auch selber mit wenig VHDL nachbauen.
>
Offensichtlich hast du da etwas übersehen. Ein Vergleich wäre also 
durchaus interessant.

Ich habe allerdings einen Verdacht.

Das Timing Diagram auf Seite 2 zeigt nicht den Ablauf, sondern dient nur 
dazu um Flankenbeziehungen mit Timingwerten zu versehen.

Der Ablauf wird auf den Seiten 14 und 15 gezeigt.
Hier steht auch, dass die gelesenen Daten aus dem vorhergehenden 
Conversionszyklus stammen. Auf Seite 25 steht unter /CNV dass SCK auch 
die Conversion der SAR ADCs antreibt.
Deinem Osciaufnahmen ist zu entnehmen, dass du nCNV schon während des 
letzen SCK Pulses auf High setzt. Möglichweise wird dadurch die 
Conversion zu früh beendet und das LSB ist immer 0.

Setze mal nCNV einen Takt später auf High.

Autor: Burkhard K. (buks)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
-gb- schrieb:
> Steht jedenfalls da im Datenblatt.
> http://www.linear.com/docs/56677
>
> Ich mach das bisher bei ADCs immer so mit der Clock, funktioniert ja
> auch. Das ist jetzt das erste Mal dass ich da länger dran sitze. Morgen
> geh ich mal mit dem Oszi an die Signale.

Im Datenblatt (S. 14) ist SCK zwar als abgeschaltet (während /CNV high 
ist) gezeichnet - aber heisst dass auch zwangsläufig, das sie 
abgeschaltet werden muss? Zumindest kenne ich ADCs (z.B. AD7476A) bei 
denen sie durchlaufen darf.

Autor: Gustl B. (-gb-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Lattice User:
Vielen Dank! Tatsache wenn ich am Ende einen Takt Pause lasse dann 
ändert das LSB seinen Wert. Nun brauche ich aber 21 Takte, erreiche also 
die 5MSample/s nichtmehr. Gut, ich könnte intern aus den 100MHz 110MHz 
machen, dann würde das passen.

@ Burkhard K.:
Das habe ich noch nie probiert sondern immer den Takt abgeschaltet. Rein 
vom Gefühl her einfach damit das weniger rauscht.

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

Bewertung
0 lesenswert
nicht lesenswert
Gustl B. schrieb:
> Nun brauche ich aber 21 Takte, erreiche also
> die 5MSample/s nichtmehr. Gut, ich könnte intern aus den 100MHz 110MHz
> machen, dann würde das passen.
>

Das Beispielcode von Linear verwendet 110 MHz. (hast du wahrscheinlich 
gesehen)

Du kannst versuchen den Takt Pause am Anfang wegzulassen, ich finde im 
Datenblatt keinen Grund (ausser dem Bilden) warum diese Pause notwendig 
sein sollte.

Autor: Gustl B. (-gb-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja, im Datenblatt steht aber auch, dass eine 100MHz Clock reicht für 
5MSample/s.

Nun, zu früh anfangen geht nicht laut Oszi braucht es irgendwie doch 
etwas Zeit bis das MSB auftaucht. Nicht viel, aber so ein Takt oder so. 
Ich überlege gerade was schöner ist, die SCK mit ODELAY zu verschieben 
bis es passt oder einfach 110MHz zu verwenden.

Autor: Lattice User (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gustl B. schrieb:

>
> Nun, zu früh anfangen geht nicht laut Oszi braucht es irgendwie doch
> etwas Zeit bis das MSB auftaucht. Nicht viel, aber so ein Takt oder so.

Laut Datenblatt sollten das nur 3 ns sein.

> Ich überlege gerade was schöner ist, die SCK mit ODELAY zu verschieben
> bis es passt oder einfach 110MHz zu verwenden.

Verschiebe nCNV um einen halben Takt.
Dazu auch als ODDR2 implementieren, und folgende Folge ausgeben

11
10 Start n
00 (dabei SCK als 10 ausgeben)
  .. insgesamt 16 mal 00
01
11
11
10  Start n+1
00

Aber eine Frage: hast du sichergestellt dass für nCNV ein IO Register 
verwendet wird?

Autor: Gustl B. (-gb-)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ok, jetzt mache ich nCNV und SCK über je ein ODDR2, die sind ja doch 
recht schön zu benutzen (habe bisher diese Herstellerspezifischen 
Features gemieden wo es ging).

Was meinst Du mit IO Register?

In den Constraints habe ich
set_property IOB TRUE [get_ports LTC2325_nCNV]
drinnen.

Edit:
So wie im Bildchen sim0 im Anhang habe ich das jetzt und das LSB bleibt 
dauerhaft Low. nCNV sind 30ns und noch früher mit dem Auslesen anfangen 
geht nicht, da verliere ich das MSB. Ich könnte noch nCNV etwas kürzen 
...

So, jetzt auch Bildchen sim1. nCNV ist jetzt nur noch 25ns, also kürzer 
als der Minimalwert im Datenblatt. Und es sieht gut aus! Ich teste noch 
etwas, aber auf dem Oszi kann ich 16 Bits sehen.

Und noch mehr Bildchen:
Gelb ist jeweils nCNV vom FPGA.
In Bild 6 in Grün ist SCK vom FPGA
In Bild 7 in Grün ist CLKOUT vom LTC2325
In Bild 8 und 9 in Grün ist SDO. Auffällig ist, dass das erste Bit MSB 
etwas kürzer ist. Es wird aber schön eingetaktet im FPGA.
Die Marker bleiben unverändert bei allen Bildern.

Ebenfalls jetzt das VHDL im Anhang.

Vielen Dank für die super Hilfe!

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

Bewertung
0 lesenswert
nicht lesenswert
Gustl B. schrieb:
>
> nCNV ist jetzt nur noch 25ns, also kürzer
> als der Minimalwert im Datenblatt.

Keine gute Idee. Damit wird die Sampling Aperture um 5 ns verkürzt, und 
das geht auf die Genauigkeit. (Siehe Step Response auf Seite 9)

Ob du damit leben kannst, hängt von deinem zu messenden Analogsignalen 
ab. (Frequenz, Amplitude)

Autor: Gustl B. (-gb-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
OK, sehe ich ein. Also mit PLL SCK auf 110MHz ändern und schneller 
auslesen?

Aber gut, ich wollte den Stein erstmal in Betrieb nehmen, die Platine 
ist dafür auch nicht optimal und nur zweilagig. Mal gucken was am Ende 
überhaupt benötigt wird, vermutlich reichen auch weniger Bits locker.

Autor: Da D. (dieter)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gustl B. schrieb:
> OK, sehe ich ein. Also mit PLL SCK auf 110MHz ändern und schneller
> auslesen?
>
> Aber gut, ich wollte den Stein erstmal in Betrieb nehmen, die Platine
> ist dafür auch nicht optimal und nur zweilagig. Mal gucken was am Ende
> überhaupt benötigt wird, vermutlich reichen auch weniger Bits locker.

Wolltest du nicht alle eine Beiträge immer in Code-Tags einschließen?

Autor: Gustl B. (-gb-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Jürgen S. (engineer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie sieht denn jetzt der Code aus? Das mit den manuellen Takten ist 
sicher behoben, oder?

Autor: Gustl B. (-gb-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hab nichts mehr gemacht weil es gut genug funktioniert.

Jürgen S. schrieb:
> Das mit den manuellen Takten ist
> sicher behoben, oder?

Mir wurden doch hier DDR FFS empfohlen?! Was würdest denn Du verwenden?

SCK hängt an einem Clock capable Pin, sollte ich dann direkt eine Clock 
auf diesen Pin geben und sie im FPGA mit einem BUFGCE abschalten wenn 
sie "stumm" seien soll?

Und wieso sollte man das überhaupt anders machen?

Wieso habe ich noch keinen 110MHz Takt verwendet? Weil auf dem Board 
eine 100MHz Taktquelle drauf ist. Würde ich mit einer PLL 110MHz 
erzeugen hätte ich vermutlich mehr Jitter wie wenn ich die 100MHz ohne 
PLL verwende und manuell die Takte ausgebe.

: 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]
  • [vhdl]VHDL-Code[/vhdl]
  • [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.