www.mikrocontroller.net

Forum: FPGA, VHDL & Co. Frage zu DCM und "schrägem" Takt


Autor: Anfänger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ausgehend von einem Spartan 3E dev-board suche ich eine Möglichkeit, mir 
einen rel. krummen Takt zu erzeugen.

Extern steht mir 50 MHz zur Verfügung.

Per core-generator habe ich schon div. Varianten ausprobiert, aber mir 
fehlt noch die zündende Idee :(

Ich möchte ein (externes) Taktsignal von z.B. 57,6 MHz erzeugen. Bei dem 
Wert meckert der core-generator, dass er das mit seinen 0-32 möglichen 
Werten nicht erzeugen kann. Das nehm ich ihm sogar ab, aber welche 
Möglichkeiten habe ich noch, um so einen Takt zu erzeugen (außer mir ein 
Tausenderpack von Quarzen zu kaufen von denen ich nur eines bräuchte)?

Autor: Irgendeiner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja, Du jubelst Dir Deinen Takt per DCM hoch und machst mit dem hohen 
Takt dann eine DDS:

   http://de.wikipedia.org/wiki/Direct_Digital_Synthesis

Das geht natürlich auch digital, ohne DA-Wandler (einfach das MSB vom 
Phasen-Akku verwenden), hat aber bei Deinen Größenverhältnissen einen 
kräftigen Jitter.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ich möchte ein (externes) Taktsignal von z.B. 57,6 MHz erzeugen.
Die Konterfrage lautet: wozu?
Warum kommst du mit deinen 50MHz nicht aus?
Wie genau müssen die 57,6MHz erreicht werden?

Autor: Anfänger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Naja, Du jubelst Dir Deinen Takt per DCM hoch und machst mit dem hohen
> Takt dann eine DDS

Hm, DDS hatte ich so abgelegt, dass das Verfahren zur Erzeugung einer 
beliebigen, konstanten Signalform ungleich dem Rechteck wäre, nicht aber 
für Rechtecksignale.

Aber egal, selbst wenn ich den Accu auf 1 begrenze, erreiche ich damit 
(sofern ich das Prinzip verstanden habe) nur 2**n Teilverhältnisse. 
Selbst wenn ich die 50 MHz auf 200 oder 250 MHz aufpeppe, wüßte ich 
trotzdem nicht, wie ich zu Frequenzen komme, die nicht durch ganzzahlige 
Teiler erreicht werden können.

>> Ich möchte ein (externes) Taktsignal von z.B. 57,6 MHz erzeugen.
> Die Konterfrage lautet: wozu?

Die 57,6 MHz waren nur ein Beispiel, es könnten auch 75.396 Hz sein.
Zum einen geht es mir ums Verständnis und zum Anderen darum, eine 
gegebene Spezifikation einzuhalten.

> Warum kommst du mit deinen 50MHz nicht aus?

Weil ich nicht weiß, wie ...

> Wie genau müssen die 57,6MHz erreicht werden?

Nominell auf 2 Herz genau, aber praktisch natürlich mit den gleichen 
Toleranzen, die ein Quarz auch mitbringt (20-50ppm?) - Klar, je genauer 
desto besser.
Ist natürlich auch eine Frage des Aufwandes.

Wenn es einen Weg gibt, eine beliebige (einstellbare) Frequenz außerhalb 
des FPGAs mit vertretbarem Aufwand zu erreichen, wäre ich zu einer 
solchen Variante auch nicht abgeneigt. Ich könnte den Takt ja auch über 
die SMA-Buchse, oder LVDS-Leitungen zuführen.

Autor: Antti (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mit DDS/NCO kannst du beliebig genaue frequenzen erzeugen,
aber es bleibt der jitter, der dann maximal eine clk von
dem NCO takt sind. mit hoch pumpten NCO clock ist es dann
weniger aber immer da.

fur S3E gibt es eine reference design, das den DCM in
"clock dither" modus betreibt, da wird eine DCM mit
NCO generated clock angespeist, und DCM macht den
jitter weniger, such die S3E starter kit reference designs
da ist es, der "frequency generator mit picoblaze" da drinne

Antti

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> aber praktisch natürlich mit den gleichen
> Toleranzen, die ein Quarz auch mitbringt (20-50ppm?)
Dann wirst du einen Quarz kaufen müssen. Nur ein Quraz hält genau die 
Specs eines Quarzes ein (Einschwingzeit, Rauschen...). Wenn du weißt, wo 
du nachgeben kannst, kannst du auch andere Lösungen suchen.

> wie ich zu Frequenzen komme, die nicht durch ganzzahlige
> Teiler erreicht werden können.
Ganz einfach: Virtuelle 275 MHz aus 300 MHz erhältst du, indem du 11 
Impulse mit 3,3333ns ausgibst, dann einen mit 6,6666ns. Das sind dann 12 
Impulse auf 43,3ns. Also einer pro 3,6ns und damit eine Frequenz von 275 
MHz. Aber
>> es bleibt der jitter, der dann maximal eine clk von dem NCO takt sind.
Und wenn du das FPGA auf 300 MHz hochprügelst, hast du einen Jitter bis 
zu 3,3ns, das sind bezogen auf z.B. 75 MHz knallharte 16%.


Da fällt mir ein:
Du hast die Frage nach dem Jitter noch nicht beantwortet.

Autor: Anfänger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Dann wirst du einen Quarz kaufen müssen.

Yepp - da wird es wohl darauf hinaus laufen.

Ich habe mir mal eine Matrix mit den möglichen DCM-Werten bei gegebener 
Eingangsfrequenz gemacht. Da geht zwar einiges, aber so richtig 
befriedigend ist es nicht.

> Du hast die Frage nach dem Jitter noch nicht beantwortet.

War das in einem anderen Thread? Oder meinst Du die implizite Frage?

Also die Antwort wird wahrscheinlich wie bei jedem Anfänger ausfallen:
Ich hätte gern so wenig wie möglich :)

Konkret erarbeite ich mir gerade einen Bustreiber für den SPI-Bus. Wenn 
ich davon ausgehe, dass jeder Busbenutzer andere Forderungen an den Bus 
hat, ist das (für mich) nicht ganz einfach unter einen Hut zu bekommen. 
Wenn ich davon ausgehe, dass der FPGA jeweils der Master ist, geht das 
ja noch halbwegs, weil der SPI-Takt dann mit dem Systemtakt zusammen 
hängt. Bleibt immer noch die Frage, wie ich eine geforderte Frequenz 
eines SPI-Slave-Chips erzeuge.

Interessanter wird der Busmaster, wenn er den FPGA (auch) im Slave-Modus 
betreiben soll, oder für den SPI-Bus ein externer Takt verwendet wird, 
der keinen Bezug mehr zum Systemtakt hat.

Wenn ich mir das jetzt unter dem Jitter-Aspekt anschaue, dann sollen die 
SPI-Signale und deren Verarbeitung/Weiterreichung mit SPI-Takt erfolgen, 
die Verwaltung des Busses und die Verarbeitung der parallisierten Daten 
mit Systemtakt des FPGA erfolgen. An irgendeiner Schnittstelle wird sich 
der Jitter sicher nicht vermeiden lassen.
Bleibt für mich die Frage, ob die Integrität der Daten darunter zu 
leiden hat.

Schließlich soll der Rest des FPGA ja mit seinem "normalen" Systemtakt 
laufen.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>  Oder meinst Du die implizite Frage?
ACK. Die war dort versteckt:
>> Wie genau müssen die 57,6MHz erreicht werden?

> Also die Antwort wird wahrscheinlich wie bei jedem Anfänger ausfallen:
> Ich hätte gern so wenig wie möglich :)
Bitte Zeit- und Toleranzangaben nicht qualitativ (schnell, klein, kurz, 
lang...) sondern gleich quantitativ.

