Hallo Leute, Ich moechte einen I2C-Bus ueber etwa 5m ausdehnen. Ich benutze ausschliesslich PIC18F442 mit integrierter I2C-Schnittstelle. Insgesamt sind es 4 PIC, die dran haengen und ein Master. Geht das? Wenn ja, wie gross darf die Geschwindigkeit sein? Muss ich an die PINs (SCL, SDA) noch Pull-Ups loeten oder ist das im PIC integriert? Wenn ich die loeten soll, wie gross sollten sie sein? Danke, der Guenther
Hallo Guenther, prinzipiell geht das schon, aber dafür ist der I2C-Bus nicht gedacht. In dem angehängten PDF findest Du auf Seite 11 eine Rechnung bzgl. der Widerstände bzw. der Geschwindigkeit. Du brauchst halt kleine Widerstände und eine niedrige Übertragungsrate, da Du bei der Länge eine hohe Leitungskapazität hast (und die kennst Du nicht so genau). Außerdem fängst Du Dir auf 5 Metern möglicherweise Störungen ein. Gruß Gerd
Es gibt sonst auch I2C Bus Extender, mit denen wird eine größere Reichweite möglich... Kannst ja mal nach P82B715 suchen... Ich mein ich hab sowas auch schonmal in einer Elektor gesehen, da war die maximale Datenrate gegen die Kabellänge in einem Diagramm aufgetragen. Und dann halt eben der Vergleich mit und ohne Bustreiber. Auf jeden Fall habe ich in Erinnerung das man bis deutlich über 100 Meter mit einem Bustreiber ordentliche Datenraten bekommt. Ohne Bustreiber fällt es halt eben schneller ab (obwohl 5m sollte man auch so erreichen können, vielleicht ein bischen auf Schirmung und so achten, also würde ich jetzt sagen). Müsste in einem Halbleiterheft gewesen sein (ich mein 2002). Werd sonst nachher nochmal nachschaun, hab die Zeitschrift grad nicht da :-)
Also brauche ich in jedem Fall Pull-Ups, auch wenn das direkt als I2C-Schnittstelle bezeichnet ist? Okay. Gibt es eine Mindestgroesse fuer den Widerstand? Ich meine, gibt es ein Limit fuer den reinfliessenden Strom? Danke. der Guenther
ich benutze hier ein messgerät, das sich die daten von einem ad-wandler über den i2c bus holt. als kabel benutze ich ein 9 poliges (geschirmtes) rs232 kabel, kabellänge ist 1 m. habe das eine zeitlang durch ein verlängerungskabel auf 3 m verlängert und keinerlei unterschied festgestellt. allerdings arbeite ich nicht mit maximaler geschwindigkeit, da der ad-wandler sowieso recht langsam ist.
Hallo Guenther, mit den folgenden 2 Tipps kannst du einen I²C Bus sehr weit ausdehnen: - 10k Pullups an die beiden Bus Enden an SDA und SCL. - 330 Ohm vor jedem I²C Baustein. Gruß, Patrick
Nur damit ich das richtig verstanden habe: der 330R soll den Eingang mit der Leitung verbinden? Kein Pull-Up? Mache ich damit mein SNR nicht schlechter, weil durch den Spannungsteiler 10k||10k und 330R der Bus nicht mehr richtig auf Masse liegt? Warum wird damit die Ausdehnung erhoeht? Die Kapazitaeten sind doch die gleichen. Ich moechte gern verstehen warum, bevor ich drauf los loete. der Guenther
Kurz: Philips sagt, bis 200 pF Kapazität reichen PullUp-Widerstände, bei mehr sollte eine Stromquelle den Bus hochziehen; bei 400 pF ist dann komplett Sense. Mit so einem üblichen 100 pF/m-Kabel kannst Du Deine 5 Meter also vergessen. Aber es gibt ja auch Kabel um die 50 pF/m. Deine Platinen solltest Du Dir auch noch daraufhin anschauen, die IC-Pins werden wohl nicht zu viel beitragen. Da kannst Du also schon unter 400 pF bleiben. Ein PullUp-Widerstand zieht da den Bus halt zunächst flott, dann aber immer langsamer hoch, zu langsam für diese Kapazität. Kleiner kannst Du ihn auch nicht machen, sonst überforderst Du die ICs. Also einen konstanten Strom zum Hochziehen, etwa die Hälfte dessen, was der schwächste Busteilnehmer an Strom auf Masse zieht. Ansonsten: liebe Leute, der I2C ist ein lokaler Bus. Wer seine Wohnung verkabeln will, soll einen differentiellen Bus nehmen, denn die Leitungskapazität ist nicht das schlimmste Übel, was Euch "da draußen" begegnen wird. Gruß, Philipp.
Ich versteh die Welt nicht mehr. Hier wurde doch von mehreren Leuten berichtet, dass es gehen soll. Und ich will nicht meine Wohnung verkabeln, ich habe ein verteiltes System von PIC-Microcontrollern, die ich ueber I2C verbinden moechte. RS232 faellt raus, weil ich 4 PICs habe und halt nen BUS brauche. Es muss ja nicht mal sehr schnell sein. Etwa 20 mal in der Sekunde 4byte Daten. Ueber SPI koennte ich nochmal nachdenken, allerdings ist da wieder eine Leitung mehr und das ein Problem. Neue (bessere) Kabel sind eher schlecht. Aber bis sagen wir 4m geht es in jedem Fall bei 100pf/m? Danke nochmal, waere aber noch dankbarer, wenn sich alle einig waeren. Egal wie das Ergebnis dann aussieht. Hauptsache ich weiss ob es geht oder nicht. der Guenther.
Sage ich nicht auch, daß es geht? Aber mit mehr Sorgfalt (wobei ein Kabel mit wenig pF/m ja auch kein Luxusgut ist). Nur entworfen wurde der I2C dafür nicht. Darum auch all die Hilfskonstruktionen von Busextendern bis hin zu Seltsamkeiten wie "Patricks Tricks" ... Warum denn nicht RS-485 (halbduplex)? Fast jeder µC hat einen passenden UART drin und die Bustreiber sind viel einfacher als RS-232, weil sie ohne externe Komponenten auskommen. Ein geeignetes Protokoll für eine Halbduplex-Vernetzung von so wenigen Komponenten ist in ein paar Codezeilen fertig und Du hast nie wieder Sorgen mit Leitungslänge, Geschwindigkeit oder Störungen.
Hab leider kein Datenblatt fuer das Kabel. Ist ein vorkonfektioniertes DIN-Kabel mit 6 Adern+Schirm. Da geht aber noch mehr durch. Eine Ader koennte ich noch frei machen. Bustreiber und sowas wollte ich eigentlich nicht auch noch verloeten. Wusste gar nicht, dass man sowas braucht. Ich dachte, man loetet seine 2 Draehte an die PINs und schon geht USART. Was muss ich denn veranstalten, damit aus meiner USART eine RS485 wird? Komme ich da (wie bei RS232 und I2C) auch mit 2 Leitungen + Gnd aus? Danke nochmal. der Guenther
Im Prinzip reichen sogar zwei Leitungen ohne Masse. Also: die UART hat eine TX, die jeweils eine 0 als GND rausgibt und eine 1 als 5 V (je nach µC). An der RX wird entsprechend irgendwo um 2,5 V herum zwischen 0 und 1 unterschieden. Für RS-232 werden die Spannungslevel übersetzt in minus ein paar Volt (5 bis 15?) für die 0 und plus ein paar für die 1. Damit hat man dann genug Abstand zwischen beiden Pegeln, um nicht gleich von jeder Störung umgehauen zu werden. Auf der anderen Seite stört man selbst fröhlich herum mit diesen wilden Spannungssprüngen und man braucht Pegelwandler mit externen Kondensatoren, falls man solche Spannungen nicht schon irgendwo "herumliegen hat". Bei RS-485 generiert der Bustreiber für eine 0 auf der einen Leitung 5 V, auf der anderen 0 V; für eine 1 gerade umgekehrt; der Treiber braucht also keine exotischen Spannungspegel und kommt als kleines IC daher. Damit kann man am anderen Ende bei jeder Dämpfung noch das Bit erkennen, auch wenn dort nur noch +0,1 V und -0,1 V ankommt. Auch Störeinstrahlungen sind egal, weil sie sich bei verdrillten Leitungen symmetrisch auswirken (dann halt z.B. +0,7 V und +0,5 V, immer noch eindeutig). Und nach außen strahlt man wenig, weil die positive Flanke auf der einen Leitung und die negative auf der anderen sich gegenseitig aufheben. Damit nun mehrere Teilnehmer auf diesen zwei Leitungen senden können, muß man den Bus ein wenig "managen", wie es beim I2C ja auch nicht anders ist. Dazu kann man den Treiber zwischen Senden und Empfangen umschalten. Dann braucht man nur noch ein Protokoll, um Kollisionen zu vermeiden, wenn mehrere senden wollen. In einem Fall wie Deinem ist das aber denkbar einfach: entweder man nimmt einen der µC als Busmaster, der einteilt, wer wann senden darf, oder sie sind gleichberechtigt und senden der Reihe nach und tippen ihrem Nebenmann auf die Schulter, wenn sie fertig sind (vereinbartes Schlußbyte oder Anzahl der Bytes am Anfang). Üblicherweise vereinfacht man sich die Sache noch durch Verwendung des 9. Bits: Bytes zum Busmanagement (etwa die ID eines Busteilnehmers) wird mit gesetztem 9. Bit übertragen. Wenn sich Nummer zwei am Bus nicht dafür interessiert, was Nummer drei so von sich gibt, kann er einfach weghören, bis wieder etwas mit neuntem Bit kommt; das kann einen kleinen Controller manchmal ganz gut entlasten. Eine Software-UART-485 kommt übrigens auch ohne Treiberbaustein aus, muß dann auf zwei Pins sitzen, die wahlweise Ausgänge oder Differenzeingang sind. Ich hoffe, das war trotz seiner Kürze verständlich und nicht abschreckend. Im Prinzip kannst Du mit der 485 arbeiten wie mit der 232, die µCs müssen sich nur reihum "das Mikrophon weiterreichen". Dafür brauchst Du keinen aufwendigen Treiber (oder gar keinen) und kannst kilometerweise Kabel verlegen oder Datenraten von 2 MBit/s erreichen. Schönes Ding, viel zu selten benutzt.
Hast du da vielleicht mal ein Codebeispiel (am liebsten in C), wie man so eine Software RS485 baut? > auch wenn dort nur noch +0,1 V und -0,1 V ankommt Bin mir nicht ganz sicher, wie das gehen soll, denn der PIC entscheiden nicht bei 0,1V ob es ne 1 oder Null ist, sondern bei etwa 2,2. Und eine Spannungsdifferenz auf beiden Leitungen muss ich doch mit nem ADU lesen. Aber davon sprichst du ja gar nicht. Hm, bin etwas verwirrt. Wie wird das denn bei einem Software RS485 synchronisiert? Woher wissen denn die Teilnehmer wann ein Wort anfaengt und wann es aufhoert? Klingt fuer mich nach ziemlich viel Timingaufwand und nach nicht unaufwaendiger Synchronisation. Und das mit dem 9.Bit ist zwar von der Idee nett, aber ich muss trotzdem die ganze Zeit den BUS pollen, und trotzdem jedes Byte aufnehmen, sonst verpasse ich womoeglich noch ein Byte mit 9.bit. Generell ist ein Pollen ja recht leistungfressend. Daher fand ich das mit dem automatischen Interrupt bei I2C so prima. Wenn was fuer meine Adresse kommt, wird ein Interrupt ausgeloest. Sonst ist mir der BUS schnurz. Hm, ich muss mir das mal ruhig ueberlegen. Vielleicht hat ja noch jemand ein paar Hinweise oder ein Stueck Code. danke. der Guenther
Also ich habe hier Sachen aus dem bereits erwähnten Elektro-Artikel mit dem P82B715 gebastelt und das funzt bei ca. 60 m einwandfrei. kann ich nur empfehlen für I2C Bus Greets Karlheinz
> Hast du da vielleicht mal ein Codebeispiel (am liebsten in C), > wie man so eine Software RS485 baut? Nein, leider nicht. Aber Bibliotheken für Software-UART gibt es genug, die man anpassen kann, damit man keinen Treiberbaustein braucht. > Bin mir nicht ganz sicher, wie das gehen soll, denn der PIC > entscheiden nicht bei 0,1V ob es ne 1 oder Null ist, sondern bei > etwa 2,2. Und eine Spannungsdifferenz auf beiden Leitungen > muss ich doch mit nem ADU lesen. ADU? "Differenzeingang" schrieb ich, also zwei Pins, die zusammen ein Bit schalten, je nachdem welcher Eingang höher ist. Hat so ziemlich jeder µC, den ich kenne. > Hm, bin etwas verwirrt. Wie wird das denn bei einem Software RS485 > synchronisiert? Für das Timing gibt es ja fertige Routinen. Einzige sollte man externe Quarze nehmen, da die internen zu sehr mit Spannung und Temperatur schwanken, als daß sie genau genug für das UART-Timing wären. > Woher wissen denn die Teilnehmer wann ein Wort anfaengt > und wann es aufhoert? Wenn der Bus aktiv wird, löst Dein Comparatoreingang einen Interrupt aus. Ab dann macht der Softwareuart in festen Abständen ein Timerinterrupt und liest jeweils ein Bit aus. Aber darum kümmern sich die fertigen Routinen, das muß nicht Deine Sorge sein. > Und das mit dem 9.Bit ist zwar von der Idee nett, aber ich muss > trotzdem die ganze Zeit den BUS pollen Bei Software-UART hast Du natürlich immer die volle Last. Das "Weghören" geht nur bei Hardware-UART. > Hm, ich muss mir das mal ruhig ueberlegen. Vielleicht hat ja > noch jemand ein paar Hinweise oder ein Stueck Code. Tja, wenn Du mit I2C auch so gerne arbeitest, dann klingt das mit diesem Busextender doch gar nicht so schlecht für Dich; "bei 60 m einwandfrei". Tut Dir ein zusätzlicher Baustein so weh? PS: Ich habe mir vor langer Zeit mal einen einfachen, differentiellen Bus ohne Treiber ausgedacht, weil ich genau vor solchen Anforderungen stand (viele Teilnehmer, kein Hardwareaufwand, lang, nicht zu langsam, einfach in der Software ...). Ich wollte den demnächst mit ein paar neuen Ideen neu implementieren, aber wie ich mich und meine Pläne kenne, lohnt es sich nicht, darauf zu warten ... )-:
Hey Philipp, danke fuer deine Hilfe. Es soll wirklich nicht so aussehen, als wuerden mich deine Vorschlaege nicht interessieren. Das nur vorweg. Ich haette kein wirkliches Problem mit einem weiteren Baustein. Brauche ich den Busextender denn nur einmal oder fuer jeden Busteilnehmer? Denkst du dass das mit dem Busextender gut ist oder ist das Flickschusterei? Ist denn dein Super-Bus damals fertig geworden? Wenn ja, waere ich an den Ergebnissen interessiert. Ich werde mir mal in Ruhe einige Quellen zu der 485 ansehen, vielleicht ist das ja gar keine so schlechte Idee. Puh, da kommt dann nochmal etwas mehr Arbeit auf mich zu. der Guenther
Den Baustein brauchst Du bei jederm Teilnehmer am Bus. Ich denke ein kleiner Vorteil vom I2C ist, dass Du dir über das Protokoll keine Gedanken machen musst.....
Mal ne bloede Frage: Habe P82B715 weder bei Reichelt noch bei Conrad gefunden. P82B715 AND kaufen bringt auch nichts. Wo gibt es denn diese Dinger? der Guenther
Wie wärs mit CAN als Alternativvorschlag ? CAN soll schnell und störsicher sein, dank Protokoll und "symetrischer- differenz-Übertragung". Einige hundert Meter Buslänge sollen problemlos funktionieren. Leider kann ich keine Erfahrung zu diesem Thema an den Tag bringen, es interessiert mich aber trotzdem sehr! Hat jemand von Euch einen Link/Library zu einem CAN-Controller wie dem SJA1000? Ich würde ein "Netzwerk" mit CAN lösen, allerdings habe ich den Eindruck dass zu diesem Thema wenig gute, verständliche Tutorials für Einsteiger vorhanden sind. Kann mich Jemand eines besseren belehren? :-)
Sorry, aber CAN bringen meine guten PICs nicht. Aber ja, da sind einige Hundert Meter Buslänge drin, allerdings zu Lasten der Geschwindigkeit. Habe mich ausfuehrlich mit CAN beschaeftigt. Ist aber vom Ansatz ein ganz anderes Prinzip. Ein normaler Bus ist stationsorientiert. Dort frage ich Stationen an und diese melden sich als Stationen zurück. Da CAN aber speziell für's Automobil entwickelt wurde, geht man da anders her. Das ist Nachrichtenorientiert. Das heißt man fragt nur (z.B.) die Geschwindigkeit an und derjenige, der die Information hat gibt sie auf den Bus. Dabei hat jede Nachricht eine Prioritaet. Werden zwei Nachrichten auf einmal gesendet, wird immer die uebermittelt, die die hoehere Prioritaet hat. Das geschieht mittels Busarbitrierung. Kollisionen sind damit ausgeschlossen. Alles in allem brauche ich aber einen stationsorientierten Bus. Und vor allem brauche ich einen, den ich auch habe. der Guenther
Nochmal ne Frage bezueglich der Pull-Ups. http://www.sprut.de/electronic/pic/grund/i2c.htm#kabel sagt, dass die Widerstände nicht groesser sein sollen, als 1,8k. Aber hier war eher die Rede von 2x10k parallel. Was soll ich denn nun nehmen? Ich werde übrigens den 'Trick' von Patrick probieren, das kostet mich erstmal gar nichts und wenn es funktioniert ist es gut, wenn nicht kann ich die Chips immernoch kaufen. Trotzdem die Frage. Soll ich nur an beiden Enden 10k nehmen und 300R direkt vor die Pins oder soll das irgendwie anders sein? Ich meine, je groesser der Widerstand, desto langsamer die Anstiegszeiten. der Guenther
Hallo Guenther, "meine Tricks" sind von der Seite von André Helbig ( http://www.cc2net.de/Tips/tips.html ). Bis jetzt habe ich meine I2C Schaltungen immer so aufgebaut und hatte nie Probleme. Allerdings habe ich noch nie Pullups<10k aufgebaut. Gruß, Patrick
BITTE NICHT I2C!! ...das taugt nix auf so eine länge, geht wohl manchmal, ist aber eher Zufall: TAUGT NIX. Es wurde ja schon RS 485 abgesprochen, dafür ist das perfekt. Man nehme einen SN75176 (gibts bei Reichelt) kostet so ca. 1 EUR und gut ist. Mit halbwegs ordentlichem Kabel könnens dann übrigens auch mehrere 100 Meter sein. Nachteil: Man braucht 3 Pins; TX, RX und "Senden", aber wie gesagt, dass funktioniert ordentlich. I2C bitte nur innerhalb Platinen / Geräten verwenden, alles andere ist Pfusch! Stefan P.S. Wenn du genaueres über den SN75176 wissen willst kannst mich gerne Fragen.
Sorry vergessen: Die drei Leitungen brauchst du natürlich nur am PIC (drei PINS waren gemeint), der Bus selber muss nur 2 haben (+ und -, kein GND!). Wurde ja hier schon angesprochen...
> Man braucht 3 Pins; TX, RX und "Senden" Wie? kannst du das mal erlaeutern? Kann ich da die USART nehmen, die im PIC drin ist? Wie ist das mit Kollision und so. Danke, der Guenther
Tach, ja, du kannst die USART nehmen! Der Chip hat zum PIC hin 3 Pins: TXD, RXD und einen Pin mit dem der Ausgangstreiber des Chips aktiviert wird. Wenn du senden willst ziehst du diesen Pin auf High, ansonsten auf Low. Kollisionen werden durch ein kleines Protokolchen vermieden (ist ja bei I2C nicht anders, da ist es halt im kleinen schon mit drin). Beispiel: Master zieht die Sendeakt.-Leitung auf High, Ausgangstreiber wird hochohmig. Du sendest z.B. ein Startbyte, ein Adresswort und was du noch willst und ein Stopbyte, dann wird der Ausgangstreiber wieder abgeschaltet. Der entsprechende Client bekommt das nun mit, schaltet seinen Ausgangstreiber ein, schickt seine Daten und macht den Ausgang wieder hochohmig... So funktionierts im Überblick. Es also im Prinzip das gleiche wie RS232, nur dass es Bustopologie hat (deswegen braucht man ein kleines Anti-Kollisions-Protokoll) und mit einer Stromschleife arbeitet... Stefan
Mit RS485 hab ich auch schonmal geliebäugelt. Hast du da vielleicht eine Beispiel-Schaltung und etwas Code um das ganze mal ausprobieren zu können ( am besten für nen ATMega8)? Gruß, Patrick
Nein, ich sehe gerade USART ist schlecht. Die Beine sind schon belegt und ich habe keine Lust das wieder auszulöten. Wenn ich nun nur "normale" IO nehme, wie wird denn dann das mit der Synchronitaet gehandhabt? Also wie weiß mein PIC, wann das nächste Bit ansteht? Aber mit deinem BUS müsste ich auch keinerlei Rücksicht nehmen, dass nur komplette Bytes gesendet werden usw? Also nehmen wir an, ich will 22 Bits an alle schicken, dann kann ich das problemlos tun, richitg? Und dann wäre es doch so, dass auf dem einen PIN nur gesendet wird und auf dem anderen nur empfangen. Das klingt ja alles gut, nur das mit der Synchronität ist mir halt noch unklar. Bin dir echt dankbar. Das kingt so, als würde ich das machen. Welchen soll ich denn da nehmen? SN 75176BP oder SN 75176BD, die verweisen auf's gleiche Datenblatt kosten aber unterschiedlich. der Guenther
> Welchen soll ich denn da nehmen? SN 75176BP oder SN 75176BD, die > verweisen auf's gleiche Datenblatt kosten aber unterschiedlich. Unterschied ist nur die Gehäuseform. Der SN 75176BD ist im SO8 Gehäusse und der SN 75176BP ist DIL. Paule
@Patrick: Beispiel Code brauchts eigentlich nicht, für PIC hab ich auch keinen weil ich mit den AVRs programmieren... Ich mach das immer so dass ich einen Sendepuffer habe, dann wird mit einer Funktion der "Data Register Empty" Interrupt aktiviert und der Ausgangstreiber des RS485 ICs aktiviert. In dem besagten interrupt wird einfach immer das nächste Zeichen gesendet bis der Buffer übertragen ist. Dann gibts beim AVR einen weiteren Interrupt der geworfen wird wenn die Daten komplett aus dem TXD Pin raus sind, in diesem Interrupthandler deaktiviere ich den Treiber wieder. Beispielschaltung brauchts eigentlich auch nicht, TXD und RXD an den CHIP, und einen weiteren Pin vom PIC / AVR auf die beiden Pins für Senden/Empfangen auf den RS485 Chip. (Der "Empfangs-Aktivierungs-Pin" des SN75176 ist invertiert, d.h. wenn man die beiden Aktivierungspins zusammenschaltet und auf einen IO des µC legt kann man schön zwischen Senden und Empfangen umschalten). Ab einer gewissen Leitungslänge, am besten aber immer, sonst ist es wieder Pfusch, sollten die Busenden mit einem Widerstand abgeschlossen werden (man kennst das ja vom Koax-Ethernet). @Guenther: Ja, du kannst natürlich auch bitweise übertragen, du musst Dir halt dann eben eine Software-UART schreiben (würde mir keinen Spaß machen). Würde aber trotzdem empfehlen zu schauen dass die Hardware UART verwendet werden kann, diese sampled nämlich jedes Bit mehrmals und ist somit wesentlich störunempfindlicher! Stefan
servus, habe gerade diesen thread gefunden. sehr interessant! hat jemand zufällig eine seite parat, die unterschiedliche bussysteme wie zB I2C, SPI, CAN, etc. vergleicht? mich interessiert ein einfaches system bestehend aus controller, bus und speicher (eeprom, ca. 64kB oder passender). es soll störunempfindlich (I2C + extender?!) und einfach und billig zu realisieren sein. irgend jemand ideen und/oder vorschläge?
Schau mal bei www.maxim-ic.com, die schicken auch sampels. So weit wie ich informiert bin sollten die RS485-Treiber Kurzschluß-fest sein. Dann sind die Längen-Angaben nicht ganz so richtig: Es sind einpaar Kilometer mit stink-ordinären AWG26 TP Kabel möglich. (Dann aber mit geringerer Datenrate und genügend starkem Treiber.) Dann müsst du dir nur noch ein Level3-Protokoll ausdenken und dann hängst du die RS485 konverter an 2 Pins. Dann musst du halt per Assembler an den Pins wackeln.
Bitte 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.