Hallo, leider hat mein Proggy im Debug Mode die 64kb schon um 6kb gesprengt. Ein paar printf, sprintf, Float Unterstützung, sin, cos... nen paar Zeichentabellen für das Display .... tipp....tipp....tipp....ups, und schon ist es passiert. sprintf + float knallt schon mit fast 10kb rein, trotz Newlib nano-branch. Mit der StandardLib sind es noch 20kb mehr. Und die Boards haben ja 64kb... angeblich. Es gibt etliche Quellen im Netz, die aber von 128kb sprechen: http://wiki.stm32duino.com/index.php?title=Blue_Pill Ich benutze aber keinen Arduino IDE, sondern die EmBitz IDE mit ST-LinkV2 und einem 10 Euro Programmer dazu. Der hängt sich auf, wenn man versucht mehr als 64kb zu flashen. In er Linker Datei habe ich den Chip mit 128kb eingetragen. Das ST-Link liest ihn natürlich als 64kb Chip aus. Gibt es da einen Trick trotzdem an die 128kb zu kommmen mit der SWD Schnittstelle und ohne das Programm per Bootloader zu laden? Das geht nämlich leider nicht so einfach, da ST-Link mit der IDE verbandelt ist. Gruss, Christian
Angehängte Dateien:
-
Unbenannt.JPG
80 KB -
Unbenannt.JPG
140 KB
Mir ist da nichts bekannt... Verwendest du - O0 oder - Og? Lezteres optimiert gut, man kann aber noch gut debuggen
Angehängte Dateien:
-
IMG_6950.JPG
350 KB -
IMG_6949.JPG
260 KB
Immer O2. Die Libs werden aber nicht optimiert, weil die schon fertig kompiliert vorliegen. printf ist immer der Hammer aber xprintf von Chan hat kein Float. Und ich muss diverse zahlenreihen ausgeben auf dem Display. PS: Beim Debuggen ist immer die Optimerung aus, sonst geht das ja nicht zeilenweise durchsteppen. Auf jeden Fall quatschen die beiden Boards schon ganz gut miteinander :-)
Versuch doch mal -Os. Optimierung auf groesse. Es gibt sehr kleine printf impementationen, mit float. Heute komm ich leider nicht mehr ran, aber in meinem "Archiv" liegt wine, die braucht IIRC 6k inkl Float.
Nils S. schrieb: > Es gibt sehr kleine printf impementationen, mit float. Die Auswahl haste ja nicht, wenn Du stdio.h benutzt. Da nimmt er das aus der Lib die mitgeliefert wird. Un die wird nur gelinked und nicht kompiliert. Und beim Debuggen kann man keine Optimierung einstellen, da muss Zeile für Zeile alles so sein wie im Source Code. ich kenne nur xprintf und die kann kein Float. printf mit float ist ca 20kb in der normalen GNU armeabi Lib. In der NewLin Nano Branch ist es immerhin noch ca 12kb. PS: Der Unterschied zwischen O2 und Os ist sehr klein. Ich habe öfter ärger mit Os gehabt, daher nutze ich es nicht mehr, seltsame HardFaults usw. Denke mal ich bestelle mir ein paar 128kb Steine vom STM32F103 und löte die dann einfach drauf. Kosten ja nicht die Welt, 5 Euro oder so.
Christian J. schrieb: > Und die Boards ... 64kb ... Es gibt etliche Quellen im > Netz, die aber von 128kb sprechen Ja. Bekannt. > Ich benutze aber keinen Arduino IDE, sondern die EmBitz IDE mit > ST-LinkV2 und einem 10 Euro Programmer dazu. > > Der hängt sich auf, wenn man versucht mehr als 64kb zu flashen. In er > Linker Datei habe ich den Chip mit 128kb eingetragen. Das ST-Link liest > ihn natürlich als 64kb Chip aus. > > Gibt es da einen Trick trotzdem an die 128kb zu kommmen mit der SWD > Schnittstelle und ohne das Programm per Bootloader zu laden? Das geht > nämlich leider nicht so einfach, da ST-Link mit der IDE verbandelt ist. Wenn du auf der Verwendung der IDE bestehst, dann ist da wohl "Ende Gelände". ST shipped den Chip (heh, ein Wortspiel!) immer mit der Größenangabe "64K" im Flash Size Register, auch dann wenn er von einem Wafer mit 128K Flash kommt. Die standardmäßigen Programmiertools lesen dieses Register aus und weigern sich beharrlich, außerhalb des da spezifizierten Bereichs zu schreiben. Wenn du diesen Automatismus übergehen willst, dan brauchst du ein Flash-Tool, das du manuell anpassen kannst, z.B. openocd. Aber wie gesagt: "keine Arme, keine Kekse!"
Der C8 hat 64kB, der CB hat 128kB.
asdfasd schrieb: > Der C8 hat 64kB, der CB hat 128kB Wollen wir wetten, dass die Firmen so gemein sind aus ein und demgleichen Wafer zig Varianten des gleichen Chips herzustellen in dem sie einfach gezielt einige Fuses durchschiessen? :-)
Ein schönes Board, welches Du gebaut hast. Sogar schwarz lackier ;-) Meiner Meinung nach wäre es besser, den Prozessor zu tauschen und für so ein aufwendiges Board gleich eine Nummer größer zu gehen: http://www.ebay.de/itm/STM32F407VET6-Mini-version-of-the-Ader-Tafel-STM32-minimum-system-version-/172387871994
Markus schrieb: > Ein schönes Board, welches Du gebaut hast. Sogar schwarz lackier ;-) Dem kann ich mich nur anschließen. Sehr hübsch. Christian J. schrieb: > asdfasd schrieb: >> Der C8 hat 64kB, der CB hat 128kB > > Wollen wir wetten, dass die Firmen so gemein sind aus ein und > demgleichen Wafer zig Varianten des gleichen Chips herzustellen in dem > sie einfach gezielt einige Fuses durchschiessen? > > :-) Ja, das ist so, wobei das mit den "Fuses durchschiessen" habe ich noch nicht beobachtet. Im Gegenteil: Bis auf das Flash Register ist alles gleich. Ich denke irgendetwas auszulasern o.Ä. wäre zu aufwendig und damit zu teuer. Bei den F030F4P6 hat man z.B. den gleichen Chip wie beim F031F6P6, d.h. man hat nicht nur doppelten Flash, sondern z.B. noch einen Timer 2, den es eigentlich gar nicht geben dürfte. Ein Controller-Hersteller, der etwas auf sich hält, muss heute eben unbedingt 1000 verschiedene Controller anbieten können. Weil sich das natürlich nicht lohnt, nimmt man 50 Masken und stellt die "Vielfalt" durch verschiedene Gehäusevarianten und durch das "herunterlabeln" von bestimmten Typen her. Ich würde ebenfalls darauf wetten, dass das nicht nur bei ST so ist. Im Endeffekt kochen die alle nur mit Wasser. Was dein eigentliches Problem angeht: Inwieweit ist denn Embitz mit dem Flash-Tool von ST verbandelt? Da steckt doch garantiert auch noch OpenOCD unter der Haube. Wenn du da irgendwo die Möglichkeit hast etwas zu deiner GDB-init hinzuzufügen, dann kannst du mit
1 | monitor reset halt |
2 | load |
3 | monitor reset halt |
per OpenOCD flashen, d.h. im GDB wird ein "load" aufgerufen, was wiederum OpenOCD dazu bewegt die aktuelle .elf in den Controller zu laden.
Ok, ich melde mich später mal dazu. Muss erstmal rausfinden, warum die Platine, wenn ich sie an die Wand hänge als Anzeige, warum dann die RTC (am LSE) nur noch 1/3 so schnell läuft. Nein, das ist kein Witz! Im Raum herumgetragen, auf den Boden gelegt, immer wenn was dicht dahinter ist außer Holz oder Ne Türe läuft die RTC viel langsamer, die Uhrzeit kriecht nur so. Und nur die RTC, alle anderen Takte stimmen, die aus Timern abgeleitet werden oder dem Systick. Ich dreh noch ab.... dafür habe ich bis 3 Uhr heute morgen getestet :-( Ja, openocd ist machbar, wenn es das für Windows gibt. Kenne das nur unter Linux.
Bei dem Blue Pill Board sind die Anschlüsse des Uhrenquarzes heraus geführt. Möglicherweise stört der Kontakt zu etwas anderem die Schwingung. Wenn du die Platine gesockelt hast, könntest du verzsuchen, diese beiden Pins abzuschneiden.
Stefan U. schrieb: > Bei dem Blue Pill Board sind die Anschlüsse des Uhrenquarzes heraus > geführt. Möglicherweise stört der Kontakt zu etwas anderem die > Schwingung. Wenn du die Platine gesockelt hast, könntest du verzsuchen, > diese beiden Pins abzuschneiden. Mein Chef meinte, dass dass kapazitive Rückwirkungen auf Gegenstände mit reinspielen könnten, da die Pins am Uhrenquarz extrem hochohmig sind. Da reichen wenige Pico aus, um den Quarz stark zu verziehen. Allerdings habe ich dieses Verhalten nicht bei einem ähnlichen Board. Ich schneide sie heute abend mal ab, muss mal gucken welche das sind. Das geht natürlich nicht, sind ja wie Antennen. Ist gesockelt natürlich. Leider weiss ich noch nicht wie man genau die HSI anbindet an die RTC, dazu finde ich keine Beispiele. HSI ist doch der 8 Mhz Quarz und der läuft ja schon vorher. LSE und LSI muss man erst "anwerfen". Da muss ja genau eine Sequenz eingehalten werden. Oder man nutzt dieses CubeMX um diesen Fall mal durch zu spielen. Reicht aus, die Zeit kommt eh vom Masterboard alle paar Minuten durchgefunkt.
Christian J. schrieb: > Ja, openocd ist machbar, wenn es das für Windows gibt. Kenne das nur > unter Linux. Ja klar gibt es das auch für Windows. Das ist in den meisten Eclipse-IDEs standardmäßig mit dabei, so wie z.B. bei SW4STM32. Es gibt aber auch einzelne Binaries für Windows zum Herunterladen: http://www.freddiechopin.info/en/download/category/4-openocd Das Problem bei der Sache ist halt, dass ich da keine Möglichkeit sehe wie du das irgendwie in Embitz integrieren kannst. Das scheint tatsächlich der absolute Albtraum, was die Flexibilität bei den Tools angeht. Flashen mit OpenOCD an sich ist ziemlich einfach:
1 | openocd.exe -f interface/stlink-v2.cfg -f target/stm32f1x.cfg -c "program pfad/zu/irgendeiner.elf verify reset exit" |
Wobei ich mir nicht ganz sicher bin ob man bei Windows die Pfade zu den .cfg-Skripten auch mit "/" angeben kann bzw. sogar angeben muss oder ob es "\" sein muss.
Christian J. schrieb: > Und die Boards haben ja 64kb... angeblich. Es gibt etliche Quellen im > Netz, die aber von 128kb sprechen: Ja, die haben alle 128kByte Flash. Du kannst das nur mit OpenOCD machen! (mit dem STM32Duino-Bootloader soll es angeblich auch gehen)
1 | In der Datei "/usr/share/openocd/scripts/target/stm32f1x.cfg" |
2 | |
3 | Die Zeile auskommentieren: |
4 | #flash bank $_FLASHNAME stm32f1x 0x08000000 0 0 0 $_TARGETNAME |
5 | |
6 | und durch diese hier ersetzen: |
7 | flash bank $_FLASHNAME stm32f1x 0 0x20000 0 0 $_TARGETNAME |
Wenn du das gemacht hast flasht er dir deinen Chip. Er sagt beim flashen:
1 | device id = 0x20036410 |
2 | ignoring flash probed value, using configured bank size |
3 | flash size = 128kbytes |
Es ist aber egal, da es ja 128kByte sind. Das habe ich mit einem 131072 Byte großem Bild getestet welches ich in den Flash geschrieben und wieder ausgelesen habe. Ich flashe mit dem "ST-Link V2" vom Chinesen. Meine STM32F103C8T6 mini-Boards (Bluepill) habe ich auch vom Chinesen für 1,82€ bekommen. Ich werde hier mal eine einfache Anleitung wie man die Speichergröße testet ... irgend wo in die Artikelsammlung einstellen.
Christopher J. schrieb: > Flashen mit OpenOCD an sich ist ziemlich einfach:openocd.exe -f > interface/stlink-v2.cfg -f target/stm32f1x.cfg -c "program > pfad/zu/irgendeiner.elf verify reset exit" Ok, bei Embitz kann man sich einen String zusammen basteln, wie beim ST-Link auch (irgendwo im Netz geklaut), wo all diese Platzhalter mit drin sind. Der öffnet so ein DOS Fenster und man sieht was er macht. Glaube das ist pratikabel. Ich schaue mal, ob ich openocd bekomme und es irgendwie einbinden kann. EmBitz ist ja auch OpenSource und von daher sollte das auch andere OS unterstützen. Ich habe auch zwei von diesen China-Stäbchen, die JTAG und SWD bieten und bin mit denen sehr zufrieden. Sind dann hoffentlich auch kompatibel zu ocd, so wie zur StLink V2 Oberfläche. Damit spiele ich mir die neueste Firmware ein und lösche mal Boards, da der Stop Mode es öfter mal unmöglich macht die erneut zu flashen und man per Hand in den Boot Mode stöpseln muss.
Mike J. schrieb: > Meine STM32F103C8T6 mini-Boards (Bluepill) habe ich auch vom Chinesen > für 1,82€ bekommen. Haste da noch welche übrig? :-) So günstig habe ich die noch nicht gesehen. Und aktuell schon 3 zerschossen, bzw einige Pins.
Christian J. schrieb: > Haste da noch welche übrig? Habe mir vor drei Tagen noch mal zwei Boards bestellt. Das vorherige mal waren die Boards von diesem Händler nach genau einer Woche da. STM32F103C8T6-ARM-STM32-Minimum-System-Development-Board-Module-For-Ardu ino http://www.ebay.de/itm/162247218933 Preis: 1,81€ Christian J. schrieb: > schon 3 zerschossen, bzw einige Pins. Die ATmegas waren ja diesbezüglich recht unempfindlich gegen Überstrom, aber ich versehe auch jeden Pin mit einem Widerstand. :-D Momentan bin ich noch beim einarbeiten in die Materie der STM32-Controller und wahrscheinlich hole ich mir ein größeres Dev-Board für 21€. (NUCLEO-F429ZI - http://www.mouser.de/Search/ProductDetail.aspx?qs=mKNKSX85ZJcE6FU0UkiXTA%3d%3d) Man kann dann das Programm in den S-RAM (256kByte) des STM32F429 schreiben anstatt es in den Flash (nur 1000 mal beschreibbar) zu schreiben. (Das Programm ist natürlich dann auch weg wenn man die Spannung weg nimmt, aber zum austesten aller Peripherie und zum probieren wäre es doch sinnvoll ... manch einer findet den Fehler nicht, probiert rum und schreibt dann an einem Tag 20 mal (oder öfter) den Flash neu. Nach 50 Tagen ist das Ding dann hinüber. :-/ ) Wenn ich hier in Eclipse (SW4STM32) auf Debug drücke, dann habe ich mir eine Option mit "nur Debug" (also ohne Load) und eine mit "Flash + Debug" angelegt. Das Beschreiben geht ja auch sehr schnell. Man kann das Projekt ja dann (angeblich recht leicht) auf einen kleineren Controller portieren.
> Leider weiss ich noch nicht wie man genau die HSI anbindet an die RTC, > dazu finde ich keine Beispiele. HSI ist doch der 8 Mhz Quarz und der > läuft ja schon vorher. LSE und LSI muss man erst "anwerfen". Die RTC kannst du nicht mit dem HSI Oszillator takten. Der HSE Oszillator startet auch nicht von alleine. Nach dem reset läuft der µC zunächst auf einem ~8Mhz R/C Oszillator (und der heisst HSI). Ich habe die Prozedur für das Einstellen des HSE Oszillators hier beschrieben: http://stefanfrings.de/stm32/index.html
> schon 3 zerschossen, bzw einige Pins. > Die ATmegas waren ja diesbezüglich recht unempfindlich gegen Überstrom Gehen die STM bei Kurzschluss einzelner Pins nach GND oder VCC kaputt?
Stefan U. schrieb: > Gehen die STM bei Kurzschluss einzelner Pins nach GND oder VCC kaputt? Ja, ich glaube leider schon. Ich habe auf diese Weise einige Steine zerschossen. Einen Überstromschutz haben die jedenfalls nicht und die sind sehr schnell tot, vor allem extrem sensibel gegenüber ESD. Im Übrigen ist es ein Märchen das Flash wäre nur 1000 Mal beschreibar. Eher 10.000 Mal. Ich debbuge den 429er auch im RAM, wenn es geht. Das ist aber nicht in jedem Fall machbar! In meiner Anwendung hängt sich der Debugger einfach irgendwann auf, obwohl scheinbar alles richtig eingestellt wurde.
Stefan U. schrieb: > Ich habe die Prozedur für das Einstellen des HSE Oszillators hier > beschrieben: http://stefanfrings.de/stm32/index.html Ok, habe es überflogen. Aber wie koppelt man den HSI oder HSE an die RTC dran? Das geht, die hat 3 Taktquellen als Referenz: HSI oder HSE, LSE und LSI.
Mike J. schrieb: >> Und die Boards haben ja 64kb... angeblich. Es gibt etliche Quellen im >> Netz, die aber von 128kb sprechen: > > Ja, die haben alle 128kByte Flash. Ist denn da ein anderer Controller drauf? Der STM32F103C8T6 hat ja nur 64kB Flash. Und lustig, auf dem Schaltplan von den Modulen ist ein MAX3232 abgebildet. Den habe ich auf den Bildern noch nicht gefunden ;-)
Pete K. schrieb: > Mike J. schrieb: >>> Und die Boards haben ja 64kb... angeblich. Es gibt etliche Quellen im >>> Netz, die aber von 128kb sprechen: >> >> Ja, die haben alle 128kByte Flash. > > Ist denn da ein anderer Controller drauf? Der STM32F103C8T6 hat ja nur > 64kB Flash. Hast du das immer noch nicht geschnallt? Der Käfer ist zwar als C8T6 gelabelt, drin ist aber meist (immer?) der gleiche Chip wie beim CBT6. Kommt halt alles von einem Wafer und wird nach Bedarf mal so, mal anders gelabelt. Womöglich ist der überzählige Flash auch unzuverlässig oder schlicht nicht getestet. Auf jeden Fall sind die C8T6 von ST per Fuse oder factory programming auf 64K Flash "kastriert". Alle offiziellen Tools beschreiben dann auch nur 64K. Aber wenn man Kontrolle darüber hat (Bootloader oder wie bei openocd ein Configfile) dann kommt man auch an den restlichen Flash.
Hat vielleicht auch jemand den Kommandostring für Embitz mal zur Hand? Das ist nämlich das Einzige, was ich bräuchte....
Axel S. schrieb: > Hast du das immer noch nicht geschnallt? Scheinbar nicht. Aber Danke für die Erklärung. Jetzt habe ich es "geschnallt".
Mike J. schrieb: > Ich werde hier mal eine einfache Anleitung wie man die Speichergröße > testet ... irgend wo in die Artikelsammlung einstellen. Ich habe das jetzt hier mit rein geschrieben, aber irgend wie habe ich da ein Fehler beim verlinken der 128kByte bin-Datei gemacht. Hochgeladen wurde sie, aber ich hätte sie wohl nicht als Miniatur anzeigen lassen sollen. Eigentlich sollte die nur einfach runterladbar sein. https://www.mikrocontroller.net/articles/STM32F103C8T6_STM32_Billig_Board#128k_Flash
:
Bearbeitet durch User
Na toll :-( Openocd drauf. EmBitz bietet sogar eine Option dafür an.... aber das war es auch. Es blitzt nur kurz eine Dos Box auf und die ist dann direkt weg. Was war kann man raten. Und nirgends eine gescheite Doku wie die Kommandostrings aussehen müssen! Ja, es ist Freeware aber ich weiss warum wir tausende Euros für Keil ausgeben..... Grumpf.
Stefan U. schrieb: > Bei dem Blue Pill Board sind die Anschlüsse des Uhrenquarzes heraus > geführt. Möglicherweise stört der Kontakt zu etwas anderem die > Schwingung. Wenn du die Platine gesockelt hast, könntest du verzsuchen, > diese beiden Pins abzuschneiden. Das war es! Habe die Pins abgekniffen und die Rest ausgelötet. PC14 und PC15. Und seitdem läuft die RTC einwandfrei. Ist schon krass was das ausgemacht hat!
> Aber wie koppelt man den HSI oder HSE an die RTC dran?
Laut dem Diagramm aus Cube geht das gar nicht, aaaaber:
Zitat aus dem STM32F103x8 Datenblatt Kapitel 2.3.14 RTC (real-time
clock) and backup registers:
"It is clocked by a 32.768 kHz external crystal, resonator or
oscillator, the internal low-power RC oscillator or the high-speed
external clock divided by 128."
Und im STM32F1 reference Manal (RM0008) Kapitel 7.2.8 steht:
"The RTCCLK clock source can be either the HSE/128, LSE or LSI clocks.
This is selected by programming the RTCSEL[1:0] bits in the Backup
domain control register (RCC_BDCR). This selection cannot be modified
without resetting the Backup domain. The LSE clock is in the Backup
domain, whereas the HSE and LSI clocks are not...
If the HSE clock divided by 128 is used as the RTC clock:
– The RTC state is not guaranteed if the VDD supply is powered off or if
the internal voltage regulator is powered off (removing power from the
1.8 V domain).
– The DPB bit (disable backup domain write protection) in the Power
controller register must be set to 1 (refer to Section 5.4.1: Power
control register (PWR_CR))."
Jetzt muss man also nur noch nachschauen, welche bits die Register
RCC_BDCR und PWR_CR haben. Steht auch alles in diesem Handbuch.
Ich frage mich nur, warum du das machen willst. Denn die RTC ist danach
keine richtige RTC mehr, der HSE Oszillator arbeitet nicht mit der
Backup Batterie.
Stefan U. schrieb: > Ich frage mich nur, warum du das machen willst. Denn die RTC ist danach > keine richtige RTC mehr, der HSE Oszillator arbeitet nicht mit der > Backup Batterie. Hi, ich habe damit etwas rumgespielt. Bei meiner Anwendung kriegt die Anzeige ihre Uhrzeit regelmässig vom Master per Funk zugespielt, von daher muss die RTC nur die Lücken überbrücken, die 1 Stunde sind. Der Master ist ein 429er wo ich die RTC penibel genau getrimmt habe mit den Trimmregistern. Alle paar Tage gucken und dann schrittweise gedreht, wenn zu schnell oder zu langsam. Eine Anzeige kann ohne die Hauptplatine eh nichts machen, von daher brauche ich kein Backup. Schalte ich die ein fordert sie alle Betriebsdaten vom Master an. Nicht mal ne RTC eigentlich, geht auch mit dem Systick. Die interne LSI ist extrem ungenau! 5 Minuten pro Stunde hatte ich da Abweichung. Muss man wohl etwas am Prescaler spielen, damit kriegt man sicher noch etwas raus. Ich hatte 4000 eingestellt. Mit der HSE geht es auch, egal was CubeMX da sagt. Man muss sich nur daran halten, dass die RTC so eine Art unfertige RTC ist. Und stänmdig auf die Syncro Befehle und WaitTillLastTask Rücksicht nehmen. Das sieht unschön aus aber klappt. Aber das mit den 128kb Flash ist geil! Jetzt passt sogar noch ein Startbild für das Display mit in den Speicher und ich kann endlich floats im printf benutzen.
Möchte das ursprüngliche Thema nochmal aufwärmen: Axel S. schrieb: > Auf jeden Fall sind die C8T6 von ST per Fuse oder factory programming > auf 64K Flash "kastriert". Alle offiziellen Tools beschreiben dann auch > nur 64K. Aber wenn man Kontrolle darüber hat (Bootloader oder wie bei > openocd ein Configfile) dann kommt man auch an den restlichen Flash. Sowohl der STM-interne Bootloader (gesteuert vom STM Flash Loader Demonstrator) als auch das ST-Link Utility (an SWD) erlauben mir meine STM32F103C8T6 auf den Bluepill Boards mit 128kB Binaries zu beschreiben und fehlerfrei zurückzulesen. Im Flash Loader Demonstrator muss man nur die 128K Size auswählen. Was nicht geht: im ST-Link Utility mit einem Offset (also z.B. die zweite 64K-Bank als Startadresse) ein kleineres Binary "da oben" zu plazieren. Habe mal ein Testfile angehängt in dem jedes 32-Bit Wort den Wert seiner eigenen Adresse im Bin-File enthält.
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.