Hallo, ich sitze gerade in der Berufsschule und habe den Auftrag bekommen, herauszufinden was _CONFIG_PWRTE_ON&_WDT_OFF&_HS_OSC bedeutet... kann mir vllt jemand weiter helfen?? danke schon mal
Vielleicht sollte hier mal ein neues Forum eingeführt werden für Leute, die a) absolut keine Ahnung haben, wovon sie reden b) nicht in der Lage sind, ihre Hausaufgaben eigenständig zu bearbeiten und c) es nicht einmal für nötig halten, die Forenregeln zu lesen...
> kann mir vllt jemand weiter helfen?? Ja. > _CONFIG_PWRTE_ON&_WDT_OFF&_HS_OSC Wahrscheinlich - ist es ein Mikrocontroller vom 8048-Derivat, - du programmierst in ADA, - das sind Compilerdirektiven ... Falls das nicht so ist: warum sagst du das nicht (so vollständig wie möglich)? Das u.A. ist gemeint, wenn du aufgefordert wirst, > die Forenregeln zu lesen > _CONFIG_PWRTE_ON&_WDT_OFF&_HS_OSC Such doch einfach mal im Manual oder im Forum nach diesen Kürzeln... Seit es PDFs gibt, ist das soooo einfach. ;-)
...! wrote:
> _CONFIG_PWRTE_ON&_WDT_OFF&_HS_OSC
Ich glaube, in Bascom heißt alles irgendwie CONFIG, damit kein Schwein
mehr durchsieht.
Peter
Daniel F. wrote:
> 42
42 ist übrigens nur die Antwort auf die Frage nach dem Universum, dem
Leben und dem Rest (oder so ähnlich), NICHT aber die Antwort auf
ALLE Fragen.
falls es sich um einen PIC handelt, könnte das hier weiterhelfen http://www.sprut.de/electronic/pic/config/config_emb.htm gruß michi
Es ist ein PIC und die Zeile verknüpft drei Configuration Bits mit der bitweisen-UND (&) Verknüpfung.
OT: Peter Dannegger wrote: > Ich glaube, in Bascom heißt alles irgendwie CONFIG, damit kein Schwein > mehr durchsieht. Langsam wird das Bascom-Bashing albern. Die Config-Direktiven von Bascom stehen fein säuberlich in der Hilfe erklärt und sind eigentlich schon vom Namen her sowas von Aussagekräftig. Zumindest weiß ich auch ohne Hilfe, was ich z.B. mit CONFIG LCD ... CONFIG GRAPFHLCD ... CONFIG 1WIRE ... CONFIG DCF77 ... CONFIG RC5 ... CONFIG SPI ... etc. konfiguriere. Mal ganz davon abgesehen, dass damit nicht nur die entsprechenden Ports/Pins für die jeweilige Sache konfiguriert werden, sondern auch die vollständige Initialisierung z.B. des LCD geschehen ist.
1 | $regfile = "m16def.dat" |
2 | Config Lcdpin = Pin , Db4 = Portd.0 , Db5 = Portd.1 , Db6 = Portd.2 , Db7 = Portd.3 , E = Portd.4 , Rs = Portd.5 |
3 | Config Lcd = 20 * 2 |
4 | Config Dcf77 = Pina.0 , Timer = 1 , Inverted = 1 |
5 | Config Date = Dmy , Separator = . |
6 | Enable Interrupts |
7 | Main: |
8 | Do
|
9 | Locate 1,1 : LCD time$ |
10 | Loop
|
11 | End
|
11 Zeilen Code für eine Funkuhr, machst du mir das in C oder Assembler nach? Gruß Dominique Görsch
> 11 Zeilen Code für eine Funkuhr, machst du mir das in C oder Assembler > nach? In C mit Makros -> geht. Wir würden aber nicht jedes Makro mit CONFIG_ beginnen lassen. ;-)
Dominique Görsch wrote: > 11 Zeilen Code für eine Funkuhr, machst du mir das in C oder Assembler > nach? Ich gehe mal davon aus, daß diese DCF77-Uhr selbstverständlich auch eine RTC (Zeit+Datum+Sommerzeit mit Timer vom MC-Quarz abgeleitet) enthält, um Empfangsstörungen zu überbrücken. Wo legt man die Quarzfrequenz für den MC fest? Wo legt man das Ausgabeformat für time fest (Vornullenunterdrückung, 12/24h, Wochentag usw.)? Wo steht, wann zuletzt die DCF77-Prüfung einwandfrei war, d.h. die RTC mit dem DCF77 synchronisiert wurde? Kann ich weitere Prüfungen hinzufügen? Was mache ich, wenn meine Aufgabe von den vorgefertigten Legosteinchen abweicht (also typischer Weise immer)? Kann ich diese modifizieren (kommentierter Bascom-Quelltext vorhanden) oder muß ich alles neu machen? Peter
Geht sogar in C noch kürzer.
#include "Dcf77_LCD.h"
int main()
{
Dcf77_LCD_INIT();
while(1)
Dcf77_LCD_SHOW();
return 0;
}
(gut man braucht noch ein Dcf77_LCD lib aber was anders macht Bascom ja
auch nicht)
Peter wrote: > (gut man braucht noch ein Dcf77_LCD lib aber was anders macht Bascom ja > auch nicht) Ach und die ist beim avr-gcc dabei? Nicht? Schade, bei Bascom schon! Natürlich kann man entsprechende Makros und Funktionen auch in anderen Sprachen selber schreiben, Bascom hat das meist benötigte schon mit an Board.
Karl-heinz Strunk wrote: > Daniel F. wrote: >> 42 > > 42 ist übrigens nur die Antwort auf die Frage nach dem Universum, dem > Leben und dem Rest (oder so ähnlich), NICHT aber die Antwort auf > ALLE Fragen. "The Answer to the Great Question [...] Of Life, the Universe and Everything [...] Is [...] Forty-two", said Deep Thought, with infinite majesty and calm. also auf die frage nach dem universum, dem leben und allem... und meiner meinung nach ist es eine passende antwort auf eine frage ohne jegliche hintergrundinformation ;-)
Peter Dannegger wrote: > Ich gehe mal davon aus, daß diese DCF77-Uhr selbstverständlich auch eine > RTC (Zeit+Datum+Sommerzeit mit Timer vom MC-Quarz abgeleitet) enthält, > um Empfangsstörungen zu überbrücken. Empfangslöcher sind in dem Fall nur über den eigenen Timer mit internem Oszi oder ext. Quarz/Oszi abgedeckt (natürlich Zeit und Datum, ob Sommerzeit weiß ich nicht). Eine echte RTC via SPI ist aber auch nicht wirklich ein Problem. Ob die Zeitfunktionen Sommer-/Winterzeit berücksichtigen könnte man aber einfach testen, indem man nicht DCF sondern direkt den Timer (CONFIG CLOCK = Timer1) nutzt und mit entsprechenden Datums- und Zeitwerten kurz vor der Zeitumstellung vorbelegt (TIMER$ = "hh:mm:ss", DATE$ = "mm/dd/yy"). > Wo legt man die Quarzfrequenz für den MC fest? Entschuldige, die Zeile habe ich dir tatsächlich vorenthalten. "$crystal = 8000000" steht hinter "$regfile ...". Es sind demnach 12 Zeilen Basic-Code für ein funktionierendes Programm. > Wo legt man das Ausgabeformat für time fest (Vornullenunterdrückung, > 12/24h, Wochentag usw.)? Das Ausgabeformat kannst du über Fusing() oder weiteren Zahlen- und Stringmanipulationen anpassen, am einfachsten dann, wenn du nicht time$ sondern _min, _hour und _sec nutzt. > Wo steht, wann zuletzt die DCF77-Prüfung einwandfrei war, d.h. die RTC > mit dem DCF77 synchronisiert wurde? Wann müsstest du selber speichert, ob synchronisiert wurde steht in Bit 7 von dcf_status. > Kann ich weitere Prüfungen hinzufügen? So wie es oben steht wird permanent mit dem DCF-Signal abgeglichen, du kannst das aber auch nur zu bestimmten Zeiten veranlassen oder selber triggern. Sogar um das ein- und abschalten des DCF-Moduls können sich die Bascom-Funktionen ootb kümmern (SWITCHPOWER=1, POWERPIN=PIND.1, POWERLEVEL = 1). > Was mache ich, wenn meine Aufgabe von den vorgefertigten Legosteinchen > abweicht (also typischer Weise immer)? Dann schreibst du das benötigte eben drumherum. Es war nur ein Beispiel wie man recht einfach in Bascom Standardaufgaben realisiert und zu ersten Ergebnissen kommt. Man kann natürlich auch umfangreichere Anwendungen in Bascom (und auch anderen Basic-Derivaten) schreiben. > Kann ich diese modifizieren (kommentierter Bascom-Quelltext vorhanden) > oder muß ich alles neu machen? In der Demo-Version sind soweit ich weiß alle Libs nur als Kompilate verfügbar, in der Vollversion auch als Quelltext (AFAIK überwiegend in Assembler). Ich will hier sicher nicht Bascom propagieren, AVRs lassen sich ebenso in C oder ASM programmieren, aber Bascom ist nicht schlecht und das ständige Bascom bashing find ich inzwischen ziemlich erbärmlich und deklassiert für mich nur den Basher. Gruß Dominique Görsch
>>Ich will hier sicher nicht Bascom propagieren, AVRs lassen sich ebenso >>in C oder ASM programmieren, aber Bascom ist nicht schlecht und das >>ständige Bascom bashing find ich inzwischen ziemlich erbärmlich und >>deklassiert für mich nur den Basher. Naja, ohne Dir zu nahe treten zu wollen, aber 'nen eingefleischten C-Fan werden diese Argumente trotzdem nicht überzeugen können. mfg
In C kann man jegliches Programm in nur einer einzigen Zeile schreiben.., die wird nur u.U. recht lang...
- - - wrote: > Naja, ohne Dir zu nahe treten zu wollen, aber 'nen eingefleischten C-Fan > werden diese Argumente trotzdem nicht überzeugen können. Doch, natürlich. Dominique hat mir grad die Augen geöffnet. Ich muss jeden Tag 100 DCF77-Uhren programmieren, und ich habe mich schon immer über die viele Tipparbeit geärgert. Ich werde zur BASCOM-Bruderschaft konvertieren und jedem erzählen, wie toll man mit BASCOM DCF77-Uhren programmieren kann. Die BASCOM-Jünger werden die Welt beherrschen! Nie mehr C! Lasset uns BASCOM in die Welt hinaustragen! Nur BASCOM ist die Lehre der Wahrheit!
- - - wrote: > Naja, ohne Dir zu nahe treten zu wollen, aber 'nen eingefleischten C-Fan > werden diese Argumente trotzdem nicht überzeugen können. Ich will niemanden davon überzeugen etwas Anderes zu nutzen, aber muss man direkt alles Andere schlecht machen, nur weil man für sich pers. das Ideal gefunden hat? Gruß Dominique Görsch
Johannes M. wrote: > Doch, natürlich. Dominique hat mir grad die Augen geöffnet. Ich muss > jeden Tag 100 DCF77-Uhren programmieren, und ich habe mich schon immer > über die viele Tipparbeit geärgert. Ich werde zur BASCOM-Bruderschaft > konvertieren und jedem erzählen, wie toll man mit BASCOM DCF77-Uhren > programmieren kann. Die BASCOM-Jünger werden die Welt beherrschen! Nie > mehr C! Lasset uns BASCOM in die Welt hinaustragen! Nur BASCOM ist die > Lehre der Wahrheit! Geh' dich doch bitte weiter an deinem C-Code ergötzen, dass ist allemal sinnvoller als wenn du hier sinnfrei postest. Irgendwann wirst auch du dann begreifen, dass ein Beispiel exemplarisch zu verstehen ist.
Hampelmann wrote: > In C kann man jegliches Programm in nur einer einzigen Zeile > schreiben.., die wird nur u.U. recht lang... Ja ganz toll, und in Perl schreib ich ganze Applikationen in eine Zeile die dann nichtmal mehr lesbare Sequenzen enthält.
Dominique Görsch wrote: > Geh' dich doch bitte weiter an deinem C-Code ergötzen, dass ist allemal > sinnvoller als wenn du hier sinnfrei postest. Irgendwann wirst auch du > dann begreifen, dass ein Beispiel exemplarisch zu verstehen ist. Erstens ist dieser ganze Thread furchtbar sinnlos, weshalb ein sinnloses Posting mehr auch nicht wirklich schlimm ist. Zweitens ist die Hauptsinnlosigkeit dieses Threads dadurch entstanden, dass ein gewisser Herr Görsch mit tierischem Ernst auf PeDas Kommentar eingegangen ist. Ich kenne Herrn Görsch nicht persönlich, aber er ist vermutlich jemand, der zum Lachen in den Keller geht (nichts für ungut)... Ich persönlich habe nichts gegen BASCOM, es gibt sicherlich auch viele Leute, die damit Sinnvolles anstellen, und die ganze Diskussion BASCOM-C ist in meinen Augen unsinnig. Jeder soll mit dem arbeiten, mit dem er am besten klarkommt. Wenn jemand sich für BASCOM begeistern kann, bitte... Nur finde ich es immer wieder bezeichnend, wenn BASCOM-User darauf hinweisen, wie kurz die Programme sind, was sicherlich kein Kriterium für eine Programmiersprache für eine Hardware ist, bei der es i.e.L. nicht darauf ankommt, dass der Quellcode kurz ist, sondern das, was letztendlich auf den µC kommt. Diese Argumentation führt die Diskussion immer wieder ins Lächerliche. Auch wenn man mit BASCOM ebenfalls kurzen Maschinencode erzeugen kann, es ist Fakt, dass viele BASCOM-Programmierer (speziell Einsteiger) mit immer den selben Fragen hier im Forum auftauchen, die sie nur deshalb haben, weil sie durch die Kompaktheit des BASCOM-Quellcodes nicht mehr nachvollziehen können, was in dem zu programmierenden System überhaupt passiert. Und ja, es gibt auch C-Programmierer, die mit ähnlichen Fragen ankommen, aber die sind anteilsmäßig zu vernachlässigen.
Was in den Chip gebrannt wurde sieht hinterher eh keiner mehr. Wichtig ist was hinten raus kommt.
Die Diskussion ist schon von daher voellig unsinnig, da BASCOM hoechstwahrscheinlich in C geschrieben ist, ergo ist BASCOM nur eine Erweiterung von C. Die Diskussion ob BASCOM oder C besser ist, ist also so sinnvoll wie die, ob Erdbeereis oder Eis besser ist. q.e.d. (Um dem Ganzen einen wissenschaftlichen Anspruch zu geben)
>>Ich will niemanden davon überzeugen etwas Anderes zu nutzen, aber muss >>man direkt alles Andere schlecht machen, nur weil man für sich pers. das >>Ideal gefunden hat? Natürlich nicht! Allerdings ist in diesem C-AVR-lastigen Forum nichtmal der PIC-Freund seiner selbst sicher. PS: Habe soweit alles mir wichtige durch, PIC's & AVR's in Assembler & C, bei ARM laß ich derweil die ARMe hängen, weil ich mit den Startup-Codes nict klarkomme, weil es niemand erklären will oder kann. Siehe Board. mfg
Johannes M. wrote: > Und ja, es gibt auch C-Programmierer, die mit ähnlichen Fragen ankommen, > aber die sind anteilsmäßig zu vernachlässigen. Dann liest du wohl ein anderes Forum. Ich kann mich an die letzte BASCOM-Frage kaum erinnern, an manchen Tagen gibt es aber gleich ein halbes Dutzend anfragen, wie man in C eine Zahl als Text ausgibt...
Peter Stegemann wrote: > Dann liest du wohl ein anderes Forum. Ich kann mich an die letzte > BASCOM-Frage kaum erinnern, an manchen Tagen gibt es aber gleich ein > halbes Dutzend anfragen, wie man in C eine Zahl als Text ausgibt... Das hat ja auch nicht direkt etwas mit der Controller-Hardware zu tun. Die typischen BASCOM-Fragen tendieren thematisch eher in andere Richtungen. Aber Du hast schon Recht: Insgesamt ist es BASCOM-mäßig in letzter Zeit eher ruhig geworden. Hat da jemand einen BASCOM-Filter eingebaut;-? Oder haben die BASCOM-Entwickler die Dokumentation verbessert? Ich weiß es nicht, aber ich habe nach wie vor nichts pauschal gegen BASCOM...
Johannes M. wrote: > Ich kenne Herrn Görsch nicht persönlich, aber er ist > vermutlich jemand, der zum Lachen in den Keller geht (nichts für > ungut)... Mitnichten, ich finde einfach nur dieses Bascom-Bashing ist total unnötig - und das nicht, weil ich Bascom-Nutzer bin. Ebenso das Linux-Bashing, Windows-Bashing, oder diverse andere Flamewars. Überlicher Weise gibt's bei Glaubenkriegen ohnehin nur verlierer. Im Übrigen kannst du mich gerne beim Vornamen nennen - auch ein Domi ist vollkommen ok... aber wenigstens "Herr", das bin ich auch anders gewohnt. ;) > Ich persönlich habe nichts gegen BASCOM, es gibt sicherlich auch viele > Leute, die damit Sinnvolles anstellen, und die ganze Diskussion BASCOM-C > ist in meinen Augen unsinnig. Jeder soll mit dem arbeiten, mit dem er am > besten klarkommt. Wenn jemand sich für BASCOM begeistern kann, bitte... Genau das ist doch der Punkt. Ich nehme mir das Recht und die Freiheit zur Lösung (m)eines Problems aus meinem Portfolio zu dem meiner Meinung nach bestem Werkzeug zu greifen. Bisher war das für mich beim Thema AVR immer Bascom, ich bin noch nicht an seine Grenzen gestossen. Für die x86-Welt oder das Web beherrsche ich noch ein paar andere Sprachen, wenn auch Basic (VBA, VB 6 und .NET) klar zu meinen Stärken gehört. Ich käme aber sicher nie auf die Idee auf Biegen und Brechen ein Problem in Basic zu lösen, wenn vielleicht drei Zeilen Perl, Python, Ruby oder was auch immer besser geeignet wären (Perl's Stärken sind ja nunmal z.B. die Stringmanipulation). > Nur finde ich es immer wieder bezeichnend, wenn BASCOM-User darauf > hinweisen, wie kurz die Programme sind, was sicherlich kein Kriterium > für eine Programmiersprache für eine Hardware ist, bei der es i.e.L. > nicht darauf ankommt, dass der Quellcode kurz ist, sondern das, was > letztendlich auf den µC kommt. Die Codelänge ist schon mit ein Kriterium, insb. wenn es auf die Etwicklungszeit ankommt. Ein paar Zeilen lauffähiger Code sind schneller geschrieben, als wenn ich mich von Hand erst um die Initialisierung der gesamten Peripherie kümmern muss. > Auch wenn man mit BASCOM ebenfalls kurzen > Maschinencode erzeugen kann, es ist Fakt, dass viele > BASCOM-Programmierer (speziell Einsteiger) mit immer den selben Fragen > hier im Forum auftauchen, die sie nur deshalb haben, weil sie durch die > Kompaktheit des BASCOM-Quellcodes nicht mehr nachvollziehen können, was > in dem zu programmierenden System überhaupt passiert. Das Problem sehe ich da eher anders. Aufallend ist, dass viele sehr dumme Fragen aus dem Bascom-Umfeld kommen. Ich denke das liegt daran, dass Bascom von vielen als sehr einfach empfunden wird und daher viele Anfänger dazu greifen. Das übliche Problem vieler Anfänger ist der fehlende Wille Datenblätter, Handbücher und andere Dokumentation zu lesen. > Und ja, es gibt auch C-Programmierer, die mit ähnlichen Fragen ankommen, > aber die sind anteilsmäßig zu vernachlässigen. Hab ich noch nie so wirklich drauf geachtet, mag aber stimmen. Gruß Dominique Görsch //EDIT: Vermutlich gibt es zwei Klassen oder besser zwei Sorten von Anfängern: die eine Klasse möchte einfach möglichst schnell und mit wenig Aufwand zum Ziel, diese Gruppe greift dann gerne zu Bascom und wenns nicht so tut wie gewollt tauchen hier die "dummen Fragen" auf. Die andere Gruppe will aber auch verstehen was im µC wirklich passiert. Die arbeiten das AVR-Tut durch und landen dann entweder bei ASM oder bei C. Wirklich dumme Fragen haben sie nicht, da sie schon vorher einiges an Doku gelesen haben. Ich glaub ich würde mich in die Mitte, aber mit deutlichem Hang zur ersten Gruppe einsortieren. Ich wollte auch erstmal Ergebnisse und nachher hat mich interessiert was passiert. Dafür finde ich z.B. die "Assemblereinführung für Bascom-User"[1] sehr gelungen. [1]http://www.roboternetz.de/wissen/index.php/Assembler_Einf%C3%BChrung_f%C3%BCr_Bascom-User
Dominique Görsch wrote: > Die Codelänge ist schon mit ein Kriterium, insb. wenn es auf die > Etwicklungszeit ankommt. Richtig, sie ist aber nicht das alleinige Kriterium... > Ein paar Zeilen lauffähiger Code sind schneller > geschrieben, als wenn ich mich von Hand erst um die Initialisierung der > gesamten Peripherie kümmern muss. Wenn es nur die Initialisierung wäre... Da gibt es für C übrigens ne ganze Reihe sog. Code Generation Wizards, bei denen man mit Klickibunti sich die Peripherie zusammenfuddeln kann und der Initialisierungscode automatisch erstellt wird. Der Code glänzt dann allerdings oft durch erhebliche Wartungsunfreundlichkeit... > Das Problem sehe ich da eher anders. Aufallend ist, dass viele sehr > dumme Fragen aus dem Bascom-Umfeld kommen. Ich denke das liegt daran, > dass Bascom von vielen als sehr einfach empfunden wird und daher viele > Anfänger dazu greifen. Ist sicher die Hauptursache für die Vorurteile. > Das übliche Problem vieler Anfänger ist der > fehlende Wille Datenblätter, Handbücher und andere Dokumentation zu > lesen. Das Datenblatt-Lese-Verweigerungssyndrom ist aber auch in anderen Kreisen verbreitet. Und wirklich "dumme" Fragen habe ich auch schon von nicht-BASCOMern gelesen. > Gruß > Dominique Görsch Gruß zurück. Johnny
Dominique Görsch wrote: > Das übliche Problem vieler Anfänger ist der > fehlende Wille Datenblätter, Handbücher und andere Dokumentation zu > lesen. Genau das ist der Punkt. Wenn jemand Fragen stellt, die im Datenblatt ausdrücklichst beantwortet werden, dann bekommt der Fragensteller hier im Forum eines drauf (und das meiner Meinung nach zu recht, denn es senkt ganz einfach das Niveau des gesamten Forums, und es nervt ganz einfach wenn jeden Tag das gleiche gefragt wird.) Wenn es dagegen eine einfache Frage ist, die aber sinnvoll ist, dann bekommt man hier auch schnell eine gute Antwort. >> Und ja, es gibt auch C-Programmierer, die mit ähnlichen Fragen ankommen, >> aber die sind anteilsmäßig zu vernachlässigen. Genau. Bei dummen Fragen ist die Sprache egal, nur sind es leider sehr häufig Leute die in BASCOM Programmieren und das Datenblatt nicht gelesen haben, denn in C ist es nahezu unmöglich auch nur irgendwas sinnvolles zu machen ohne zumindest mal die Grundlagen im Datenblatt gelesen zu haben. Aber wenn es doch mal einer schafft, wird der hier im Forum genauso nieder gemacht, wenn er eine leicht durch das Datenblatt zu beantwortende Frage stellt. Und da statistisch gesehen BASCOM nunmal verstärkt von Leuten mit wenig/keiner Ahnung genutzt wird, hat BASCOM nunmal ein entsprechendes Image.
Dominique Görsch wrote: > Ich will hier sicher nicht Bascom propagieren, AVRs lassen sich ebenso > in C oder ASM programmieren, aber Bascom ist nicht schlecht und das > ständige Bascom bashing find ich inzwischen ziemlich erbärmlich und > deklassiert für mich nur den Basher. Danke für die Beantwortung der Fragen. Der kleine Seitenhieb war doch nicht so ernst gemeint. Er fußte ja darin, daß der Ursprungspost für die meisten völlig unverständlich war. Peter
>_CONFIG_PWRTE_ON&_WDT_OFF&_HS_OSC
Nach erfolgreicher Hinrichtung des Fragestellers versuche ich einmal
eine Übersetzung:
Stelle Programmschreiben auf EIN &
mache den Wachhund AUS &
wähle den Hochgeschwindigkeits-Oszillator.
Irgendwelche Einwände?
Na dann ist gut :-)
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.