www.mikrocontroller.net

Forum: FPGA, VHDL & Co. VHDL Design für den IC 74185


Autor: Clemens Lariviere (clela)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
kennt jemand von euch eine gute Implementierung des IC 74185(6-Bit 
Binary to BCD converter von TI)in VHDL mit Testbench,wenn möglich nicht 
taktgesteuert?
Vielen Dank!

Autor: Christoph Kessler (db1uq) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe in zwei Applikationsbüchern ( AT&T und ST) nachgeschaut, in 
denen TTL-Typpen als FPGA-Datei beschrieben sind, aber der 74185 war 
nicht darunter. Aber als 6 KV-Diagramme mit 5 Eingängen sollte sich der 
Konverter doch beschreiben lassen, das ist nicht viel. Im 
Texas-Datenblatt ist die Logiktabelle enthalten. Das unterste Bit0 wird 
direkt weitergegeben, es geht nur um Bits 1-5, die in 6 BCD-Ausgänge 
umgesetzt werden.

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

>Ich habe in zwei Applikationsbüchern ( AT&T und ST) nachgeschaut, in
>denen TTL-Typpen als FPGA-Datei beschrieben sind, aber der 74185 war
>nicht darunter.

Findet man diese Bücher Online?

Gruß,
Dirk

Autor: Christoph Kessler (db1uq) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die sind schon relativ alt, außerdem sind das nur Abbildungen und kurze 
Beschreibungen, die vermutlich zu einer FPGA-Entwurfssoftware gehören. 
In Xilinx Webpack oder Altera Quartus sind auch Beispiele enthalten, ich 
weiß aber nicht ob auch TTL-Emulationen darunter sind.

Autor: clemens lariviere (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank an Christoph und Dirk für Euer Interesse an meinem Problem.
Ich habe selbst nochmal im Netz gesucht und einige Anregungen gefunden.
Habe inzwischen ein einfaches Design in reiner nebenläufiger 
(concurrency logic)Logik geschrieben,bezogen auf eine Instanz des 
IC.Jetzt kann ich mir durch Instanzierung entsprechende Converter selbst 
erstellen(siehe Datenblatt
SN74185)

Anbei vielleicht interessante Links:
http://www.cse.secs.oakland.edu/hanna/cse378/378Lectures.htm
(Codeconverter mittels Shiftoperation)
http://www.doulos.com/knowhow/vhdl_designers_guide...
(Umsetzung der App.Note XAPP029 für XILINX,allerdings taktgebunden)

Autor: Selma (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"kennt jemand von euch eine gute Implementierung des IC 74185(6-Bit
Binary to BCD converter von TI)in VHDL mit Testbench,wenn möglich nicht
taktgesteuert?"

Kann man das nicht einfach mit ein paar ANDs und NOTs zusammenschustern?

Autor: Michael Werner (michelw)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
vielleicht hilft das hier weiter

Autor: Fpga Kuechle (fpgakuechle) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab was getippert und ins wiki gestellt:

http://www.mikrocontroller.net/articles/TTL74185

Autor: Falk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Selma

Wenn man verdammt viele NANDs nimmt kann man das. Will man aber kaum.

@fpgakuechle

Wäre es nicht einfacher und übersichtlicher, einfach die 64 Codes 
hinzuscheiben mittels Case ?

MfG
Falk

Autor: Fpga Kuechle (fpgakuechle) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
<Wäre es nicht einfacher und übersichtlicher, einfach die 64 Codes
<hinzuscheiben mittels Case ?

Case nehme ich für rein kombinat. Netzwerke ungern, da man schnell ein 
signal in der sensetivity list vergisst(case verlangt process) Das 
Äquivalent zum Case ohne process ist select, also wenn dann dieses.

Dann schreib ich die Sachen gerne so das sie optimal in einen 
Xilinx-FPGA passen. Und das ist eben die Beschreibung in einzelen 
Gleichungen mit fanin 5, das passt in zwei LUTs mit F5MUX. Bei der 
Beschreibung als Tabelle 6Bit vector zu 8 bit vector muss das 
synthesetool schon etwas intelligent sein um nicht auf den Gedanken zu 
kommen ein ROM zu verwenden. ROM wäre schlecht da man alle Pfade zu 
einem Punkt und von diesem wieder weg führen müsste (timing/routing 
probs). Kurzum die Beschreibung in  Gleichungen:
y_n = f(x_n1,x_n2,X_n3,X_n4,x_n5)  ist Hardwarenäher (FPGA,CPLD).

Autor: Fpga Kuechle (fpgakuechle) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
<@Selma

<Wenn man verdammt viele NANDs nimmt kann man das. Will man aber kaum.

Zumindest was FPGA's betrifft sind NAND/AND ausgestorben (fast). Das 
Grundelement eines FPGA sind (Xilinx,Altera) LookUpTables. Damit kann 
man beliebige Funktion mit 4 (Xilinx) und 6(?) (Altera) basteln. 
Notfalls auch ein NAND, aber in der Regel bleibt es bei der Komplexeren 
Funktion, sie wird nicht in NAND zerlegt.

Autor: Falk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@fpgakuechle

Wo ist das Problem bei der Sensitivity List? Der Compiler meckert, man 
korrigiert es.

Und wenn du alles Gleichungen schon "optimiert" hinschreibst, machst du 
die Arbeit des Compilers. Ist manchmal sinnvoll, wenn man maximalen Takt 
erreichen will und ein paar Optimierungen, für die der Compiler zu 
dämlich ist. In den meisten Fällen jedoch nicht. Und gerade in diesem 
Beispiel ist es a) wesentlich unübersichtlicher und b) fehleranfälliger 
und c) sind die Compiler heute schlau genug, den ROM (und nix weiter ist 
es) maximal zu optimieren. Probiers aus.