> Bleibt immer noch die Frage, wie ich eine geforderte Frequenz
> eines SPI-Slave-Chips erzeuge.
Du kannst alle mir bekannten SPI-Slaves auch langsamer als mit der 
maximalen Taktfrequenz anfahren.

> Interessanter wird der Busmaster, wenn er den FPGA (auch) im Slave-Modus
> betreiben soll, oder für den SPI-Bus ein externer Takt verwendet wird,
> der keinen Bezug mehr zum Systemtakt hat.
Das ist doch komfortabel: dann bekommst du den SPI-Takt von aussen 
angelegt. Und du musst nur die Daten mit diesem Takt in dein FPGA 
einschieben und dann über den Slave-Select auf deinen FPGA-Takt 
übernehmen.

Ganz einfach:
SPI sind gekoppelte Schieberegister. Zur Synchronistation auf Bitebene 
wird der Takt hergenommen. Und zur Synchronisation der Datenübertragung 
auf Byte- oder Wortebene wird der Slave-Select verwendet.

> Bleibt für mich die Frage, ob die Integrität der Daten darunter zu
> leiden hat.
Die Integrität der Daten darf nicht leiden, schon gar nicht bei einem so 
simplen Bus wie SPI, der über keinerlei eigenständige Fehlerkorrektur 
verfügt. Also bist du selber für die Zuverlässigkeit deiner Daten 
verantwortlich.

> oder für den SPI-Bus ein externer Takt verwendet wird
Es wird nicht irgenein Takt von irgendwoher verwendet. Der Master macht 
den Takt.

Sieh dir mal das an:
http://www.lothar-miller.de/s9y/categories/17-SPI
http://www.lothar-miller.de/s9y/categories/26-SPI-Slave
http://www.lothar-miller.de/s9y/categories/45-SPI-Master

> dass jeder Busbenutzer andere Forderungen an den Bus
> hat, ist das (für mich) nicht ganz einfach unter einen Hut zu bekommen.
Das wirst du sowieso niemals.
Es gibt ja auch nicht den einen Mikrocontroller. Sondern jeder kann 
etwas besser, schwächelt dafür an einer anderen Stelle.


BTW:
Urig, dass du auf die wichtigste Frage keine Antwort gefunden hast:
>> Warum kommst du mit deinen 50MHz nicht aus?
> Weil ich nicht weiß, wie ...

Autor: Anfänger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> Also die Antwort wird wahrscheinlich wie bei jedem Anfänger ausfallen:
>> Ich hätte gern so wenig wie möglich :)
> Bitte Zeit- und Toleranzangaben nicht qualitativ (schnell, klein, kurz,
> lang...) sondern gleich quantitativ.

Nun, bei der Frequenz hatte ich doch quantitativ geantwortet.
Auf 2 Herz genau - wenn ich das bei 100 Mhz umsetzen würde, wäre das 
eine Genauigkeit von 0,00002 Promille - also völlig utopisch.

Deshalb habe ich geschrieben, es sollte der Genauigkeit von Quarzen 
entsprechen. 100ppm dürfte dort wohl "normal" sein, 20ppm sind dann wohl 
die besseren.

> Du kannst alle mir bekannten SPI-Slaves auch langsamer als mit der
> maximalen Taktfrequenz anfahren.

Logisch! - Aber wenn man gewisse Protokolle fahren will, gibt es dort 
spezielle Vorgaben. Nur um mal ein Beispiel zu nennen: Bei ner CD sind 
44.100 KHz Standard. Ich weiß nicht, ob man hören kann, wenn eine CD mit 
44.105 oder 44.095 kHz abgetastet wird - jedenfalls wäre es schon 
nominell nicht mehr konform. Die Fehler der ganzen Signalkette kommen ja 
noch dazu - es ist eher unwahrscheinlich, dass sich Fehler gegenseitig 
aufheben.
Genauso ist es ja auch mit den 12,5 MHz von Ethernet. Keine Ahnung, wie 
dort die Toleranzen sind, aber wenn man nicht versucht, den nominell 
geforderten Wert zu erreichen, kann man seine Arbeit nicht als 
"standardkonform" bezeichnen.

