Hallo Leute, ich habe mal ein Paar Fragen zum ARM. Ich habe bald meinen Jahresurlaub (2 Wochen) und will mich doch auch mal mit dem ARM außeinander setzen. Mein Problem ist nur... welches Device! Ok ich denke ein ATMEL(AT91) oder ein NXP(LPC2000) sollte es schon sein, da man die ja fast schon in der Grabbelbude um die Ecke findet. Aber das war es auch schon. Was ich denke zu brauchen: - ~64 - 256k Flash - mind. 16 16k RAM (idealerweise 32 - 64) - mind. 1x SPI und das möglichst schnell (~10MHz) - mind. 1x UART für RS232 - mind. 1x CAN - 16-... IO's - idealerweise als 44 oder 64 Pinner was auch noch wichtig ist: - ein möglichst schnelles Flash da viel aus ihm gelesen werden muss - DMA währe optional daher auch ganz fein - falls es soetwas gibt, eine Programmierschnittstelle ohne extra Geräte also idealerweise (ohne vorherigen Bootloader zu schreiben) direct via USB oder RS232 - GCC Support (auch der rest an Tools sollte kostenfrei sein) - möglichst günstig (nicht über 20€ pro Chip) - möglichst wenig "Hünerutter" rings rum um das Ding zum laufen zu bekommen ;-) Irgendwie finde ich genügend Pros & Kontras für viele ARM`s von Atmel und NXP, aber die letzte Festlegung kann ich nicht treffen. Ein genaues Projekt schwebt mir momentan noch nicht vor, aber ich würde ersmal viele meine früheren Apps von MSP430`s und AVR`s auf den ARM portieren um erstmal mich einzuarbeiten. Ein Anfänger bin ich nach ~4 Jahren mit uC`s nicht mehr unbedingt, aber nachdem ich viel mit AVR`s und MSP430`s rumhantiert habe, denke ich das es ganz schön währe mit einem Industriestandard anzufangen. Zum 8051 habe ich irgendwie keine Mutivation gefunden und ARM`s (so haben mir viele aus der Industrie bestätigt) wird langsam genauso wichtig wie 8051'er. Könnt Ihr mir da ein oder zwei Typen nennen, die genau das sind, die ich brauche?
Mach mal bitte die "Deppenapostroph-Funktion" aus. Ich würde Dir den AT91RM9200 empfehlen, aber es gibt bestimmt 1000 Leute, die etwas anderes sagen würden. Du kannst doch sicher auch Datenblätter lesen? Da Du schon sehr genaue Vorstellungen hast, was Du haben möchtest, sollte sich doch sicher in 1-2 Stunden Recherche etwas finden lassen. Geht bestimmt schneller, als hier auf Antworten zu warten...
Wie wäre es wenn du einfach auf der ATMEL Homepage vorbeischaust. Dort werden alle ARM Typen in einer Matrixauflistung verglichen. Also viel einfach gehts dann wirklich nicht mehr!!!
Hmm, nagut... ich glaube ich habe mit dem LPC2148 ungefähr das gefunden, was ich brauche... Ist es eigentlich eine "Glaubensfrage" ob man einen Atmel oder einen NXP nimmt, oder gibt es da klare Pros und Kontras?
Seitens LPC2000 gibt es CAN in den schon älteren gut verfügbaren LPC2129/2294 und den neuen LPC2300. Auf letztere wirst du allerdings noch ein paar Monate warten müssen, es sei denn dir reicht erst einmal ein entsprechendes Experimentierboard (gibt's wohl von Keil oder so). Bei den älteren sollte man unbedingt die Bugliste lesen, FullCAN ist aufgrund von Bugs unmöglich, BasicCAN geht aber. Günstiges Header/Bastelboard mit LPC2119 siehe http://stores.ebay.de/Micro-Research_W0QQcolZ4QQdirZ1QQfsubZQ2d33QQftidZ2QQtZkm oder http://www.futurlec.com/index.shtml. Solltest aber noch ein bischen Zeit bis zum Urlaub haben, denn zumindest bis das von MicroResearch verschifft ist dauert's etwas.
> ich glaube ich habe mit dem LPC2148 ungefähr das gefunden, was ich > brauche... Seit wann ist da CAN drin? Ach ja, der LPC2119 hat zwar SPI, aber bei 7,5MHz ist Schluss. > ob man einen Atmel oder einen NXP nimmt Man nimmt beispielsweise was man schon kennt und auch kriegen kann. Ist beides neu, kann man ja nach den Funktionen gehen. Bei Header- und Experimentierboards ist LPC2000 verbreiteter als SAM7, weil schon länger auf dem Markt.
Ein paar Unterschiede Atmel SAM7... genenueber NXP LPC2... Dieser Vergleich ist etwas biased, da ich bei NXP arbeite aber vielleicht kann ja ein Atmel Mitarbeiter einen aehnlichen Vergleich zur Verfuegung stellen, der ebenfalls auf Fakten beruht: 1. CPU-Takt max. bei NXP 60-72 MHz abarbeiten aus dem Flash, Atmel 55 MHz 2. Max. Performance bei Atmel im Thumb-Mode, bei NXP im ARM Mode. Flash Breite ist der Flaschenhals bei Atmel. Das spielt eine grosse Rolle bei der Spitzengeschwindigkeit aus dem Flash aber keine grosse Rolle bei der Durchschnittsgeschwindigkeit. 3. Um maximale Geschwindigkeit zu erreichen muss der Code bei SAM7 ins SRAM geladen werden, beim LPC2000 auch. Der Verlust an Performance wenn aus dem Flash gearbeitet wird ist bei NXP ca. 5%, bei Atmel ca. 30% jeweils bei der max. Clock Rate. D.h. ein LPC2000 ist vom Flash bei 60 MHz ein klein wenig schneller als ein Atmel bei 55 MHz vom SRAM. 4. Angenommen max. Performance ist nicht so wichtig, bei 30 MHz sind beide praktisch gleich schnell, weil SAM7 da auch vom Flash im ARM mode fahren kann. 5. Stromverbrauch ist aehnlich zwischen diesen beiden Familien und beide sind viel besser als der Rest der ARM7-Welt 6. GNU-Tools gibts fuer beide (schau ach mal rein bei YAGARTO !) 7. Aeltere LPC2000 benoetigen 2 externe Spannungen, 1,8V und 3,3V, die SAM7 sind spaeter an den Markt gekommen und haben alle einen internen DC/DC, brauchen somit extern nur 3,3V. Der LPC2119/01 oder der LPC2129/01, der fuer die Anforderung passen koennte brauchen 2 Spannungen. 8. DMA gibt es bei NXP nur in den LPC23xx und LPC24xx, bei SAM7 haben das alle. Diese LPC23/24xx Teile sind noch neu und wie schon gesagt etwas schwierig zu bekommen. Derzeit am einfachsten auf Evaluation Boards. 100-pin ist auch das kleinste Gehaeuse. Positiv waere natuerlich, das absolut beste Preis/Leistungsverhaeltnis, 2 CAN Schnittstellen, bis zu 3 schnelle SPI, obendrauf USB und Ethernet und trotzdem aehnlicher Preis wie LPC2129. Bei Digikey kostet der LPC2364 nur 6,06 Euro! mit der Moeglichkeit auf einen 2366 oder 2368 drop-in/kompatibel aufzuruesten. Voraussichtliche Verfuegbarkeit weiterer Teile bei Digikey, Ende September. Entwarnung fuer Errata Sheets LPC2119/01 und LPC2129/01 haben die CAN Probleme behoben! Ausserdem geht auch eine SPI mit der SSP Funktion bis 15 Mbit/sek, Siehe Data Sheet Kapitel 6.13 Errata Sheet: http://www.standardics.nxp.com/support/documents/microcontrollers/pdf/errata.lpc2119.01.pdf Data Sheet: http://www.standardics.nxp.com/products/lpc2000/datasheet/lpc2109.lpc2119.lpc2129.pdf Zusammenfassend: Egal ob es ein SAM7 oder ein LPC2000 wird, beide Familien bieten sehr gutes Preis/Leistungsverhaeltnis. Der groesste LPC Vorteil ist die Spitzenperformance aus dem Flash wogegen die flexible DMA Implementierung bei Atmel schon hilfreich ist. Robert
@ Travel Rec hast Du Dir die Minute genommen um die Frage von Tueddel zu lesen? Er fragt nach einem Flash micro (hat der AT91RM9200 nicht), mit CAN (hat der AT91RM9200 nicht), am besten im 64-pin Gehauese (das kleinste AT91RM9200 Gehaeuse ist 208-pin), mit moeglichst wenig Huehnerfutter drum rum (braucht der AT91RM9200 jede Menge) Ausserdem ist der AT91RM9200 ausgestattet mit einer veralteten CPU, fast alle neueren Teile haben eine verbesserte ARM926 CPU. You can do better than that ;-) Robert
@Robert: Ich habe mir mal die aktellen Erratas angesehen. Bei 2138/2148 komme ich mir bei den Workarounds zum neu entdeckten MAM Fehler etwas auf den Arm genommen vor: MAM.1: MAM auf Mode 2 stellen, sonst Müll. MAM.2: MAM auf Mode 1 stellen, sonst Müll. Besondern gefällt mir ja die ausgesprochen wolkige Beschreibung von MAM.2 (der offenbar auch in den .01 Versionen rumgeistert): Wenn das Problem bei ihnen auftritt, dann.. - nur dass diese Art Problem verteufelt schlecht zu diagnostizieren ist, zumal kein Tip gegeben wird, in welcher Konstellation das auftreten kann. Irgendwie klingt das so als ob NXP noch selber im Nebel stochert.
Das Problem koennte mit bestimmten Bus-Zustaenden in der Simulation erklaert werden. Evtl. sogar noch mit bestimmten Assembler Sequenzen aber da fast jeder in "C" programmiert, laesst sich die Beschreibung nicht so greifbar beschreiben wie es jeder gerne haette. Fakt ist, das Problem taucht in einer Konfiguration immer oder gar nicht auf. Das MAM.2 Problem ist ein reproduzierbares. Wenn MAMCR auf 1 gesetzt wird, ist das MAM auch enabled, so dass MAM.1 nicht mehr auftritt. Zugegeben, die Wortwahl ist mehr als ungluecklich :-(( ich werde das an die betreffenden Mitarbeiter weiterleiten. Robert
@Robert: Schon recht, bin nicht bei den ARMen zuhause, der 9200 ist der einzige, den ich mal in Aktion gesehen habe und über den ich somit berichten kann ;-)
@ Robert Teufel Danke für deine Übersicht. Aber Sie beschreibt gut mein Problem! Welches Device denn jetzt. Klar, eine eierlegende Woll-Milch-Sau ist zwar schön, aber manche Features brauche ich (erstmal nicht). So dass ich z.B. erstmal auf CAN verzichten kann (und falls doch, dann habe ich noch ein paar MCP2515 rumfliegen) Ich glaube, ich bestell mir erst mal dieses Board http://shop.mikrocontroller.net/csc_article_details.php?nPos=0&saArticle[ID]=72&VID=mC19xT06e6HhN6Xj&saSearch[word]=&saSearch[category]=ARM&saSearch[special]= und spiele damit rum. Das sollte mir erst einmal als Basis genügend Spielraum bieten! Und durch Seriell ist es auchnoch flashbar.
@Tüddel Gute Wahl, sehr gut verfuegbar, hohe Kompatibilitaet falls Du spaeter auf einen LPC23xx umsteigen moechtest und nicht zu komplex. Go for it! Robert
Hi, ich würde dir auch zu NXP raten. die ausführung von code aus dem flash ist wesentlich schneller als bei den AT91xxx. die AT91SAM7 können kein IIC-Slave (voll doof)! dafür ist das DMA bei den LPC's recht mies (umständlich zu konfigurieren, nur 2 channels und transfers gehen nur in's/vom USB-RAM). ...und die LPC's sind bei ähnlicher ausstattung sogar billiger als die Atmels -> Peter
Sollte ich mir auch einen JTAG adapter besorgen, oder wird der ser. Bootloader wohl reichen? Gibt es auch irgendwo ein C tutorial für LPC`s -> so wir unser AVRGCC Tutor hier? Ich habe zwar schon viel Gegoogelt, aber soetwas ausführliches wie eben das AVRGCC Tutorial nicht gefunden.
> Sollte ich mir auch einen JTAG adapter besorgen, oder wird der ser. > Bootloader wohl reichen? JTAG ist gut, wenn du auf dem target debuggen willst. für reine downloads reicht die serielle bestimmt aus, kann natürlich bei grossen images recht lahm sein. es gibt ja auch freeware JTAG debugger (OpenOCD), da muss man sich nur ein adapterkabel für'n parallelport basteln und kann dann über telnet debuggen. source-level debugging soll damit auch gehen (mit GDB und Insight), hab's aber nie hinbekommen, dieses GNU-zeug ist ganz schön widerspenstig. ich benutze dann doch lieber IAR und JLink, das geht wenigstens 'out-of-the-box'...
Naja, IAR ist für ein Bastler/Hobby ganz schön teuer! Hab mit IAR damals (Beruflich) für den MSP430 Programmiert. Fand da die IDE aber recht bescheiden! Aber die mitgelieferten Tools waren schon gut
> Naja, IAR ist für ein Bastler/Hobby ganz schön teuer! ja, das stimmt was du sagst, die IDE ist auch nicht so toll, die tools aber schon. auf der arbeit benutzen wir auch eine gekaufte version, aber privat könntest du, wenn dein unrechtsbewusstsein es zulässt, die gecrackte evaluation version benutzen. es gibt übrigens noch eine uVision-variante (von keil) mit dem GCC drin. ich glaube die war auch umsonst. ich weiss aber nicht, ob damit das debuggen anständig funktioniert (ich glaube ja eher nicht). die vollversion mit dem echten ARM-compiler und debugger ist natürlich sauteuer.
Als Alternative käme noch Rowley Crossworks in Frage. Das gibt es auch
in einer nichtkommerziellen Version, die für 150 USD verkauft wird.
Zur Zeit wird auch dieser Version ein USB-JTAG-Adapter ("CrossConnect
Lite") beigelegt.
Die nichtkommerzielle Version entspricht der kommerziellen, darf aber
nicht kommerziell eingesetzt werden.
Crossworks unterstützt verschiedene JTAG-Interfaces, den
FT2232-basierenden USB-JTAG-Adapter von Olimex ebenso wie die üblichen
"Wiggler"-Clones für den Parallelport.
Das verwendete Compiler-Backend ist hier übrigens auch gcc.
http://rowley.co.uk/arm/index.htm
> Das gibt es auchin einer nichtkommerziellen Version, die für 150 USD > verkauft wird. 'nicht-kommerziell' und 'verkauft'. wie passt denn das zusammen?
> 'nicht-kommerziell' und 'verkauft'. wie passt denn das zusammen?
Kommerziell seitens Rowley, nichtkommerziell seitens des Käufers.
Och, ich denke ich bleibe auch weiterhin beim GCC (wie auch beim AVRGCC,MSPGCC, und auch sonstige GCC-Versionen für den "großen" Rechner). Wenn man sich erst einmal an ihn gewöhnt hat, dann kommt man mit seiner Bedienung auch meist mit anderen Platformen zurecht. Aber sagt mal ein schönes Tutorial wie "C für LPC2000" oder so gibt es rein zufällig nicht, oder? Habe bislang(wie oben schon beschrieben) noch nichts finden können.
>Aber sagt mal ein schönes Tutorial wie "C für LPC2000" oder so gibt es >rein zufällig nicht, oder? Habe bislang(wie oben schon beschrieben) noch >nichts finden können. http://www.mikrocontroller.net/articles/ARM-elf-GCC-Tutorial MfG Mark
Das habe ich auch schon gefressen ;-) aber soooo ausführlich wie eben das AVRGCC Tutorial ist es leider nicht :-(
Hallo Tüddel, alles was Du wissen willst, findest Du im Datenblatt und in den Beispielen von Martin Thomas (http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/index.html) Sonst kannst Du ja immer noch im Furum fragen.
>Entwarnung fuer Errata Sheets LPC2119/01 und LPC2129/01 haben die CAN >Probleme behoben! Und bei LPC23xx gleich wieder neue eingebaut, CAN habe ich auf LPC23xx zwar noch nicht nutzen müssen, aber hoffentlich werden die Versionen die denn "bald" mal ausgeliefert werden den Fehler nicht mehr haben. >Evtl. sogar noch mit bestimmten Assembler Sequenzen >aber da fast jeder in "C" programmiert, laesst sich die Beschreibung >nicht so greifbar beschreiben wie es jeder gerne haette. Soweit ich sehe, nutzt RealView/Keil, GCC und inzwischen auch IAR das elf-Format (in versch. Versionen). Wenn man diese Fehler schon in ausgelieferten ICs hat, dann würde es NXP gut zu Gesicht stehen, eine Programm anzubieten, dass die elf-Datei einliest und falls entsprechende Sequenzen entdeckt werden, eine Warnung mit Adresse auszugeben. Dann wäre man zumindest sicher, dass man "sauberen" Maschinencode" hat und nicht ständig ein "vielleicht liegt's doch an der Hardware" im Hinterkopf. >3. Um maximale Geschwindigkeit zu erreichen muss der Code bei SAM7 ins >SRAM geladen werden, beim LPC2000 auch. Der Verlust an Performance wenn >aus dem Flash gearbeitet wird ist bei NXP ca. 5%, bei Atmel ca. 30% >jeweils bei der max. Clock Rate. D.h. ein LPC2000 ist vom Flash bei 60 >MHz ein klein wenig schneller als ein Atmel bei 55 MHz vom SRAM. >...Der groesste LPC Vorteil ist die Spitzenperformance aus dem Flash... Was kommt bei eine solchen Vergleich raus, wenn das MAM nur "partialy enabled ist", so wie im Errata zum LPC2368 empfohlen? >...dafür ist das DMA bei den LPC's recht mies (umständlich zu > konfigurieren, nur 2 channels und transfers gehen nur > in's/vom USB-RAM). Die "LPC's" gibt es eigentlich nicht mehr. Mit LPC23xx/24xx hat sich einiges getan, nicht nur in Hinsicht DMA (VIC, I2S ...). Aber neue Fehler gibt es auch, die Mitbewerber bieten allerdings auch keine perfekten Produkte. Core-Frequenz und Speicherzugriff ist nicht alles. Bei kleineren Benchmarks mit SD-Karte/FAT/kein Code im RAM, hat ein mit 48MHz getakteter SAM7 mit SPI-DMA gut mit einem LPC213x bei 60MHz/MAM und SPI FIFO mithalten können. Test mit LPC23xx und SPI-DMA steht noch aus. Wie immer: "kommt halt auf die Anwendung drauf an". >Naja, IAR ist für ein Bastler/Hobby ganz schön teuer! Die Kickstart-Version ist auf 32kB Code begrenzte (hat auch ein paar andere Einschränkgungen) aber kostet "nur" die Preisgabe der Kontaktdaten. Damit lässt sich schon vieles ausprobieren. EWARM-KS ist aber meines Wissens vollkommen frei verwendbar, also auch für kommerzielle Sachen. Habe bisher allerdings nur kurz damit "gespielt". (Ja, ich nutze GNU-Tools meist in Form meiner WinARM Sammlung und für die wenigen Cortex-M3-Spielereien das Packet von Codesourcery) >...es gibt übrigens noch eine uVision-variante (von keil) mit dem GCC > drin. ich glaube die war auch umsonst. ich weiss aber nicht, ob >damit das debuggen anständig funktioniert (ich glaube ja eher nicht). Keil bietet ein sehr veraltetes GCC-Packet für uVision zum download. Kein Wunder, dass die ehemals veröffentlichten Benchmarks auf viel Kritik stiessen. Man kann allerdings neuere GNU-Toolchains integrieren. Für die GNU Toolhchain aus WinARM gibt es entsprechende "Glue-Programme", diese sollten auch mit anderen z.B. codesoucery/Yagarto etc. funktionieren. Habe selbst nur kurz mit WinARM (was sonst ;-) ) ausprobiert. Auch bei Verwendung von GNU-Tools gilt für den uVision Debugger/Simulator eine Codegrößenbeschränkung (16kByte wenn richtig erinnert). Debuggen mit uVísion/ulink"1" funktionierte zumindest in ein paar oberflächlichen Tests auch bei mit GNU-tools erzeugten elf-Dateien problemlos. Vor allem der Simulator und die Anzeige von Speicherinhalten/Registern mit deren Bedeutung bei Simulation und JTAG-Debugging ist bei Keil schon recht schick. Falls die die Lizenz richtig interpretiere, darf man die Evaluierungsversion auch bei Verwendung von GNU-Tools nicht für kommerzielle Arbeiten nutzen. > Och, ich denke ich bleibe auch weiterhin beim GCC Im Hintergrund der Rowley-IDE ist eine GNU Toolchain (also "gcc") im Einsatz. Man zahlt nicht für den Compiler/Assembler sondern für die IDE inkl. Debugger, JTAG-Ansteuerung/Interface und deren selbstgemachte libc. Nichts was es nicht auf für wenig Geld/"umsonst" gäbe, aber bei Rowley besser vorgekaut. Ich habe mit dem Rowley Produkt allerdings noch nie wirklich gearbeitet. Nun denn, meine x* 0,02ct dazu, vielleicht ja für jemanden nützlich. Martin Thomas
@ Tueddel schau mal die Tutorials von Hitex an. Hier gibts ne Menge: http://www.hitex.de/lpc2000/con-lpc2000.html und ein tutorial bzw. zwei fuer die LPCs gibts hier: http://www.hitex.de/download.html?download/con_download_insiders-guides.html~content Zum Thema JTAG-Debugger, nicht der billigste aber der vielseitigste ist Segger's J-Link. Funktioniert mit GNU, auch unter Eclipse (Yagarto), mit IAR, mit Rowleys und auch mit Keil. Ist ausserdem der mit der schnellsten download Geschwindigkeit, beim Flashen ca. 10x schneller als die UART Loesung oder auch als andere Clones. Robert
> Core-Frequenz und Speicherzugriff ist nicht alles. > Bei kleineren Benchmarks mit SD-Karte/FAT/kein Code im RAM, hat ein mit > 48MHz getakteter SAM7 mit SPI-DMA gut mit einem LPC213x bei 60MHz/MAM > und SPI FIFO mithalten können. Test mit LPC23xx und SPI-DMA steht noch > aus. Wie immer: "kommt halt auf die Anwendung drauf an". ich habe selbiges erlebt. SAM7 und LPC2378, schreibzugriffe auf eine SD-karte im SPI mode. bei beiden ist der zugriff in etwa gleich schnell und beiden benutzten DMA (ca 4 sekunden für 1MB). der SAM7 ohne DMA war um etwa die hälfte langsamer (SPI-clock ~20Mhz), der LPC ohne DMA war genau so schnell wie mit DMA (SPI-clock ~10Mhz). aus irgendeinem grund konnte man die SPI clock des LPC nicht höher als 10Mhz einstellen, zudem kamen die besseren ausführungszeiten aus dem flash und die nötige kopieroperation vom USB-RAM, die dafür sorgten, dass das DMA beim LPC nichts brachte.
Ich hätte gernen noch einen Rechten Arm anstatt meinen Linken Arm. Irgendwie funktioniert der Rechte Arm besser. *duck und wech
@Peter was Du beschreibst war der Hauptgrund weshalb die LPC so lange keine DMA hatten. Die schnellere Abarbeitung aus dem Flash gleicht alle DMA Vorteile im Bezug auf Geschwindigkeit aus (selbst bei 10-20 Mbit/sec). Viele Kunden wollen nicht glauben, dass ein UART mit 115200 Baud sogut wie keine Belastung fuer die CPU darstellt und dafuer eine DMA wirklich reichlich wenig bringt. Trotzdem macht die DMA fuer Schnittstellen wie die SPI Sinn, nicht weil sie dadurch schneller wird, sondern weil die CPU dadurch mehr Rechenleistung fuer andere Dinge zur Verfuegung hat. Im uebrigen hat der 2378 eine parallele SD Schnittstelle, sollte ca. Faktor 4 bringen. Robert
So, ich habe nun das Board und den OpenOCD-USB Adapter von Olimex (http://www.olimex.com/dev/arm-usb-ocd.html). Von der mitgelieferten CD habe ich die Software installiert und den Treiber für den Adapter. Wenn ich das Peispielprogramm öffnen und über Run->external tools->OpenOCD auswähle, macht meine Platine nen Piip (das ist ja anscheinend noch ok), aber wenn ich auf den Bug klicke um den Code einzuspielen, dann bekomme ich einen Fehler (siehe Anhang) Auch mit Insight habe ich es probiert. Da bekomme ich eine "Memory access error" ... Könnt ihr mir da auch weiter helfen?
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.