Just my two cents.

MfG
Falk

Autor: Fpga Kuechle (fpgakuechle) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habs ausprobiert (siehe Artikel
http://www.mikrocontroller.net/articles/TTL74185). Die Variante als ROM 
istetwas größer als in der Gleichungsvariante. Wenn ein ROM erkannt 
wird, wird ein ROM benutzt und eben nicht zu Gleichungen ungeformt. 
Woher sollen die Tools wissen was für den Anwender Optimal ist. 
Vielleicht will er ja einen kompakten Block (Flächenpartionierung).

Warum soll man case verwenden wenn es mit select genauso getan ist. Mit 
select macht man weniger falsch. Und spätestens wenn die lieben Kollegen 
einen mit Modulen zuballern, übersieht man die kleinen warnings wegen 
der sense list. Mehrere Hundert warnings sind in der Praxis üblich. Und 
das sind die die man nicht wegbekommt.

Autor: Falk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@FPGAküchle

Man kann bei ISE (und den meisten anderen Tools) einstellen, ob ROMs 
erkannt und in spezielle Hardwarefunktionen (BRAMS) umgewandelt werden 
sollen.

Warum case anstatt select. Ganz einfach! Weil es übersichtlicher, 
weniger fehleranfällig und sinnvoller ist, dass dem Compiler die Arbeit 
gelassen wird, für die er da ist, nämlich Boolsche Algebra zu 
minimieren.

Ausserdem wie kommst du darauf, dass die ROM-Variante grösser ist als 
die "Gleichungsvariante"? Da steht ein BRAM gegen X LUTs/LEs. Birnen und 
Äpfel.

MfG
Falk

Autor: FPGAküchle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Quatsch BRAM! XST sagt in der synthese deutlich was es erkennt, und das 
ist im zweiten Fall eine ROM-Struktur während er beim ersten zwei,drei 
kleinere ROM-Strukturen erkennt (siehe synthesereport *.syr) Diese 
"Strukturen" bauen XST und map dann aus den FPGA Elementen auf 
(memory-Slices (SRL16,distr. RAM), Logic-slices, CARRYMUX etc). Beim 
Beispiel verwendet er keine BRAM's sondern slices. Und lt. 
abschliessenenden report nach Place und Route verbraucht Variante 2 5 
Slices und Variante 1 4 slices.

Wie gesagt ich habs ausprobiert (kompletter Tooldurchlauf), ich 
theoretisiere nicht.

Autor: Falk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> abschliessenenden report nach Place und Route verbraucht Variante 2 5
> Slices und Variante 1 4 slices.

Na dann sag das doch gleich.

Trotzdem ist der Vergleich nicht ganz korrekt, schliesslich hast du im 
Beispiel 1 bcd_o(0) direkt verbunden während es in Beispiel 2 noch im 
Decoder drin ist. Was kommt in Beispiel zwei raus (Resourcenbedarf) wenn 
du bcd_0(0) direkt durchverbindest?

Und mein Argument beleibt bestehen, Version 2 ist 
übersichtlicher/lesbarer und du machst die Arbeit die der Compiler in 
den meisten Fällen besser kann. Und dafür kann ich locker 1 Slice 
"opfern". Ist im Endeffekt die alte Diskussion wie Assembler vs. C. 90% 
der Logik kann man "einfach so" (Variante 2) hinschreiben und mit ein 
minimal suboptimalen Egebnis leben. Nur 10% oder weniger müssen bis aufs 
letzte ausgequetscht werden (Variante 1).

MfG
Falk

Autor: FPGAküchle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
<Na dann sag das doch gleich.

Steht doch im Artikel, lies den doch.

Autor: Fpga Kuechle (fpgakuechle) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
<Warum case anstatt select. Ganz einfach! Weil es übersichtlicher,
<weniger fehleranfällig und sinnvoller ist, dass dem Compiler die Arbeit
<gelassen wird, für die er da ist, nämlich Boolsche Algebra zu
<minimieren.

Ich hoffe mal wir reden aneinander vorbei. Case ist im Vergleich zu 
select weniger übersichtlich, länger und fehleranfälliger (wg. Process). 
Die beiden neuen Codebeispiele (behave3 select|behave4 case) im Artikel 
beweisen das.

Wenn schon als ROM, dann als Konstantenfeld, eventuell noch select 
(obwohl ich da jetzt keine Vorteile erkenne).
http://www.mikrocontroller.net/articles/TTL74185

Autor: Falk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wieso bitte schön ist ein case wegen Process fehleranfälliger?
Und ich die Formatierung ist nicht so, wie ich sie hinschrieben würde. 
Was spricht gegen 64 Zeilen, pro Zeile eine Zuweisung?
Ausserdem, ich wiederhole mich, macht bei Variante 1 der Programmierer 
die Arbeit des Compilers. Denn die Kodierung der einzelnen Bits schreibt 
man nicht einfach so mal hin, da muss man sich schon auf Papier oder in 
Excel die Wahheitstabelle hinschreiben und dan per Hand "umcodieren". 
Alles unnötig, erst recht wenn gerade mal ein Slice dabei rausspringt. 
Aussederm sieht man in Vrsion 1 nciht das Ergebnis des Dekoders auf 
einen Blick, i allen anderen Versionen schon.

Die Frage bleibt natürlich, ob der Compiler, wenn er eine ROM-Struktur 
erkannt hat, ob er dann noch versucht den ROM zu minimieren oder einfach 
faul den ROM 1:1 übernimmt. In diesem Fall wahrscheinlich letzteres.

MfG
Falk

Autor: Fpga Kuechle (fpgakuechle) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
<Wieso bitte schön ist ein case wegen Process fehleranfälliger?

Weil man Fehler in der sensetivity list, z.B. fehlende Signale machen 
kann. Bei Select dagegen nicht, das ist ja der nebenläufige Counterpart 
zum sequentiellen Case, braucht also keinen prozess.

Wenn man Code über tausende von Zeilen hat ist jede mögliche fehlstelle 
eine zuviel. Und wenn man nicht etliche Überstunden schrubben will 
ebenfalls. Synthese anwerfen, Viertelstunde warten, report nach warnings 
durchforsten ... . Jede zeile code die nicht geschrieben werden muss ist 
fehlerfrei.

Autor: tobias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da ich ein Freund von parameterisierbaren Komponenten bin habe ich hier 
mal
was hingetippert für beliebig breite Vektoren. Für eine Analyse hatte 
ich leider keine Zeit mehr. Der Eingangsvektor muss genauso breit sein 
wie der Ausgangsvektor. Also einfach ein paar Nullen beim Eingansvektor 
ranhängen sonst funktioniert das nicht.

Gruß tobias

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

Bewertung
0 lesenswert
nicht lesenswert
OK hier der Anhang

Autor: Fpga Kuechle (fpgakuechle) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Scheint nach den ersten Durchschauen OK, ist leider nicht 
synthetisierbar ( die Division wird angemeckert). Aber uns fehlte ja eh 
noch die Testbench und dazu passt die Funktion ganz gut.

Für bastler mit Hang zum Selbstversuch statt dunkler Theorie, anbei das 
VHDL File mit allen angesprochenen Architekturen. Bis auf die letzte 
passt alles durch die Synthese. Durch auskommentieren ganzer Blöcke kann 
man die einzelnen Variante testen. Oder man schreibt eine configuration 
(aber die mag der XST manchmal nicht).

Autor: Falk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@fpgakuechle

SO ein Quark! Wer nicht mal EIN popeliges Signal in ne sensitivity list 
schreiben kann sollte besser die Strasse fegen und nicht VHDL Designer 
sein! Ausserdem schreibt kein Mensch tausende von Zeilen um dann (völlig 
erschöpft?) die Warnungen des Compilers zu ignorieren. Wer sooooo faul 
(unfähig?) ist, solls bleiben lassen. Und gerade WENN die Synthese ne 
Viertelstunde dauert (Monsterdesign) muss man erst recht schauen, dass 
überall die Warnugen vor allem bezüglich der Sensitivity list weg sind, 
sonst spinnt die Simulation. Und gerade bei so nem Mosnterdesign ist es 
vollkommen daneben, alles per Hand zu "optimieren". Lesbarkeit gegen 
null.

Und Überstund schrubbst ja wohl eher DU, wenn du alles auf Papier 
"optimierst".

"Jede zeile code die nicht geschrieben werden muss ist
fehlerfrei."

So ein Quark. Du klingst wie die alten, halsstarrigen Assembler-Freaks. 
Systematisches Design ist nicht dein Ding.

MfG
Falk

Autor: FPGAküchle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Falk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es ist immer wieder schön, Diskussionspartner mit substantiellen 
Argumenten zu haben . ..

Schönen Tag noch.

Falk

Autor: Bustle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich denk ihr habt beide Recht... mir gefällt aber die Variante von 
fpgaküchle auch besser. Und zwar weil diese kleine Logik keine 
Schwierigkeit darstellt und es mir auf diese Weise mehr Spaß machen 
würde es umzusetzen. Schließlich ist es ja ein Hobby.

Autor: Bustle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ach und ja... @fpgaküchle: cooler Link rofl

Autor: Falk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also hobbymässige Bastelei/Herausforderung/Lernprojekt ja, aus 
professioneller Sicht nein.

MFG
Falk

Autor: alex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mir geht grade eine Frage durch den Kopf. Wie es denn bei der 
case-Variante, falls man aus welchen Gründen auch immer mehr als 6 Bit 
abarbeiten muss? Der Aufwand steigt doch dann mit 2 hoch N. Bei 6 Bit 
sind es noch 64 Zweige. Bei einem Byte 256... also 256 "when"-Zweige?
Ob das noch so praktisch ist...

Autor: Falk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, es IST praktisch. Denn man schreibt einfach hin, welches Ergebnis 
bei welchem Eingangssignal gewünscht ist. Schön übersichtlich. Und man 
muss nicht per hand alles kodieren und optimieren. Das macht der 
Compiler, und das zu 95% sehr gut.

MfG
Falk

Autor: Rick Dangerus (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Naja, alles was nicht mehr auf den Bildschirm passt, ist auch 
unübersichtlich. Eleganter ist m.E. die Variante die im Anhang 
aufgezeigt ist. Einmal mehr nachgedacht und tausendmal weniger getippt.

Grüße
Rick

Autor: Fpga Kuechle (fpgakuechle) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab das akademische Powerpoint sheet mal für Xilinx synthetisierbar 
umgeschrieben:
ARCHITECTURE behave5 OF ttl74185 IS
BEGIN

  bcd_o(0) <= binary_i(0);

  PROCESS(binary_i)
    VARIABLE v_tmp : unsigned(12 DOWNTO 0);
  BEGIN
    v_tmp := "0000" & unsigned(binary_i) & "000";

    FOR i IN 0 TO 2 LOOP
      IF v_tmp(9 DOWNTO 6) > unsigned'("0100") THEN
        v_tmp(9 DOWNTO 6) := "0011" + v_tmp(9 DOWNTO 6) ;
      END IF;
      v_tmp( 12 DOWNTO 1) := v_tmp( 11 DOWNTO 0);
    END LOOP;  -- i 
    bcd_o(7 DOWNTO 1) <= STD_LOGIC_VECTOR(v_tmp(12 DOWNTO 6));


  END PROCESS;

END behave5;

Erstes ergebnis es braucht 5 slices. Find ich erst mal nicht so toll, 
schau ich mir später noch genauer an.

Autor: Fpga Kuechle (fpgakuechle) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
So ich habs in den Artikel eingearbeitet:

http://www.mikrocontroller.net/articles/TTL74185

Also ich versteh (noch) nicht, warum das mit der 3er Addition zur BCD 
Wandklung taugt. Der Code stammt wahrscheinlich von einem Programmierer 
nicht Hardwerker. Die Initialisierung geht über drei Zeilen, da kennt 
einer das "&" nicht. Und der Code ist ohne Überarbeitung nicht 
synthesefähig.

Der Vorteil dieser Variante liegt in der regelmäßigen und kompakten 
Struktur. Man kann einen generischen Wandler für beliebige Bitlängen 
bauen.

Wahrscheinlich stammt dieser Entwurf aus der ASIC-Ecke, im FPGA 
bevorzugt man statt N Input zu M Output Komponenten  N zu 1 Schaltungen 
(LUT). Strukturen mit mehren Ausgängen werden durch (platzgreifende) 
Parallelschaltung nachgestellt.

Also funktional nicht (sofort) verständlicher Code, nicht optimal für 
FPGA aber einfach erweiterbar.

Die behave5b ist ein test ob eine Strukturbeschreibung besser 
synthetisierbar ist. Da sie das nicht ist, ist die kompakte behave5a 
vorziehen. Persönlich würde ich einen 6bit Wandler mit Variante behave2 
aufbauen, bei breiteren mit Erweiterungen von behave5a.

Danke für das interessante Beispiel.

Autor: Rick Dangerus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Fpga Kuechle:

Hmm. Bei mir ließ sich m.E. alle Beispiele ohne große Änderungen sofort 
synthetisieren (Xilinx und GHDL). Aber nagut.

[Wandlung mit add 3]

shift left
add 6

und

add 3
shift left

ist dasselbe.

Aber schön, daß es mit im Wiki erscheint. Ich hab mir nach sowas vor 
zwei Wochen den Wolf gesucht :)

Rick

Autor: Fpga Kuechle (fpgakuechle) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
<Hmm. Bei mir ließ sich m.E. alle Beispiele ohne große Änderungen sofort
<synthetisieren (Xilinx und GHDL). Aber nagut.

Welche Xilinx Version? Ich habs mit der 8.2 versucht und die Operationen 
mit Konstanten Integer auf std_logic_vector wollten nicht. Xilinx 
scheint mit  jeder neuen Version etwas weniger zu synthetisieren, was 
die 8.1 frißt ist der 8.2 unbekömmlich (z.B. array of array als 
generic). Oder es liegt an der benutzten Bibliothek.

Wo has Du das Dokument gefunden? Liegt da vielleicht noch mehr?

Autor: clemens lariviere (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
Vielen Dank noch mal an alle Beteiligten für die die vielen Anregungen 
bezüglich meiner Anfrage hier im Forum!
Ich habe die Version der oakland university ebenfalls mit Xilinx ISE 7.1
synthetisiert.
Leider hatte ich in meinem ersten Eintrag nicht erwähnt,das ich das 
Design
in einen GAL von Lattice 18V10-15LP implementieren mußte.
Mit der Version von ispLEVER kann ich zwar über Synplify synthetisieren 
aber nicht das physische Design der Synthese sehen,so wie bei XST.
Ein Design habe ich nach der Original Beschreibung des Converters nur 
mit
AND und OR beschrieben,jedoch war das Ergebnis in der Schaltung so ,das 
die Werte verdoppelt wurden!
Die Original Beschreibung habe ich auf der Website von TI im Bereich der 
PLD
gefunden.Es ist ein JEDEC File und eine Beschreibung für den ProLogic 
Compiler.Ob diese Version allerdings auf Lattice GAL läuft weiß ich 
nicht.
Vielleicht hat jemand Erfahrung damit?

Autor: Rick Dangerus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Fpga Kuechle:
Aktuelle Xilinx-Version (8.2.03i). Ja irgendwelche Typanpassungen 
mussten korrigiert werden.

Quelle:
http://www.cse.secs.oakland.edu/haskell/CSE378/Lec...

Rick

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.