Die Wahl eines Prozessors steht an, es muss nicht AVR sein. Hat sich schon mal jemand die Mühe gemacht, und eine Übersicht aktueller Controller und deren Einstiegskosten (Debugger, Compiler) erstellt? Es würde mich freuen.
Sehr lustig, die Bandbreite reicht von $4,30 bis 10000 EUR. Beim Launchpad geht's los, Debugger habe ich nie getestet. STM32VLDiscovery beginnt ab 13 EUR mit Debugger. In diesem Fall zahlt man in Form von Zeit, bis die Toolchain läuft, zumindest unter Linux. Was hast Du denn schon selbst recherchiert?
GCC und GDB gibt es nur für einige Plattformen. Bei den anderen bekommt man für $4,30 auch nur einen eingeschränkten Compiler. Daher die Frage, ich habe noch keine Hersteller abgeklappert. Die Anwendung erfordert <100 kB Programm, <2kB RAM, ein paar UARTs, SPI, I2C. Ein integrierter Bootloader (USB) wäre nett, ebenso Mass-Storage Host für Updates im Feld, CAN, Ethernet. Kleinserie, <10 Euro der Chip. Mehrere Entwickler, daher fallen Compilerlizenzen ins Gewicht. C oder C++ wär gut, eine FPU muss nicht sein. Verschlüsselungshardware nice to have. RTOS oder embedded linux wäre eine Überlegung wert, damit habe ich allerdings noch keine Erfahrung. STM32 sehe ich mir mal an. Danke soweit.
Mark T. schrieb: > Die Wahl eines Prozessors steht an, es muss nicht AVR sein. Warum nicht AVR? Da kriegst Du mit AVRStudio4 und WINAVR ne recht leistungsfähige Toolchain für umme. Nur der Programmieradapter kostet was. Ob man nen Debugger braucht, weiß ich nicht, ich benutze keinen. Der AVR hat ja ne gradlinige Architektur, da muß man nicht viel debuggen (keine spurious Interrupts, Traps, Exceptions, Faults usw.). Und logische Fehler im Programmablauf kriegt man mit Tests auf dem PC oder mit dem Simulator oder UART-Ausgaben auch gut raus. Peter
Mark T. schrieb: > Die Wahl eines Prozessors steht an, es muss nicht AVR sein. > Hat sich schon mal jemand die Mühe gemacht.. Aber ja, ich hab mir für meine Belange schon immer die Mühe gemacht. Du solltest es auch machen, ich meine, dir die Mühe machen. Aber zuallererst solltest du dir Klarheit darüber verschaffen, was du eigentlich machen willst, was du dafür brauchst, auf welche Bezugs-Quellen du zurückgreifen kannst und so weiter. W.S.
Mark T. schrieb: > Die Anwendung erfordert <100 kB Programm, <2kB RAM, ein paar UARTs, SPI, > I2C. Ein integrierter Bootloader (USB) wäre nett, ebenso Mass-Storage > Host für Updates im Feld, CAN, Ethernet. Kleinserie, <10 Euro der Chip. > Mehrere Entwickler, daher fallen Compilerlizenzen ins Gewicht. C oder > C++ wär gut, eine FPU muss nicht sein. Verschlüsselungshardware nice to > have. RTOS oder embedded linux wäre eine Überlegung wert, damit habe ich > allerdings noch keine Erfahrung. STM32 sehe ich mir mal an. Danke > soweit. Wenig RAM im Vergleich zum Flash, vor allem bei C++. Ich würde gleich mit C++ einsteigen. USB boot loader in HW gibt's z. B. beim atmega32u2, als "mass storage" zum Flashen beim lpc1343. Die erfüllen aber die restlichen Anforderungen m. W. nicht wirklich. STM32 und LPC haben beide einen USART boot loader in HW. Z. B. die stm32f107 connectivity line (die stm32f103 können USB und CAN nicht gleichzeitig), eine Nummer besser die stm32f2xx. Oder relativ aktuell stm32f4xx, vielleicht noch zu früh, Cortex-M4. Mit FPU und Crypto engine für DES et. al. lpc17xx sollte auch einen Blick wert sein, ungefähr in der Kampfklasse der stm32f1xx. Ich baue mir den ARM GCC selbst, zufällig gestern für Cortex-M4. Wenn es frei verwendbare Linker-Skripte und Startup-Codes gibt, dann nehme ich diese. Ansonsten schreibe ich die Dinger selber, das ist für letzeres beim Cortex-M3 in C möglich und kein Hexenwerk. Das Bestellen und Verwalten von Lizenzen kostet auch Zeit, kann aber auch ein "Nicht-Entwickler" machen. Dazu noch Makefiles und Emacs/Eclipse, Lizenzkosten also 0 EUR. Den Aufwand für diese Integration muss man dagegen rechnen. Mit dem Debugger halte ich es wie Peter, die Zeit ist besser vorher beim Design und bei der Implementierung in log-Ausgaben via USART/USB investiert. Das letztere zahlt sich auch für andere im Team aus. Peter Dannegger schrieb: > Ob man nen Debugger braucht, weiß ich nicht, ich benutze keinen. > Der AVR hat ja ne gradlinige Architektur, da muß man nicht viel debuggen Nun das liegt nicht ja nicht am Typ des Mikrocontrollers, sondern an dem Typ, der vor der Tastatur sitzt ...
Hallo Peter, gegen AVRs und GCC habe ich nichts, aber man kann sich ja auch mal umhören. Schließlich gibt es wahrscheinlich Controller, die den Anbau von viel Peripherie (RAM, Ethernet, CAN, zusätzliche IO und Schnittstellen) erübrigen und für gleiches Geld sogar noch mehr bieten.. Z.B einen integrierten Bootloader und eben USB. Einen Debugger möchte ihn nicht mehr missen, aber du machst ja auch selten Fehler.. andererseits, bei externen / zeitkritischen Signalen nützt er auch nicht soviel. Grüße
Brauchst Du USB zwingend? Wenn nein, lass es weg. Eine SD-Karte als Massenspeicher macht so sehr viel weniger Aufwand, dass Du schon ziemlich gewichtige Gründe für USB haben musst. Zur Prozessorwahl einige Gedanken: - Die Luminary Micro (jetzt TI) LM3S Serie hat bei Ethernet auch gleich den PHY mit eingebaut. Das ist dann ein TQFP48 weniger. Die Teile haben allerdings teilweise erhebliche Errata-Listen. - Ich empfehle ganz gerne die Microchip PIC24 und PIC32 Serien als ARM-Alternative, einfach weil der Support von Microchip verhältnismäßig gut ist und Du alles aus einer Hand bekommst: Chips, Compiler, IDE, Debugger-Hardware, Bibliotheken für TCP/IP, USB, Grafik, Peripherie, WLAN, Bluetooth, etc. Alles passt zusammen, und Du kannst ziemlich schnell loslegen, und ein großer Teil der Arbeit ist gemacht. Außerdem finde ich es sehr praktisch, dass das ICSP nur zwei Portpins braucht und nicht wie JTAG mindestens vier. fchk
> Brauchst Du USB zwingend? Wenn nein, lass es weg. Eine SD-Karte als > Massenspeicher macht so sehr viel weniger Aufwand, dass Du schon > ziemlich gewichtige Gründe für USB haben musst. Da kann ich nur zustimmen. USB kann schon aufwändig werden. > Die Luminary Micro (jetzt TI) LM3S Serie hat bei Ethernet auch gleich > den PHY mit eingebaut. Wie auch der lpc1769 > Ich empfehle ganz gerne die Microchip Auch wenn das Posting anonym gewesen wäre, spätestens jetzt hätte man gemerkt, das war der Frank :-)
Roland H. schrieb: >> Die Luminary Micro (jetzt TI) LM3S Serie hat bei Ethernet auch gleich >> den PHY mit eingebaut. > > Wie auch der lpc1769 Wo im Datenblatt siehst Du das? MAC ja, ist klar, aber von Ethernet PHY finde ich hier nichts (Datenblatt Rev. 6.01 — 11 March 2011, eben geladen) >> Ich empfehle ganz gerne die Microchip > > Auch wenn das Posting anonym gewesen wäre, spätestens jetzt hätte man > gemerkt, das war der Frank :-) Warum auch nicht. fchk
Frank K. schrieb: >>> Die Luminary Micro (jetzt TI) LM3S Serie hat bei Ethernet auch gleich >>> den PHY mit eingebaut. >> >> Wie auch der lpc1769 > > Wo im Datenblatt siehst Du das? MAC ja, ist klar Du hast recht. Sorry, da habe ich mich geirrt. Also kein Ethernet PHY auf dem Chip beim lpc1769.
> Die Wahl eines Prozessors steht an, es muss nicht AVR sein. > Hat sich schon mal jemand die Mühe gemacht, und eine Übersicht aktueller > Controller und deren Einstiegskosten (Debugger, Compiler) erstellt? > Es würde mich freuen. Im Bereich Markt verkauft jemand gerade M16C/29. Wenn du 10Stueck nimmst dann bekommst du einen fuer 2Euro. Das ist ein moderner 16Bit Controller mit folgenden Eigenschaften: 128k Flash, 4k-Dataflash, 12k Ram. 20Mhz Takt, laeuft mit 3.3V oder 5V! 9x Timer 2x UART/SPI 1x UART/SPI/I2C-Bus 1x I2C Multimaster 2x DMA 1x 10Bit AD-Wandler mit 27Eingaengen 1x CAN-Bus 1x CRC Generator Der Controller kann Programme im Ram ausfuehren und kennt Interruptprioritaten. Ein klassischer AVR ist ein Witz dagegen. Die Entwicklungsumgebung von Renesas (HEW) kannst du einfach so runterladen und sie ist dann auf maximal 64kByte Codegroesse beschraenkt. Reicht dir das nicht so kannst du dort den gcc nachinstallieren. Solltest du aus irgendwelchen Gruenden die die professionelle Vollversion des Renesascompilers kaufen wollen so kostet die 2kEuro. (R8C/M16C/M32/R32) Der PRozessor laesst sich einfach ueber RS232 programieren oder mit einem Debugger E8/E8a. Der Debugger, den man nicht unbedingt braucht, kostet so 80-160Euro. Abhaengig davon ob man den direkt kauft oder sich bei Ebay oder Glyn irgendein billiges Demoboard kauft wo er dabei ist. Die Nutzung unter Linux ist kein Problem. Sowohl gcc wie auch flasher laufen. E8/E8a laeuft unter Linux nicht. Renesas hat sehr viele und gute Dokumentation und Applikationen. Aber man muss die halt auch mal lesen. Leute die immer nur bei anderen abschreiben und nichts eigenes zustande bringen sind in Deutschland mit AVR besser dran. Renesas hat bis auf ganz wenige exotische Ausnahmen nur Controller in SMD. Das mag Anfaenger erstmal abschrecken! Ich wuerde aber nichts anderes verwenden wollen. Olaf p.s: Ich bin nicht der Verkaeufer, hab mir aber gerade bei ihm 10Stk gekauft. .-)
Danke für den Tipp. Renesas hatte ich noch nicht im Blickfeld.
Olaf schrieb: > 20Mhz Takt, laeuft mit 3.3V oder 5V! Aber nicht die angebotene V-Version :-) Mark T. schrieb: > Renesas hatte ich noch nicht im Blickfeld. Dann wirf auch einen Blick auf die RX610 bzw. RX621/RX62N. Es gibt sehr günstige Entwicklungsboards mit Segger J-Link Lite RX (Glyn) und ferner HEW (Renesas) und auch GCC (kpit). Prozessorpreise erhält man bei digikey.de unter dem Suchbegriff RX600.
Hier geht es offenbar um einen "Neueinstieg", es ist also
-außer Wissen- keine nennenswerte HW oder SW da.
Ich würde so vorgehen:
a) Welcher Prozessor erfüllt die gestellten Forderungen am Besten?
b1) Welche Entwicklungstool gibt es dazu, was kosten die?
b2) Wie hoch ist die Chance daß dieser Prozessor, diese
Prozessorfamilie weiterhin verwendet wird?
b3) Rentiert sich eine teure professionelle Entwicklungs-
umgebung (Frage b2)?
c) Kann ich die Kosten aufs Projekt bzw. den Kunden
verlagern?
d) Welches Budget habe ich also zur Verfügung?
Richtig, a) und b) sind ja der Anlass meiner Frage.
> Aber nicht die angebotene V-Version :-) STimmt, der laeuft nur von 4.2V bis 5.5V. Aber das ist ja die Version fuer -40 bis +125Grad. Ich denke mal wenn man die bei gemuetlicher Zimmertemperatur betreibt dann werden sie wohl auch mit 3.3V klar kommen. Wer dagegen ein Motorsteuergeraet fuer sein Auto bauen will der sollte aber wohl bei 5V bleiben. BTW: Wer sowas unter Linux nutzen will und ein ld-file fuer den Linker braucht der kann sich bei mir melden. .-) Oh..ein Nachteil will ich nicht verschweigen. Der gcc kommt nicht mit den 24Bit Pointern von Reneas klar. Deshalb verwendet er 16bit Pointer+Trampolin. Das ist zugegebenermassen etwas aergerlich. > Dann wirf auch einen Blick auf die RX610 bzw. RX621/RX62N. Ist das nicht eine etwas andere Liga? Also so fuer Einsteiger jetzt? So wegen Anspruechen an Boardlayout, Spannungsversorgung usw? Das sind ja gleich sehr dicke Kisten. Olaf
Mark T. schrieb: > Die Anwendung erfordert <100 kB Programm Bei bis zu 100 kB Programm müsstest man bei den AVR schon die ATmega nehmen und zu dem Preis bekommt auch schon Cortex-M0 und M3 Controller. Die Renesas M16C/M32C sind trotz 16 Bit und teilweise höheren Takt im Performance Bereich der AVR. Gestern erst einen Regel-Algorithmus getestet - Ausführungsdauer skaliert auf 20 MHz Takt: M32C, gcc -oO, KPIT: 1305,9 µs ATmega128, gcc -O2, AVRStudio5: 656,75 µs (Achtung: double = float) Cortex-M3, gcc -O2, Codesourcery: 79,5 µs Cortex-m3, armcc, -O2, Keil Arm: 49,8 µs Hinweis: Algorithmus enthält auch float und double Berechnungen u.a. sqrtf(). Leider kein open source. AVR nur so schnell, weil dort double nur 32 Bit haben und dem float entsprechen.
Soll natürlich: M32C, gcc -02, KPIT heißen!
Olaf schrieb: > Ist das nicht eine etwas andere Liga? Also so fuer Einsteiger jetzt? So > wegen Anspruechen an Boardlayout, Spannungsversorgung usw? Das sind ja > gleich sehr dicke Kisten. Jein. Es gibt kleinere Typen ab TQFP64, wenn man auf Vieles verzichten möchte. Aber selbst im LQFP144 sind die 25er Preise <10€/Stk. und die Leistung enorm. Wenn hier Cortex-M3 genannt werden, dann dürfen die RX nicht fehlen. Dann denke ich nicht, dass Mark ein absoluter Anfänger ist. Daniel schrieb: > Leider kein open source. Schade, hätte ich gerne mit RX getestet. Oder, wenn Du eh schon Zugriff auf KPIT hast, heute soll es noch Starkregen geben; dann hättest Du genug Zeit für einen weiteren Test :-)
> Schade, hätte ich gerne mit RX getestet.
Und ich gerne mal auf nem SH2A. Was uns aber zu einer interessante Frage
bringt, gibt es eigentlich irgendwo mal einen herstellerunabhaengigen
Vergleichstest verschiedener Microcontroller? Das waere doch mal ganz
interessant.
Olaf
Mit 64 Bit Double: M32C, gcc -O2, KPIT: 1305,90 µs RX610, gcc -O2, KPIT: 105,00 µs (mit FPU on) Cortex-M3, gcc -O2, Codesourcery: 79,50 µs Cortex-M3, armcc, -O2, Keil Arm: 49,80 µs Mit 32 Bit Double ATmega128, gcc -O2, AVRStudio5: 656,75 µs M32C, gcc -O2, KPIT: 296,90 µs RX610, gcc -O2, KPIT: 24,90 µs (mit FPU on) Cortex-M3, armcc, -O2, Keil Arm: 20,45 µs Alle mit C99 (armcc --c99, gcc -std=c99), und Gebrauch von inline Funktionen. Skaliert auf 20 Mhz. M32C also doch doppelt so schnell wie AVR. Die Werte sind nur als Hausnummern zu sehen, da dies kein Benchmark ist. Bitte keine Diskussion über die Verwendung von double und float. Darüber rede ich nur mit Mathematikern. Basta ;-) Daniel
Daniel schrieb: > RX610, gcc -O2, KPIT: 105,00 µs (mit FPU on) > Cortex-M3, gcc -O2, Codesourcery: 79,50 µs > RX610, gcc -O2, KPIT: 24,90 µs (mit FPU on) > Cortex-M3, armcc, -O2, Keil Arm: 20,45 µs Sehen das meine tränenden Augen richtig? Ein Cortex-M3 mit Fliesskommarechnung in Laufzeitfunktionen ist schneller als ein Controller mit Hardware-FPU? Oder was soll das "FPU on" heissen?
A. K. schrieb: > Sehen das meine tränenden Augen richtig? Ein Cortex-M3 mit > Fliesskommarechnung in Laufzeitfunktionen ist schneller als ein > Controller mit Hardware-FPU? Oder was soll das "FPU on" heissen? Richtig, immer vergesse ich die Hälfte hier noch RX610 mit -nofpu Option hinzugefügt: Mit 64 Bit Double: M32C, gcc -O2, KPIT: 1305,90 µs RX610, gcc -O2, KPIT: 222,75 µs -m64Bit-doubles -nofpu RX610, gcc -O2, KPIT: 105,00 µs -m64Bit-doubles Cortex-M3, gcc -O2, Codesourcery: 79,50 µs Cortex-M3, armcc -O2, Keil Arm: 49,80 µs Mit 32 Bit Double ATmega128, gcc -O2, AVRStudio5: 656,75 µs M32C, gcc -O2, KPIT: 296,90 µs RX610, gcc -O2, KPIT: 284,90 µs -nofpu RX610, gcc -O2, KPIT: 24,90 µs Cortex-M3, armcc -O2, Keil Arm: 20,45 µs 64 Bit double schneller als 32 Bit double, wenn -nofpu Option! Der Code ist C99 kompatibel, ohne Optimierung für die Cotec-M3 Familie. Der Code stammt eigentlich aus einer x386 Umgebung. Am besten schreibt mal jemand einen Benchmark mit Int, float und double tests. Daniel
Irgendwas läuft da doch granatenmässig schief. Bis auf die 32-Bit FPU sind sich Cortex-M3 und RX610 strukturell relativ ähnlich. Wie der RX610 mit Floasskommahardware mit Laufzeit von wenigen Takten bei 32-Bit Rechnung langsamer sein kann als der CM3 mit Softfloats ist für mich unbegreiflich. Das Desaster mit den 32-Bit Softfloats beim RX610 liesse sich erklären, wenn die Lib nur in 64 Bits rechnet und deshalb munter herumkonvertiert wird.
Die Lib, hier newlib, wurde mit den gleichen Einstellungen neu-compiliert. Dies kann man in der HEW IDE einstellen. Bin aber auch kein RX600 Profi, heute das erste mal sozusagen. Am besten, wie gesagt, einen open source Benchmark schreiben, so dass auch andere Leute Ergebnisse beisteuern und evaluieren können. Liegt wahrscheinlich an den 32 Bit Soft-Routinen der newlib. Die musste ich leider wegen C99 benutzen. Beim Keil Compiler sind die soft-floats natürlich hoch optimiert (asm). Daniel
Daniel schrieb: > Liegt wahrscheinlich an den 32 Bit Soft-Routinen der newlib. Das erklärt die langsamen Softfloats. Aber nicht das schlechtere Abschneiden bei Hardfloats.
Statt newlib die optimierte Lib verwendet: RX610, gcc -O2 -std=c99 -m32Bit-doubles, KPIT: 292 Cycles @20 MHz 14,6 µs @100 MHz 2,92 µs
Nachtrag: Der Regel-Algo benutzt ja nicht nur Fließkommaberechnungen, so dass die FPU hier nicht voll zum tragen kommt.
Daniel schrieb: > Bin aber auch kein RX600 Profi, heute das erste mal sozusagen. Ich finde es ganz toll, dass Du Dir die Mühe gemacht hast! Von Renesas kann man sich auch deren Compiler herunterladen. (Ich will jetzt aber nicht frech werden :-) Soweit ich das sehe, sind die Renesas-Compilate auch besser, weil sie speziell für den Zielprozessor den Code erzeugen. GCC kann das nicht (voll) leisten; aber bei dessen 'Preis' darf man auch nicht meckern. Daniel schrieb: > @100 MHz 2,92 µs Hier zeigt sich, dass die Testroutine doch zu kurz ist. Andererseits sieht man, dass solche Berechnungen auch locker im Interrupt ablaufen könnten.
Noch etwas zu GCC: bei 68k und SH Prozessoren setze ich immer die Option -fomit-frame-pointer.
> bei 68k und SH Prozessoren setze ich immer die Option > -fomit-frame-pointer. Das ist doch der default bei: -O, -O2, -O3, -Os. Benutzt du keine Optimierung? Olaf
m.n. schrieb: > Soweit ich das sehe, sind die Renesas-Compilate auch besser, weil sie > speziell für den Zielprozessor den Code erzeugen. GCC kann das nicht > (voll) leisten; aber bei dessen 'Preis' darf man auch nicht meckern. Man darf allerdings nicht die Librarys vergessen, beim gcc häufig die newlib. Bei den Proprietären Produkten sind die Libs meistens speziell für den Zielprozessor in asm optimiert. m.n. schrieb: > Hier zeigt sich, dass die Testroutine doch zu kurz ist. Das ist ja auch gar keine Testroutine, ich will ein Modul vom PC auf einen Mikrocontroller portieren (deswegen auch float und double) und wollte mir erst einmal einen Überblick verschaffen, wie es grob mit der Laufzeit aussieht. Der CM3 ist so schnell, dass ich mir die Umwandlung in Fixpoint Berechnung locker sparen kann. Mann könnte ja mal fiese Astronomische Bahnberechnungen durchlaufen lassen. Mit sin, atan2, cos... Werde die Tage mal nach entsprechenden Open Source Projekten suchen und dann einen neuen Thread aufmachen. Oder hat jemand einen Open Source Benchmark mit floats und doubles?
Olaf schrieb: > Das ist doch der default bei: -O, -O2, -O3, -Os. Allgemein kann ich das so nicht bestätigen. Beim H8SX (habe ich gerade zu laufen) und GNUH8-V11.01 und -O2 wird ohne zusätzliche Option erzeugt: mov.l er6,@-er7 mov.l er7,er6 stm.l er4-er5,@-er7 sub.l #40,er7 -fomit-frame-pointer sorgt für: stm.l er4-er6,@-er7 sub.l #36,er7 Das (unnütze) Anlegen eines frampointers frisst merkliche Zeit natürlich erst bei vielfachen Funktionsaufrufen. Ich werde die Sache im Auge behalten, wenn ich andere CPUs auf dem Tisch habe. Daniel schrieb: > Der CM3 ist so schnell, dass ich mir die Umwandlung > in Fixpoint Berechnung locker sparen kann. Vielleicht ist Fixpoint durch die Umwandlung sogar langsamer :-)
Olaf schrieb: >> Schade, hätte ich gerne mit RX getestet. > > Und ich gerne mal auf nem SH2A. Was uns aber zu einer interessante Frage > bringt, gibt es eigentlich irgendwo mal einen herstellerunabhaengigen > Vergleichstest verschiedener Microcontroller? Das waere doch mal ganz > interessant. > > Olaf Wie man's nimmt Coremark http://www.coremark.org/benchmark/index.php RX610 mit KPIT 2.34 Coremark/MHz K60 (Freescale, Cortex-M4 z.T. auch mit FPU) mit GHS 2.37, mit Keil 2.17 An den TO: RX600, K60, PIC32 (Nachteil 3)) oder wenn's ein M3 sein soll, mal die FM3 von Fujitsu ansehen (Eclipse+gcc 1) und u.U. interessant: Long term Availability 10 years + 2)) 1) http://www.glyn.de/News-Events/Newsletter/Newsletter-2011/Oktober-2011/Hier-kostenlos-runterladen-Entwicklungs-Umgebung-fuer-FUJITSU-FM3-Mikrocontroller 2) http://www.fujitsu.com/downloads/MICRO/fme/documentation/a45.pdf 3) C++ wird beim PIC32 offiziell nicht unterstützt http://www.microchip.com/forums/m579761.aspx
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.