Hallo Ich bitte um Tipps, wie ich meine Datenübertragung per UART fehlerfreier gestalten kann. Ich verwende:ATMega128, 18,432MHz, UART1, 8-bit 1-Stop 0-Parity und die Leitungen TXT und RXD Als Terminalprogramm: Terminal v1.9b von Bray Ich möchte ca. 65000 Messdaten fehlerfrei übertragen (je 24bit)und habe bisher über das genannte Terminalprogramm immer ein Logfile schreiben lassen. Auf die Menge der Daten gibt es ca 20 Fehler in der Übertragung. Wenn ich das Terminalprogramm in der Standarteinstellung belasse erhalte ich diese Fehler bei allen Bautraten. Ich vermute, dass der Fehler nicht auf der Seite des ATMega zu suchen ist. Ich glauge, dass der Fehler kleiner wird, wenn man das Anzeigefenster des Terminalprogramms verkleinert. Kann das sein?? Muss ich unter Windows (Win2000) Prioritäten verändern (oder sowas)? Ich würde ja gerne mir ein eigenes Programm mit Checksummen schreiben - hierfür reichen meine Kenntnisse leider nicht aus. Kann man die restlichen Leitung der Schnittstelle verwenden um mein Problem hardwaremäßig zu lösen? Vielen Dank für die Mühe - hoffentlich reichen meine Angaben aus Euer Moin
Das der Mega128 nur bis 16MHz spezifiziert ist ist wohl klar. Wenn man drübergeht sollte man doch aufpassen das sonst alles stimmt, wie Betriebsspannung, kleinere C am Quarz und sonstige Entstörmassnahmen. Die geringsten Frequenzhacker wirken sich aus. Ansonsten bin ich mir sicher das es hier im Forum etwas zu CRC gibt.
An den 18MHz liegt es höchst warscheinlich nicht. Ich habe schon öfters einige MByte an einen mit 22MHz laufenden AVR übertragen, und das ohne Fehler. Auch in der anderen Richtung ging es fehlerfrei. Teste mal HTerm (unter PC-Programmierung hier im Forum zu finden).
Bei seriellen Übertragung ist es aufgrund der "integrierten" Taktung wichtig, das der Abstand zwischen Standardeinstellung am Terminalprogramm (2400Bd, 4800Bd, 9600Bd, ...) und der programmierten Taktung am AVR (meist ungleich der Standardeinstellungen). Beim Empfänger wird immer in Bitmitte abgetastet -> nach der Übertragung des kompletten Bit-Rahmens muss der Abstand immer noch kleiner als die halbe Bitbreite sein. bestimmt a bissl Wirre Zur Erläuterung hatte bei einem 8051er ein ähnliches Problem bei folgenden Einstellungen wie folgt gelöst: - DÜ mit 8 Datenbits, je 1 Start- und Stoppbit (=10 Bit als Bitrahmen) - eingestellte Baudrate am Terminal 4800 Baud - durch Timing am µC konnte ich eine nur eine Ü-Rate von 4630 Baud einstellen - nach 10 Bit muss die Differenz noch kleiner als das halbe Bit sein * eingestellt Baudrate: 4800Bd * Ü von einem Bit: 480Bd (-> 50%: 240Bd) * Differenz: 4800Bd (+-) 240Bd = 4560Bd < Ü(µC) < 5080Bd --> die Datenübertragung klappt bei dieser Einstellung Ich vermute eventuell, dass Du auch dort Problem haben könntest. Also einfach mal schauen, ob bei Deiner Ü-Rate am Ende Deines 24Bit-Rahmens noch eine "halbe" Bitrate (lieber ein wenig mehr :)) ). Viele Grüße müllo
hallo müllo. der moin schrieb aber eindeutig dass er 8 bit mit 1 stopbit benutzt. die 24 bits werden wohl als 3 aufeinanderfolgende bytes gesendet. 20 fehler auf 65000 ist 20 zuviel. das parity bit zu benutzen bringt nicht viel. vielleicht benutzt moin eine zu hohe bitrate. was benutzt du denn ? bei hohen baudrates wirken sich kleine abweichungen im takt stark aus, auch wenn alles wieder neu synchron ist mit einem neuen startbit. neben einer ungenauen bitrate, kann es auch daran liegen dass die ersten zeichen nicht richtig erkannt werden. müsste moin auch mal untersuchen ob das so ist. ich muss hier bei mir 32 kbytes mit 57600 baud in wenigen sekunden übertragen, was ohne probleme mit einem msp430 (2,.. MHz takt, takt ist ganzzahliges vielfaches der bitrate) geht, auch bei starken temperaturschwankungen dank einer temp-kompensation. kenne aber übertragungsprobleme zu genüge die zu beginn einer übertragung auftreten wenn der uart des msp zwischenzeitlich "offline" war, also abgeschaltet war. es darf zu keiner break situation kommen. ein paar ideen: 1.) eine kleine sequenz von eindeutigen startzeichen erstmal senden, die der empfänger erkennt und bei deren ende der eigentliche empfang erst losgeht. wenn du "rohe daten" als werte 0...255 sendest, kann es etwas heikel sein, da das erste byte zufällig auch diesen wert haben kann. 2.) ich würde jeweils eine sequenz (paket) von z.b. 32 zeichen senden, mit startzeichen und einer angehängten prüfsumme. (8 bit quersummee ist nicht optimal, aber ganz brauchbar - es gibt bessere verfahren) wenn die quersumme falsch ist, muss der sender die daten sooft wiederholen bis alles ok ist. etwas aufwendig und langsamer. 3.) das s-record verfahren von motorola vielleicht ? würde die übertragung erheblich verlangsamen.
sorry, habe wohl nicht alles richtig durchgelesen... Ich wollte auch nur beschreiben, wie sich eine zu starke Abweichung der programmierten µC-Baudrate zur Standard-Ü-Rate des Terminals auf die Daten-Ü auswirken kann. Vor allem, wie man relativ einfach (ohne Oszi) schauen kann, ob es überhaupt funzt. Bei meiner Erläuterung ging's um eine Fernsteuerung eines Lauflichts (Schnelligkeit) per Hyperterminal. Wenn ich ein Zeichen zweimal an den 8051er sendete, änderte sich die Geschwindigkeit irrational -> Fehler der DÜ! (eingestellte Baudrate am µC war etwas zu langsam, sodass er bei der 8Bit- Übertragung das eigentliche Stopbit als 8.Datenbit erkannte) --> Baudrate etwas erhöht und es funzte einwandrei Bei einer anderen Gruppe war es ein Fehler in der Interruptroutine. Die haben bei Einsprung weitere Interrupts zugelassen, sodass es dort zu Überläufen kam. Viele Grüße müllo
@müllo Deine +/-240Baud sind immerhin 5% Fehler, während alle PC üblichen Baudraten mit den 22,1184MHz die moin verwendet, mit (theoretisch) 0% Fehler erreichbar sind. Daran liegt es also nicht. 20 Fehler bei 200kByte sind zwar nur 100ppm, aber bei einer RS232 Verbindung sollten Fehler von <1ppm bei kurzen Leitungen und ordentlicher MAX232 Schaltung eigentlich kein Problem sein.
@moin wertest du RTS vom Host am µP aus? (RTS=Request to Send / Host Ready to receive) Wie verteilen sich denn die Fehler über den gesammten Datenstrom. Wird es schlimmer wenn der PC stark beschäftigt (z.B. mit der Festplatte) ist? Die Sache mit dem kleineren Anzeigenfenster->weniger Fehler deutet in die Richtung dass der Host zwischendurch nicht empfangsbereit ist.
@Benedikt: Und auf welcher Taktrate sendet/ empfängt denn der µC? In meiner Erläuterung bin ich auch davon ausgegangen, dass der PC mit 4800Bd (==100% konstant) arbeitet. Aber i.d.R. bekommt man keine 100%ige normierte Baudrate hin) --> Welche Toleranz darf also bei der programmierten Baudrate (im µC) gerade noch vorhanden sein, damit das vorletzte Bit vom Stop-Bit unterschieden wird. Durch die Abtastung (optimal auf Bitmitte) draf es also maximal um eine halbe Bitverschiebung kommen (bei 10 Bit == 5%). Es ist natürlich okay, wenn es an etwas anderem liegt. Manchmal addieren sich auf mehrere kleine Fehler zu einem größeren Problem. Viele Grüße müllo
Ich betreibe die AVRs meistens mit 18,432MHz (=10 fache der UART Taktrate in einem PC -> 0% Fehler). Wenn es schnell gehen muss verwende ich 115200Baud, ansonsten 19200Baud. Damit habe ich schon einige 10MByte am Stück übertragen, und am Ende kamen genau soviel Bytes an, wie gesendet wurden.
dito bei mir (115200Baud) auch über 10m Kabel (gestückelt). Die einzigen Probleme als ich RTS noch nicht auswertete waren Bytedrops wenn der PC arg beschäftigt war und ich nicht schnell genug die Eingangspuffer leerte. Aber ob dieser Fall vorliegt kann moin ja leicht feststellen.
Ich bin begeistert über eure Hilfe. Ich werde heute abend mal über eure Vorschläge nachdenken. Ich vermute, dass die Fehler entstehen, wenn der PC zu stark beschäftigt ist. Ich glaube, dass mein Problem fast oder ganz beseitigt ist, wenn ich das Terminalprogramm 'HTerm' verwende. Ich werde mal den Rechner stärker belasten und sehen, ob dei Fehler zunehmen. @ Kupfer Michi: Was sind Bytedrops? Wie wertet man RTS aus? (Würde ich gerne machen) Zur Fehlerverteilung: Zu Anfang habe ich keine Fehler. Bis zum Ende der Übertragung werden es immer mehr und die Anbstände werden kleiner. Ich deute 'meine Fehler' so, dass der PC eine Bytes vergisst oder sich irgend etwas so verschiebt, das Teile falsch gelesen werden. Nach einer kürzeren Überprüfung habe ich festgestellt,dass ich eine fehlerfreie Übertragung erhalte, wenn ich nur das Programm 'HTerm' laufen lasse. (bisher nur zweimal geprüft) Ob das Problem gelöst ist, kann ich noch nicht sicher sagen. Euer moin
@moin >Bytedrops Bytes die bei der Übertragung verloren gehen (z.b. weil der Eingangspuffer voll ist und die HW. nichts mehr annehmen kann). Schick einfach einen synthetischen Datenstrom (0x00 ... 0xFF repetitiv) und schau was ankommt bzw wert es mit einem kleinen Program aus. Wenn bytes fehlen -> RTS Problem, wenn falsche Bytes -> Übertragungsfehler. >RTS siehe Anhang. Wird von der Host HW bzw. SW gesetzt um anzuzeigen dass gesendet werden darf. Schau einfach mit dem Oszi nach ob RTS kurzeitig ausgeht (angeht? Polarität???) RTS einfach wie TXD/RXD über einen MAX232 an den µP ranführen und vor dem UART_Send abfragen und ggf. warten. Das Host Terminalprogram muss jedoch als Flowcontrol: RTS/CTS aktivieren. Sonst werden die Signale nicht gesetzt. Es gibt auch noch XON/XOFF Steuerung über den Datenstrom. Die Windows API Calls für Serielle I/O kennst du ja um nicht auf ein Terminal Programm angewiesen zu sein?
@ Kupfer Michi Es fehlen wirklich Bytes, wenn ich Daten von Hex 1100 bis FFFF sende (aufsteigend). Deine Vermutung war wohl richtig. @ Kupfer Michi Was sind Windows API Calls für Serielle I/O??? Von Programmierung auf dem PC habe ich keine Ahnung - leider. Ich werde jetzt RTS zusätzlich in meine Routine einbinden: Ich werde vor jedem Byte dass ich senden möchte abfragen, ob RTS=1 gesetzt ist (oder nicht-gesetzt=0 ist - ausprobieren) und dann die Übertragung starten.
Auch nach dem Lesen im Internet ist mir die Einbindung von RTS noch nicht gantz klar: - RTS leite ich vom PC über den MAX232 zum ATMEGA128 - Im Terminalprogramm schalte ich die Hardwaresteuerung ein - Ich sende nur dann vom mega128 zum PC, wenn RTS high ist-sonst warte ich mit dem Senden. Ist das richtig??
richtig. RTS und CTS zeigen dem jeweiligen Partner an ob man selbst empfangsbereit ist. RTS - PC out, sagt µP PC ist bereit für Datenempfang, µP kann senden CTS - µP out, sagt PC µP ist bereit zum Datenempfang, PC kann senden Im aller einfachsten Fall ist RTS->CTS am Kabel gebrücked. Wenn der PC also beim Öffnen der Verbindung RTS setzt wird dies als CTS zurückgeschickt und der PC denkt der µP/Modem ist Empfangsbereit, was in den meisten Fällen auch so stimmt. Also: µP ist empfangsbereit -> µP setzt sein CTS, PC weis dadurch er kann senden. wenn der µP gerade beschäftigt ist (d.h. ein USART Interupt könnte verloren gehen) dann wird CTS zurückgenommen. Das Terminalprogramm wartet mit senden. µP will Senden -> RTS prüfen und ggf. warten. RTS wird von der PC HW/SW gesetzt wenn die COM Verbindung geöffnet ist und der PC Eingangspuffer nicht mehr als 3/4 voll ist. Ist der Puffer voller so wird RTS zurückgenommen und erst wieder eingeschaltet wenn er wieder 1/2 leer ist. Das PC Terminal Programm muss natürlich RTS/CTS Handshake aktiviert haben und unterstützen. Wegen der Invertierung im MAX232 werden die Signale am µP natürlich Low im Aktivzustand. >Windows API Calls für Serielle I/O Das sind die Betriebssystemaufrufe mit denen man von der Seriellen Schnittstelle bedienen kann. Wenn du auf der PC Seite nicht selbst programmierst was kannst du den dann mit den Daten überhaupt anfangen?
Die Daten kann ich dann in Excel einlesen und dann weiterverarbeiten, z.B. Mittelwert bilden, gleitenden Mittelwert bilden, Histogramm erstellen, ... An mehr habe ich mich noch nicht gewagt. Auf Dauer werden ich wohl nicht um VB herumkommen. Ich träume noch von einer automatischen Schnittstelle vom ATMEGA zu Excel, wo alles automatisch gemacht wird. Die Übertrgung ist Teil eines Messwerterfassungssystems wo du mir auch schon mit Verbesserungsvorschlägen geholfen hast: http://www.mikrocontroller.net/forum/read-1-161803.html
>Ich träume noch von einer automatischen Schnittstelle
Mach doch eine Programmier AG auf und stell es als Projektziel :)
In der Oberstufe hats doch sicher den ein oder anderen für den sowas
schon im Bereich des mögliche liegt und so hat jeder was davon... oder?
Hier scheint einiges durcheinander zu kommen... Zur Kärung: RTS + TxD sind ausgehende Signale. CTS + RxD sind eingehende Signale. (Eselsbrücke: Die es gibt auf jeder Seite ein R.) Eine Verbindung zwischen Sendersignal und Empfängersignal = TxD -> RxD und RTS -> CTS Man muss also den Zustand des CTS Eingangs (verbunden mit dem RTS Ausgang der Gegenstelle) prüfen bevor man sendet.
Ja, normalerweise wird für Signal und Anschlusspunkt der selbe Name verwendet. Beides wird dann umgangssprachlich als synonym verwendet. RS-232 geht da einen anderen Weg und benennt die beiden Endpunkte einer Leitung unterschiedlich und zu allem Überfluss überkreuz gleich. Dies ist zwar wegen der Symetrie der Situation sinnvoll und logisch, führt jedoch trotzdem schnell zur Verwirrung (zumindestens bei mir, wenn man vereinfachend von RTS spricht, was meint man damit, das Eigene, das der Gegenstelle oder das RTS das auf der Gegenstelle CTS heisst?) Ich hoffte dadurch dass ich mich primär auf die PC Ausgangsignale/Pinbezeichnungen bezog dieser verwirrung aus dem Weg zu gehen. Scheinbar mit mässigem Erfolg...
> RS-232 geht da einen anderen Weg und benennt die beiden > Endpunkte einer Leitung unterschiedlich Die Verwirrung entsteht nur, wenn an beiden Enden der Verbindung Endgeräte sitzen, wie PCs, Controller, Programmer, etc. Freilich ist RS232 dafür garnicht konzipiert worden. Sondern für Modems. > RTS + TxD sind ausgehende Signale. Nur bei Anschlusstyp DTE (Data Terminal Equipment = PC/µC). Beim Anschlusstyp DCE (Data Communication Equipment = Modems) sind es Eingänge. Es ist also immer wichtig, den Anschlusstyp zu kennen. Der STK500 beispielsweise kommt als DCE daher, damit keine Nullmodemkabel notwendig sind.
Ich beziehe mich bei meinem obigen Beitrag bei RxD und TxD auf die Bezeichnung bzw. Funktion der Pins am AVR. Synonym dazu werden von mir CTS als IN und RTS als OUT bezeichnet (obwohl die Pins dazu nicht vorgeben sind).
@Benedikt: Ich muss jetzt nochmal nachhaken, weil ich entweder auf dem Schlauch stehe oder etwas falsch verstanden habe. Ich bin davon ausgegangen, das ein ATMega128 mit f_osz=18,432MHz betrieben wird und die DÜ an der UART1, 8-bit 1-Stop 0-Parity gewünscht wird. Mich würde jetzt mal interessieren, welche Baudrate über das Atmel-Register eingestellt ist und auf welcher rü das Terminal läuft.
@Müllo
ATMega128: f_osz=18,432MHz; UART1; 8-bit 1-Stop 0-Parity
.equ CLOCK = 18432000 ;d.h. 0% Fehler
.equ BAUD = 115200
.equ UBRRVAL = CLOCK/(BAUD*16)-1 ; UBRRVAL = 9 (exakt)
ldi t0,Low(UBRRVAL) ;Low-Byte für Baudrate
ldi t1,High(UBRRVAL) ;High-Byte für Baudrate
sts UBRR1L,t0;out
sts UBRR1H,t1;out ;Baudrate setzen
PC: Terminalprogramm HTerm 0.5.7 115200 Baud; Com1 (höhere Bautraten
lässt der PC nicht zu)
@ AN ALLE
Dies ganze hin und her hat mich doch verwirrt ;-(
Könnt ihr bitte überprüfen, ob ich alles richtig verstanden habe?
Wenn ich auf den Stecker des PCs (oder einer 1:1 Verlängerung) sehe
habe ich folgende Pins:
1 2 3 4 5
DCD RxD TxD DTR GND
6 7 8 9
DSR RTS CTS RI
Ist das richtig, dass ich die RTS-Leitung des PCs abtasten muss?
Wenn alles OK ist, muss sie auf low sein (hinter dem MAX232 auf Seiten
des AVR). Wenn der Puffer des PCs zu voll wird, wird die RTS-Leitung
high und der AVR muss mit dem Senden von Daten warten. Ist das
richtig???
Nun zu meinem ursprünglichen Problem:
-Seit ich das Terminalprogramm gewechselt habe (von Terminal v1.9b
(Bray) nach HTerm 0.5.7)kann ich selbst bei 115200 Baud und über
500000 übertragenen Bytes KEINE Fehler mehr erzeugen. :-)))))
Ich kann immer noch nicht glauben, dass all meine Probleme nur vom
'falschen' Terminalprogramm verursacht worden sind.
-Da ich mich von dem ganzen hin und her habe verwirren lassen, habe ich
nacheinander die RTS und die CTS Leitungen abgetastet. Während der
Übertragungen konnte ich keine Pegeländerungen durch eine zu hohe
Rechnerlast feststellen (egal wie ich den Rechner belastet habe -
Rechner läuft unter win2000).
Bevor jemand nachfragt: Ja, ich habe das Handshaking eingeschaltet ;-)
Auch bei dem fehlerhaften Programm habe ich auf beiden Leitunge keine
Fehler feststellen können. (Es produziert noch immer seine Fehler -
auch bei recht niedrigen Baudraten)
Wie könnt ihr eine Pegeländerung durch eine zu hohe Rechnerlast
hervorrufen???
Vielen Dank für eure Mühe
moin
alles klar...bei der 8051er Kiste konnte man die serielle Schnittstelle nur über einen Timer synchronisieren und da konnte man keine "genormte" Baudrate (in deinem Falle 115200) einstellen. aber jetzt läuft's ja...viel Freunde und viele Grüße müllo
>Pin Belegung am DB9 PC Ausgang Stimmt, und diese Bezeichnungen sind für dich allein entscheidend. Und um nicht noch mehr Verwirrung durch die verscheidenen Signalpolaritäten auf dem Weg bis zu deinem AVR zu stiften Mess einfach nach: Vor dem Start des Terminal Programms sollte RTS "nicht Empfangsbereit" anzeigen, nach dem Start/Öffnen des COM Ports sollte dann die Leitung umschalten. Daran erkennst du auch ob RTS/CTS Handshake aktiviert ist.*** Wie misst du ob RTS kurzzeitig umschaltet? Im PC gibt es 2 Eingangspuffer: den FIFO Puffer des UART,der dürfte vielleicht so 16-64 Byte grosse sein, von dort schafft das BS die Daten in den COM API Puffer, der ist vielleicht so 2-3KB gross. Holt die Applikation z.B. durch falsches Design (Multithreading und Asynchrone I/O) die Daten nicht schnell genug ab so gehen sie verloren (d.h. wenn das Handshake nicht befolgt wird). ***mist, hab gerade nochmal nachgeprüft: selbst bei deaktivierten RTS/CTS Handshake wird beim COM Port öffnen RTS aktiviert, dann aber in der Pufferüberlaufsituation nicht mehr zurückgenommen. Ob der COM port von deinem Terminalprogramm richtig konfiguriert ist kriegt man also so nicht direkt heraus.
Hi, ich habe nicht jedes einelne Wort hier gelesen aber was hälst du von ner CRC Prüfsumme. Ich tausche zwischen PC und MC Daten in Byte orientierten Telegrammen (Modbus RTU) aus. Darin enthalten ist ne CRC 16 Prüsumme die wird über die Daten des Einzelnen Telegrammes erzeugt auf beiden Seiten. Beim Senden und Empfangen. Die Summe wird mitgesendet. Du kannst dann prüfen ob die Übertrgung fehlerfrei abgelaufen ist. Die CRC 16 Berechnung kann glaub ich dasWinAVR schon selbst. Ansonsten stell ich dir gern entsprechenden Code zur Verfügung. Gruß Steffen
@ Steffen Da ich noch keine Programme für den PC schreiben kann, lade ich die Daten mit einem Terminalprogramm herunter und kopiere sie dann nach Excel. Excel macht dann alles weitere. (Ich träume noch von einem kleinen Programm, dass auf dem PC die Daten direkt nach Excel kopiert) Eine Prüfsummenberechnung kann also leider noch nicht stattfinden. Da ich in Assembler programmiere, hilft mir dein Angebot leider nicht weiter Wenn die Daten wahlweise an einen graphischen Taschenrechner TI83/TI84 gesendet werden, findet eine Prüfsummenkontrolle statt, da das Übertragungsprotokoll dies zwingent vorschreibt.
@Benedikt > An den 18MHz liegt es höchst warscheinlich nicht. > Ich habe schon öfters einige MByte an einen mit 22MHz laufenden AVR > übertragen, und das ohne Fehler. Auch in der anderen Richtung ging es > fehlerfrei. Das ist schön. Da "moin" aber von einer fehlerfreien Übertragung sprach, ist es sicher der flasche Weg, ein Bauteil außerhalb seiner Spezifikation zu betreiben.
Nicht Träumen. ;) Wenn du dichn Bissel mit Visual Basic beschäftigst, hast du ruck zuck ne Verbindung zwischen Excel und AVR zurechtgebastelt. Die serielle Kommunikation geht recht einfach. Nach den ersten obligatorischen Rückschlägen zumindest. Ich kann nur sagen, dass sich bei mir die CRC Geschichte richtig gelohnt hat. Bei dir müsste allerdings auch das Terminal damit klar kommen... Aber vielleicht magst dus ja mal mit Telegrammen und CRC Prüfung probieren, wenn du anfängst kleine PC Programme zu schreiben. ;) Viel Erfolg Steffen
Also wenn genügend Leitungskapazität vorhanden ist, kann man einfach die Daten dreimal schicken und dann die 2-von-3-Funktion bilden, die jedes einzelne gekippte Bit korrigiert: #define mc_two_of_three(a, b, c) (((a) bitand (b)) bitor ((a) bitand (c)) bitor ((b) bitand (c))) Das Makro hat den Vorteil daß man wahlweise chars, ints ... übergeben kann. Für die Fehler-Detektion nimmt man einfach das EXOR von a, b und c mit anschließendem Bitcount. Ansonsten gibt's auch kompliziertere ECC Codes, die weniger Leitungskapazität benötigen.
Hi! @Steffen, Könnstet Du mir den Source für Modbus zusenden?? Grüße Sascha
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.