Mir ist schon klar, dass ich solange ich mich innerhalb des 
Entwicklungsboards befinde, mich einen feuchten um Standards kümmern 
kann.
Das sieht aber anders aus, wenn ich Anschluss suche und/oder meine Daten 
anderweitig verwenden will.

Allerdings ist mir auch bewusst, dass selbst wenn ich eine Frequenz auf 
die letzte Stelle exakt produzieren könnte immer noch die Toleranz des 
Quarzes reinspielt, der den Takt für den FPGA erzeugt.

> Sieh dir mal das an:
Im Moment mag ich nicht :)
Ich will ja nicht immer nur abschreiben, sondern auch mal was verstehen, 
bzw. selbst hinbekommen. Da die Grundlagen noch nicht sitzen, muss ich 
schon genug nachschlagen.
Wenn's klemmt oder ich fertsch bin, melde ich mich sowieso.

> BTW:
> Urig, dass du auf die wichtigste Frage keine Antwort gefunden hast:
>>> Warum kommst du mit deinen 50MHz nicht aus?
>> Weil ich nicht weiß, wie ...

Öhm, könntest Du das bitte etwas erläutern?

Autor: berndl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> Sieh dir mal das an:
>Im Moment mag ich nicht :)

solltest du aber! Wenn du nur bei SPI, deinem momentanen Projekt, Sorgen 
wegen krummer Takte hast: SPI ist sowieso total asynchron, ein SPI 
Master kann auch mal einen Moment laenger mit dem Takt aussetzen. Und 
damit hast du ein komplett asynchrones I/F und must es eben auch 
entsprechend in deiner Logik behandeln.

Und wenn du Outputs generierst, die eine gewisse, krumme, Taktfrequenz 
benoetigen, dann brauchst du einen externen Quartz/Oszillator und musst 
den halt evtl. mit einem DCM hinzwiebeln.

Also ich glaube auch, du verstehst dein eigentliches Problem noch nicht 
ganz...

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  berndl
> SPI ist sowieso total asynchron
SPI ist in sich absolut synchron.
Deshalb kann ganz problemlos der Master mal einen Takt verzögern. Jitter 
ist kein Thema, solange die Specs des Slaves für den SCLK nicht verletzt 
werden.

Du weißt das, hast es aber unvollständig weitergegeben ;-)


@  Anfänger
> Bei ner CD sind 44.100 KHz Standard. Ich weiß nicht, ob man hören kann,
> wenn eine CD mit 44.105 oder 44.095 kHz abgetastet wird -
> jedenfalls wäre es schon nominell nicht mehr konform.
Und ganz definitiv ist das kein SPI    :-o

> ob man hören kann, wenn eine CD mit 44.105
> oder 44.095 kHz abgetastet wird
Ja, man kann es hören, wenn eine CD abgetastet wird  ;-)

Allerdings hörst du keinen Unterschied, ob die CD mit 44.105 oder 44.100 
kHz abgetastet wird. Das sind gerade mal 0,011% Abweichung. Ein Halbton 
hat eine Abweichung von 5,95%. Da zeigt nicht einmal ein Stimmgerät eine 
Verstimmung an...  :-o

> du verstehst dein eigentliches Problem noch nicht ganz...
Da muss ich berndl recht geben: das glaube ich auch...

Autor: berndl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>@  berndl
>> SPI ist sowieso total asynchron
>SPI ist in sich absolut synchron.

aber nur senderseitig gesehen! Am Slave musst du mit jedem Worst-Case, 
der unterwegs auftauchen kann, rechnen...

Autor: Irgendeiner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Allerdings hörst du keinen Unterschied, ob die CD mit 44.105
> oder 44.100 kHz abgetastet wird.

Naja, sag das nicht den Hifi-Fetischisten...

Davon abgesehen: Mit einem 24 Bit Phasen-Akku bei 50 MHz 
Eingangsfrequenz und 44,1 kHz Ausgangsfrequenz, hat man schon eine 
Auflösung von unter 70 ppm, bezogen auf den 44,1 kHz, bei 32 Bits sind 
es in dieser Konstellation schon rund 0,25 ppm...

Was bleibt, ist der Phasenjitter. Bei 50 MHz zu 44,1 kHz wären das rund 
800 ppm. Darum die Eingangsfrequenz per DCM hoch jubbeln oder wie oben 
erwähnt, den Jitter der Ausgangsfrequenz direkt reduzieren.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> SPI ist in sich absolut synchron.
Nein, auch empfängerseitig ist die SPI-Übertragung in sich synchron 
zum SPI-Takt.
Dass der SPI-Takt natürlich vollkommen asynchron zum FPGA-Takt ist, 
steht auf einem anderen Blatt. Aber das Empfangsschieberegister kann 
durchaus mit dem SPI-Takt durchgetaktet werden. Nur müssen dann nach der 
Übertragung z.B. mit Hilfe des einsynchronisierten Slave-Select stabile 
Daten in die Taktdomäne des FPGAs übernommen werden.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Davon abgesehen: Mit einem 24 Bit Phasen-Akku bei 50 MHz
> Eingangsfrequenz und 44,1 kHz Ausgangsfrequenz
Ja, zu den eingangs erwähnten 57,6 MHz sind da ja auch gute 3 
Zehnerpotenzen dazwischen   :-o

Autor: Anfänger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schade, aber die letzten beiden Antworten finde ich eher bedauerlich.

