www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Grafik LCD Ansteuerung funz nicht??


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

Bewertung
0 lesenswert
nicht lesenswert
Hi
Ich habe einen Assembler Code geschrieben
um mein 240x64 Pixel großes
Grafik LCD mit T6963C Kontroller mit nem ATmega8515
anzusteuern aber der code funzt nicht.
Warum was habe ich falsch gemacht??

Code als Anhang gepostet.

Gruß
Merle

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

Bewertung
0 lesenswert
nicht lesenswert
Hoppala war der Falsche code
Hier istb der richtige.

Mfg. Merle

Autor: ->Andre-< (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Merle:

>Ich habe einen Assembler Code geschrieben

Aneignung von Code ? :-)

Der wahre Author wird sich bedanken. ;-)
Vielleicht kann der Author Dir ja beim Debuggen helfen.

Autor: ---- (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Herr Shark:
Ist der Code für 4 oder 8 MHz geschrieben?

Ansonsten: Respekt!

---- (QuadDash).

Autor: Wolfram Hildebrandt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Durch Zufall bin ich der wahre Autor.
Ich habe den Code für einen PIC geschrieben und dann versucht, ihn in
AVR-Assembler zu übersetzten.
Ich habe Merle in den letzten Wochen die Grafikansteuerung mit T6963C
erklärt und den Code für ihn übersetzt. Seit einigen Wochen versuchen
wir, den AVR Code zum laufen zubekommen.
Gestern hat Merle vorgeschlagen, den Code ins Forum zu stellen. Da ich
denke, die Probleme besser beschreiben zu können, wollte ich dies
übernehmen, so dass die Fehleranalyse schneller gehen kann.
Dass Merle den Code als seinen gepostet hat und gleichzeitig meinen
Namen nicht gelöscht hat, ist natürlich äußerst amüsant.
Obwohl zugleich nur die Prozessordatei und eine Übnerschrift
hinzugefügt wurden, und das ganze dann als seinen eigenen Code
anzupreisen, dass ist dann doch etwas dreist.

Das wichtigste hat Merle aber komplett vergessen. Und zwar die
Fehlerbschreibung.
Da ich keine AVR-Hardware habe, habe ich Merle einige Tests machen
lassen, mit dem folgenden Ergebnissen:

Der AVR hängt in der Abarbeitung der Befehle bzw. geht zu früh in den
Reset. Im Code verteilt wurden Testbits eingebaut. Kommt der Code zu
dieser Stelle, so wird das Testbit an einem freinen Port gesetzt.
Das war aber schon beim ersten Unterprogramm nicht mehr der Fall.
Ich rufe als erstes Unterprogramm die Statusabfrage auf, die die Bits
STA0 und STA1 aus dem Display ausließt.
Um die Steuerleitungen Read, Write, CE, CD einzlen setzten zu können
und das im Programm später nachvollziehen zu können, habe ich den
Steuerport am µC (z.B. Portb) mit dcmd ("DisplayCommand") definiert.
Der AVR hängt bei der Abarbeitung dieser Befehle jedoch schon:
        SBI    dcmd,CD
  SBI    dcmd,WR1
  CBI    dcmd,RD1

bis heier geht alles

  CBI    dcmd,CE

hier nicht mehr.
Ich verstehe jedoch nicht, wieso der AVR bei so einem Portzugriff
hängen beleiben kann. Als ich testweise die SBIs und CBIs durch nops
ersetzten liess, hing der AVR angeblich nicht mehr.
Dann wurde mir gesagt, dass man die Befehlsfolge doch mal anders
schreiben kann. Ungefähr so:

ldi  r16,0b00000101
out  dcmd,r16

damit kam laut Merle der AVR weiter.
Jedoch diese Änderung in writecommand0, writecommand1 und writecommand2
(meine Unterporgramme, die SBIs und CBIs benutzten) brachte nichts.
Laut dem Testergebnissen von Merle hängt der AVR bereits wieder in
writecommand0.
Jetzt hat Merle aber leider zu früh ans Forum verwiesen.
Die genaue Stelle, and der der Avr hängt, wisssen wir nicht.
Ob das ohne SBIs und CBIs etwas gebracht hat und der AVR dann nicht
nach gleicher Anzahl von Befehlen hängt bzw. in reset geht, weiss ich
nicht.
Das hat Merle nicht mehr getestet, soweit ich informiert bin.

Ich kann mir nur einen Hardware-Reset vorstellen, der die
Befehlsarbeitung unterbricht.
Also entweder ein Interupt, eine Schwankung in der Stromversorgung
(kein 100nF Kondensator?), der Watchdog, oder am Resetpin irgendwas
störendes.
Der Watchdog ist doch standardmäßig deaktiviert, oder nicht? Der AVR
hing bzw. ging in reset (mit dem SBIs und CBI-befehlen) nach ca. 25µs.
Dass kann dann der Watchdog doch eigenltich nicht sein, weil das zu
kurz wäre.

Das Grundproblem ist also, dass der AVR die Befehle nicht
durcharbeitet, sondern entweder hängt, oder in den reset geht.
Das wäre ja die interessanteste Frage: Geht der AVR dutch irgendeine
Unstimmigkeit in den Reset, oder hängt er? Ersteres ist wohl
anzunehmen.
An der Verwendung der SBIs und CBIs wirds wohl nicht liegen (?), denn
das sind doch zugelassene Befehle für die PortA-D.

Ich könnte Merle zwar mit dem Code alleinlassen, und sollte das
eigentlich auch tun, nachdem er meinen Code als seine Leistung
dargestellt hat, aber ich bin mal nicht so.
Mich interessiert aber natürlich auch, wo die Fehler liegen können,
zumal der Code auf dem PIC wunderbar funktioniert.

Autor: Wolfram Hildebrandt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Den Code habe ich (Wolfram Hildebrandt, ungleich Merle) für 1Mhz
geschreiben (für 4Mhz beim kleinen und mittleren PIC). Das sollte aber
sehr leicht auf 8 oder mehr Mhz angepasst werden können.

Autor: ---- (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Wolfram:

Die Frage nach der Taktung war auch nur ne "Fangfrage" ob er
wenigstens den Kommentar in deinem Code gelesen hat. Außerdem ists
gleichzeitig ein dezenter Hinweis auf einen eventuellen Fehler gewesen.
War also nicht nur Boshaftigkeit von mir.

"Respekt" war mein Ausruf über Merle für wie dumm er das Forum
eigentlich hält.

---- (QuadDash).

Autor: Wolfram Hildebrandt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab' mich schon gewundert. Der Code ist zwar funktionsfähig, aber
doch sehr umständlich, wenn man viele Zeichen darstellen will.

Autor: Merle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo ich möchte mich
bei allen besonders Wolfram
OFFIZIELL
für diese und auch andere
Dinge die ich schon im
Forum Verbockt habe entschuldigen.

Dank an alle die mir
helfen wollte und auch
dank an die die mich
über meine Fehler
informiert haben.

Ich hoffe ihr alle
könnt mir Verzeihen
Und ich schwör bei meiner
Ehre das soe twas niewieder
vorkommt.

Danke das ihr diesen
Text gelesen habt.

Gruß
Merle (Beni)

Autor: Wolfram Hildebrandt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich rufe im Code zuerst das Unterprogramm writecommand0 auf. Dann direkt
das Unterprogramm "status". das zweite unterprogramm (status) wird
bis zum ende ausgeführt, aber der Rücksprung klappt nicht.
beim avr muss man sich ja um einiges kümmern, damit die Unterprogramme
richtig funktionieren, sowas wie stackpointer initalisieren etc.
Ist der Code richtig für zweifach verschaltelte unterprogramme
geschrieben?

Autor: thkaiser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Unterprogramme:
Naja, "einiges" isses ja nicht. Eben nur Stackpointer initialisieren.
Ein "etc." gibts nicht mehr.
Die Initialisierung ist so O.K., daran liegts nicht.

Autor: Merle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi thakiser
Wasist denn mit dem
Stackpointer??
Wird er falsch initialisiert?

Gruß
Merle

Autor: thkaiser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hab ich doch geschrieben, ist so richtig.
Ich glaube eher, daß der Atmel fürs Display um einiges zu schnell ist.
Falls vorhanden, versuchs mal mit einem kleineren Quarz (um 1 Mhz) oder
mit NOPs zwischen den Buszugriffen. Ich habe das Programm nicht
intensiv durchgesehen, aber grobe Fehler habe ich jetzt nicht gesehen.

Autor: thkaiser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
hab schonmal einen Fehler gefunden:
Bei der Status-Bit Auswertung fragt ihr den PORTB ab. Um von einem Port
den aktuellen Zustand der Eingangspins zu lesen, müßt ihr PINB nehmen.
Lesen von PORTB ergibt den Zustand des aktuellen Ausgabepins oder den
Zustand der Pull-Ups.

Autor: Wolfram Hildebrandt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da ist bei mir der PIC durchgekommen. So einen Blödsinn wie Stackpointer
initialisieren und hunderte extra-Register wie z.B. PINB hat der PIC
nicht, bzw. man muss sich nicht darum kümmern.
Aber daran kann die nicht richtig endende Rückkehr aus dem
Unterprogramm doch eigentlich nicht liegen.

Zur Taktung: die einzigste Stelle, wo evtl. die Taktung eine Rolle
spielt, habe ich schon früher mit 4mal (PIC teilt durch 4) so viel nops
ergänzt. Die Unterprogramme hängen trotzdem.

Um herauszufinden, ob der AVR am Rücksprung hängt, oder in den reset
geht, kann man doch mit einem anderen µC den Reset-pin abfragen.
Der erste Hardware-Reset (durch RC-Strecke) wird vom zweiten µC erkannt
und dann wird solange der Reset-Pin abgefragt, bis evtl. eine zweite
zum reset ausreichende "Low-Zeit" erkannt wurde. Wenn der zweite µC
dies erkennt, weiss man, dass es sich um einen ungewollten
Hardware-Reset handelt.

Was meint ihr dazu? Reset oder hängen des AVRs?
Ich würde mir eher vorstellen, dass die Unterprogramme nicht richtig
funktinieren. Aber das kann man ja mit Testunterprogrammen, die freie
Portbits setzten testen.
Nur wie gesagt, ich habe keine AVR-Hardware und kann daher nicht selber
testen, sondern kann Merle nur anweisen, bestimmte Tests durchzuführen.

Autor: thkaiser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja, man kann sich über die verschiedenen Architekturen der AVRs und
PICs streiten - mir gehts andersrum, ich "mag" die PICs nicht - aber
das ist hier nicht das Thema ;-) Es ist sicherlich schwierig, sich auf
eine vollkommen andere Architektur umzustellen, wenn man sich mal
"eingeschossen" hat. Ich habe früher 68000 programmiert, dadurch
fühlte ich mich beim Atmel sofort pudelwohl.

Die Übergabe der Parameter per SRAM ist auch sehr ungewöhnlich, beim
Atmel hat man so viele Register zur Verfügung, daß man eigentlich zu
solchen Schritten nicht greifen muß (aber eine interessante Lösung, auf
die ich noch nicht kam, weil die "kleinen" Atmels die STS/LDS-Befehle
garnicht haben).
Ich habe hier ein 240x128 Display liegen, das schon Schimmel ansetzt,
und ich bin gerade dabei, zu überlegen, ob ich einen 4414 rauskrame und
ihn dranhänge; wollte ich schon immer mal machen - vor allem das
touch-panel endlich mal abfragen....

In diesem Programmteil habe ich noch etwas gefunden:

; auswerten des Statusbytes vom Display
  SBIC  ddata,0            ; STA0=H?
  rjmp  statuscheck
  SBIC  ddata,1            ; STA1=H?
  rjmp  statuscheck


Laut dem T6963 Datenblatt ist der Status bei high O.K., bei Low muß
gewartet werden. SBIC bedeutet "Skip if Bit in I/o is Cleared", also
"ignoriere den nachfolgenden Befehl wenn das Bit gelöscht ist". Das
macht dann genau das Gegenteil von dem, was gewünscht ist...
Ersetzt das mal durch "SBIS", denn der Rücksprung zu "statuscheck"
soll ja nur bei Status=low erfolgen. Abgesehen davon, wie bereits schon
gepostet, daß mit PINx  abgefragt werden muß.

Üblicherweise Resettet der Atmel nur unter folgenden Bedingungen:
1. Per Hardware. Reset ist ein EINGANG, man kann daran nicht erkennen,
daß der µC gerade einen Reset ausführt.
2. Per Software, wenn man zu Adresse $0000 springt
3. Per Watchdog (muß erst initialisiert werden, ein einschalten "aus
Versehen" ist ausgeschlossen)
4. Durch einen Software-Bug (Stack o.ä.)

Schaut mal, ob sich durch die Änderungen was tut. Irgendwann werden wir
das Ding doch zum Laufen kriegen (ehrgeiz entwickel)

Gruß

Autor: Wolfram Hildebrandt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mit dem Springen ist das beim AVR doch wenig konsequent.
Z.B. der Befehl BRNE  hier. D.h. springe zur Sprungmarke hier, solange
das Zerobit nicht gesetzt ist, also springe zu hier, wenn die Bedingung
erfüllt ist.

Jetzt habe ich mir dementsprechend gedacht,
statuscheck


  SBIC  ddata,0            ; STA0=H?
  rjmp  statuscheck
heißt, springe zu statuscheck, wenn das Portbit 0 in ddata Null ist.
Also sollte der AVR, wenn STA0 und STA1 High ist, die Schleife
verlassen. Jetzt wird dann bei der Bedingung nicht dahin gesprungen,
was angegeben ist, sondern es wird übersprungen.
Tja, aber eben sowas muss man lernen.

Dass ddata falsch ist, und durch PINB ersetzt werden muss, habe ich bei
dem Sprungbeispiel mal weggelassen.

Bezüglich des Ehrgeizes stimme ich dir voll und ganz zu. So eine
triviale Ansteuerung muss man doch hinkriegen.

Ich habe den Code mal so erweitert, dass ein Testunterprogramm
aufgerufen wird, dass dann einige Testbits an einem freien Port setzt.
Dann kann man schnell sehen, ob Unterprogramme prinzipiell
funktionieren. Das muss Merle dann aber noch testen.

Autor: thkaiser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mit den SBIS/SBIC tappe ich ab und an auch noch in eine Falle...
Wenn man die Mnemonik-Kürzel aber (im Geist) ausschreibt, klappts
meistens.

Der Lötkolben raucht bereits, negative Spannung ist da, der 4414 ist
gefunden (nach langem suchen, ist der einzige "große" Atmel den ich
zu Hause rumliegen habe), die ISP funktioniert auch schon. Noch ein
wenig gefummel und das Ding ist dran...

Autor: Wolfram Hildebrandt (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Sehr schön.
Mein Code ist ja nur für ein 240x64 Pixel Display geschrieben. Aber
solang dein Display größer ist, geht das wohl. Obwohl dann natürlich
nicht alle Pixel gelöscht werden, da ich nur den angezeigten RAM
lösche, also 240*64 Pixel im Grafik-RAM.
Hast du ein T6963C Display mit integriertem Touchscreen? Oder ist der
Touchscreen einzeln? Bei Reichelt gibt es ja ein Display mit
intergriertem Touchscreen, den man, glaube ich, über RS232
konfiguriert. Ab 150 Euro aufwärtz.

Im Anhang noch mal der überarbeitete Code. Prozessor ist der ATmega8.
PORTA sind die Testbits, PORTC der Steuerport fürs Display und PORTB
der Datenport fürs Display. Kann aber ganz leicht angepasst werden. Ich
habe immer ddata bzw. dcmd mit dem ports vernüpft. also man muss nur
die prozessordatei ändern und einmal ddata als PORTX und dcmd als PORTY
einstellen (direkt am Anfang). Aber das siehst du sicher.
Das Testunterprogramm ist auch schon drin. Porta zeigt dann, obs
geklappt hat.

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

Bewertung
0 lesenswert
nicht lesenswert
Ich habs mal runtergeladen und getestet - es funktioniert.

Aber:

In den Schleifen hast Du als Schleifenzähler R16 benützt. Eben dieses
Register wird aber in den ganzen Status-Prüf und Display-Schreib-
Subroutinen auch geändert, und somit geht die Schleife ins Nirwana ->
bricht nie ab.

Angehängt die korrigierte Datei, sie funktioniert auf dem Display.
Meine Hardware sieht allerdings komplett anders aus, weshalb ich ein
wenig dran rumgestrickt habe. Ich arbeite gerade an einer
String-Ausgabefunktion, die die Text-Ausgabe wesentlich vereinfacht.
Außerdem habe ich schnell noch die serielle Schnittstelle
drangebastelt, das hilft bei der Fehlersuche auch enorm g

Gruß
Thomas

Autor: thkaiser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ach so, ich vergaß:
Das Display ist das 240x128 von Conrad (da ist Conrad ausnahmsweise mal
relativ preiswert) und auch das Touch -Panel (analog). Allerdings muß
man das Touch-Panel selbst irgendwie dranbasteln. Die Fertiglösungen
sind doch langweilig g
Es ist garnicht so einfach, nachträglich Touch-Panels zu bekommen, da
war Conrad auch (wieder ausnahmsweise) der Günstigste.

Autor: Wolfram Hildebrandt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ach. Das ist toll. Geändert hat du also im Prinzip außer ein paar
schöneren Umschreibungen nur meinen Denkfehler in Bezug auf Sprünge
(SBIS anstatt SBIC), das einlesen (PINB), und natürlich meine aufgrund
von erwiesener Dusseligkeit überschriebene Clearschleife Aber das
passiert, wenn ein PIC-User seinen ersten AVR-Code schreibt und
dämlicherweise auch noch das Zählregister als Zwischenspeicher benutzt
;)
Aber eins ist doch merkwürdig: Wie kann ein Unterprogramm nicht
zurückspringen, und plötzlich geht das ohne Probleme und keine
Änderungen wurden daran vorgenommen? Die Fehler wirken sich zwar klar
auf das Display aus (besonders die SBIC Geschichte), aber mit dem
Sprüngen im Unterprogramm hat das ja nichts zu tun. Aber ich konnte es
ja auch nicht selber testen.
Aber das interessiert ja jetzt alles nicht. Hauptsache, es läuft.

Ich danke dir sehr für die Korrektur des Codes!!

Autor: thkaiser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jupp, Dein Code war eigentlich, bis auf den "Dusselfehler", in
Ordnung. Aber mach Dir mal keine Sorgen, so etwas passiert immer wieder
mal... und dann sucht man sich einen Wolf. Wenn man etwas Distanz hat,
sieht man so etwas sofort.

Ich gehe davon aus, daß die "Unterprogramm springt nicht
zurück"-Sache eine Fehlinterpretation war.

Autor: Wolfram Hildebrandt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich denke auch, dass es mit dem Unterprogramm daran lag.
Ich habe den Code jetzt mal für Merles AVR [ich hätte automatisch
beinahe PIC geschrieben ;)] angepasst.
Den Grafikram habe ich wieder zurück auf das 240x64 Pixel Display
geschrieben.
Mal sehen, was der Test von Merle ergibt.

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

Bewertung
0 lesenswert
nicht lesenswert
Hier noch mein bisheriger geistiger Erguß, ist für Debuggen des Displays
ein nettes Tool:

Das Display wird nicht initialisiert, man muß alles von Hand per
serieller Schnittstelle senden (ich habe ein Programm, das HEX sendet
und ausgibt).
Befehle (Hex)
80 = Sende ein Command ohne Datenbyte
81 = Sende ein Command mit einem Datenbyte
82 = Sende ein Command mit zwei Datenbytes
88 = Sende 8 Datenbytes im Auto-Write Modus
FF = Reset des Displays.

Damit kann man mit dem Display rumspielen und verschiedene
Initialisierungen austesten. Löschen des Displays ist allerdings etwas
mühselig g könnte aber durchaus als weiterer Befehl implementiert
werden. Man erspart sich halt das neu Flashen, wenn man an den
Einstellungen des Displays rumbasteln will.

Beispiel: Die Sequenz
80-97 80-80 82-00-00-40 82-1E-00-41 82-00-00-24
88-01-02-03-04-05-06-07-08
initialisiert das Display (nur Text), setzt Text-Home-Adress und Area,
setzt den Adress-Pointer und gibt die ersten 8 Zeichen aus.

80-A3 setzt den Cursor auf 3 Linien

usw.

Autor: Wolfram Hildebrandt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie genial. Wie hast du das denn jetzt so schnell hinbekommen?
Welches hex-Programm benutzt du dafür?

Autor: Merle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wird der stackpointer
beim ATmega8515 genau
gleich wie beim ATmega8
Initialisiert??

Gruß Merle

Autor: Wolfram Hildebrandt (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Eine schlechte Nachricht:
Bei Merle funktioniert der wieder von mir abgeänderte Code nicht.
Es kann jetzt an seiner Hardware liegen, oder ich habe wieder neue
Fehler in den Code eingebaut.

Im Anhang ist noch mal der Code. Wenn ihr bzw. du (thkaiser) noch mal
drübergucken würdest?
Der Display-Reset liegt bei Merle aber nicht am µC, sondern per
RC-Strecke an Masse und VCC.

Autor: Merle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi thkaiser du brauchst
nichtmehr nachzuschuen.
Es funktioniert.

Wolfram und ganz besonders ich
Danke dir für deine Hilfe und geduld.

Gruß
Merle

Autor: Wolfram Hildebrandt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Merle hatte ein kurzen zwischen Read und Write.
Jetzt läufts.

Autor: thkaiser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na wunderbar, dann habe ich meine gute Tat für heute erledigt ;)

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
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.