Hallo zusammen Ich bin auf der Suche nach einer Möglichkeit ein Programm (in C) für den SAB80C517A zu compilieren und zu linken. Hab mir das Ding von Keil heruntergeladen nur leider ist das Projekt zu gross. Die Code Beschränkung wird aktiv. :-( Auf der Suche nach einer Alternativen bin ich auf Ride gestossen aber die haben ja auch eine Code Beschränkung. Hab auch den SDCC gefunden. Nur steht da nirgends explizit das der SAB80C517a unterstützt wird. Kann mir das einer sagen? Wenn ja, wäre ich froh um ein Beispiel mit den richtigen Argumenten für den SAB80C517a. Oder gibt es eine andere Alternative? Vielen Dank und eine schönen Abend noch
Markus schrieb: > Hab auch den SDCC gefunden. Nur steht da nirgends explizit das der > SAB80C517a unterstützt wird. Man muß vermutlich eine passende header/include-Datei einbinden. Der 517 ist ein "normaler" 8051 mit einigen anderen SFRs. Diese muß man noch deklarieren. > Oder gibt es eine andere Alternative? Wickenhäuser. Kostet, aber nicht viel.
Markus schrieb: > Hab auch den SDCC gefunden. Nur steht da nirgends explizit das der > SAB80C517a unterstützt wird. Mit SDCC und 80C517A arbeite ich gelegentlich ebenfalls. Leider unterstützt der SDCC-Compiler den 80C517A nicht. Es gibt zwar ein Registerfile zum Einbinden, aber keine Libraries für die eingebauten Features (multiple DPTR, MDU, usw.) im µC. Dann läuft er ganz normal wie ein Standard-8051. Da hat man natürlich was gewonnen!!! Ich wollte den SDCC schon mal auf 80C517A aufpeppen, aber das ist eine Stange Arbeit. So kann ich dann z.B. die schöne schnelle MDU zum Rechnen gar nicht verwenden. Weil der 80C517 aber etwas alt ist, werde ich mir die Aufpepparbeit des Compilers wahrscheinlich nicht mehr antun. Die Keil-Vollversion kann sicher alles, aber, haste mal ne Mark? ;-)
Raisonance RIDE 7 gönnt einem in der freien Version immerhin 8kByte (wie Wickenhäuser). Die alte RIDE 6 lag noch bei 4kByte. Ohne die Verwendung von Float-Berechnungen kommt man mit 8kByte sehr weit...
Bernhard Spitzer schrieb: > Ohne die Verwendung von Float-Berechnungen kommt man mit 8kByte sehr > weit... Im Augenblick komme ich mit dem 80C517A und SDCC auch noch zurecht. Aber die Float-Berechnungen sind doch das besonders interessante i-Tüpfelchen an diesem µC, weil er eine auf Float-Arithmetik optimierte 32-bit-Hardware-MDU hat, die um ein bis zwei Zehnerpotenzen schneller ist, als Standard-8051-Software. Dafür müßte man selbst in Eigenregie die Mathe-Libraries anpassen, und das ist Arbeit. Keil hat das eben fertig drinne. Dieser µC war besonders für schnelle Regelalgorithmen mit vielen Berechnungen vorgesehen, auch wenn es nur ein 8-Bitter ist.
Bei RIDE steht bei den Projekteinstellungen zum 80517A: Arithmetic Unit... Bleibt zu hoffen, dass der die dann auch korrekt zu nutzen weiss. Ich komme bei meinen Projekten meist ohne Float aus. Wenn es Kommazahlen sein sollen, dann nehme ich z.B. einen sigend int für Millivolt (ergibt dann einen Wertebereich von -32V...+32V) und wandle (wenn überhaupt) erst bei der Displayausgabe in Dezimalzahlen um. printf() bleibt auch wesentlich schlanker, wenn man da keine Float-Zahlen reinpackt.
> Keil hat das eben fertig drinne.
Und produziert in der Version 9.X immer noch haarsträubende Compilerbugs
bei harmlosen Code. Man könnte fast meinen, nicht nur die CPU selbst ist
aus den 70ern. Aber mit den dummen Embedded-Entwicklern kann man's ja
machen...
>> Keil hat das eben fertig drinne. > Und produziert in der Version 9.X immer noch haarsträubende Compilerbugs > bei harmlosen Code. Beweise? Ralf
Mach zB. mal eine 32Bit-Variable und schiebe Einzelbits durch bzw. setze bestimmte anhand eines Zustandes (x|=1<<n oder so). Was man halt zB. beim IR-Dekodieren braucht. Der Code ist vom AVR (avr-gcc) übernommen und ging da wunderbar. Mit Keil kamen da im wesentlichen 0en raus, egal, was reingeschoben wurde. Umändern auf 4 Byte-Variablen mit if-Unterscheidung ging dann. Aber dann brauche ich eigentlich keinen Compiler, wenn ich eh wieder alles von Hand stricken muss. Gab auch noch einige andere Absonderlichkeiten, die durch hin- und herschieben von Code auf einmal weg waren. Der Rest der 8051-Umgebung ist auch ziemlicher Schrott und in den 80ern stehengeblieben. Linkerskript? Wozu, wenn man die 100 Section-Parameter auch in der Kommandozeile angeben kann bzw. muss... Dass man dafür noch soviel Geld ausgeben muss, grenzt schon an übelste Abzocke. Leider hat sich noch keiner erbarmt und einen .LIB-Konverter nach irgendwas geschrieben. Aber wenn man nur eine Keil-.LIB von einem SoC-Hersteller bekommt, bleibt einem nichts anderes übrig, als den Dreck zu kaufen. Ja, ich bin etwas ungehalten über diese sogenannte "Industriequalität". Da hat ja der sdcc noch weniger Bugs.
@Georg: > Mach zB. mal eine 32Bit-Variable und schiebe Einzelbits durch bzw. setze > bestimmte anhand eines Zustandes (x|=1<<n oder so). Was man halt zB. > beim IR-Dekodieren braucht. Ich hab bisher nur 16/32-Werte mit 0x01 verodert und dann geschoben, war immer zufrieden damit. Das von dir gezeigte wäre wie du auch sagt das gezielte Bitsetzen, das müsst ich mir mal angucken. Poste mal den fehlerhaften Code. > Der Code ist vom AVR (avr-gcc) übernommen und ging da wunderbar. Mit Keil > kamen da im wesentlichen 0en raus, egal, was reingeschoben wurde. Umändern > auf 4 Byte-Variablen mit if-Unterscheidung ging dann. Aber dann brauche > ich eigentlich keinen Compiler, wenn ich eh wieder alles von Hand stricken > muss. Gab auch noch einige andere Absonderlichkeiten, die durch hin- und > herschieben von Code auf einmal weg waren. Hmmm... Deckt sich absolut nicht mit meinen Erfahrungen. > Der Rest der 8051-Umgebung ist auch ziemlicher Schrott und in den 80ern > stehengeblieben. Linkerskript? Wozu, wenn man die 100 Section-Parameter > auch in der Kommandozeile angeben kann bzw. muss... oO Sämtliche Einstellungen hab ich entweder über #pragma gedeckelt bekommen oder konnte sie in den Projekteinstellungen eingeben. Meinst du mit "Kommandozeile" die Projekteinstellungen? Von Linker-Scripten halte ich nichts - das liegt aber daran, dass ich nicht weiss, was man da alles einstellen kann und dass ich bisher zumindest für den GCC (Cortex-Mx) auch keine gescheiten Beschreibungen für Linkerscripte gefunden hab. WENN ich LS verstehen würde, dann würd ich sie auch intensiv nutzen :) > Dass man dafür noch soviel Geld ausgeben muss, grenzt schon an übelste > Abzocke. Dann zeig mir einen C-Compiler für 8052 bzw. Cortex-Mx, der es ermöglicht SPI-, I2C- oder welche Schnittstellen auch immer in den Memory-Bereich zu mappen, und das sogar über mehrere Pages, sodass sich sogar ein I2C-EEPROM wie ne ganz normale Variable ansprechen lässt. > Ja, ich bin etwas ungehalten über diese sogenannte "Industriequalität". Kann ich wie gesagt nicht nachvollziehen. > Da hat ja der sdcc noch weniger Bugs. Dafür ne beknackte Laufzeit. Ich hab ein C51-Programm mal auf den SDCC umgebaut - schnarch langsam. Keine Ahnung, ob ich etwas falsch gemacht habe, es lief halt nicht zufrieden stellend - und ich hab beim Schreiben des C-Codes m.E. dafür gesorgt dass es ein Compiler einfach hat. Ralf
Ralf schrieb: > @Georg: > Poste mal den > fehlerhaften Code. Ja, den würde ich auch gerne mal sehen. Ich setze den C51 seit 1995 ein und haben keine Bugs bemerkt. Float setze ich nur für den langsamen Menschen ein (Zahlenein-, Ausgabe), daher hat die Rechenzeit nie gestört. Den 80C517 habe ich noch nie benutzt, externer Flash ist mir zu aufwendig. Infineon hat seine 8051 erst viel zu spät auf Flash umgestellt, da lohnt sich kein Umstieg mehr. Peter
Ralf schrieb: > Dafür ne beknackte Laufzeit. Ich hab ein C51-Programm mal auf den SDCC > umgebaut - schnarch langsam. Also, ich fand den SDCC da reichlich brauchbar, und schaue auch sehr oft ins Assembler-Listing, was er aus C-Code macht, es gibt da keinerlei Beanstandung. Zeitkritische Dinge und Echtzeitanforderungen löst man ja auch per Interrupt. Wo ich bemerkte, daß es mal schnarchlangsam werden kann, das ist beispielsweise, wenn man generell für alles und jedes das Speichermodell "large" wählt. Besonders beim Kopieren und Verschieben größerer Datenblöcke braucht es da spürbar Zeit. Das Speichermodell kann man außer global sogar für jede einzelne Variable auswählen, ob man small oder large möchte. Damit kam ich prima zurecht. Bernhard Spitzer schrieb: > Ich komme bei meinen Projekten meist ohne Float aus. Wenn es Kommazahlen > sein sollen, dann nehme ich z.B. einen sigend int für Millivolt (ergibt > dann einen Wertebereich von -32V...+32V) und wandle (wenn überhaupt) > erst bei der Displayausgabe in Dezimalzahlen um. printf() bleibt auch > wesentlich schlanker, wenn man da keine Float-Zahlen reinpackt. Bisher kam ich auch gut so zurecht, die meisten Anwendungen schaffen es ohne float. Printf() verwende ich nie, und für z.B. Zahlenumwandlungen BIN-BCD und einige weitere Arithmetik habe ich aus der Assemblerzeit noch gute schnelle Assemblerroutinen, sogar skalierbar, die ich mit einbinde. So ein Assemblercode ist erheblich schneller und optimierter, als wenn man das in C direkt umrechnet. Warum sollte ich diese weg werfen? Auch große FIFOs für die serielle Kommunikation machte ich mir auf diese Art, viel schneller als in C. Jedoch schaute ich sie aus C-Code ab. Allerdings kann man solche Spielereien im Beruf kaum bewältigen, da wird man eines Tages gesteinigt: Das ist was fürs Hobby, immer sehr zeitaufwändig. Im Job nimmt man da lieber einen schnelleren µC. Aus diesem Grunde habe ich die 80C517A-Boards auch noch, es macht mir da immer Spaß, noch was zu optimieren. Gereizt hat mich diese MDU schon lange, aber es ist nichts eilig, weil bei mir eben nur Hobby. Vielleicht läßt sie sich ja auch noch unkompliziert in die Compiler-Libraries einfügen. Mit den Datapointern versuchte ich sowas schon mal in der Funktion memcpy(), da ist es gar nicht kompliziert. Ein zusätzlicher Datapointer beschleunigt bspw. einen Kopiervorgang erheblich. Der SDCC hat ansonsten eine ganze Menge Optionen und Einstellungen. Damit kann man sich auch mal eine Weile beschäftigen. Ich komme inzwischen sehr gut damit klar, mir fallen im Augenblick keine offenen Wünsche ein.
@Wilhelm: >> Dafür ne beknackte Laufzeit. Ich hab ein C51-Programm mal auf den SDCC >> umgebaut - schnarch langsam. > Also, ich fand den SDCC da reichlich brauchbar, und schaue auch sehr oft > ins Assembler-Listing, was er aus C-Code macht, es gibt da keinerlei > Beanstandung. Keine Frage, das direkte Nur-Lauffähig-Umschreiben wird sich sicherlich drauf ausgewirkt haben, genauso wie die Tatsache, dass ich ansonsten keinerlei Compilereinstellungen vorgenommen habe. > Der SDCC hat ansonsten eine ganze Menge Optionen und Einstellungen. Fragt sich, an welchen Schrauben man da hätte drehen können, dann wär ich vielleicht auch beim SDCC geblieben :) Eine Frage nebenbei: Du hattest mal in einem anderen Beitrag erwähnt, dass du den originalen Intel-Assembler in der "neuesten" Version von 1992(?) hast, plus die entsprechenden Handbücher. Ich hatte dir dazu eine PN geschrieben, die kam wohl nicht an, daher hier nochmal die Frage: Kannst du den Assembler bzw. zumindest die Handbücher zur Verfügung stellen? Ralf
So, nochmal geschaut, der Originalcode ist
uint32_t xir_data_tmp;
uint8_t last_bit;
... und in der IR-ISR dann:
if (xir_state!=old_xir_state) // 0-23
xir_data_tmp=(xir_data_tmp<<1)|last_bit;
Simpel und gut abgehangen. Geht im AVR seit 2004 ;)
Hr. Keil war anderer Meinung. Extra für ihn sieht die Stelle jetzt so
aus:
uint8_t xdata xir_data_tmp[3];
if (xir_state!=old_xir_state) {
uint8_t ll=23-xir_state;
uint8_t llx=ll>>3;
if ((llx==0 || llx==1 || llx==2)) {
xir_data_tmp[llx]=(xir_data_tmp[llx]<<1)|last_bit;
}
}
Keine Ahnung, ob es da noch das Drumherum der restlichen ISR braucht, um
den Fehler zu provozieren. Da der 8051 so tief im SoC-System ist, dass
die einzige Debugmöglichkeit dieselbe UART ist, über die auch seine
sonstigenLebenszeichen kommen, war es etwas fummelig, die Stelle zu
finden, ab der es nicht mehr ging. Und das war übrigens die aktuelle
Version (irgendwann März/April).
> Dann zeig mir einen C-Compiler für 8052 bzw. Cortex-Mx, der es
> ermöglicht SPI-, I2C- oder welche Schnittstellen auch immer in den
> Memory-Bereich zu mappen, und das sogar über mehrere Pages, sodass sich
> sogar ein I2C-EEPROM wie ne ganz normale Variable ansprechen lässt.
Mag ja alles sein. Aber wenn der Compiler so triviale wie oben nicht
schafft, dann traue ich dem ganzen Rest auch nicht mehr. Schau doch mal
die korrigierten Errata der 9er-Versionen an. Das ist doch gruselig:
"Corrected: Common sub-expression elimination can deliver incorrect
values when array pointers are used. "
"Corrected: Wrong code with pointer arithmetic and conversions to long."
"Corrected: explicit cast to unsigned char was ignored with complex
address arithmetic."
"Corrected: when using conditional operators (? :) in complex parameter
lists, there is a potential for unbalanced PUSH / POP instructions. This
typically creates a application program crash at the function call."
"
Und der Brüller:
"Corrected: constant folding of two negative array index values. For
example:
i = arr[i-1-5]; // incorrect in C51 V8: arr[i-4] instead of arr[i-6]"
Ist ja schön, dass sie das korrigiert haben, aber das waren Bugfixes
nicht von 198x, sondern 2009-2012. Wir reden hier nicht von C++ mit
Templates und so Abstrusitäten, sondern von einem Plain-C-Compiler. Wer
weiss, was da noch alles begraben ist.
Ralf schrieb: > Ich hatte dir dazu > eine PN geschrieben, die kam wohl nicht an, daher hier nochmal die > Frage: Kannst du den Assembler bzw. zumindest die Handbücher zur > Verfügung stellen? Doch, die PN kam sehr wohl an. Aber es kommt vor, daß ich dann an PN unter gehe, mir alles über den Kopf wächst, wenn öfter Leute über PN nach was fragen. Es überfordert mich dann einfach, und ist nicht persönlich. Normalerweise ist es nicht mein Stil, nicht zu antworten. Ich bin dann bis zur Halskrause voll gestopft auch mit anderen Dingen außerhalb des Themas. Nimm es mir nicht übel. Ich finde, daß man sowas auch hier im Forum ohne PN diskutieren kann, und dies absolut keineswegs peinlich ist. Denn ich befürchte, daß manch einem hier im öffentlichen Raum was peinlich ist. Das muß man ein wenig abstellen, sonst wäre ich schon längst daran gestorben. Ich würde dir den Assembler sofort zur Verfügung stellen, aber ich habe Angst vor Abmahnungen, mache nichts illegales. Der hat eine Lizenz und Copyright. Das Handbuch habe ich auch nur in Papierform, und im Buchhandel gekauft. Der ASM51, wie ich ihn habe, wird sich heute in ähnlicher Form sogar völlig gleich oder mit 1-2 unbedeutenden Detailunterschieden garantiert irgendwo zum kostenlosen Download finden. Also, Ralf, ich beantworte eine Frage lieber hier im Forum, wo alle was davon haben, und wenn ich eine Antwort weiß. Einen Server habe ich leider auch nicht, sonst hätte ich dir da drauf einen Download-Link über PN gepostet. Ich wäre aber behilflich, das Assembler-Paket im Internet mit zu suchen, und zu schauen, ob es das selbe ist. Das ist heute nach 25 Jahren kaum noch gebraucht, und deswegen bestimmt irgendwo frei erhältlich ohne Copyright. Auf meinem sind eben nur Rechtshinweise, die ich nicht umgehe. Bei einem Buchverlag fragte ich dieses Jahr, ob ich mal einen Ausschnitt für eine Forendiskussion fotografieren dürfte. Röhrenschaltung. Deren Antwort war: Nein. Der Artikel war von 1954, und man möchte den in Zukunft weiter verwerten.
Wilhelm Ferkes (ferkes-willem) schrieb: > Bei einem Buchverlag fragte ich dieses Jahr, ob ich mal einen Ausschnitt > für eine Forendiskussion fotografieren dürfte. Röhrenschaltung. Deren > Antwort war: Nein. Der Artikel war von 1954, und man möchte den in > Zukunft weiter verwerten. Das war dann die 0815-Standardantwort, die ich von solchen Heinis auch erwarten würde. Da hättest du noch mal nachfragen sollen, was sie denn zu unternehmen gedenken gegen die tausende Scans, die permanent in Foren so herumgeistern. Wahrscheinlich hätten sie dann ihr Drohpotential beschworen. Nur packen sie die Bazooka in der alltäglichen Praxis dann doch nicht aus, sonst wären nicht so viele Ablichtungen im Netz. Was den Ausschnitt betrifft, einfach ein wenig neue Schöpfungshöhe mit einbringen und das Ding neu abzeichnen + eigene Kommentare hinzufügen. Daran haben sie keine Rechte. Nebenbei bemerkt, ist dir eigentlich schon mal aufgefallen, was David L. Jones in seinem Videoblog so alles an Schaltplänen veröffentlicht? Den müsste doch eigentlich die US-Copyright-Industrie schon längst auf dem Kicker haben .. Aber nichts dergleichen scheint sich zu tun. Mysteriös oder?!
Proxxon schrieb: > Was den Ausschnitt betrifft, einfach ein wenig neue Schöpfungshöhe mit > einbringen und das Ding neu abzeichnen + eigene Kommentare hinzufügen. Richtig, Proxxon. So handhabe ich das auch. Notfalls einen Schaltungsauszug von Hand malen, einscannen. Das geht sogar recht schnell wenn man will, schneller als einen Plan in z.B. LTspice. ;-) Eine Abmahnung wollte ich dennnoch nie riskieren. Ich kenne die Merkmale nicht, wonach man sowas rechtlich exakt identifiziert. Aber dem Ralf kann ich den ASM51 Assembler nicht abmalen!!! Wenn er hier neben mir stünde, könnte ich ja noch sagen: Huch, mir ist mal eine CD herunter gefallen.
Wilhelm Ferkes (ferkes-willem) schrieb: Proxxon schrieb: >> Was den Ausschnitt betrifft, einfach ein wenig neue Schöpfungshöhe mit >> einbringen und das Ding neu abzeichnen + eigene Kommentare hinzufügen. > Richtig, Proxxon. So handhabe ich das auch. Notfalls einen > Schaltungsauszug von Hand malen, einscannen. Das geht sogar recht > schnell wenn man will, schneller als einen Plan in z.B. LTspice. ;-) > Eine Abmahnung wollte ich dennnoch nie riskieren .. Es fehlt halt an richtigen, echten Reformen in unserer Gesellschaft, nicht nur welchen, die immer eine bestimmte Gruppe bevorteilen. Das Urheberrecht auf Druckwerke wie Fachbücher sollte auf die Zeit beschränkt bleiben, solange noch Neuauflagen erscheinen (ohne Unterbrechung der Auflage). Mit dem Ende der letzten Auflage bekundet der Verlag implizit kein weiteres Interesse am Verkauf (s)eines Buches zu haben. Damit erlischt mit Frist dann auch das Schutzrecht. Ende Gelände! Bei technischen Fachbüchern sollte es zusätzlich eine grundsätzliche Ablaufgrenze geben, z.B. 20 Jahre nach Erstauflage und dann ist Schluss, weil die schnelle Veralterung solche Druckwerke ohnehin relativ schnell adäquat werden lässt. Diese bescheuerte Situation, der Rechteinhaber zeigt kein Interesse mehr an der Vermarktung/Weiterentwicklung seines Werkes, pocht aber gleichzeitig auf sein Recht einem vorhandenen und nachweislichen öffentlichem Interesse die allgemeine Nutzung auf Jahrzehnte vorzuenthalten bzw. zu versagen, sollte dringend geändert werden. Da entsteht nach meiner Ansicht nämlich mehr Schaden für die Gesellschaft als es irgend einen Nutzen hätte, außer den Begriff 'überholte Privilegien' zu strapazieren. Abgesehen davon vagabundieren sowieso fast alle bekannten Fachbücher der letzten ein, zwei Jahrzehnte im Netz herum. Dagegen ist kein Kraut gewachsen. Die Findigen (das darf man in diesem Fall wörtlich nehmen) wissen das und ich denke die Verlage wissen das ebenfalls. Die Schlauen unter den Verlagen werden das Phänomen dieser Verbreitung als Werbung begreifen, die anderen als Untergang des Abendlandes. Die Wahrheit wird irgendwo dazwischen liegen bzw. hin- und her pendeln, abhängig von der Qualität des jeweiligen Pamphlets.
Proxxon schrieb: > Es fehlt halt an richtigen, echten Reformen in unserer Gesellschaft, > nicht nur welchen, die immer eine bestimmte Gruppe bevorteilen. Der ganze Mist auch mit Patentwesen behindert die gesamte Gesellschaft nur. Was will man denn noch? Sich auch die Emitterschaltung am Transistor patentieren lassen, oder gar den Spannungsteiler mit 2 Widerständen, und Lizenzen verkaufen? Wo ist da eigentlich die Grenze?
@Wilhelm: > Normalerweise ist es nicht mein Stil, nicht zu antworten. > Ich bin dann bis zur Halskrause voll gestopft auch mit anderen Dingen > außerhalb des Themas. Nimm es mir nicht übel. Kein Thema :) > Ich finde, daß man sowas auch hier im Forum ohne PN diskutieren kann, > und dies absolut keineswegs peinlich ist. Denn ich befürchte, daß manch > einem hier im öffentlichen Raum was peinlich ist. Das war es nicht. Die PN hatte ich geschrieben, weil es in dem ursprünglichen Beitrag um was anderes als den Intel Assember ging. > Ich würde dir den Assembler sofort zur Verfügung stellen, aber ich habe > Angst vor Abmahnungen, mache nichts illegales. Mich würde interessieren, wie Intel dazu steht, ich würde auch nix illegales damit machen wollen. Wenn man ein bisschen sucht findet man die aktuellsten Versionen im Internet auf diversen Projektseiten, bei Unis, etc. > Der hat eine Lizenz und Copyright. Das Handbuch habe ich auch nur in > Papierform, und im Buchhandel gekauft. Vom Assembler oder dem Linker (weiss nicht mehr von welchem) hatte ich die aktuellste Version als PDF gefunden, vom anderen nur die Vorgängerversion des Handbuchs - und da fehlt mir eben ein Fetzen Info, der wahrscheinlich eben in der letzten Handbuch-Version drin ist. Wenn also das Handbuch für den Intel Assembler ist, kannst du die ISBN posten? Ralf
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.