> solltest du aber! Wenn du nur bei SPI, deinem momentanen Projekt, Sorgen
> wegen krummer Takte hast ...

In diesem Thread schrieb ich nix davon, dass ich mir Sorgen um einen 
krummen Takt mache. Ich denke, ich habe einen Weg gefunden, 2 
Taktdomaine unter einen Hut zu bekommen. In diesem Thread wollte ich 
wissen, wie ich einen krummen Takt erzeugen, bzw. definieren kann/muss.

Klar weiß ich, dass die Abtastung der CD nix mit SPI zu tun hat.
Ich wollte lediglich ein allgemein bekanntes Beispiel verwenden, bei dem 
Frequenzen vorgegeben sind. Aber sich über jemand anderen lächerlich zu 
machen ist ja leichter, als auf die Frage einzugehen.

> SPI ist sowieso total asynchron, ein SPI Master kann auch mal einen Moment
> laenger mit dem Takt aussetzen.

Das mag im Audiobereich ja angehen. Schätze aber wenn ich in den 
Grenzbereich der IO-Frequenzen des FPGA komme, wird es schwierig werden, 
einen verlorenen Takt wieder einzuholen.

>> du verstehst dein eigentliches Problem noch nicht ganz...
> Da muss ich berndl recht geben: das glaube ich auch...

Das mag wohl sein. Will ich auch überhaupt nicht in Abrede stellen.
Ist das aber ein Grund, sich deshalb über die Beispiele lustig zu 
machen, anstatt beim Kernproblem, bzw. der eigentlichen Frage zu 
bleiben?
Ich bezeichne mich schließlich nicht umsonst als Anfänger.

Wünsche Euch noch einen schönen Sonntag

Autor: berndl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
davon mal abgesehen, oben ging es im konkreten Bsp um SPI: Empfangen des 
SPI signals ist kein Problem, solange dein FPGA schneller laeuft als die 
SCK. Latenz fuer die Daten die rausgehen ist dann schonmal ein anderes 
Thema, verschlimmbessert durch z.B. Laufzeit auf der 
Uebertragungsstrecke. Da muss man evtl. schon mal tricksen...

Beim Beispiel 44,1kHz fuer .wav Uebertragung: Dann baue ich mir halt 
einen Quartz/Oszillator dazu und clocke mit dem meine Daten raus. Ob 
25ns frueher oder spaeter ist ja nicht das Problem. Hauptsache genau 
genug! Und bei 4Byte bei 44,1kHz, das ist ja nu auch nicht das 
Problem...

Ich hatte nur den Eindruck, der OP dachte, er muss fuer jeden 'Slave' 
(SPI oder sonstwas) sich genau die passende Empfangsfrequenz zurecht 
biegen. Das ist Nonsens, ein FPGA ist fuer die meisten Sachen viel 
schneller, kann also mit '(Over)sampling' das ganze loesen.

Und ja, Lothar, natuerlich hast du recht, SPI ist senderseitig synchron. 
Aber Empfaengerseitig halt nicht, selbst wenn du den gleichen 
Oszillator-Eingang am FPGA verwendendest wie der Sender. Deine 
Phasenlage kann eben nun mal 'worst-case' sein, darum ging es mir.

Autor: berndl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Schade, aber die letzten beiden Antworten finde ich eher bedauerlich.

Sorry wenn das so rueber kam, aber du hast weiter oben im Thread danach 
gefragt :o)

Worum es hier geht, ist der Punkt, dass du beim FPGA Design 'genau' 
wissen musst, was deine Anforderungen sind. Ob du jetzt ein guter oder 
schlechter Logic-Designer bist, das zu beurteilen steht mir nicht zu und 
ich hab' auch gar keine Lust dazu!

Also bitte nicht auf den Schlips getreten fuehlen, jeder von uns 
'hardies' hat so seine eigenen Vorstellungen. Schilder doch dann nochmal 
konkret dein Problem, hier gibt's genuegend Leute, die die mit 
positiven/negativen Erfahrungen vlt. weiter helfen koennen.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ich wollte lediglich ein allgemein bekanntes Beispiel verwenden, bei dem
> Frequenzen vorgegeben sind. Aber sich über jemand anderen lächerlich zu
> machen ist ja leichter, als auf die Frage einzugehen.
Wenn du dir lächerlich gemacht vorkommst, dann ist das evtl. deinem 
unduchschaulichen Beispiel zu danken. Glaub mir, ich kann meine Zeit 
sinnvoller verwenden, als andere lächerlich hinzustellen.

Evtl. ist mir nur nicht klar, was denn jetzt dein eigentliches Problem 
ist   :-o

Ich hatte der Beschreibung entnommen, es ginge um ein konfigurierbares 
bzw.  parametrierbares SPI-Interface.
Falls ja: Wozu dann unbedingt eine SPI-Taktfrequenz von abc,xyz Mhz 
[a,b,c,x,y,z = E(0,1,...9)] erzeugen?

> Wünsche Euch noch einen schönen Sonntag
Dito, jetzt ab in den Pool  ;-)

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich versteh die ganze Diskussion um die 57,6MHz nicht.

Einmal schreibt der OP, dass er sie genau einhalten muss. Ein anderes 
mal schreibt er, dass es nur um krumme Frequenzen geht und dass es ja 
auch "75.396 Hz" sein könnten.

Dann heißt es, er hat SPI und vergleicht es mit Audio und 44,1kHz oder 
mit den 12,5MHz von Ethernet. Beides kriegt man übrigens exakt von der 
Frequenz hin.

Das macht alles keinen Sinn ...

Verrat doch einfach mal, wofür du die 57,6MHz genau brauchst.

Wie andere schon angesprochen haben, kann man normalerweise SPI immer 
mit weniger als der maximalen Frequenz fahren. Aber Informationen will 
er sich auch keine Anschauen.

