Hallo, seit einigen Jahren mache ich Projekte mit PIC18 uCs, nun möchte ich gerne in die ARM M0/M0+ Ecke reinschnuppern und ggf. umsteigen. Welche IDEs, DevKits empfehlt ihr für einen Ein-/Umstieg. Bisher code ich in C. Danke für euere Tipps!
AppleII E. schrieb: > Welche ... DevKits empfehlt ihr für einen Ein-/Umstieg. Voellig abhangig von welche Hardware devices du denkst zu benoetigen. Sensoren (welchen) ? Motor (welchen) ? USB ? Low-power ? CAN-Bus ? Display ? Wireless ? U.s.w.
Moin, AppleII E. schrieb: > Welche IDEs, gcc, make, vim - klingt komisch, ist aber so. Kost' nix, macht keinen Aerger mit Lizenzkram, und wenn du von ARM auf Bein oder x86 oder risc-v oder sonstwohin umsteigen willst, ist's ganz simpel. > DevKits empfehlt ihr für einen Ein-/Umstieg. Welche, die du momentan tatsaechlich kaufen kannst, mit Chips drauf, die du momentan auch kaufen kannst? Gruss WK
von PIC18 nach SAMD wechseln macht man in MPLABX wohl recht einfach, oder ? Vielleicht noch Compiler nachkaufen ? >Welche DevKits empfehlt ihr ? die von Microchip
AppleII E. schrieb: > seit einigen Jahren mache ich Projekte mit PIC18 uCs, nun möchte ich > gerne in die ARM M0/M0+ Ecke reinschnuppern und ggf. umsteigen. Was versprichst Du Dir davon? Warum gerade M0 und nicht M3/M4/M7? Wenn Du mehr Leistung brauchst, wären PIC24, dsPIC33 und PIC32 die natürlichen Aufstiegspfade. Ein PICKIT3 hast Du wahrscheinlich schon. dsPIC33E liegt in Bereich eines M0, PIC32MZ geht leistungsmäßig in Richtung M4. IDE bleibt MPLABX, XC16 und XC32 musst Du nachinstallieren. fchk
STM32 wäre auch eine Möglichkeit http://stefanfrings.de/stm32/index.html Das Dev-Board dazu ist sogar lieferbar: https://www.amazon.de/-/en/STMicroelectronics-Nucleo-64-Development-Cortex-STM32L073RZT6/dp/B08Q492DTX https://www.reichelt.de/de/de/index.html?ACTION=446&LA=3&nbc=1&q=nucleo%20f0
AppleII E. schrieb: > seit einigen Jahren mache ich Projekte mit PIC18 uCs, nun möchte ich > gerne in die ARM M0/M0+ Ecke reinschnuppern und ggf. umsteigen. Umsteigen? Etwa so wie bei der Eisenbahn? Aus einem Zug raus und in einen anderen rein? Und der bisherige Zug ist dir dann egal? Wozu? Laß dein bisheriges Entwicklungszeugs für die PIC18 so wie es ist und benutze es für solche Projekte, denen es angemessen ist. Lade dir den Keil herunter und lies dich in die Manuals zu den Cortexen ein, die du zu benutzen gedenkst (und die es derzeit noch gibt). Wenn du dann konkrete Fragen hast, dann frage. Aber so etwas Algemeines wie "ich will umsteigen, welchen Zug empfehlt ihr mir?" ist z.B. mir zu unkonkret. Ach ja, nochwas: ARM M0 und so gibt es nicht, das ist auch zu schwammig formuliert. Du meinst sicher Cortex M0, hast aber nicht daran gedacht, daß es von ARM auch noch immer die ARM9 usw. gibt. Da sind ziemliche Unterschiede zu den Cortex-M. W.S.
ARM MO := schadstoffstark und leistungsarm => genau der richtige Controller fuer RPi0/Antuino LED-Blinker.
warum beim M0+ nicht gleich einen Raspberry Pi Pico mit RP2040 (auch ein M0+)nehmen Um da C zu programmieren nimmt man dann das RP2040 SDK Der Pico ist guenstig und doch schnell...kann man ohne Probleme auf 250Mhz overclocken (z.B. auch fuer Enulatoren)
Guido L. schrieb: > warum beim M0+ nicht gleich einen Raspberry Pi Pico mit RP2040 (auch ein > M0+)nehmen Viel zu speziell auf der einen oder zu "arduinohaft" auf der anderen Seite. Daß dort zwei M0+ Kerne verbaut sind, ist völlig schnuppe. Davon soll der Anwender nichts mitbekommen. Hauptsache man kann sich irgendwelche "libs" zusammenklicken. > Der Pico ist guenstig und doch schnell Hat aber beispielsweise ein sehr spezielles IO (PIO), keine vernünftigen Timer mit input-capture, einen 12 Bit ADC ohne spezifizierte Daten ... Wenn man damit umgehen und leben kann, ist es gut. Wenn man mal Erweiterungen braucht ist das Teil eine Sackgasse. Mein Vorschlag wäre irgendein STM32 Nucleo64-Board mit angekoppelten ST-Link für recht wenig Geld. Zur Zeit ist die verfügbare Auswahl zwar bescheiden, aber (hoffentlich) bald wieder eine große Anzahl mit unterschiedlicher Pinzahl und Peripherie verfügbar. Alternativ natürlich auch Controller SAMxyz, NXP, ...
Die ARM M0/M0+ namhafter Hersteller sind doch aktuell gar nicht lieferbar: STM32 LPC usw. Auch die Eval-Boards sind kaum lieferbar. Lieferbar sind die ATSAMD21 weil die keiner will :-) Auch die Arduino dafür sind lieferbar: https://www.mouser.de/ProductDetail/Adafruit/3727?qs=qpJ%252B%252B%252Bdg6p3QA%252Bz3VP9G7g%3D%3D Die meisten Hersteller haben kostenfrei Eclipse, gcc mit den passenden Makefiles, dann muss man nichts selbst machen. Debugger customized J-Link im Bereich 10-30 EUR Aber auch die Arduino IDE ist nicht so schlecht wie hier immer gesagt wird. Man muss ja nicht die Arduino Libraries nehmen, man kann auch alles selbst machen. Für den ATSAMD21 also statt analogRead() selbst die ADC Register auslesen.
Lothar schrieb: > Auch die Eval-Boards sind kaum lieferbar. Der TO braucht ja nur eins: https://www.mouser.de/ProductDetail/STMicroelectronics/NUCLEO-G071RB?qs=PqoDHHvF64%2FiIo1nQ3ZWtw%3D%3D
Lothar schrieb: > Aber auch die Arduino IDE ist nicht so schlecht wie hier immer gesagt > wird. Ich fürchte, man würde mich kündigen, wenn ich mit so einem Tool wertvolle Arbeitszeit vergeuden würde. Man pflügt den Acker ja nicht mit einer Ziege.
Die Frage ist, welche neuen Aufgaben willst Du mit dem ARM lösen und welche Probleme hast Du mit dem PIC18 gehabt. Zu beachten ist auch, die PIC18 laufen von 1,8..5,5V, die ARM brauchen dagegen immer eine stabilisierte Spannung. Die ARM haben viel mehr Funktionen, sind aber deshalb auch viel komplizierter zu programmieren. Da muß man sich erstmal lange durch die vielen Dokumente und Headerfiles wühlen, ehe man z.B. einen Portpin für die gewünschte Funktion richtig gesetzt hat. Wir benutzen z.B. die LPC4357 von NXP (Cortex M4/M0). Jeder Pin hat bis zu 8 Funktionen, die erstmal ausgewählt werden müssen. Aber nicht alle sind implementiert, z.B war ich ganz verdutzt, daß viele Pins keine universellen IOs sein können. Man muß also vor dem Schaltplan erstmal ganz genau überprüfen, welchen Pin man wofür verwenden kann. Die meiste Zeit benötigte das Lesen, Suchen und Probieren, der eigentliche Funktionscode war dagegen schnell geschrieben. Ein Kollege hatte mal 14 Tage lang einen Fehler gesucht. Es war eine falsche Funktionsauswahl, er hatte den Pin als TXD statt GPIO konfiguriert. Erschwerend ist, daß da kein System hintersteckt. Mal ist GPIO Funktion 0, mal Funktion 4 und mal nicht vorhanden. Falsche Defines in den Headerfiles habe ich auch gefunden. Auch fehlerhaften Beispielcode, der sich bei dem LPC-Typ des Autors nicht auswirkte, bei meinem aber schon. Die LPC von NXP sind also alles andere als leicht zu programmieren. Und ja, Beschaffungsprobleme haben wir jetzt auch. Wir benutzen den IAR mit Netzwerklizenz. Nach Benutzung ist die Lizenz für 30min gesperrt, d.h. sie kann nicht sofort ein anderer benutzen.
:
Bearbeitet durch User
Peter D. schrieb: > Ein Kollege > hatte mal 14 Tage lang einen Fehler gesucht. Das ist ja schrecklich! ARM sollte man daher nicht nehmen? Es wird ja keiner gezungen, den Sandkasten zu verlassen. Wenn ich zum Beispiel STM32H7xx verwende, nutze ich maximal 5 % der Eigenschaften. Was ich nicht brauche, lasse ich liegen. Und dennoch würden nicht 100 x ATmega328 die gleiche Leistung bringen, aber viel mehr Leistung verbrauchen ;-) > Wir benutzen den IAR mit Netzwerklizenz. Zum Kennenlernen der STM32 würde ich trotz diverser "Geschichten" ebenfalls die IAR EWARM IDE empfehlen. Mit dem Debugger kann man sehr gut die Interna zur Laufzeit ansehen/ändern. Die Codebeschränkung auf 32 KB bei der Demoversion, ist ersteinmal keine Einschränkung. Wenn die Programme größer werden, kann man sich eine passende IDE aussuchen.
m.n. schrieb: > Das ist ja schrecklich! ARM sollte man daher nicht nehmen? Das hat er nicht geschrieben. Man sollte sich die Komplexität aber nicht ohne Notwendigkeit antun - es sei denn man hat sportlichen Spaß an der Herausforderung.
STM32 Demo Board (weil gibts überall "nachgeschmissen"), mit ST-Link on board MDK Community: https://www2.keil.com/mdk5/editions/community
Ich würde auf arduino umsatteln. Dann kommst du erstmal von der unsäglichen pic-umgebung weg und lernst etwas zukunftsorientiertes. Prozessoren sind neben dem obsolaten 328p auch esp32 oder stm32.
:
Bearbeitet durch User
m.n. schrieb: > Und dennoch > würden nicht 100 x ATmega328 die gleiche Leistung bringen, aber viel > mehr Leistung verbrauchen Das bestreite ich. Stefan ⛄ F. schrieb: > Man sollte sich die Komplexität aber nicht > ohne Notwendigkeit antun Der springende Punkt.
m.n. schrieb: > Das ist ja schrecklich! ARM sollte man daher nicht nehmen? Wer hat das behauptet? Bei unerklärlichen Fehlern sollte man aber jeden Initialisierungsschritt nochmal gründlich überprüfen. Das SGPIO zu verwenden, ist schon recht komplex. Es gibt kaum Beispiele dazu bzw. die Beispiele treffen oft nicht den gewünschten Anwendungsfall.
Stefan ⛄ F. schrieb: > m.n. schrieb: >> Das ist ja schrecklich! ARM sollte man daher nicht nehmen? > > Das hat er nicht geschrieben. Man sollte sich die Komplexität aber nicht > ohne Notwendigkeit antun - es sei denn man hat sportlichen Spaß an der > Herausforderung. MannFrauKind, ist es denn so schwierig einen einfachen Text zu verstehen? Der TO will ARM Cortex-M0+ antesten, also soll er das auch machen. Diese blöde Angstmacherei geht immer wieder auf den Kecks! Peter D. schrieb: > m.n. schrieb: >> Das ist ja schrecklich! ARM sollte man daher nicht nehmen? > > Wer hat das behauptet? Funktion des Fragezeichens nicht verstanden? Der Kern Deiner Schwafelei ist doch, daß so ein ARM M0 richtig gefährlich ist, daß man damit in Teufels Küche kommen kann, wenn man sich darauf einläßt. IO-Pin mit mehreren Funktionen? Ganz schwierig! Man muß sogar Dokumentation dazu lesen! Wie kann man sich das nur antun? Beo B. schrieb: > Ich würde auf arduino umsatteln. Dann kommst du erstmal von der > unsäglichen pic-umgebung weg und lernst etwas zukunftsorientiertes. > Prozessoren sind neben dem obsolaten 328p auch esp32 oder stm32. Mit dem Arduino-Zeugs wird doch der eigentliche Controller zugekleistert und weichgespült. Heute könnte Freitag sein.
m.n. schrieb: > Diese blöde Angstmacherei geht immer wieder auf den Kecks! Hä? Ich habe ihm sogar Boards und ein Tutorial empfohlen.
Beo B. schrieb: > Ich würde auf arduino umsatteln. Dann kommst du erstmal von der > unsäglichen pic-umgebung weg Vom Regen in die Traufe :-( Sorry, aber wenn ich schon auf ARM programmiere, dann will ich wenigstens anständige Debugger haben. Und Arduino als Entwicklungsumgebung zu sehen, ist schon sehr positiv ausgedrückt. Bei mir sind es LPC mit MCUxpresso (angepasstes Eclipse, gibt es frei von NXP) mit Black Magic Probe als Debugger. Und ja, als Ersatz für 8-Bitter würde ich die ARMs auch nicht sehen. Wo ein 8-Bitter reicht, kommt der auch rein.
m.n. schrieb: > Heute könnte Freitag sein. Heute IST Freitag. Dieser Thread entwickelt sich wie alle bisherigen mit ähnlichen Fragestellungen: Jemand fragt "ich will mich mit XYZ beschäftigen, welche IDE empfehlt ihr mir?" - und alle anderen rufen "nimm ABC, den benutze ich auch und er ist besser als geschnitten Brot". Da steigert sich sogar der WK zu "gcc, make, vim" und sobald das 2x insgesamt geschrieben dasteht, wird sich voraussichtlich die Diskussion über diese 3 Dinge erhitzen. Dabei ist es alles doch so einfach: Wenn jemand nicht vor einem dringenden Problem steht, für das er eine Lösung zeitnah suchen muß, dann hat er auch die Zeit, sich aufzuraffen und eigenständig sich in eine für ihn neue Thematik einzulesen. Und Quelltexte kann man mit fast jedem Editor schreiben und bearbeiten. W.S.
m.n. schrieb: > Peter D. schrieb: >> Ein Kollege >> hatte mal 14 Tage lang einen Fehler gesucht. > > Das ist ja schrecklich! ARM sollte man daher nicht nehmen? Ja, ganz furrrrchtbar! Aber mal im Ernst: Wer solche Fragen stellt wie der TO, der sollte lieber nicht sogleich versuchen, etwas zu reiten, bevor er sich nicht angesehen hat, was er da besteigen will. Und wer 14 Tage lang einen Fehler sucht, der hat dazu offenbar die Zeit. Vielleicht hat das Verstehen bei dem auch bloß so lange gedauert? Das Verstehen scheint mir auch das größte Problem zu sein, da ist die Qualität von Dokumentationen auch weitaus wichtiger als teures Debugger-Zeugs. Aber wenn man das hier vertieft, driftet die Diskussion schnell in "wer hat den dicksten SUV?". W.S.
Sowas z.B. https://www.digikey.at/de/products/detail/silicon-labs/EFM32ZG-STK3200/4379911 Oder besser mit Cortex M3/M4 - https://www.digikey.at/de/products/detail/silicon-labs/SLSTK3401A/5729924 Wenn du es beruflich nutzen willst, dann kannst auch direkt beim Vertrieb nachfragen. Allerdings war der Einstieg in die EFM32 früher leichter als man noch die alten EM Tools nutzte. Entweder mit dem Silabs Studio (gratis soweit ich weiß) oder Rowley CrossStudio (kostet). Ich meine Segger hat auch eine IDE gratis für Private (Spezialversion von Rowley?). Keil und vor allem IAR hab ich vor langer Zeit ausgeschieden. Ob die aktuell viel aufgeholt haben, bezweifle ich. Hab's aber schon seit Jahren nicht mehr verglichen.
Stefan ⛄ F. schrieb: > mit so einem Tool wertvolle Arbeitszeit vergeuden Die Arduino IDE ist in der Industrie im Einsatz. Nicht nur für Teststände, auch für Produkte: https://www.controllino.com/ https://www.controllino.com/wp-content/uploads/2020/06/Controllino-Customers-1536x755.png Raspberry Pi auch: https://revolutionpi.de/ Andi B. schrieb: > Entweder mit dem Silabs Studio (gratis soweit ich weiß) Für die ARM EFM32 und die 8051 EFM8. Die EFM8 sind zudem lieferbar und haben auch DAC/ADC usw. J-Link für 8051. Kostenfreie Keil Lizenz. Ist aber eigentlich nur Eclipse mit passenden Makefiles. https://www.silabs.com/developers/simplicity-studio
Andreas B. schrieb: > Und ja, als Ersatz für 8-Bitter würde ich die ARMs auch nicht sehen. Wo > ein 8-Bitter reicht, kommt der auch rein. Unter normalen Umständen würde ich dir vollkomen Recht geben. Nur sind die Umstände derzeit halt nicht normal. Viele olle und auch moderne 8Bitter sind derzeit schlicht nicht in Stückzahlen verfügbar oder nur zu horrenden Preisen aus der Brooker-Szene (sprich: der Mafia der Chips). Da muss man dann auch mal Wege beschreiten, die nicht technisch sinnvoll sind...
Ein PIC32CM könnte interessant sein. Wenn man sowieso mit MPLAB-X vertraut ist, müsste man wenigstens nicht mit einer neuen IDE anfangen (auch wenn ich persönlich das in dem Fall für einen Vorteil halten würde sich von MPLAB-X zu verabschieden). https://www.microchip.com/en-us/products/microcontrollers-and-microprocessors/32-bit-mcus/pic32-32-bit-mcus/pic32cm-mc Die Dinger sind im Grunde genommen umgelabelte ATSAMC20, zumindest habe ich noch keinen echten Unterschied gefunden. Das sind Cortex M0+ mit 48MHz die mit 5V laufen. Gegenüber z.B. ATSAMC21 oder auch ATSAMD51 / ATSAME51 vom gleichen Hersteller sind die PIC32CM sogar lieferbar: https://www.mouser.de/c/semiconductors/embedded-processors-controllers/microcontrollers-mcu/arm-microcontrollers-mcu/?q=PIC32CM&instock=y Und es gibt ein kleines EVal-Board mit integriertem Debugger: https://www.mouser.de/ProductDetail/Microchip-Technology/EV10N93A?qs=pUKx8fyJudBHc3LP%2FASorA%3D%3D
c-hater schrieb: > Da muss man dann auch mal Wege beschreiten, die nicht technisch sinnvoll > sind... Dem muss man leider zustimmen. Ich bin gerade dabei, von PIC18 auf PIC24 umzusteigen, weil es PIC18 mit den benötigten Funktionen, Gehäusen und 5V quasi nicht gibt. Die PIC24 liegen bei Reichelt rum, sind hoffentlich auch wirklich lieferbar. Ich hoffe nur, dass der Umstieg nicht zu komplex wird. Ein Kollege meinte zwar, wenn man einen PIC versteht, bekommt man die anderen auch zum laufen. Mal schauen... @ TO: Warum ist der Umstieg gewollt? Leistung, Verfügbarkeit, Interesse an neuer Plattform?
Erst mal Danke für die rege Diskussion und Antworten. Zur Klarstellung: Ich komme mit den PICs gut zurecht. Ich möchte rein aus Interesse und eigene Weiterbildung mich auch mal mit dem ARMs beschäftigen. Ein Punkt ist zudem, dass ich als zweiten Rechner vor vielen Jahren mal einen Archimedes hatte (leider verkauft). Zudem reizt mich den ARM als Softcore in FPGAs zu integrieren. A.
AppleII E. schrieb: > vor vielen Jahren mal einen Archimedes hatte Using RISC OS on the Raspberry Pi https://www.riscosopen.org/wiki/documentation/show/Using%20RISC%20OS%20on%20the%20Raspberry%20Pi
c-hater schrieb: > Viele olle und auch moderne > 8Bitter sind derzeit schlicht nicht in Stückzahlen verfügbar Stimmt, aber das gilt erst recht fuer die ARMs. Einigen wir uns darauf, dass man zur Zeit das nimmt was verfuegbar ist. ;-) AppleII E. schrieb: > Ich möchte rein > aus Interesse und eigene Weiterbildung mich auch mal mit dem ARMs > beschäftigen. Das macht Sinn. Aber wenn Du da nach Toolchains fragst, wirst Du soviele Antworten bekommen wie es Toolchains gibt. Daher: Greif Dir etwas das Dir zusagt und leg los.
:
Bearbeitet durch User
Ich machte vor 12 Jahren gute Erfahrungen mit CoIde V1.75 und Atollic Studio. Der uC damals waren STM32F103 und 407. Der GDB Debugger war in beiden Fällen sehr brauchbar. Aus Atollic Studio wurde dann später CubeIDE.
AppleII E. schrieb: > Zur Klarstellung: Ich komme mit den PICs gut zurecht. Das dachte ich vor ca. 10 Jahren auch. Also PIC24, die 16er (8 Bitter) waren mir schon lange zu klein. > Ich möchte rein > aus Interesse und eigene Weiterbildung mich auch mal mit dem ARMs > beschäftigen. Gute Entscheidung. Wenn man die Einstiegshürden genommen hat und nicht nur den komplexeren Core sondern die üblicherweise meist viel mächtigere Peripherie mal gelernt hat zu nutzen, dann mag man die kleinen 8 und 16 Bit Spielzeuge mit beschränkter Debugfunktionalität nicht mehr angreifen.
AppleII E. schrieb: > Zudem reizt > mich den ARM als Softcore in FPGAs zu integrieren. Ähem... was ist für dich der ARM? Nochmal: Die Firma ARM hat im Verlaufe von vielen Jahren einige Prozessorarchitekturen erdacht. Vor etwa 15 Jahren war (auch hier) die Architektur ARM7TDMI gebräuchlich, daneben immer noch ARM9, von Intel der StrongARM und derzeit ist hier mit den Cortex-M eine der Cortex-Architekturen die aktuelle Mode. Da wirst du dir vor dem Gedanken, sowas in einem FPGA zu machen, erstmal ein Küken aus dem Nest heraussuchen müssen. Neenbei gesagt: Ich erinnere mich daran, daß vor geraumer Zeit mal ein Japaner so etwas gemacht hatte, aber das mündete wohl in einem Hickhack mit ARM. Aber das Kennenlernen dieser Controller ist schon OK, es besteht aber nicht darin, sich irgend eine IDE oder eine bestimmte Toolchain auszusuchen. Mein Rat nochmal: Lies. Und zwar die Manuals zu den Chips. Da wirst du je nach Firma Unterschiede aller Art feststellen und dich von manchen Produkten abwenden, nicht weil sie per se schlecht sind, sondern weil die zugehörigen Manuals dir überhaupt nicht zusagen. Andererseits wirst du feststellen, daß die Manuals zwar gut sind, aber die Chips nicht. Na und so weiter. Aber das kann dir keiner abnehmen, das mußt du selber erleben. W.S.
Andreas B. schrieb: > Stimmt, aber das gilt erst recht fuer die ARMs. Nicht für alle (thanks god). Und da es viel leichter ist, was in Richtung leistungsfähigerer Hardware zu migrieren als in umgekehrter Richtung, sind die ARMs schon durchaus ein attraktives Ziel für Sachen, die mal auf 8Bittern liefen... Technisch völlig sinnlos, aber wenn nur der Wechsel die weitere Auslieferung von Produkten ermöglicht, keine schlechte Wahl...
Andreas B.: >Sorry, aber wenn ich schon auf ARM programmiere, dann will ich >wenigstens anständige Debugger haben. Und Arduino als >Entwicklungsumgebung zu sehen, ist schon sehr positiv ausgedrückt. Ich habe gerade mal ein wenig mit VScode + PlatformIO (STM32Duino + STlink) herum probiert: Ein STM32F103 BluePill Board lies sich auf Anhieb debuggen. Beim STM32F411 BlackPill musste ich in der "platform.ini" den Eintrag "debug_tool = stlink" von Hand machen, dann ging's auch.
W.S. (Gast) >Da wirst du dir vor dem Gedanken, sowas in einem FPGA zu machen, erstmal >ein Küken aus dem Nest heraussuchen müssen. Neenbei gesagt: Ich erinnere >mich daran, daß vor geraumer Zeit mal ein Japaner so etwas gemacht >hatte, aber das mündete wohl in einem Hickhack mit ARM. Im FPGA würde ich gleich auf RISC-V gehen. Da gibt's mittlerweile Haufenweise Designs und man kann alles selber anpassen.
Thread beobachten
Seitenaufteilung abschalten
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.