Hallo Leute! Kann mir jemand definitiv sagen, welche max. Geschwindigkeit ein FTDI USB 2.0 high-speed Chip (z.B. FT2232H) über Virtual COM Port (VCP) Treiber schafft? Irgendwie konnte ich das nicht aus den Datasheets ableiten. Ich möchte den Chip evtl. an ein FPGA klemmen. Danke im Voraus. Grüße, Anguel
Schau mal im Hyperterminal nach. Dort kann man maximal 921600 Bits pro Sekunde einstellen. Und das habe ich mit einem FTDI USB 1.1 Chip auch schon geschafft. Zwar schleichen sich bei höheren Geschwindigkeiten auch mehr Fehler ein, aber das ist ja ein anderes Problem.
Danke für den Tipp! Leider habe ich den Chip noch nicht. Sowas müsste doch in einem Datasheet stehen. Ich habe an FTDI geschrieben, mal sehen was die antworten. mki schrieb: > Schau mal im Hyperterminal nach. Dort kann man maximal 921600 Bits pro > Sekunde einstellen. Und das habe ich mit einem FTDI USB 1.1 Chip auch > schon geschafft. Zwar schleichen sich bei höheren Geschwindigkeiten auch > mehr Fehler ein, aber das ist ja ein anderes Problem.
Zu dem FT2232H kann ich nichts sagen, aber dem FT245 habe ich schon
>500kByte/s in der Richtung PC->FT245 über den VCP entlocken können.
In umgekehrter Richtung waren es glaube ich um die 300kByte/s.
Mit dem D2XX Treiber waren in Richtung PC auch mal 700kByte/s möglich.
Das Ding ist also ganz schön flott wenn die Hardware nachkommt die Daten
wegzuschaffen, bzw. zu liefern.
Interessant, eigentlich redet FTDI von Unified Driver Model und der COM Port ist eh nur virtuell, trotzdem gibt es Unterschiede in der Geschwindigkeit im Vergleich zu D2XX. Ist die Geschwindigkeit der virtuellen COM Ports eigentlich durch etwas begrenzt, oder könnte ich unter Windows auch Datenraten von 2MByte/s z.B. mit LabVIEW erreichen? Benedikt K. schrieb: > Zu dem FT2232H kann ich nichts sagen, aber dem FT245 habe ich schon >>500kByte/s in der Richtung PC->FT245 über den VCP entlocken können. > In umgekehrter Richtung waren es glaube ich um die 300kByte/s. > Mit dem D2XX Treiber waren in Richtung PC auch mal 700kByte/s möglich. > Das Ding ist also ganz schön flott wenn die Hardware nachkommt die Daten > wegzuschaffen, bzw. zu liefern.
Anguel S. schrieb: > Interessant, eigentlich redet FTDI von Unified Driver Model und der COM > Port ist eh nur virtuell, trotzdem gibt es Unterschiede in der > Geschwindigkeit im Vergleich zu D2XX. Vermutlich liegt das an dem zusätzlichen Overhead durch die Weitergabe der Daten an das Betriebssystem, während man mit D2XX direkt in den Puffer des FTDI Treibers schreiben kann (und damit schön einen Bluescreen erzeugen kann, da FTDI einen Pufferüberlauf beim Senden nicht abgefangen hat).
"RS232/RS422/RS485 UART Transfer Data Rate up to 12Mbaud. (RS232 Data Rate limited by external level shifter)." Datenblatt FT2232H. 1. Seite
Da ist aber gar kein External Level Shifter wenn alles direkt über USB geht oder verstehe ich etwas falsch? ich schrieb: > "RS232/RS422/RS485 UART Transfer Data Rate > up to 12Mbaud. (RS232 Data Rate limited by > external level shifter)." > > Datenblatt FT2232H. 1. Seite
Anguel S. schrieb: > ich schrieb: >> "RS232/RS422/RS485 UART Transfer Data Rate >> up to 12Mbaud. (RS232 Data Rate limited by >> external level shifter)." >> >> Datenblatt FT2232H. 1. Seite > > Da ist aber gar kein External Level Shifter wenn alles direkt über USB > geht oder verstehe ich etwas falsch? Mit der USB-Seite hat das nix zu tun. Das heisst blos das, wenn du einen externen Pegelwandler an der RS232-Seite des FTDI anschliesst, der mit dieser hohen Geschwindigkeit auch mitkommen muss (mit standard MAX232 ist schon bei 115k Schluss). Wenn du die ganze Geschichte an einen FPGA haengen willst brauchste natuerlich wahrscheinlich gar keinen Konverter => kein Problem. Sebastian
Genau das meinte ich. Sebastian B. schrieb: > Wenn du die ganze Geschichte an einen FPGA > haengen willst brauchste natuerlich wahrscheinlich gar keinen Konverter > => kein Problem.
Antwort von FTDI: The speed is not only decided by the driver type but also many other factors such as operation mode and so on. Please refer to the application note: http://ftdichip.com/Documents/AppNotes/AN232B-04_DataLatencyFlow.pdf Werde mir das ganze mal anschauen. Leider ist die App Note schon etwas älter.
Der COM-Treiber wird in jedem USB Mikroframe nur einen Read request absetzen. Mit 512 Bytes USB Blocksize und davon 2 Bytes Statusinformation kommt man dann maximal auf 8000 x 510 Byte = 4MByte/Sekunden. Ein extra Treiber oder ein Programm, dass libusb oder evt auch libftd2xx nutzt, kann auch mehr Requests pro Mikroframe absetzen und so deutlich hoeher kommen. Ob der VCP Treiber eine entsprechend hohe Bausrate setzen kann, ist eine andere Frage.
Uwe Bonnes schrieb: > maximal auf 8000 x 510 Byte = > 4MByte/Sekunden. > Ob der VCP Treiber eine > entsprechend hohe Bausrate setzen kann, ist eine andere Frage. Vielen Dank für die Info! 4MByte/s hört sich gut an, auch wenn nur theoretisch - müsste ich dann also kaufen und testen :) Die Frage ist letztendlich, welcher USB 2.0 Chip für meine Anwendung am besten geeignet ist. Am besten beschreibe ich aber zuerst, was ich genau machen möchte: Ich sample Daten mit einem A/D-Wandler der am FPGA hängt, verarbeite diese evtl. und streame sie an einen Host-PC über USB 2.0 (auf dem PC läuft z.B. LabVIEW). Die geforderte Datenrate ist dabei ca. 2 MByte/s. Der Host-PC sendet nur kurze Befehle an das FPGA, um z.B. zu sagen, wann das Streaming starten bzw. enden soll. Welcher USB 2.0 Chip wäre aus eurer Erfahrung in meinem Fall am besten geeignet? FTDI? Cypress? Ich kenne bisher nur die FTDI Chips und davon nur die langsameren. Ich wollte FTDI nutzen, weil der Treiber viele Betriebssysteme unterstützt und das gute am VCP Treiber ist, dass man das Ding dann als normalen COM-Port sieht. Ich sehe, dass Xilinx auf deren Demo-Boards den Cypress USB 2.0 Chip verwendet. Wäre das eine gute Alternative? Danke im Voraus für jede Empfehlung. Grüße, Anguel
Also wir verwenden für sowas (nur bissl schneller) den Cypress FX2 im Slave FIFO Modus. Geht super und liefert knapp 40MB/s, wenn man die daten schnell genug anliefern kann und der PC auch schnell genug abnimmt. Und man muss große Blöcke übertragen, sonst hat man die gleichen 4MB/s Maximum.
Danke Christian! Hab in der Zwischenzeit auch nochmal geschaut und so ziemlich alle Designs scheinen FX2 zu verwenden. Soweit ich das überblicke, sollte es auch für die meisten Betriebssysteme (Win, Linux, Mac OS) auch Standardtreiber von Cypress geben, so dass das Gerät sofort erkannt wird, oder? Christian R. schrieb: > Also wir verwenden für sowas (nur bissl schneller) den Cypress FX2 im > Slave FIFO Modus. Geht super und liefert knapp 40MB/s, wenn man die > daten schnell genug anliefern kann und der PC auch schnell genug > abnimmt. Und man muss große Blöcke übertragen, sonst hat man die > gleichen 4MB/s Maximum.
Mit dem FT2232H wirst Du keine Probleme haben dies zu schaffen. die ganzen Beiträge gehen noch von den älteren Versionen aus. Der H-Typ kann sowohl parallel als auch seriell betrieben werden. Im parallelen Betrieb kann pro Kanal je 12 MByte übertragen werden. Davon hast Du im Notfall ja zwei. Der H-Typ ist ja ein High-Speed-Device (480 M-Bit). Die älteren Typen sind nur Full-Speed. Allerdings solltest Du den Chip im parallelen Mode betreiben. Seriell sind maximal 12 MBaud möglich. Also ca. 1 MByte Pro Kanal. Viel entscheidender ist aber die PC-Seite. Dort müssen die Daten ja auch zeitlich abgeholt werden können. Wenn der PC mal schnell in einen dummen Task abtaucht oder ein anderes USB-Device angesteckt wird, dann taucht der Rechner auch mal schnell für einige Sekunden ab. Es wäre deshalb durchaus sinnvoll mal so 10 Sekunden Daten zwischenspeichern zu können. Also Speicher am FPGA nicht vergessen. Mit dem internen kommst Du da nicht weit. Egal was für ein Chip verwendet wird. Das Problem mit dem Puffer besteht überall. Alternativ kannst Du ja mal über Ethernet nachdenken.
Richtig, der FX2 ist ziemlich verbreitet. Wahscheinlich weil das nahezu das einfachste USB 2.0 HighSpeed Bauteil ist. Puffern muss man natürlich echt viel, wenn man durchgängig hohe Datenraten fahren will. Treiber gibts zumindest für Win und Linux, geht ja auch mit der LibUSB problemlos.
FX2 braucht eine eigene Firmware, FT2232H braucht keine Firmware...
Wäre das Problem mit dem Puffern durch Ethernet behoben? Matthias G. schrieb: > Egal was für ein Chip verwendet wird. Das Problem mit dem Puffer besteht > überall. > > Alternativ kannst Du ja mal über Ethernet nachdenken.
Habe leider bisher nicht so viele Referenzimplementierungen mit dem FTDI gefunden, während der FX2 fast schon eine Art "Standard" zu sein scheint. Außerdem lese ich auch negetives über FTDI: http://www.embeddedrelated.com/usenet/embedded/show/108794-1.php http://www.8052.com/forum/read/161005 Uwe Bonnes schrieb: > FX2 braucht eine eigene Firmware, FT2232H braucht keine Firmware...
Der FX2 ist schon meherer Jahre auf dem Markt, der FT2232H erst seit letztem Jahr. Das erklaert die Anzahl der veroeffentlichten Designs. Ob die Probleme un den Baustein, oder in dem liegen, was die Leute damit machen, kann ich nicht sagen. Ich habe zwar ein Demoboard, bin aber noch nicht zum Programmieren gekommen...
Würde mich diesbezüglich jederzeit auf Feedback freuen. Wo kann man eigentlich so ein Demo-Board kaufen? Uwe Bonnes schrieb: > Ob die Probleme un den Baustein, oder in dem liegen, was die Leute damit > machen, kann ich nicht sagen. Ich habe zwar ein Demoboard, bin aber noch > nicht zum Programmieren gekommen...
Hi, die VCP-Treiber bringen nicht die optimale Performance, besser faehrt man mit den D2XX-Treibern im FIFO oder MPSSE-Mode. Zur Anbindung ans FPGA ist die FIFO-Schnittstelle ziemlich simpel zu implementieren, wenn Du genug Pins hast. SPI habe ich noch nicht probiert, aber JTAG schafft beim maximalen Clock schon ca. 2MByte/s transfer (und das Protokoll ist nicht effizient). Ich benutze den 2232H v.a. unter Linux via modifizierte libftdi und kann den Chip ziemlich bedingungslos empfehlen. Mit einem wirklich dummen Protokoll, dass viele Reads/Writes macht, sind's um die 5MByte/s an write, bei read etwas weniger. Den FX2 habe ich auch eingesetzt, der Chip ist auf jeden Fall lecker, aber fuer die meisten Zwecke zu komplex, da wie gesagt, Firmware noetig (viel Spass beim Debugging..) Ausserdem gibt es die ueblichen laestigen Nachteile: Wer sein Geraet auf den Markt werfen moechte, muss sich mit den bescheuerten VID/PID policies der usb.org herumschlagen. Bei FTDI ist man da eher generoes mit einem kostenlosen PID 8er-Block. Zum Thema Referenzimplementierungen: Der 2232H ist gegenueber dem 2232L softwarekompatibel, Designs lassen sich also sehr leicht 'upgraden'. Gruss, - Strubi
Noch mal zur Frage Datenbuffer: Um den wird man bei keinem Bussystem herum kommen. Das hängt in Deiner Anwendung aber vor allem an der PC-Seite. Betriebssystem etc. Die neueste FTDI-Generation habe ich noch nicht in Verwendung, aber bei den älteren ist die Handhabung denkbar einfach. Ein virtueller COM-Port ist sehr leicht überall zu implementieren. Dadurch, dass der Virtuell ist, hat der ja nichts mit Gewschwindigkeit zu tun. Auf der Hardwareseite ist quasi ebenfalls nichts zu tun. Also schon fast Hardware-Plug-and-Play. Wenn es nicht zwingende Gründe gibt, wäre für mich die FTDI-Lösung die 1. Wahl. Noch mal zurück zur Ethernetschnittstelle: Ethernet ist im Vergleich zu USB deutlich robuster. Mal abgesehen von der Netwerkfähigkeit etc. bietet das physische Übertragungsmedium schon eine galvanische Trennung (Trafos in oder vor der Buchse). Dadurch ist es deutlich weniger Störanfällig und es kommt auch nicht zu Masseschleifen, die vor allem bei Analog-Anwendungen immer wieder zu Problemen führen. Zudem "kakt" bei ESD, Burst und Surge regelmäßig die USB-Schnittstelle weg. Daher: USB ist nicht Insustrietauglich (außer für Firmwareupdates) und auch nur Bedingt Labortauglich, wenn es um Messungen geht. Vorteil USB: Bei moderatem Energiebedarf und lokaler Anwendung als Stand-Alone-Gerät kann man über ein Kabel alles erschlagen. Und bei Verwendung von solchen Schaltkreisen wie die von FTDI wird auf der Hardware für die Schnittstelle kein Controller benötigt.
USB als per se nicht industrietauglich abzutun, halte ich für gewagt. Wir haben hier ordentlich ausgeführte USB Verkabelungen in harschen Umgebungen im Einsatz, durchdachtes EMV Design mit FX2 als Device Controller. Bisher ist auch in den rauhen Umgebungen noch nicht ein Byte verloren gegangen. Das kommt nur mal an schrottigen USB Host Controllern vor, mit VIA kann man da viel Spaß haben. Ethernet ist an sich super, allerdings ist der Aufwand einige Größenordnungen höher als bei USB.
Matthias G. schrieb: > Ein virtueller COM-Port > ist sehr leicht überall zu implementieren. Dadurch, dass der Virtuell > ist, hat der ja nichts mit Gewschwindigkeit zu tun. Auf der > Hardwareseite ist quasi ebenfalls nichts zu tun. Also schon fast > Hardware-Plug-and-Play. Wenn es nicht zwingende Gründe gibt, wäre für > mich die FTDI-Lösung die 1. Wahl. Für mich auch, dumm nur, dass der VCP Treiber anscheinend doch langsamer ist als der D2XX (siehe andere Postings)... Sonst würde ich die FTDI VID/PID drin lassen und dann läuft das Teil auf etlichen Betriebssystemen ohne Problem und man kann es in allen Programmiersprachen als Seriellen Port ansprechen (mein Target ist vor allem LabVIEW). > Noch mal zurück zur Ethernetschnittstelle: > Ethernet ist im Vergleich zu USB deutlich robuster. Ich würde es natürlich vorziehen, aber die Nachteile von Ethernet die ich sehe: 1. Kein Host-Powered-Mode wie bei USB. Welcher PC hat schon PoE? 2. Wie konfiguriere ich die IP-Adresse. Wenn Lantronix nur Ethernetchips mit parallelem Interface anbieten würde, wäre alles einfach... 3. Man braucht einen Switch, da man am Laptop meist nur einen Ethernet-Port hat. 4. Implementierung im FPGA: Man braucht EDK. Ok kostet nicht die Welt, aber was für einen FPGA-Chip soll man dann nehmen? XC3S500E soll evtl. zu klein für Ethernet Lite sein?
Christian R. schrieb: > USB als per se nicht industrietauglich abzutun, halte ich für gewagt. Ok, da gebe ich Dir recht. > Wir haben hier ordentlich ausgeführte USB Verkabelungen in harschen > Umgebungen im Einsatz, durchdachtes EMV Design mit FX2 als Device > Controller. Bisher ist auch in den rauhen Umgebungen noch nicht ein Byte > verloren gegangen. Das kommt nur mal an schrottigen USB Host Controllern > vor, mit VIA kann man da viel Spaß haben. Meist hat man in den Anwendungen aber auch eine galvanisch Trennung am USB-Controller zur eigentlichen Hardware-Applikation. Damit ist aber auch gleich der Vorteil der Energieübertragung über USB mit hin. Man könnte da zwar auch noch mit DCDC-Wandlern arbeiten, aber auch die haben meist relativ hohe Kapazitäten zwischen Primär und Sekundär. Konkret hatte ich da schon Probleme, wenn dann in der Anwendung z.B. Hochspannungspulse >1kV mit 20-100A vorhanden sind (Prozessbedingt). Da reichen auch schon kleinste Kapazitäten über DCDC-Wandler für solche Effekte. Bei Ethernet gibt es da keinerlei Probleme. > Ethernet ist an sich super, allerdings ist der Aufwand einige > Größenordnungen höher als bei USB. Ja, leider. Es ist letztlich immer eine Entscheidung die im Hinblick auf die Gesamt-Anwendung bezogen werden muss. Zur Größe des FPGAs bei Ethernet ist immer die Frage, wie viel man vom "Ethernet" in den FPGA verlegen will. Eine Phy braucht man sowieso und es gibt ja auch Schaltkreise, die einen MAC und eine Phy enthalten. Da reicht dann ein kleiner 8-Bit µC im FPGA (oder sogar in einem CPLD). Oder man verwendet gleich einen externen µC mit MAC.
Matthias G. schrieb: > Zur Größe des FPGAs bei Ethernet ist immer die Frage, wie viel man vom > "Ethernet" in den FPGA verlegen will. Eine Phy braucht man sowieso und > es gibt ja auch Schaltkreise, die einen MAC und eine Phy enthalten. Da > reicht dann ein kleiner 8-Bit µC im FPGA (oder sogar in einem CPLD). > Oder man verwendet gleich einen externen µC mit MAC. Naja, wenn man nur 100MBt/s braucht, ist das alles recht entspannt. Bei GbE siehts schon schwieriger aus, da muss man dann schon einen Virtex 4 FX oder sowas auffahren....um die 40MB/s vom USB 2.0 zu erstzen. Übrigens gibts für galvanische Trennung und lange Kabel die IRanger Lösungen von Icron.
@Strubi: Hast Du Deine Modifikationen auf der linftdi Liste diskutiert? @Anguel S: Mit libUSB/libftdi kannst Du auch auf Windows auf die FTDI Chips zugreifen, auch wenn das System VCP Treiber geladen hat.
> Übrigens gibts für galvanische Trennung und lange Kabel die IRanger > Lösungen von Icron. Da kann man ja gleich WLAN oder was vergleichbares machen. Zudem ist die maximale Datenrate auf 54 MBit doch recht dürftig um dann reell auf die mittlere Datenrate von 4MByte zu kommen.
Matthias G. schrieb: >> Übrigens gibts für galvanische Trennung und lange Kabel die IRanger >> Lösungen von Icron. > > Da kann man ja gleich WLAN oder was vergleichbares machen. Zudem ist die > maximale Datenrate auf 54 MBit doch recht dürftig um dann reell auf die > mittlere Datenrate von 4MByte zu kommen. Deswegen Icron. Da kannst du Lichtleiter nehmen und hast die vollen 480MBit/s von USB 2.0, das Ding verhält sich wie ein Hub. Wir haben das in der Cat5 Variante, klappt wunderbar über 60m.
Matthias G. schrieb: > Zur Größe des FPGAs bei Ethernet ist immer die Frage, wie viel man vom > "Ethernet" in den FPGA verlegen will. Eine Phy braucht man sowieso und > es gibt ja auch Schaltkreise, die einen MAC und eine Phy enthalten. Da > reicht dann ein kleiner 8-Bit µC im FPGA (oder sogar in einem CPLD). > Oder man verwendet gleich einen externen µC mit MAC. Ich dachte da eher an etwas fertiges, was sich mit dem EDK zusammenclicken ließe :) Das Problem ist, dass ich noch keine FPGA-Erfahrungen habe. Meine Applikation würde so aussehen: Sampling mit 1 MSample/s mit 16 bit A/D. Gesamplete Daten werden entweder in externes DDR SDRAM gepackt und später auf Anforderung zum PC übertragen oder aber gleich über USB (oder evtl. Ethernet) gestreamt. Da klar wurde, dass auch Buffering benötigt wird, könnte man IMHO den externen RAM auch gleich als Puffer nutzen. Tipps sind an dieser Stelle herzlich willkommen :) Nun dachte ich bisher, dass das RAM-Interface (inkl. RAM-Controller) mit den Xilinx Tools (MIG) einfach zu realisieren wäre. Habe aber vorhin hier im Forum ein paar Beiträge gelesen und es scheint doch nicht so unproblematisch zu sein. Ob sowas in einen XC3S500E passt?
Anguel S. schrieb: Naja, EDK ist ohne Erfahrung ein steiler Weg. Aber Microblaze plus xps_ethernet_lite wäre schon ein Anfang. Dann aber noch den IP-Core (PLB-Slave oder FSL) für deine Hardware schreiben...naja. Für die Geschwindigkeiten reicht dir ja SRAM oder gar der interne BlockRam, da brauchst du keinen MIG (ist eher für SDRAM, DDR, DDR2...). Schau dir mal die Quellem vom gnuRadio an, FPGA plus Cypress FX2.
Hi Uwe,
> Hast Du Deine Modifikationen auf der linftdi Liste diskutiert?
Nee, ehrlich gesagt, weiss ich nicht mal mehr, was ich veraendern
musste. Irgendwas ging nicht, kann sein, dass es die Anzahl Ports (ev.
beim 4232-Typen) war. Werde mir demnaechst mal die neuesten Sourcen
ziehen und diffen, gehe mal davon aus, dass inzwischen auch die Userbase
fuer den 2232H gewachsen ist und sich die Anfangsprobleme geloest haben.
Irgendwas war da noch mit dem USB port claiming, aber aus Zeitmangel
habe ich mich darum nicht mehr gekuemmert.
Gruss,
- Strubi
Christian R. schrieb: > Für die Geschwindigkeiten reicht dir ja SRAM oder gar der interne > BlockRam, da brauchst du keinen MIG (ist eher für SDRAM, DDR, DDR2...). Hab ich mir auch so gedacht, leider hat das Spartan 3E Starter nur DDR SRAM :( > Schau dir mal die Quellem vom gnuRadio an, FPGA plus Cypress FX2. Danke für den Tipp! Das sieht sehr interessant aus. Sieht aber auch nach ziemlich viel Code aus. Wenn es nur VHDL wäre, so muss ich erstmal auch Verilog lernen :) Naja, ich glaube ich arbeite mich erstmal langsam in die Welt der FPGAs ein. Gibt es vielleicht ein gutes Buch, was vor allem die Zusammenhänge gut erklärt? Man findet hier und dort etwas, verliert aber so den Überblick, z.B. wie einzelne Module miteinander synchronisiert werden etc.
> Ich benutze den 2232H v.a. unter Linux via modifizierte libftdi und kann > den Chip ziemlich bedingungslos empfehlen. Mit einem wirklich dummen > Protokoll, dass viele Reads/Writes macht, sind's um die 5MByte/s an > write, bei read etwas weniger. Hi Strubi, Ich habe mir mal libftdi direkt aus dem Git-Repository gezogen und damit versucht eine Baudrate von 6 bzw 12 MBit/s einzustellen. Allerdings verweigert mir damit die Lib den Dienst mit der Meldung: "unable to set baudrate: -1 (Unsupported baudrate. Note: bitbang baudrates are automatically multiplied by 4)" Auf Grund der 5 M*Byte*/s die du angibst nehme ich zwar an, dass du eh nen andren Mode benutzt, aber der dürfte ja den gleichen Probs unterliegen. Wie hast du das geschafft, so hohe Datenraten einzustellen? Grüße, Chris
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.