Bei einem SPI-Analog-Digitalwandler geht das übrigens auch ... Da wird 
der SPI-Clock für den SAR-Converter verwendet.

Was ist es denn für eine Peripherie, die exakt 57,6MHz benötigt und über 
SPI angebunden wird?

Grüße
Gast

Autor: Anfänger (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Oups - gerade gemerkt, dass während des Schreibens meines letzten 
Beitrages hier weiter diskutiert wurde - was ich garnicht mitbekam. 
Insofern sind die Referenzen (letzten beiden) natürlich falsch.

Ich möchte 2 Zitate loswerden:
- alles ist schwierig, bevor es einfach wird
- jetzt wo ich weiß, wie es geht, weiß ich auch, wie ich hätte fragen 
können

Der Punkt ist doch, dass ich noch nicht genug weiß, um mein Problem klar 
umreißen zu können, ja dass ich nichtmal weiß, ob das, was ich als 
Problem empfinde überhaupt eines ist. Wenn ich es könnte, bräuchte ich 
vielleicht garnicht mehr fragen.

> Sorry wenn das so rueber kam, aber du hast weiter oben im Thread danach
> gefragt :o)

Die ganze Diskussion um Jitter und Co hat mir einen neuen Aspekt 
eröffnet, über den ich mir bislang keine Gedanken gemacht habe. Deshalb 
hatte ich etwas weiter ausgeholt.

Im Spartan-Handbuch ist ein Bild, welches die Situation recht gut 
veranschaulicht. Nur sind auf dem Bild alle 3 Daten-/Logikpfade 
isolierte Inseln.

Auf dem Dev-Board hat es z.B. ein DAC, ein ADC und einen "Verstärker" 
für die ADC-Eingänge, wobei DAC und ADC mit 50 MHz angefahren werden 
dürfen, der Verstärker nur mit 1,5 MHz. Die Frequenzen sind gut aus dem 
Systemtakt erzeugbar.

Jetzt habe ich aber auch noch externe Komponenten, die ich auch noch 
ansteuern möchte. Die verwenden unterschiedliche Taktraten. Deshalb habe 
ich über div. externe Taktquellen angefangen nachzudenken.

> Verrat doch einfach mal, wofür du die 57,6MHz genau brauchst.

Ich brauche die garnicht. Es war ein fiktives Beispiel um eine Zahl zu 
haben, die sich aus dem Systemtakt nicht erzeugen lässt.
Genausowenig habe ich vor, die 44.100 kHz zu verwenden. Es waren beides 
nur Beispiele.

> Dass der SPI-Takt natürlich vollkommen asynchron zum FPGA-Takt ist,
> steht auf einem anderen Blatt.

So, jetzt kommen wir auf den Punkt.
Von der Voraussetzung bin ich auch ausgegangen. Ich bin davon 
ausgegangen, dass jedes FPGA-Modul, welches mit einem externen 
SPI-Baustein kommuniziert, einen völlig anderen Takt (und evtl. auch 
andere SPI-Modi) haben kann.

Wenn ich nun eine Instanz haben will, die den Zugriff auf den SPI-Bus 
regelt, dann muss die mit dem FPGA-Systemtakt laufen, da sie ja keinen 
SPI-Takt kennt.

Um die Signale vom SPI-Bus an das richtige Modul zu routen, braucht also 
der Busmaster einen Teil, der mit dem jeweiligen SPI-Takt läuft und 
einen anderen Teil, der mit dem FPGA-Systemtakt läuft. Je nach 
Parallelschnittstelle brauchen die FPGA-Module, die mit den 
SPI-Bausteinen kommunizieren nix vom FPGA-Systemtakt zu wissen.

> Ich hatte nur den Eindruck, der OP dachte, er muss fuer jeden 'Slave'
> (SPI oder sonstwas) sich genau die passende Empfangsfrequenz zurecht
> biegen. Das ist Nonsens, ein FPGA ist fuer die meisten Sachen viel
> schneller, kann also mit '(Over)sampling' das ganze loesen.

Ja, berndl, damit hast Du völlig recht! Genau das habe ich auch gedacht, 
bzw. denke es immer noch. Das (Over)sampling funzt ja, wenn der 
Frequenzunterschied hinreichend ist, bzw. die Frequenzen in einem festen 
Verhältnis stehen. Wenn allerdings die Frequenzen durch verschiedene 
Taktquellen erzeugt werden, kann es doch zu Datenfehlern beim Samplen 
kommen - oder irre ich mich da?

> Aber Informationen will er sich auch keine Anschauen.

Woraus entnimmst Du das?
- Weil ich die vorgefertigte Lösung von Lothar nicht verwenden will?
Das eine hat mit dem anderen nix zu tun.
Ich habe von allen Bausteinen, die ich ansprechen will die Datenblätter 
- und glaub mir, ich kann unterscheiden zwischen Maximal- und 
Nominalwert.

Ich lese gerne, wenn es der Wissensbildung dient.
Abschreiben ist für mich eher ein Akt der Faulheit. Unter lernen 
verstehe ich was anderes.

Vom (meinem) Ansatz her habe ich ein SPI-Modul, welches die Schiebung 
veranstaltet, dann habe ich ein Modul zur Ansteuerung des DAC, eines für 
den ADC und eines für den Verstärker. Zwischen dem SPI-Modul und den 
anderen soll ein Busmaster den Zugriff regeln. Das SPI-Modul bezieht 
seinen Takt mal vom DAC-, mal vom ADC- und mal vom Verstärkermodul...

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ich brauche die garnicht. Es war ein fiktives Beispiel um eine Zahl zu
> haben, die sich aus dem Systemtakt nicht erzeugen lässt.
> Genausowenig habe ich vor, die 44.100 kHz zu verwenden. Es waren beides
> nur Beispiele.

