Hallo zusammen, nachdem ich nun viele meiner AVR-Routinen auf dem SAM (Hardware Arduino DUE) erfolgreich portiert habe, will ich den nativen USB Port auch zum Spielen bringen. Als erstes will ich ihn als Slave ("Device") zu konfigurieren, daß er dem PC gegenüber als COM-Port erscheint und dann (später) als solcher nutzbar ist. Eine passende INF-Datei für Windoof werde ich mir schon zusammenfrickeln. Nur ich komme nicht weiter. Ich nutze Atmel Studio 7 in Standard C und ohne ASF. Wie bekomme ich den Port zum Spielen bzw. richtig konfiguriert? Hier gibt es ein hervorragendes Tutorial, das mir verständnismäßig schon weiter geholfen hat, aber es ist für den STM32 und damit nicht ohne weiteres auf den ATMEL übertragbar. Zumindest habe ich es nicht geschafft, auch nur die ersten Register richtig setzen zu können. Bei Github habe ich auch zwei Sachen gefunden, eine von "Erlkönig", leider in CPP, und einen von "emagli", durch die ich nicht durchsteige. Ist hier jemand, der sich mit dem SAM3X8 auskennt und mir Links zu entsprechenden Tutorials oder Examples geben könnte? Wäre toll. Meine Googelei führen mich immer nur im Kreis.
Na, du bist mir aber einer.... Also du musst dich schon mit dem in deinem Chip vorhandenen USB-Core befassen, sonst wird das nix. Ich habe im Laufe der Zeit hier schon ein paar USB CDC Quellen gepostet, die prinzipielle Logik ist immer dieselbe, aber die Handhabung des Codes ist eben unterschiedlich. Also nimm dir die Quelle für nen LPC (deren SIE ist noch am erträglichsten) und schreibe die für deinen Chip um. W.S.
Hanns-Jürgen M. schrieb: > Wie bekomme ich den Port zum Spielen bzw. richtig konfiguriert? Ein einfacher Port wie ein UART wird das nie sein. Du brauchst ein gehöriges Paket an Software dafür. Irgendwo in den Tiefen des Arduino Board Packages für den SAM3X8E wirst du eine Sourcen-Sammlung finden (in C++ natürlich) die es dir ermöglichen mag daraus einen eigenständigen Treiber in C zu extrahieren. Aber einfach ist das nicht. Da haben es die STMler etwas leichter. Und für die STM32-Controller gibt es dermassen viele fertige und bessere Boards dass die einem den Arduino Due schnell vergessen lassen. Ein K.O. Kriterium für mich war dass es beim Arduino Due keine durchgehenden 8 Bit breite Ports an den Board-Schnittstellen gibt. Wie kann man nur so etwas designen .....
STM Apprentice schrieb: > Wie kann man nur so etwas designen ..... Genial ist auch, dass man das Parallelinterface so designt hat, dass eine der Adressleitungen mit einer Steuerleitung verbunden ist. Damit sind parallele Displays nur per Bitbanging ansteuerbar. Idioten. BTDT.
Hanns-Jürgen M. schrieb: > Ich nutze Atmel Studio 7 in Standard C und ohne ASF. Freunde Dich schon mal mit ASF an, denn damit läuft das Herstellerbeispiel (Appnote) von Atmel/Microchip. Bei USB sollte man zuerst versuchen den Hersteller Beispiel Code zum Laufen zu bekommen, denn da muss eine ganze Menge Zeugs richtig gemacht werden. Anderenfalls gibt das nur ein häßliches Ausrufezeichen im Gerätemanager, das dem Anfänger auch nicht wirklich weiter hilft...
Hanns-Jürgen M. schrieb: > Eine passende INF-Datei für Windoof > werde ich mir schon zusammenfrickeln. Braucht man nicht, ist seit Windows 8 integriert. Hanns-Jürgen M. schrieb: > leider in CPP Ausrede! Und der Code ist im Tutorial doch detailliert erläutert... Jim M. schrieb: > Anderenfalls gibt das nur ein häßliches Ausrufezeichen im Gerätemanager, > das dem Anfänger auch nicht wirklich weiter hilft... Linux hilft hier, denn der Kernel gibt relativ gute Fehlermeldungen aus. Virtuelle COM Ports ("VCP"), ob per CDC-ACM oder anders, sind auch nur eine Krücke. Wenn du Kontrolle über das PC-Programm hast, definiere dein eigenes USB-Protokoll und greife direkt per libusb zu. So hast du mehr Flexibilität, Performance und Kontrolle, und vermeidest diverse Probleme.
:
Bearbeitet durch User
Hanns-Jürgen M. schrieb: > Ich nutze Atmel Studio 7 in Standard C und ohne ASF. Was wir gemacht haben: das Beispiel mit ASF zusammenstöpseln lassen, dann den relevanten Core-Code von ASF rausgepopelt und bei uns reingesteckt. Alles andere ringsum ist unser eigener Code. (Ist hier ein SAM4E16E, USB-Core dürfte sich von deinem kaum unterscheiden.)
Ja, danke für die vielen Antworten und Hinweise. Da ich aktuell nur "spiele" und kein produktives System plane, ist der DUE für mich der Richtige, insb, da ich einen auf dem Tisch habe. Und ja, das besagte, wirklich sehr gute Tutorial, ist schon sehr hilfreich, ohne hätte ich die USB-Idee gar nicht erst aufgegriffen. Dank an Erlkönig! CPP: Nun, ich habe in einer anderen Geschichte CPP Routinen in K&R C umgesetzt. Machbar wäre das auch hier, notfalls.. Ach ja: Ich nutze auf meinen PCs Win XP und Win 7. Updaten auf irgendeinen Kachelmist (Win 8 oder gar 10) werde ich nicht. Definitiv. Mit Linux habe ich mich vor 15 Jahren mal intensiver beschäftigt, vlt. werde ich irgendwann wieder mit Linux anfangen. Daher: Niklas G. schrieb: > Hanns-Jürgen M. schrieb: >> Eine passende INF-Datei für Windoof >> werde ich mir schon zusammenfrickeln. > Braucht man nicht, ist seit Windows 8 integriert. > nicht zutreffend, a.o. > Virtuelle COM Ports ("VCP"), ob per CDC-ACM oder anders, sind auch nur > eine Krücke. Wenn du Kontrolle über das PC-Programm hast, definiere dein > eigenes USB-Protokoll und greife direkt per libusb zu. So hast du mehr > Flexibilität, Performance und Kontrolle, und vermeidest diverse > Probleme. Ja, mag sein. Die COM-Geschichte sehe ich zunächst als Einstieg. Ob und inwieweit ich "später" weitergehe, kann ich heute noch nicht sagen. Ich denke aber, daß ich dann eine Kommunikation eher über Ethernet nutzen werde ASF will ich nicht. Ich will mein System möglichst selber kontrollieren und damit auch verstehen. Daß das Ganze dann länger dauert ist für mich irrelevant.... Jörg W. schrieb: > Hanns-Jürgen M. schrieb: >> Ich nutze Atmel Studio 7 in Standard C und ohne ASF. > > Was wir gemacht haben: das Beispiel mit ASF zusammenstöpseln lassen, > dann den relevanten Core-Code von ASF rausgepopelt und bei uns > reingesteckt. Alles andere ringsum ist unser eigener Code. (Ist > hier ein SAM4E16E, USB-Core dürfte sich von deinem kaum unterscheiden.) Wenn alle Strick reißen, werde das wohl versuchen
Hanns-Jürgen M. schrieb: > CPP: Nun, ich habe in einer anderen Geschichte CPP Routinen in K&R C > umgesetzt. Machbar wäre das auch hier, notfalls.. C++ läuft auch auf SAM3x8E Mikrocontrollern... Und auch C11. Es muss nicht K&R C sein... Hanns-Jürgen M. schrieb: > Ach ja: Ich nutze auf meinen PCs Win XP und Win 7. Updaten auf > irgendeinen Kachelmist (Win 8 oder gar 10) werde ich nicht. Definitiv. Unter Windows 10 kann man die Kacheln komplett abschalten und das Startmenü klassisch nutzen. Unter Windows 7 kann man über den Geräte-Manager manuell die usbser.sys laden und kann sich auch da die .inf Datei sparen... Unter XP - keine Ahnung, wer sich das antut ist selber schuld :-) Hanns-Jürgen M. schrieb: > Mit Linux habe ich mich vor 15 Jahren mal intensiver beschäftigt, vlt. > werde ich irgendwann wieder mit Linux anfangen. Da ist das eh alles einfacher - keine .inf -Datei, keine manuelle Treiber-Zuweisung, kein Laden von ggf. WinUSB, bessere Fehlermeldungen, Kompilieren mit libusb. Man muss eigentlich nur die Berechtigungen der /dev -Datei beachten mithilfe einer udev-Rule. Hanns-Jürgen M. schrieb: > Ja, mag sein. Die COM-Geschichte sehe ich zunächst als Einstieg. CDC / VCP ist aber komplizierter zum Laufen zu bringen, als erstmal "nacktes" USB... Hanns-Jürgen M. schrieb: > Ich > denke aber, daß ich dann eine Kommunikation eher über Ethernet nutzen > werde Dann mach das doch direkt, ist eh einfacher als USB.
:
Bearbeitet durch User
Nun ja... Niklas G. schrieb: > Hanns-Jürgen M. schrieb: >> CPP: Nun, ich habe in einer anderen Geschichte CPP Routinen in K&R C >> umgesetzt. Machbar wäre das auch hier, notfalls.. > > C++ läuft auch auf SAM3x8E Mikrocontrollern... Und auch C11. Es muss > nicht K&R C sein... Ich selber beherrsche CPP nicht, daher nehme ich nur nur K&R C > Hanns-Jürgen M. schrieb: >> Ach ja: Ich nutze auf meinen PCs Win XP und Win 7. Updaten auf >> irgendeinen Kachelmist (Win 8 oder gar 10) werde ich nicht. Definitiv. > Unter Windows 10 kann man die Kacheln komplett abschalten und das > Startmenü klassisch nutzen. Unter Windows 7 kann man über den > Geräte-Manager manuell die usbser.sys laden und kann sich auch da die > .inf Datei sparen... Unter XP - keine Ahnung, wer sich das antut ist > selber schuld :-) Nun, Windof ist Mist, so oder so. Irgendwann, so um 2008, habe ich mir einen ersten Rechner mit XP aufgebaut und der Win 2k Rechner aufs Altenteil geschickt. Das funzte/funzt ganz gut. Nach knapp 5 Jahren hat sich dann das (ASUS-) MB verabschiedet. Ich konnte ein gebrauchtes erwerben, das aber nur ein knappes jahr hielt. Also baute ich mir einen komplett neuen Rechner und beging den Kardinalfehler, dort Win 7 zu installieren. Win 7 hat zwar Vorteile gegenüber XP, aaaaber: Keinen Druckertreiber für meinen Drucker mehr verfügbar, kein Treiber bzw,. SW für mein Progranmuiergeröt, kein NETBEUI für die Vewrbinung zu meinem DOS-Rechner (TCP schluckt zuviel RAM), 2 meiner 3 Videso-Schnittprogramme liefen nicht mehr und einiges andere auch nicht mehr. Auch der XP-Emulator half nicht, ebensowenig wie eine VMWare Installation. Alles nur Gemurkse. Schließlich baute ich mit einem "neuen" gebrauchten, zum alten fast kompatiblen MB wieder einen -zusätzlichen(!)- XP-Rechner... Das Ganze will und werde ich nicht ein weiteres Mal durchführen. Daher wird es auch kein "modernes" Windoof geben. Ach ja: XP und 7 laufen absolut stabil bei mir. Ich "nutze" ja auch kein MS Office > > Hanns-Jürgen M. schrieb: >> Mit Linux habe ich mich vor 15 Jahren mal intensiver beschäftigt, vlt. >> werde ich irgendwann wieder mit Linux anfangen. > Da ist das eh alles einfacher - keine .inf -Datei, keine manuelle > Treiber-Zuweisung, kein Laden von ggf. WinUSB, bessere Fehlermeldungen, > Kompilieren mit libusb. Man muss eigentlich nur die Berechtigungen der > /dev -Datei beachten mithilfe einer udev-Rule. Dem ist nichts hinzuzufügen. Ich muß wohl meinen alten Linux-Rechner, der damals aös Web- und Fileserver diente, aus dem Abstellraum zurückholen. Ob der noch läuft? Wird wohl was für die langen Winterabende > > Hanns-Jürgen M. schrieb: >> Ja, mag sein. Die COM-Geschichte sehe ich zunächst als Einstieg. > CDC / VCP ist aber komplizierter zum Laufen zu bringen, als erstmal > "nacktes" USB... Das sehe ich auch so, was ich da gerade durchgehe ist absolut unübersichtlich. > > Hanns-Jürgen M. schrieb: >> Ich >> denke aber, daß ich dann eine Kommunikation eher über Ethernet nutzen >> werde > Dann mach das doch direkt, ist eh einfacher als USB. Klar, Ethernet hatte ich mit dem AVR schon lauffähig
Hanns-Jürgen M. schrieb: >> CDC / VCP ist aber komplizierter zum Laufen zu bringen, als erstmal >> "nacktes" USB... > > Das sehe ich auch so, was ich da gerade durchgehe ist absolut > unübersichtlich. Naja, sooo schlimm ist es nun auch wieder nicht. Man sollte einen gut getesteten Satz von Descriptors benutzen, verschiedene Betriebssysteme reagieren allergisch auf verschiedene Feinheiten in dem, was das Device über sich so behauptet. Vorteilhaft an CDC ist, dass du am Ende irgendein einfaches Kommandozeilen-Interface auf deinem Controller zimmern kannst, welches du mit einem üblichen (Seriell-)Terminalemultor auf dem Host bedienen kannst. Wenn es einmal läuft, ist der wesentliche Nachteil halt, dass Windows <= 7 dafür noch so'n blödes .inf-File braucht.
Hanns-Jürgen M. schrieb: > Ich selber beherrsche CPP nicht, daher nehme ich nur nur K&R C Das heißt C++, denn CPP ist der C PreProcessor... Wirklich K&R C? Das von 1978? Nicht mal ANSI-C? Uff. Man kann übrigens auch C++ Code in C Projekte einbinden... Hanns-Jürgen M. schrieb: > Keinen > Druckertreiber für meinen Drucker mehr verfügbar, Linux hat Treiber für ein paar Drucker, für die es nach WinXP keine mehr gibt... Hanns-Jürgen M. schrieb: > Ich muß wohl meinen alten Linux-Rechner, > der damals aös Web- und Fileserver diente, aus dem Abstellraum > zurückholen. Ob der noch läuft? Wird wohl was für die langen > Winterabende Oder parallel zu Windows installieren ("dual-boot"). Dauert je nach Glück mit den Treibern 1-2h.
Hanns-Jürgen M. schrieb: > Ich selber beherrsche CPP nicht, daher nehme ich nur nur K&R C Als K&R-C wird der C-Standard vor 1989 bezeichnet, der noch keine Funktionsprototypen kannte und damit praktisch überhaupt keine Typprüfungen durchführen konnte. Bist Du Dir sicher, daß Du dieses Fossil meinst?
Oops, da habe ich mich falsch/unklar ausgedrückt bzw. die fslschen Begriffe benutzt: Mit CPP meinte ich natürlich C++ und mit K&R C das "Standard C" (ANSI C?). Ursprünglich habe ich "damals" bei meinen ersten C-Versuchen 1985 ein Buch von K&R benutzt, später dann das Buch von Claus Schirmar mit ANSI C (1992). Also sagen wir mal: #define K&R ANSI :-) Noch eine Anmerkung zum Dual Boot: Ich hatte einen Dual Rechner (Win 98 / LUNIX SUSE 8), aber der ist längst verschrottet. Dual Boot dauert mir heute zu lange (Runterfahren, Hochfahren), da ist ein weiterer PC ggf. über KVM-Switch gemuxt eher die Wahl. Ach ja: Druckertreiber: Es ging um den Treiber für den HP LJ 3100...Ob da Linux was zu bieten hat bzw. HP einen beigetsuert hat, weiß ich nicht. Ich werfe nunmal ungern Sachen weg, die noch funktionieren (oder reparabel sind), nur, weil es keine Treiber mehr gibt.
Hanns-Jürgen M. schrieb: > Ach ja: Druckertreiber: Es ging um den Treiber für den HP LJ 3100...Ob > da Linux was zu bieten hat bzw. HP einen beigetsuert hat, weiß ich nicht Laut HP ja: https://developers.hp.com/hp-linux-imaging-and-printing/models/laserjet/hp_laserjet_3100
Jörg W. schrieb: > Vorteilhaft an CDC ist, dass du am Ende irgendein einfaches > Kommandozeilen-Interface auf deinem Controller zimmern kannst, welches > du mit einem üblichen (Seriell-)Terminalemultor auf dem Host bedienen > kannst. exakt DEN Satz solltest du ungefragt in goldenen Lettern in jeden Thread kopieren, wo einer anfängt, über USB aud seinem µC zu schreiben. Wie man das von der Pike auf für diverse µC hinbekommt, habe ich hier zur Genüge gepostet, wer es also tatsächlich an seinen µC adaptieren will, darf die Suchfunktion benutzen. W.S.
So, ich möchte meine (frustrierten) Zwischenstand abgeben, nachdem ich letzte mich Woche 30 Stunden mit dem Thema "USB" befaßt habe. Aber zunächet: Ich habe hier im Forum nach dem Hinseis von W.S. (das vorhergehende Posting" nach dessen Postings gesucht. Aber weder einen Suche nach w.S., noch nach CDC oder USB brachte Erfolg. Nun, auch egal. Ich hatte bei meiner Suche auch einen SEHR interesanten Artikel bezüglich USB (allerdings als Host betrieben) auf einem SAM3X8E gefunden. Ich möchte euch das hier nicht vorenthalten: https://www.codeproject.com/Articles/876161/Getting-video-stream-from-USB-web-camera-on-Ardu Zunächst habe ich muir die Startroutinen (Init) bei ihm angesehen. Dann habe ich mir so gedacht, ich nehme das Projekt von emagii auf Github https://github.com/emagii/at91sam3s und portiere das zum SAM3X8. Das war sehr zäh, immerhin waren über 20 Files (H und C) einzubinden und zu portieren und meiner Nomenklatur entsprechend anzupassen. Als ich zuletzt das USB-HAL.c File anpassen wollte, habe ich aufgegeben. Grund: Der SAM3S kann im Gegensatz zum SAM3X nur den USB-Device Mode. Mir ist es daher nicht gelungen, die Register entsprechend "umzudenken" Mein Ansatz bestand/besteht halt darin, ein Fremd-Projekt zum Spielen zu bringen und es dann zu analysieren. So habe ich es beispielsweise bei "FAT32 auf Speicherkarte" gemacht (AVR). Da mir das Beisipiel von erlkönig auf dem STM32 trotz des dort vorhandene USB2GO Ports noch zu umständlich in der Portierung (C++ und zudem ein anderer Prozessor) erscheint, habe ich nun, wie hier auch vorgeschklagen wurde, ein nacktes ASF Projekt angefangen, das ich nun als erstes mit meinen Umgebung (Display etc) verbinden werde. Ich melde mich wieder, allerdings habe ich nur noch 2..3 tage Zeit, danach muß ich mich für 3..4 Wochen um wichtigere Dinge kümmern. VG Yogy Der dort verwendete
Hanns-Jürgen M. schrieb: > Der SAM3S kann im Gegensatz zum SAM3X nur den USB-Device Mode. Mir ist > es daher nicht gelungen, die Register entsprechend "umzudenken" Wo ist das Problem? Du wolltest doch ein USB-Device bauen?
S. R. schrieb: > Wo ist das Problem? Dass er offenbar versucht hat, einen für OTG geschriebenen Code als Device-Code umzubauen. Das dürfte nicht nur wegen anderer Registernamen kaum praktikabel sein, sondern das Verhalten als USB Host ist ein völlig anderes als das als USB Device. Selbst, wenn eine Hardware beides kann, ist die dahinter liegende Software für beide Betriebsarten komplett anders gestrickt.
Hanns-Jürgen M. schrieb: > Die COM-Geschichte sehe ich zunächst als Einstieg. Mach doch erstmal was simpleres wie HID. Hast Du schon das Buch "USB Complete"? Das ist Pflichtlektüre.
So, einen nicht mehr so frustrierten Zwischenbericht. HEUREKA! Es funzt "im Prinzip" Am und Mo habe ich ein ASF-Projekt begonnen und dann die ASF Files mit meinm SW-Grundgerüst verknotet. ASF hat noch mehr Files einzubinden als die amagii-Geschichte. Gestsrn, DI habe ich das dann soweit zum Spielen gebracht, daß ich im Windoof Gerätemanager den USB-Port ohnen Fehlermeldung sehen konnte. Heute habe ich dann damit "rumgespielt", so daß ich jetzt mittekls des termainal programms Zeichen senden und empfangen kann. Nun, ein erster aber sehr wichtiger Schritt. So bald ich wieder zeit habe, werde die ASF Dateien entmüllen und meiner Nomenklatura anpassen. Was mir noch fehlt, sind der Zeichenempfang und das Zeichensenden mittels Interrupt, damit es kompatibel zu meinen anderen Communikationsroutinen wird. Diese funktionieren, wie wohl allgemein üblich, folgendermaßen: Durch den Empfang eines Zeichens wird ein IRQ ausgelöst, in dem das zeichen in einen Buffer geschrieben wird. Zugleich wird ein Eventflag gesetzt. In der Hauptprogrammschleife werden dann alle bis dahin empfangenen Zeichen ausgewertet. Soll ein Zeichen geschrieben werden, wird es in einen anderen Buffer geschrieben und der Sende-IRQ freigegeben. In der Sende-IRQ Routine werden dann nach und nach elle Zeichen im Buffer ausgesendet, und nach dem letzten Zeichen wird der IRQ gesperrt. Bei USB-Systemen scheinen ja Buffer defaultmäßig vorhanden zu sein, so daß ich zumindest den Sende-IRQ nicht benötige. Aber einen Empfangs-IRQ brauche ich zum EventFlag-setzen. Pollen ist halt blöd. Ich denke "so mal eben auf die Schnelle", daß dazu der IRQ den Endpoints-0 verwendbar ist, oder? So, jetzt muß ich mich (leider) erst einmal um wichtige Dinge kümmern. Bis bald
Hanns-Jürgen M. schrieb: > Bei USB-Systemen scheinen ja Buffer defaultmäßig vorhanden zu sein, so > daß ich zumindest den Sende-IRQ nicht benötige. Jein. Dafür solltest du dir sendeseitig Gedanken machen, ab welchem Füllstand des Puffers bzw. bei welche(m|n) Zeichen du das Senden anwirfst. Gesendet wird ja immer in ganzen Paketen, und wenn du worst case jedes Zeichen einzeln in einem USB-Paket verpackst, dann geht die Datenrate in den Keller. > Aber einen Empfangs-IRQ > brauche ich zum EventFlag-setzen. Pollen ist halt blöd. Ich denke "so > mal eben auf die Schnelle", daß dazu der IRQ den Endpoints-0 verwendbar > ist, oder? Wenn du den HAL aus ASF benutzt, dann gibt es eine Funktion HAL_UsbRead(), bei der ein Callback für das Ende des Transfers angegeben werden kann. Wir starten ein solches HAL_UsbRead(), danach läuft das Programm im Vordergrund weiter. Wenn der ankommende Transfer bereits zum Abholen ist, wird der Callback gerufen. Der verarbeitet das, was eingetrudelt ist, und startet danach ein neues HAL_UsbRead(). Gewissermaßen startet man mit jedem HAL_UsbRead() einen separaten Thread, der so lange schläft, bis auf dem USB wieder „was passiert“ ist.
:
Bearbeitet durch Moderator
Ja, danke für die Antwort. Werde ich mir dann genauer ansehen.
So, das Thema ISB ist jetzt ersteinmal erledigt. In den vergangenen Tagen habe ich einen teil des ASF Überbaus entfernt, den rest mache ich irgendwann, wenn es ernst wird. Die Kommunkation habe ich nun laufen. Lesen aus dem UOTGHS erfolgt per Interrupt nach einem empfangene Zeichen, es werden dann alle bis dahin abrufbaren Zeichen abgeholt. Rücksendung erfolgt entweder als Einzelzeichen oder, falls möglich, blockweise aus einem Array. Große Datenblöcke hat meine Kommunkationsstruktur allerdings keine, maximal 240 byte,
Hanns-Jürgen M. schrieb: > Die Kommunkation habe ich nun laufen. Schön! Bei uns ist nun gerade der SAM4E durch einen SAME70 ersetzt worden. Der hat Highspeed-USB statt nur Fullspeed … da wird sicher noch einiges an Umbau nötig werden.
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.