Guten Tag, Ich versuche den AD5292 über SPI anzusprechen. Leider folgt dieser nicht den übermittelten Kommandos(Schleifer bleibt immer in mittlerer Position). Die SPI-Nachricht sollte stimmen, ich hänge hierzu ein paar Bilder vom Oszi an. Momentan übermittle ich lediglich zwei Kommandos: 0x1802, um den Schreibschutz zu deaktivieren, und 0x0700, was den Schleifer auf ca 75% des Maximalwiderstandes setzen sollte. Beides mache ich mehrmals, zur Sicherheit, sie werden dennoch nicht erkannt. Ich habe sowohl höheren als auch niedrigeren SS/CLK-delay ausporbiert(im Anhang ersichtlich). Die Frequenz ist sehr gering gewählt, um diesbezüglichen Problemen vorzubeugen (bin bis 100KHz hoch). Erwähnenswert ist auch, dass ich nicht in der Lage war ein hohes RDY-Signal zu registrieren(am Oszi), sowie dass ca drei Mal der Schleifer richtig gesetzt wurde (mit selben Einstellungen bei denen es meist nicht geht). Der AD5292 ist nach Datenblatt angeschlossen: - ~RESET an Vlogic (3,3V) - Vss an 0V, Vdd an 15-25V; entkoppelt mit 0,1µF and 10µF dazwischen - A an 13V, B an 0V (W wird als ~6,5V gelesen) - EXT_CAP via 1µF an GNDlogic - Vlogic an 3,3V vom µC, GND an GND vom µC; entkoppelt mit 0,1µF and 10µF dazwischen - DIN an MOSI von µC - SCLK an SPICLK von µC - ~SYNC an SSL von µC - SDO floating - RDY entweder floating oder am Oszi gelesen Ich bin mir ziemlich sicher dass das Problem beim AD5292 liegt, da das SPI-Datenpaket in Ordnung aussieht(16 CLK-Perioden, korrekte Bits, ...). Ich habe auch ein weiteres Exemplar ausprobiert, mit denselben Ergebnissen. Ich hoffe jemand kann mir hierbei weiterhelfen, und danke im Voraus. AC ps.: Bezüglich ich möge keine JPGs verwenden: Bei Konvertierung zu BMP erhöht sich die Größe nur noch, daher denke ich es ist auch im Sinne der Admins wenn ich es im JPG-Format belasse
Angehängte Dateien:
-
WP_20160324_15_39_12_Pro.jpg
240 KB -
WP_20160324_15_38_57_Pro.jpg
240 KB -
WP_20160324_15_40_25_Pro.jpg
240 KB -
WP_20160324_15_41_56_Pro.jpg
210 KB
Albert C. schrieb: > Ich bin mir ziemlich sicher dass das Problem beim AD5292 liegt, Ich bin mir ziemlich sicher dass das Problem vor dem Bildschirm sitzt und die Tastatur bedient.
Albert C. schrieb: > Ich hoffe jemand kann mir hierbei weiterhelfen, Solange du keinen Schaltplan zeigst (und das Programm dazu) wird dir hier keiner weiterhelfen können.
Wow, diese Höflichkeit Ich habe keinen Schaltplan angegeben da ich es einfach nach Datenblatt verbunden habe, was ich auch nochmal explizit beschrieben habe. und ich bin nicht der Ansicht dass mein Programm, welches das SPI-Paket erzeugt, benötigt wird, eben zu diesem Zweck sind die Bilder des Oszilloskops vorhanden, welche ja wohl auch aussagekräftiger sind. ps.: Keiner zwingt dich mir zu "helfen". Ich denke es ist nicht zuviel verlangt, dass wenn einen etwas nicht interessiert, derjenige doch bitte dies übergehen möge anstatt beleidigend zu werden.
Dann wären die einzig möglichen Antworten "Nein, es liegt nicht am IC" und "Ja, es liegt am IC. Es ist fehlerhaft designed, keines davon kann funktionieren."
:
Bearbeitet durch User
- ich kann die Bilder nicht richtig zuordnen, bitte beschriften was was ist - bist du sicher, dass du den SYNC pin richtig verwendest. Ich habe noch nie von einem SSL Pin an einem Mikrocontroller gehört. SSL klingt nach Slave SeLect und das wäre dann nur da wenn dein ominöser Controller als Slave und nicht als Master fungiert. Der Sync Pin wird in deinem Fall ein einfacher GPIO / IO-Pin sein den du selbst im Code setzen musst. - Welchen Controller verwendest du? - Hast du gesehen, dass Command Words auf die steigende Flanke von SYNC ausgeführt werden. Machst du das richtig? - Poste bitte deinen vollständen Quellcode. Albert C. schrieb: > Erwähnenswert ist auch, > dass ich nicht in der Lage war ein hohes RDY-Signal zu registrieren(am > Oszi), sowie dass ca drei Mal der Schleifer richtig gesetzt wurde (mit > selben Einstellungen bei denen es meist nicht geht). Dann hast du vermutlich irgend einen Pin (z.B. SYNC) floatend. Je nachdem ist der halt mal high oder low ...
Herbert schrieb: > Ich habe noch > nie von einem SSL Pin an einem Mikrocontroller gehört. SSL klingt nach > Slave SeLect und das wäre dann nur da wenn dein ominöser Controller als > Slave und nicht als Master fungiert. Das ist ein Pin der bei den AVRs schon seit jeher zur SPI Maschine gehört und üblicherweise auf Input (beim Slave Modus) oder auf Output (im Master Modus) gesetzt ist um den Datenaustausch mit dem Gegenüber zu signalisieren. Und das wird bei anderen (nicht-AVR) Controllern nicht anders sein.
Herbert schrieb: > - ich kann die Bilder nicht richtig zuordnen, bitte beschriften was was > ist Entschuldige die fehlende Beschriftung. Da der Oszi nur zwei Kanäle hat, konnte ich jeweils nur das SlaveSelect Signal mit der Clock bzw die Clock mit dem Mosi Ausgang zeitgleich aufzeichnen. Das erste Bild ist das Kommando 0x700 (setzen des Schleifers). Das zweite das Kommando 0x1802 (Setzen der Schreibaktivierung, natürlich nicht in dieser Reihenfolge ausgeführt). Die letzten beiden sind das SlaveSelect/Sync Signal, jeweils unterschiedlich konfiguriert (höherer/niedrigerer CLK-delay/SSL-delay) Herbert schrieb: > - Hast du gesehen, dass Command Words auf die steigende Flanke von SYNC > ausgeführt werden. Machst du das richtig? Tut mir leid, ich verstehe nicht ganz was du meinst. Der µC sowie der AD5292 nehmen die Werte zur fallenden Flanke soweit ich weiß. Meinst du dass ich in dieser Annahme falsch liege und der AD die Werte zur steigenden liest? Herbert schrieb: > - bist du sicher, dass du den SYNC pin richtig verwendest. Nun, Beispieldiagrammen vom Datenblatt her schon. Angeblich, wenn das SYNC-Signal low geht, werden die ankommenden Daten auf den fallenden Flanken der nächsten 16-Clk Perioden ausgelesen, danach soll SYNC wieder hoch gesetzt werden, wenn dies vorher passiert wird das Paket verworfen. Herbert schrieb: > - Welchen Controller verwendest du? Ich verwende den RX63N von Renesas. Dieser hat einen integrierten SPI-Controller, sowie 3 SSL-Pins, welche weitgehend konfigurierbar sind. Momentan verwende ich nur einen dieser Pins, sowie den RX63N im Single-Master-Mode. Herbert schrieb: > - Poste bitte deinen vollständen Quellcode. Diesen habe ich leider momentan nicht zur Hand, aber alles was dieser tut ist die SPI-Pakete erzeugen. Andere als diese beiden habe ich nicht verwendet, daher hoffe ich dass der Code auch nicht benötigt wird. Herbert schrieb: > Dann hast du vermutlich irgend einen Pin (z.B. SYNC) floatend. Je > nachdem ist der halt mal high oder low ... Bis auf SDO und RDY ist leider nichts floating. Es ist auch nicht so dass es mal funktioniert und mal nicht, mehr dass diese drei Mal sehr selten waren. Diesbezüglich hätte ich vermutet dass ich möglicherweise mit irgendwelchen (zeitlichen) Parametern einen Fehler mache, aber ich konnte nach Abgleich mit dem Datenblatt keine Unstimmigkeiten finden. Danke für deine Mühe.
Albert C. schrieb: > Erwähnenswert ist auch, > dass ich nicht in der Lage war ein hohes RDY-Signal zu registrieren Aus dem Datenblatt (man braucht es eigentlich nur lesen) Seite 11: Table 10. Pin Function Descriptions ............ 14 RDY Ready Pin. This active-high open-drain output identifies the ----------------------------^^^^^^^^^^---------------------- completion of a write or read operation to or from the RDAC register or memory.
Mitlesa schrieb: > Aus dem Datenblatt (man braucht es eigentlich nur lesen) Seite 11: Gut dann habe ich das übersehen, aber dies kann ich insofern rechtfertigen dass ich dem RDY Pin keine sonderliche Bedeutung beimesse für meine Zwecke, und ihn meist ohnehin auf floating lasse (wie erwähnt). Er ist lediglich eine Bestätigung für einen Schreibvorgang, und dass dies nicht (erfolgreich) geschieht ist ersichtlich.
Bis jetzt ist immer noch nicht klar, ob Du den, wenn auch nur für
Prüfzwecke, richtig beschaltet hast.
Bis jetzt wissen wir nur:
>- RDY entweder floating oder am Oszi gelesen
Albert C. schrieb: > Herbert schrieb: >> - Hast du gesehen, dass Command Words auf die steigende Flanke von SYNC >> ausgeführt werden. Machst du das richtig? > > Tut mir leid, ich verstehe nicht ganz was du meinst. Der µC sowie der > AD5292 nehmen die Werte zur fallenden Flanke soweit ich weiß. Meinst du > dass ich in dieser Annahme falsch liege und der AD die Werte zur > steigenden liest? Bits werden zur fallenden CLK Flanke ausgewertet. Was ich meine ist die Übernahme der command bytes. Die erfolgt auf die steigende SYNC Flanke. Ich wollte nur wissen, ob du SYNC nach 16 bit immer wieder high setzt. Sonst würde das Kommando einfach ignoriert werden. Versuch mal 0x1803 und 0x0700, ich wüsste zwar nicht wieso man das 20TP bräuchte aber probieren kannsts ja mal. Und versuch den RDY pin zum laufen zu bekommen. Das ist ein einfacher Indikator ...
Albert C. schrieb: > Das erste Bild ist > das Kommando 0x700 (setzen des Schleifers). Das zweite das Kommando > 0x1802 (Setzen der Schreibaktivierung, natürlich nicht in dieser > Reihenfolge ausgeführt). Vielleicht einfach mal das ausführen was im Datenblatt steht? (ist nicht so naheliegend, ich weiss, aber ich mach das "manchmal" ...) Seite 23: Table 12. Write and Read to RDAC and 20-TP Memory --------------------------------------------------- DIN SDO Action 0x1803 0xXXXX Enable update of wiper position and 20-TP memory contents through digital interface. DIN SDO Action 0x0500 0x1803 Write 0x100 to the RDAC register; wiper moves to ¼ full-scale position.
Herbert schrieb: > ich wüsste zwar nicht wieso man das 20TP bräuchte Das Enable Kommando braucht man immer wenn ich das Datenblatt richtig interpretiere. Zumindest einmal beim ersten Anlauf.
und schließ vll. mal SDO an / oszilliere SDO und hole dir nach 0x1802 bzw. 0x1803 mit COMMAND 7 und einem anschließenden Dummy Write das Status Register zur Überprüfung zurück.
Okay, werde ich machen, danke euch. Leider kann ich erst nächste Woche wieder an die Hardware, aber mit diesen Tipps sollte ich zumindest an mehr Information kommen. Ich werde mich dann nochmal melden. Gruß Albert
Update:
Also ich habe SDO sowie RDY nun auch überprüft, sowie die
Beispielsequenz vom Datenblatt ausgeführt. Mit der Beschaltung bisher
war dies aber alles nicht erfolgreich (RDY kein Signal, SDO kein Signal,
Wiper bleibt).
Ich habe allerdings aus einer Vermutung heraus den ~Reset nicht wie im
Datenblatt beschrieben auf Vlogic gebunden, sondern auf GNDlogic. Dies
hat zu einer Veränderung geführt, nämlich dass ich über SDO nun Signale
erhalte.
Konkret hier meine Pakete, sowie die Ausgänge vom SDO:
DIN: - 0x1802 (write-enable)
- 0x1C00 (read Control Bits)
- 0x0000 (dummy-write)
- 0x0700 (set wiper to 75%)
- 0x0000 (dummy-write)
- 0x0000 (dummy-write)
Parallel dazu SDO:
- 0x0000
- 0x1802 (weitergereichtes 'write-enable')
- 0x1C00 (weitergereichtes 'read Control-Bits'), -> Dieses Kommando
sollte nicht weitergereicht werden, sondern ausgeführt
- 0x0000 (weitergereichtes 'dummy-write')
- 0x0700 (weitergereichtes 'set wiper to 75%')
- 0x0000 (weitergereichtes 'dummy-write')
Auf RDY konnte ich allerdings weiterhin keine Flanke registrieren, und
der Schleifer verändert sich (logischerweise) auch nicht.
Aufgrund der Tatsache dass das Kommando weitergereicht wird und nicht
ausgeführt könnte man annehmen dass ~SYNC nicht high wird nach dem
Paket, doch dies ist weiterhin nach jedem der Fall.
Hat einer von euch möglicherweise Erfahrung darin wie vertrauenswürdig
das Datenblatt ist? Wenn ich das richtig interpretiere, ist der Reset ja
nicht low-aktiv (wie beschrieben), sondern high-aktiv.
Edit: Ich vergaß hinzuzufügen dass RDY konstant auf low ist. Das
erwartete Verhalten davon ist auch widersprüchlich, er ist als
active-high bezeichnet, im Timing-Diagramm ist er aber als active-low
abgebildet (nach dem Schreibvorgang für einen Takt auf low).
:
Bearbeitet durch User
Albert C. schrieb: > Hat einer von euch möglicherweise Erfahrung darin wie vertrauenswürdig > das Datenblatt ist? Wenn ich das richtig interpretiere, ist der Reset ja > nicht low-aktiv (wie beschrieben), sondern high-aktiv. Das ist unwahrscheinlicher als ein Stein der nach oben fällt.
Albert C. schrieb: > ist der Reset ja > nicht low-aktiv (wie beschrieben), sondern high-aktiv. Genau genommen ist er Low-High aktiv: A low-to-high transition of the hardware RESET pin loads the RDAC register with the contents of the most recently programmed 20-TP memory Location.
Ja, im Datenblatt steht aber auch: Tie RESET to VLOGIC if not used. Dies scheint mir aufgrund meiner Beobachtung kontraproduktiv zu sein, da dann überhaupt keine Reaktion vom AD5292 kommt.
Albert C. schrieb: > Ich vergaß hinzuzufügen dass RDY konstant auf low ist Hast du auch ein Pull-Up an dem Pin?
Albert C. schrieb: > - Vss an 0V, Vdd an 15-25V; entkoppelt mit 0,1µF and 10µF dazwischen > > - A an 13V, B an 0V (W wird als ~6,5V gelesen) passt das? Datenblatt S.3 steht Va = Vdd Bei dir ist aber Va < Vdd?
Ja, an SDO sowie and RDY ist ein Pullup. Dass RDY nicht high wird stimmt aber auch damit überein dass keine Werte geschrieben werden (was ja mein primäres Problem ist).
Bitwurschtler schrieb: > passt das? Datenblatt S.3 steht Va = Vdd Bei dir ist aber Va < Vdd? Ja, das passt auch, "VSS ≤ VA ≤ VDD" EDIT: Seite 11
:
Bearbeitet durch User
Update: Habe nun vor der Übertragung meiner Pakete eine low-to-high transition eingebaut, erhalte nun dasselbe Verhalten wie mit RESET auf GND. Schleifer bleibt aber weiterhin unbewegt.
:
Bearbeitet durch User
Bitwurschtler schrieb: > Albert C. schrieb: >> ist der Reset ja >> nicht low-aktiv (wie beschrieben), sondern high-aktiv. > > Genau genommen ist er Low-High aktiv: > > A low-to-high transition of the hardware RESET pin loads the RDAC > register with the contents of the most recently programmed 20-TP memory > Location. das läuft wohl wie bei den DDS IC´s. Mit Reset wird der geschriebene Wert übernommen ! Im Timingdiagramm ist das auch so dargestellt ! Daten alle schreiben, Reset toggeln und alles wird gut. Datenblatt Seite 9 oben. Vermutlich doch nicht der IC fehlerhaft sondern der Bediener.
:
Bearbeitet durch User
Stephan H. schrieb: > Mit Reset wird der geschriebene > Wert übernommen Nein, das ist leider nicht der Fall, mit Reset wird der GESPEICHERTE Wert übernommen, nicht der geschriebene. Und um ihn speichern zu können muss man ihn zunächst schreiben. S.11: "RESET [...]Refreshes the RDAC register with the contents of the 20-TP memory register." S.22: "Write contents of serial data to RDAC" (^= Wiper) "Store wiper setting: store RDAC setting to 20-TP memory"
ich würde wie folgt proggen: SCK ist Low REST auf High Sync auf Low Datum anlegen (Bit) SCK toggeln nächstes Datum SCK toggeln wenn alle bits raus dann Sync auf High setzen evtl. mach es mal zu Fuss ( Software SPI ) ist ja nur Pin wackeln. ICh muss mal schauen ich habe mal was mit Digi Potis von AD gemacht. War ein 8 fach.
Stephan H. schrieb: > evtl. mach es mal zu Fuss ( Software SPI ) ist ja nur Pin wackeln. Okay, ich probiers mal so, auch wenn ich um ehrlich zu sein keine große Hoffnung auf Änderung habe, da der Controller ziemlich dasselbe macht. Stephan H. schrieb: > ICh muss mal schauen ich habe mal was mit Digi Potis von AD gemacht. Wäre ich dir sehr dankbar wenn du das tun könntest.
damit kannst Du aber Konfig Probleme Deiner MCU ausschließen. das ist dann aber ASM auf 8051.
:
Bearbeitet durch User
also mein Code ist für den AD5206. zum Verständnis: CSPOT = CS vom AD PUTSPI = Soft SPI Senden SCLK = GPIO Pin MOSI = GPIO Pin abgleichmodus: clr enter mov DPTR,#display3 acall display_fuellen ; Displayanzeige Abgleichmodus anl P0,#0C0h ; Alle Ladestufen ein ( LOW ) mov b,#6 mov R3,#0 poti: CLR CSPOT acall putspi mov a,#33 ; ladewert acall putspi inc R3 setb CSPOT djnz b,poti warte_enter: jnb noenter,warte_enter jnb enter,warte_enter clr noenter ;*********************** ; SPI Write 8 Bit, Wert in R3 ;*************************** putspi: mov r4,#8 mov a,R3 clr c spiwr: clr SCLK rlc a mov MOSI,c nop setb SCLK djnz r4,spiwr ret wie gesagt ist 0815 SPI zu Fuss Code. Nicht alle 8051 haben SPI in Hardware, was aber die Konfiguration der SPI Register erübrigt und damit Fehler ausschließt. ( H/L aktiv ) Der Code hat keinen Zusammenhang da willkürlich aus der Main ausgeschnitten. Sorry !
:
Bearbeitet durch User
Okay, danke dir, werde das versuchen sobald ich wieder an die Hardware kann. Und entschuldige falls ich hier etwas übersehe, aber was genau kann ich hierbei nochmal überprüfen was nicht auf dem Oszi erkennbar ist? So wie ich das verstehe ist das ja der Code für den µC, welcher das SPI-Paket sendet. Mit dem Oszi greife ich ja dieses ab (bei mir), und ich konnte darauf keine mögliche Probleme erkennen. Ich gebe zu ich frage dies auch nochmal weil ich in asm lediglich Grundkenntnisse besitze, mit dem von dir bereitgestelltem Code ginge das sicher dennoch, aber bisher war meine Vermutung dass sich das Problem nach der Übertragung des SPI-Pakets aufhält (aufgrund dessen dass die vom µC gesendeten Pakete am Oszi in Ordnung zu sein scheinen).
Albert C. schrieb: > Vlogic an 3,3V vom µC, GND an GND vom µC; entkoppelt mit 0,1µF and > 10µF dazwischen Was heisst denn "dazwischen"??? Schon vor einer Woche hat man dich gebeten den Schaltplan zu posten, aber anscheinend verfolgst du lieber weiterhin das Try-and-Error-Prinzip.
Und vor allem ist nicht nur der Schaltplan, sondern auch der Aufbau wichtig. Unruhiges Gnd und Ringing auf den Signalen bewirken oft ein mehrfaches Erkennen von Flanken. Steckbrett? alles klar! Deshalb: gute kurze Gnd-Verbindungen, Versorgung mit Cs entkoppeln und Dämpfungs-Rs (22 - 100 Ohm seriell) an die Sender-Pins.
Da laut Text weiter oben nur ein 2-Kanal-Oszi vorhanden ist würde ich mir schnellstmöglich einen Logic-Analyzer besorgen. Wenn man nur langsame SPI-Verbindungen anschauen will reicht auch sowas: https://www.ikalogic.com/scanaquad-logic-analyzer-signal-generators/ 69 € ... Geht auch noch billiger, aber dann muss man möglicherweise auch da noch frickeln... Warum: Viele Kanäle für wenig Geld, die empfangenen Daten werden automatisch dekodiert und man kann im Vergleich zum Oszi über sehr lange Zeiträume aufzeichnen.
Angehängte Dateien:
-
ad5229.png
3,7 KB
Hier das schematic um das ich gebeten wurde. moeb schrieb: > würde ich > mir schnellstmöglich einen Logic-Analyzer besorgen Danke für den Tipp. eProfi schrieb: > sondern auch der Aufbau > wichtig Prinzipiell hast du da natürlich recht, und ja ich verwende ein Steckbrett, aber aus diesem Grund verwende ich ja auch eine besonders niedrige Frequenz. Außerdem denke ich nicht dass es ein Übermittlungsproblem ist, da die Pakete ja wieder von SDO aus gesendet werden wie sie empfangen werden, daher muss der AD sie ja zumindest erkennen. Ich habe inwzischen noch einen weiteren Beitrag gefunden der ein ähnliches Problem beschreibt: https://ez.analog.com/thread/16203 Kurz zusammengefasst: Rdy ist konstant auf low, SDO gibt alle Pakete weiter, führt keine aus. Lösung: Bauteil war "halb-"kaputt. Weiß möglicherweise jemand ob RDY-Low ein ausreichendes Indiz dafür ist dass das Bauteil beschädigt ist? Ich beobachte dieses Verhalten bei mir an vier Exemplaren, und das wäre schon eine sehr großer Zufall. Natürlich könnte ich sie auch irgendwie beschädigt haben, aber ich wüsste nicht wie, ich bin mit dem Werten deutlich innerhalb der Spezifikation. Power-up Sequenz halte ich (inzwischen) ein.
Ich habe nun einen weiteren (unbeantworteten) Post gefunden, in dem EXT_CAP (gegensätzlich zur Anweisung im Datenblatt) an Vss/B angeschlossen ist. Nun nur um sicherzugehen: Ich sollte GNDlogic nicht mit Vss/B verbinden? Ich würde das nur ungern einfach ausprobieren, da ich Angst hätte dabei den µC zu beschädigen.
Update: Ich habe den Fehler gefunden. Es hängt wahrscheinlich mit dem Power-up sowie dem dafür benötigtem EXT_Cap zusammen. Ich habe nun beide GNDs (GNDlogic und 0V) verbunden, und nun funktioniert alles wie gewünscht. Danke allen für die Hilfe.
Schön, dass Du die Ursache gefunden hast und uns wissen lässt. > Prinzipiell hast du da natürlich recht, und ja ich verwende > ein Steckbrett, aber aus diesem Grund verwende ich ja auch > eine besonders niedrige Frequenz. Die niedrige Frequenz bringt überhaupt nichts gegen Ringing, welches dann nur seltener, aber nicht schwächer auftritt. Ursache dafür sind steile Flanken, die bekommst du am besten mit einem Serien-R am Treiber weg, da er mit der Leitungs- und Eingangskapazität einen Tiefpass bildet.
eProfi schrieb: > die bekommst du am besten mit einem Serien-R am Treiber > weg Okay danke. Das hat jetzt zwar nicht direkt mit dem Thema zu tun, aber das wäre auch wahrscheinlich die Ursache für falsches Empfangen über längere Strecken(2m)? Du sagtest ja Ringing könnte dafür sorgen dass er mehr Flanken erkennt als vorhanden sind, was ich gerade beobachte nach Verlängerung der Leitung. Edit: Ich sehe gerade das ist teilweise ein größeres Thema. Schätze es ist nachteilig das unter diesem Beitrag nochmal auszuführen, ich werde mich einfach gesondert Informieren.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.