Vermutlich war genau das der Fehler der Fragestellung ... Oft ist es 
sinnvoll eine genaue Spezifikationen zu einem Problem zu haben, weil das 
die Bandbreite an möglichen Problemlösungen stark eingrenzt. Oft machen 
es sich die Anfänger einfach zu kompliziert und wollten etwas erreichen, 
was mit der entsprechenden Fachkenntnis überhaupt kein Thema ist, weil 
z.B. in einer Applikation eingebettet es evtl. garnicht so genau geht 
oder es andere Vereinfachungen gibt, die trotzdem zu einem richtigen 
Ergebnis führen.

Daher auch das permanente hinterfragen nach der Anwendung, weil 
Anfänger aus Erfahrung eben manche Sachen anders machen, als jemand mit 
Fachkenntnis und jede Problemlösung auch vom Problem abhängt.

Nur so eine Anmerkung ...

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ich bin davon ausgegangen, dass jedes FPGA-Modul, welches mit einem
> externen SPI-Baustein kommuniziert, einen völlig anderen Takt (und evtl.
> auch andere SPI-Modi) haben kann.
Richtig. Jeder externe SPI-Baustein ist in diesem Fall aber ein 
SPI-Slave. Der hat i.d.R. einen weiten Bereich, in dem sich sein SCLK 
bewegen darf. Wenn ein SPI-Slave für seine Funktion einen Takt braucht 
(z.B. der Netzwerk-Chip ENC28J60), dann hat er einen dedizierten 
Takteingang. Mit welcher Geschwindigkeit das SPI-Interface läuft, steht 
auf einem anderen Blatt.

Es bringt daher nichts, sich mit aller Gewalt einen externen asynchronen 
Takt einzuhandeln, nur um die Kommunikationsschnittstelle der Bausteine 
an der oberen Übertragungsgrenze zu fahren.

> Ich lese gerne, wenn es der Wissensbildung dient. Abschreiben ist für
> mich eher ein Akt der Faulheit. Unter lernen verstehe ich was anderes.
Es lag nie in meiner Absicht, dass du irgendwas abschreibst oder 
herkopierst. Was nicht verboten ist, und durchaus zum "Lernen" zählt, 
ist zu schauen, wie andere eine Aufgabenstellung angehen. Dir bleibt 
dann immer noch die Aufgabe, das Ganze zu verstehen und an deine 
Gegebenheiten anzupassen.

> Das SPI-Modul bezieht seinen Takt mal vom DAC-, mal vom ADC- und mal vom
> Verstärkermodul...
Hier liegt der Hund begraben.
Diesen Ansatz solltest du nochmal überdenken, das macht die Sache 
unnötig umständlich  :-/

Als Gedankenanstoss und ohne Quelltext:
Meine SPI-Engine sieht so aus, dass im DPRAM ein 32-Bit Konfig-Wort 
abgelegt ist, das die Parameter der Übertragung festlegt (Mode, Phase, 
Geschwindigkeit, Protokolllänge, Verzögerungszeiten, welcher 
Slave-Select ...). Danach folgt ein 32-Bit-Wort, das die Sende-Daten 
enthält, dann ein 32-Bit-Wort, das die Empfangsdaten enthält. Zum 
Abschluss kommt ein 32-Bit Statuswort, das bestimmte 
Übertragungsparameter abbildet.
Dieses Muster mit 4x32 Bit wiederholt sich im DPRAM 64 mal. Dort hinein 
werden von einem uC die ganzen Übertragungsparameter und Daten 
geschrieben. Wenn das fertig ist, wird vom uC ein Start-Flag gesetzt.
Jetzt kommt eine State-Machine, die ein Busy-Flag aktiviert, dann den 
ersten Datensatz aus dem DPRAM holt, das SPI-Interface entsprechend 
einstellt, den Slave-Select aktiviert, und dann die Übertragung startet. 
Nach dem Ende der Übertragung wird der Slave-Select deaktiviert, die 
empfangenen Daten ins DPRAM geschrieben und von dort der nächste 
Datensatz geholt und abgearbeitet. So geht das Ganze bis zu 64 mal, dann 
wird das Busy-Flag gelöscht und bis zum nächsten Aktivieren des 
Start-Flags gewartet.
Dazu kommen noch ein paar Feinheiten, wie z.B. das Aktivhalten des 
Slave-Selects über mehrere der 64 Kanäle hinweg, das deaktivieren der 
einzelnen Kanäle...

Autor: Anfänger (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

> Daher auch das permanente hinterfragen nach der Anwendung, weil
> Anfänger aus Erfahrung eben manche Sachen anders machen, als jemand mit
> Fachkenntnis und jede Problemlösung auch vom Problem abhängt.

Das mag in vielen Fällen ja auch richtig sein. Aber nicht wenn es um das 
Verständnis geht. Dann ist die konkrete HW Schall und Rauch.
Ich kann nur sagen - für meinen Geschmack wird nicht alles in den 
Büchern hinreichend erklärt, sodass ich es ohne zusätzliche Erklärung 
verstehen könnte.
Manchmal tauchen in einer Diskussion auch neue Aspekte auf, die ich auch 
gerne verstehen würde. Beispiele machen anschaulich und in dem Fall ist 
es mir wurscht, ob sie einen konkreten HW-Bezug haben.
In so einem Fall bringt mich das permanente Bohren nach konkreten Chips 
nicht weiter.

> Wenn ein SPI-Slave für seine Funktion einen Takt braucht
> (z.B. der Netzwerk-Chip ENC28J60), dann hat er einen dedizierten
> Takteingang.

Das ist korrekt. Mein externer ADC hat einen Systemtakt-Eingang. Dazu 
einige Konfigurationspins, über die man ihn als Master oder Slave 
betreiben kann. Einige Spielarten sind nur verfügbar, wenn man das 
Steinchen im Master-Modus betreibt. Master-Modus heißt für mich, dass 
der ADC den SPI-Takt erzeugt (deshalb habe ich ihn als gegeben 
eingestuft).

Selbst wenn ich den ADC im Slave-Modus betreiben will, ist die Spanne, 
die mein SPI-Takt variieren darf nicht sehr groß, denn der Wert sollte 
abgeholt sein, bevor ein neuer zur Verfügung gestellt wird. Deshalb habe 
ich über asynchronen Takt bezogen auf den externen ADC garnicht 
nachgedacht.

> Es bringt daher nichts, sich mit aller Gewalt einen externen asynchronen
> Takt einzuhandeln, nur um die Kommunikationsschnittstelle der Bausteine
> an der oberen Übertragungsgrenze zu fahren.

Das war nie meine Absicht. Nur wenn ich mit dem ADC eine vorgegebene (!) 
Samplerate einhalten will, ergeben sich die Taktraten von alleine. Das 
hat nix mit ausreizen zu tun, sondern mir geht es um Einhaltung einer 
Spezifikation.

>> Das SPI-Modul bezieht seinen Takt mal vom DAC-, mal vom ADC- und mal vom
>> Verstärkermodul...
> Hier liegt der Hund begraben.
> Diesen Ansatz solltest du nochmal überdenken, das macht die Sache
> unnötig umständlich  :-/

Nun, nicht jeder Takt läßt sich aus dem Systemtakt erzeugen. Also muss 
ich schon mal die Möglichkeit eines externen Taktes in Betracht ziehen. 
Dann habe ich ein paar Versuche gemacht, mit einem eigenen 
"Taktmultiplexer" die unterschiedlichen Takte zu erzeugen. Selbst mit 
der CE-Technik komme ich nicht auf die Zeiten, die ein DCM bietet.
Um jetzt 50 MHz, 12,5 MHz und 1,5 MHz gleichzeitig zur Auswahl zu haben, 
war das bislang beste Resultat 2 geschachtelte DCMs, wobei ich für die 
1,5 MHz noch einen separaten Teiler brauche (die DCMs lassen sich nicht 
so langsam konfigurieren).

Die ganzen Anforderungen sprengen den Rahmen dessen, was ein SPI-Master 
verwalten kann. Das hat mich zu dem Entwurf gebracht, dass ich den Takt 
entweder in den FPGA-Modulen erzeuge, oder in der Top-Entität durch 
Routing der entsprechenden Taktleitung.

Mit meiner Variante ist das SPI-Modul so flexibel, dass es als Master 
und als Slave arbeiten kann, ohne das es weiß, ob es Master oder Slave 
ist.

Die Speicherschnittstelle habe ich auch angedacht (war ein anderer 
Thread), wird vielleicht nicht so knackig wie Deine Variante, aber 
bislang bin ich mit meinem Entwurf zufrieden.

Etwas was mir ganz wichtig ist (um angesichts meines eingeschränkten 
Könnens trotzdem was zu erreichen), ist die Reduzierung der Komplexität 
schon beim Entwurf. Mag sein, dass ein Profi da mehr rausholen könnte - 
damit kann ich im Moment gut leben.
Ich habe mir einen Plan mit den zu erstellenden Modulen gemacht und da 
gehe ich jetzt eins nach dem anderen an.

Auf den asynchronen Takt, bzw. die Grenzen zwischen Taktdomainen bin ich 
jetzt von verschiedenen Seiten gestoßen und deshalb ist es nach wie vor 
ein Thema für mich.
Ich kann nicht behaupten, dass ich den Umgang mit unterschiedlichen 
Takten inzwischen kapiert hätte, noch kann ich mögliche Fehlerquellen im 
späteren Betreib ein- oder abschätzen.

Kann also durchaus sein, dass ich das nochmal wieder zum Thema machen 
muss.

> Es lag nie in meiner Absicht, dass du irgendwas abschreibst oder
> herkopierst.

Habe ich Dir ja auch nicht zum Vorwurf gemacht. Ich bin sehr froh und 
dankbar für Deine Seiten und habe schon viel von Dir gelernt und 
abgeschaut. Aber manchmal muss ich mich auch durchbeißen. Nur dann finde 
ich meine Verständnislücken.
Inzwischen habe ich es mir angeschaut - und festgestellt, dass es nicht 
in mein Konzept passt.
Wenn ich es richtig verstanden habe, ist ein Generic-Parameter ja etwas, 
was zum Zeitpunkt der Synthese aufgelöst wird. Lässt sich also später 
nimmer ändern.

Ich häng mal meinen aktuellen Stand des SPI-Moduls an (der Busmaster ist 
noch nicht fertig).

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Inzwischen habe ich es mir angeschaut - und festgestellt, dass es nicht
> in mein Konzept passt.
Richtig, das hätte ich nach deiner jetzigen (konkreten) Beschreibung 
auch gesagt.

> Wenn ich es richtig verstanden habe, ist ein Generic-Parameter ja etwas,
> was zum Zeitpunkt der Synthese aufgelöst wird. Lässt sich also später
> nimmer ändern.
Nimm den Generic-Parameter in die Port-Liste, dann ginge das   ;-)
Ausgehend von http://www.lothar-miller.de/s9y/categories/45-SPI-Master
z.B. sowas:
entity SPI_Master is
    Generic ( Quarz_Taktfrequenz : integer   := 50000000;  -- Hertz 
              SPI_Taktfrequenz   : integer   :=  1000000;  -- Hertz / zur Berechnung des Reload-Werts für Taktteiler
              Pre_Delay          : integer   :=   50;      -- us / Zeit nach Aktivieren von CS bis Beginn der Übertragung
              Post_Delay         : integer   :=   10;      -- us / Zeit nach Beenden der Übertragung bis Deaktivieren CS 
             ); 
    Port ( TX_Data  : in  STD_LOGIC_VECTOR (Laenge-1 downto 0); -- Sendedaten
           RX_Data  : out STD_LOGIC_VECTOR (Laenge-1 downto 0); -- Empfangsdaten
           CPHA     : STD_LOGIC;                                -- Clock Phase
           CPOL     : STD_LOGIC;                                -- Clock Polarity
           MOSI     : out STD_LOGIC;
           MISO     : in  STD_LOGIC;
           SCLK     : out STD_LOGIC;
           SS       : out STD_LOGIC;
           Laenge   : std_logic_vector (4 downto 0)      -- Anzahl der zu übertragenden Bits
           Start_TX : in  STD_LOGIC;
           TX_Done  : out STD_LOGIC;
           clk      : in  STD_LOGIC
         );
end SPI_Master;
Aber schon für die SPI-Taktfrequenz wäre eine deutlich größere Baustelle 
nötig, weil nur Divisionen durch Zweierpotenzen synthetisierbar sind 
:-(

Autor: Anfänger (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
> Aber schon für die SPI-Taktfrequenz wäre eine deutlich größere Baustelle
> nötig, weil nur Divisionen durch Zweierpotenzen synthetisierbar sind
> :-(

Das ist scheinbar eine (sinnvolle) Beschränkung, die nur für Xilinx 
gilt.
Anbei mein Versuch, mehrere Systemfrequenzen (gleichzeitig) zur 
Verfügung zu stellen.

ClkGen-1.vhd war mein erster Entwurf - so herunter geschrieben, wie ich 
es für richtig hielt. Bei Altera läuft es durch, allerdings wird für 
sysClk eine max. Frequenz < 70 MHz ermittelt.

Erst im RTL-Viewer sah ich, dass ich ein Tabu verletzt hatte, die Takte 
waren alle 'derived clocks'.

Umgestellt auf CE-Technik war nur unwesentlich mehr drin.

Also mit Xilinx probiert. Hier erfuhr ich dann, dass Modulo 134 nicht 
synthetisierbar ist. Ich habe dann die möglichen Werte selbst 
ausgerechnet und in ein Case verpackt.

Mit dieser Variante brauchte Altera nur noch ein Drittel der 
Logikelemente und plötzlich waren die 200 MHz (bei Altera) möglich. Also 
ist Modulo außerhalb der Zweierpotenzen so teuer, dass ich es für 
richtig halte, von Xilinx hier eine Fehlermeldung zu schmeißen.

Nach diesen Tests sind die DCMs natürlich doppelt wertvoll!

Autor: Antti (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
das clock divider von

http://www.frank-buss.de/vhdl/advancedClock.html

hast du naturlich schon angesehen?

Antti

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Also ist Modulo außerhalb der Zweierpotenzen so teuer, dass ich es für
> richtig halte, von Xilinx hier eine Fehlermeldung zu schmeißen.
Hinter Modulo steckt eine Division.
Wenn du keine Pipeline-Register in der Division hast, wird sie 
kombinatorisch synthetisiert. Und eine kombinatorische Division ist 
ressourcenfressend und langsam.

Ein Modulo-2 Division ist einfach eine andere Verdrahtung (oder ein 
Multiplexer), das geht natürlich ratzfatz...


> das clock divider von
> http://www.frank-buss.de/vhdl/advancedClock.html
> hast du naturlich schon angesehen?
Naja, Kombinatorik im Taktausgang:
  clockOut <= latchedData(0) xor latchedData(1);
Wird schon gutgehen...
Aber auch damit können aus 50MHz keine 57,6MHz gemacht werden :-(

Autor: Antti (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
aber du brauchst ja keine 57.6?
war ja nur ein beisbpiel?

mann kann nicht allzuviel zu tricksen

1) externes chip
2) NCO in FPGA mit PLL (v5,v6,s6,altera,lattice,actel)
3) DCM clock dither Spartan3e

mit allen den 3 kriegst du belibiege frequenz mit wenig jitter

aber mit allen losungen den FPGA internen fixed clock benutzen
kannst du zwar sehr genaue (beliebig genau!) bekommen aber mit
+- clock jitter


Antti

Autor: Anfänger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> das clock divider von
> http://www.frank-buss.de/vhdl/advancedClock.html
> hast du naturlich schon angesehen?

Nein, kannte ich noch nicht.
Aber nach überfliegen würde ich das eher als PWM-Engine oder so 
bezeichnen.

> 2) NCO ...

Sehr interessantes Stichwort. Gerade mal ergurgelt.
Bei digikey fand ich dann z.B. den HPS45102 - nicht gerade ein 
Schnäppchen.
Gibt es derlei Steine vielleicht auch ohne die analoge Endstufe, d.h. 
dass kein Sinus sondern ein Rechteck erzeugt wird?

Autor: Mitleser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wenn du gerade dabei bist, such doch mal nach fractional PLL.

Der Teiler im Feedback ist nicht fix sondern wird verändert. Wenn der 
Teiler z.B. immer abwechselnd zwischen 5 und 6 gewechselt wird ergibt 
sich ein Teiler von 5.5.
Das abwechselnde umschalten des Teilers würde allerdings einen Noise bei 
fs/2 erzeugen. Um das zu vermeiden wird ein Sigma-Delta Modulator 
benutzt, der den Noise zu höheren Frequenzen moduliert.

Autor: Michael O. (mischu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
57,6 MHz / 50MHz  = 144 / 125

Um ein Ausgangssignal in diesem Verhältnis zu erzeugen, brauchst Du nur 
2 DCMs nacheinander zuschalten.

1. DCM:   12/5    50MHz => 120MHz
2. DCM:   12/25   120MHz => 67.5MHz

fertig.

Autor: jago (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
jittert das dann nicht?

Autor: Netzspannungsregulatoroberaufseher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> jittert das dann nicht?

Jo. Und?

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.