Hallo, für ein Uni-Projekt zu ausfallsicheren Systemen, kam meiner kleinen Gruppe aus Kommilitonen die Idee auf, ein byzantinischer Verbund aus aktuell 4 gleichartigen "Rechnern" zu entwickeln. (einer ist "Hot-Spare" und die anderen drei arbeiten im Redundanzbetrieb (min. zwei-aus-drei Ergebnisse müssen identisch sein)). Jeder Rechner wird zur Kommunikation einen kleinen FPGA bekommen und als "Rechenknecht" ein Cortex-M7 Single-Core bekommen. - Um es hier kurz zu halten erzähle ich jetzt nicht von den unzähligen Watchdogs und Co. - Wir eh schon lang genug werden :P Das ganze ist erst einmal nicht auf Performance ausgelegt, sondern soll uns als Basis zum spielen und testen dienen. Auch haben wir nur Komponenten ausgewählt, mit denen wir schon gearbeitet haben, eben dem FPGA und dem Cortex-M7. Jeder Node muss hierzu mit jedem anderen kommunizieren können, was den FPGA als externen und schnellen N-fachen UART (sowohl als Applikation-Data-In, als auch der "Inter-Node-Communication), Router und einer Watchdogebene erforderlich macht. Wir haben auch einige Referenzen hierzu gefunden. u.A. das ATV (der Cargo-Versorger der ISS) soll einen solchen Verbund besitzen. Stand der Technik ist halt typisch 80er bis frühe 90er, spricht langsame Kommunikation (<= 1MBit) und Prozessor-Nodes (nebst toten Transputern) Wir sind uns bei der Software aber noch nicht sicher, wie wir diese umsetzten. Einigen kam auf die Idee, das die einzelnen Rechner doch am besten taktsynchron arbeiten sollten. Hierbei kam die Idee auf, ob es nicht auch Daten-Busse/Protokolle gibt, die Takt mitliefern. Viele Übertragungen haben eine Überabtastung von Datenströmen und extrahieren ja so die Daten (Ethernet als auch CAN machen das wohl so). Wir haben allerdings auch (wieder aus dem Weltraum) das SpaceWire gefunden. Dieses bietet die Möglichkeit, aus dem Datenstrom einen Takt zurück zu gewinnen. (Quelle: https://www.4links.co.uk/application/files/7515/4445/5470/6_SpaceWire-on-FPGA.pdf) Das hätte für uns mehrere Vorteile. Zum einen könnte man so ohne eine Feste Baudrate arbeiten, da die einzelnen Nodes sich automatisch auf den Bus synchronisieren und man so die Rechner Takten kann (Aufbereitung müsste der FPGA machen) und man könnte eben auch die gewünschte Taktsyncronität zwischen den Nodes erreichen. Ich finde die Idee der taktsynchronität noch nicht wirklich gut - ich würde das ganze lieber Task-Ergebnis basiert machen, aber die Idee ohne feste Baudrate zu arbeiten an sich schon! Habt ihr vielleicht noch Beispiele für die Taktrückgewinnung die mich umstimmen könnte?
Noisy Boy schrieb: > Wir haben allerdings auch (wieder aus dem Weltraum) das SpaceWire > gefunden. Dieses bietet die Möglichkeit, aus dem Datenstrom einen Takt > zurück zu gewinnen. Jede Fernbedienung mit RC5 Code macht das. Du kannst auch sonst irgend ein Manchester-codiertes Signal nehmen. Oder es wie solche Busse wie CAN und Sercos machen, die nach mehreren gleichen Bits einen Pegelwechsel einstopfen (Bitstuffing) oder anderweitig einen Pegelwechsel erzwingen, um sich darauf zu synchronisieren. Aber das mit irgend einer Taktsynchronität solltest du dir aus dem Kopf schlagen. BTW: das mit der Metastabilität auf Seite 3 mag für FPGAs weit vor der Jahrtausendwende gegolten haben. Heute sind Flipflops in FPGAs so schnell, dass Metastabilität bestenfalls im Bereich über 300MHz relevant wird.
:
Bearbeitet durch Moderator
Das LIN-Protokoll könnte dich weiterbringen. Auch als UPDI bei den AVM-Mikrokontrollern bekannt. Es Basiert auf der UART. Da wird das "U" vorausgeschickt. Das "U" bei der UART hat die Eigenschaft, dass jedes BIT wechselt, Damit kann man die Bitrate bestimmen.
Uwe K. schrieb: > Das "U" bei der UART hat die Eigenschaft, dass jedes BIT wechselt Dann könnte ich nur 0x55 oder 0xAA versenden, denn wenn ich 0x00 oder 0xFF übertrage, dann bleibt der Pegel für mindestens 8 Bits stabil. Deshalb ist es nicht ganz einfach, sich auf eine völlig unbekannte UART-Baudrate zu synchronisieren. Das U bedeutet lediglich, dass bei dieser seriellen Schnittstelle kein Takt übertragen wird. Bei anderen seriellen Schnittstellen wird dagegen der Takt explizit mitgeführt (I2C, SPI,...).
Beliebige Baudratenerkennung ist beliebig schwierig. Lasst das. Taktrückgewinnung ist bei allen synchronen Verfahren Standard, die nur einen Kanal (je Richtung) brauchen. Asynchron (Uart) geht auch mit MBaud und selbst GBaud. Der Vorteil bei z.b. Ethernet (auch z.b. BroaderReach) wäre das Gesamtpaket aus Treiber, Signalverlauf, Verarbeitung. Nehmt einen Standard, wenn es nur Baustein eurer eigentlichen Aufgabe ist. Uart mit 100MBit z.b.. dann könnt ihr zum testen auf 1MBit runtergehen und mit beliebiger Standard-HW/SW testen/Fehler suchen. Oder HDLC wenn es einfach und synchron sein soll. Beide, asynchron und synchron arbeiten einkanalig mit fester Baudrate @ 3..5% Toleranz. Asynchron heißt: ein Paket ist kleiner als dass das zum Problem wird. Synchron heißt: es kommen ganz sicher früh genug Flanken um sich neu zu "synchronisieren". Entweder durch z.b. Manchester-Codierung oder Bitstuffing. Baudratenerkennung ist dazu orthogonal: bei beiden möglich aber problematisch.
Noisy Boy schrieb: > Hierbei kam die Idee auf, ob es nicht auch Daten-Busse/Protokolle gibt, > die Takt mitliefern. Das zeugt von bemerkenswerter Unkenntnis. Solche Verfahren sind seit vielen Jahrzehnten üblich, die Takt-Rückgewinnung ist schon in uralten UART-ICs hardwaremässig implementiert (digital phase-lock loop), z.B. Z8530 aus dem vorigen Jahrhundert. Das HDLC-Protokoll ist ISO-genormt und wurde 1979 (!) eingeführt. Georg
Lothar M. schrieb: > Das U bedeutet lediglich, dass bei dieser seriellen Schnittstelle kein > Takt übertragen wird. Nein. Dafür ist das "A" zuständig. Das U bedeutet ganz im Gegenteil, dass die Schnittstelle auf Wunsch auch einen Takt übertragen kann.
c-hater schrieb: > Dafür ist das "A" zuständig. Stimmt: Universal Asynchronous Receiver/Transmitter > Das U bedeutet ganz im Gegenteil, dass die Schnittstelle auf Wunsch auch > einen Takt übertragen kann. Das wäre eher das S in USART: Universal Synchronous/Asynchronous Receiver/Transmitter
Lothar M. schrieb: > Das wäre eher das S in USART: > Universal Synchronous/Asynchronous Receiver/Transmitter Könnte sein. Aber welche Funktion bleibt denn dann noch für das U?
Warum das Fahrrad neu erfinden und zudem erstmal mit eckigen Rädern? Für kleines Geld gibt es 10GbE Ethernet, da kannste Deine schnarchlahme UART voll vergessen.
:
Bearbeitet durch User
A. S. schrieb: > Nehmt einen Standard Das spart Euch 100-te Mannjahre an Eigenentwicklung. Es sei denn, es soll nichts verwertbares rauskommen.
Peter D. schrieb: > Warum das Fahrrad neu erfinden und zudem erstmal mit eckigen Rädern? Multi-Slave mit UARTs muss man nun wirklich nicht neu erfinden. Das ist eine seit Jahrzehnten in unzähligen Anwendungen bewährtes Konzept. > Für kleines Geld gibt es 10GbE Ethernet, da kannste Deine schnarchlahme > UART voll vergessen. Und das macht inwiefern irgendeinen Sinn, wenn eine schnarchlangsame UART für die Anwendung völlig ausreichend ist? Insbesondere unter Berücksichtigung der Kosten?
c-hater schrieb: > Und das macht inwiefern irgendeinen Sinn, wenn eine schnarchlangsame > UART für die Anwendung völlig ausreichend ist? FPGA und ARM7 klingt nach Tempo. Man muß ja nicht 10GbE benutzen, Ethernet geht auch bei 1 oder 0,1GbE. Der große Vorteil von Ethernet ist, in den meisten MCs ist es integriert und es gibt fertige Libs und vor allem zuverlässige und erprobte Protokollstacks dafür. Ich würde mir nicht anmaßen, mal eben einen zuverlässigen Stack selber entwickeln zu können. Selbst wenn man mir 10 Jahre Zeit und 10E6€ dafür gibt. Wenn es langsam sein darf, ginge auch CAN/CAN FD. Es gibt ARM mit 4 CAN-Bussen.
:
Bearbeitet durch User
Peter D. schrieb: > Der große Vorteil von Ethernet ist, in den meisten MCs ist es integriert Das würde ich dann doch sehr bezweifeln. Die allermeisten MCs haben schlicht keinerlei Unterstützung für Ethernet und im höheren Segment haben sie zumindest überwiegend keinen eingebauten PHY. Außerdem ist Ethernet "teuer" im Sinne des Energiebedarfs. Als Folgeschaden sind also oft auch noch Aufrüstungen bei der Versorgung nötig. Also selbst bei den Teilen, die zumindest grundlegende Unterstützung für Ethernet bieten, kann dann die tatsächliche Verwendung die Kosten sehr deutlich in die Höhe treiben.
Lothar M. schrieb: > Du kannst auch sonst irgend ein Manchester-codiertes Signal nehmen. Ich plädiere ebenfalls für Manchester - ändere aber minimal in Richtung BMC ab: Das ist fast Dasselbe und codiert etwas anders, stellt aber auch einen 1b2b dar. Der Takt ist damit sehr engmaschig und ohne Aufwand rekonstruierbar. Konkret wird der Code bei S/PDIF verwendet, was in Form von AES/EBU bis 50Mbps spezifiziert ist und in nicht zu sehr gestörten Umgebungen bis zu 100m läuft. Das wäre dann ein RS422-Signal, also differentiell. Jeder gute Studio-ADDA nimmt das an und übersetzt es auf USB. Auch als Consumer über TOS oder Coax läuft das hervorragend bis 50m auf 12,288Mbps und ist so von jeder Soundkarte aus auslesbar, wenn die einen S/PDIF hat. Ich habe 48kHz-Signale (also 3Mbps schon mit 5 Kupplungen über 100m bekommen). Es gibt da verschiedene Libraries, das dann über mit PCs über API auszulesen. http://www.synthedit.com bietet da einiges. Auch über VST geht das. Wenn ihr unter Linux arbeiten möchtet, hat es auch das Libs zu. Damit bekommt ihr die PCs ohne Aufwand auf Microsekunden genau gesynched, wenn ihr TimeCodes für die Tasks im Voraus übertragt, auf die ein Programm dann wartet und ad hoc reagiert. Bei 192kHz und einem PC mit GHz CPU seid ihr dann auf bis zu 5us genau. In Echtzeit hängt dann halt noch Windows-Zeitscheiben und USB-Latenz dazuwischen. Die billigste Lösung ist wahrscheinlich, die PCs mit einigen USB-S/PDIF Wandlern aus der Bucht zu 19,99 das Stück zu vernetzen.
Noisy Boy schrieb: > Hierbei kam die Idee auf, ob es nicht auch Daten-Busse/Protokolle gibt, > die Takt mitliefern. Informier dich zum Stichwort "Leitungscodes" bzw "Kanalkodierung". Ein brauchbarer Einstieg wäre z.B. https://de.wikipedia.org/wiki/Leitungscode oder https://de.wikipedia.org/wiki/Kanalkodierung - auch der dort erwähnten Quellen. Besser noch: Holt euch Hilfe beim Fachbereich "Nachrichtentechnik" an eurer Uni ...
Lothar M. schrieb: > Uwe K. schrieb: >> Das "U" bei der UART hat die Eigenschaft, dass jedes BIT wechselt > Dann könnte ich nur 0x55 oder 0xAA versenden, denn wenn ich 0x00 oder > 0xFF übertrage, dann bleibt der Pegel für mindestens 8 Bits stabil. > Deshalb ist es nicht ganz einfach, sich auf eine völlig unbekannte > UART-Baudrate zu synchronisieren. > > Das U bedeutet lediglich, dass bei dieser seriellen Schnittstelle kein > Takt übertragen wird. Bei anderen seriellen Schnittstellen wird dagegen > der Takt explizit mitgeführt (I2C, SPI,...). Das "U" erzeugt eine Rechteckimpuls am Anfang der Übertragung, um die Baudrate zu ermitteln. U einspricht 0x55. binär: 0101 0101. Die UART sendet das LSB zuerst und hat "1" als Ruhepegel. Bei 8N1 sieht das dann so aus: 11111 0 10101010 11111111111111 - Ruhe - Start-Bit - "U" - Stop-Bit und Ruhe An diesem Rechtecksignal wird die Baudrate der UART ermittelt. Danach ist die Baudrate bekannt und die UART arbeitet wie gewohnt. Das "U" hat als Buchstabe keine Bedeutung. Es geht nur um die Bit-Folge. So lassen sich über die UART fast beliebige und ungenaue Baudraten verwenden und man ist nicht auf eine feste Baudrate beschränkt.
Uwe K. schrieb: > Das "U" erzeugt eine Rechteckimpuls am Anfang der Übertragung, um die > Baudrate zu ermitteln. Nein, das ist völlig hirnlose gequirlte Kacke. Ja, bei UARTs gibt es ein Startbit, soweit stimmt das. Allerdings können unmittelbar nach diesem Startbits Nutzbits mit demselben Pegel folgen. Deswegen ist das Startbit alleine völlig unbrauchbar zur Bestimmung der Baudrate. Das kann allenfalls in Kombination mit einem geeigneten Protokoll klappen, welches z.B. vorschreibt, dass das erste "Nutzbit" (welches eben durch dieses Protokoll dann aber kein solches mehr wäre) den alternativen Pegel zu haben hat.
Ob nun U oder A, in Kombination mit einem geeigneten Protokoll wird es schon verwendet. https://en.m.wikipedia.org/wiki/Automatic_baud_rate_detection
c-hater schrieb: > Uwe K. schrieb: > >> Das "U" erzeugt eine Rechteckimpuls am Anfang der Übertragung, um die >> Baudrate zu ermitteln. > > Nein, das ist völlig hirnlose gequirlte Kacke. Ich bin beim LIN-Protokoll. https://www.ni.com/de-de/innovations/white-papers/09/introduction-to-the-local-interconnect-network--lin--bus.html#section--1299403952 Ein Blick auf das Sync-Zeichen. Zitat: "Sync wird definiert als das hexadezimale Zeichen x55". Und welches Zeichen ist HEX 55 als ASCII? Ich Zitiere weiter: "Das Sync-Feld ermöglicht Slave-Geräten, die eine automatische Baudratenerkennung durchführen, die Periode der Baudrate zu messen und ihre interne Baudrate mit dem Bus zu synchronisieren." LIN ist also "völlig hirnlose gequirlte Kacke"? So hat jeder seine eigene Meinung...
Uwe K. schrieb: > "Das Sync-Feld ermöglicht Slave-Geräten, die eine > automatische Baudratenerkennung An den LIN-Bus erinnere ich mich noch dunkel. Ich denke aber nicht, dass man das hier braucht. Jester schrieb: > Informier dich zum Stichwort "Leitungscodes" bzw "Kanalkodierung". Bevor man sich einen eigenen Leitungscode baut oder es selber realisiert, sollte man auf etwas Vorhandenes zurückgreifen, wie o.g. Manchester / BMC. ... zumal die PCs dafür die Interfaces parat haben.
Jürgen S. schrieb: > Jester schrieb: >> Informier dich zum Stichwort "Leitungscodes" bzw "Kanalkodierung". > Bevor man sich einen eigenen Leitungscode baut oder es selber > realisiert, sollte man auf etwas Vorhandenes zurückgreifen, wie o.g. > Manchester / BMC. Einer meiner Kumpels plappert auch immer alles nach. Ist eigentlich ein ganz lieber Kerl - eigentlich ... Hatte ich dem TO nicht empfohlen, einen Nachrichtentechniker mit ins Boot zu holen? > ... zumal die PCs dafür die Interfaces parat haben. Welche PCs? TO "Noisy Boy" spricht von FPGA und Cortex-M7, mokiert sich über die "langsame Kommunikation der frühen 1990er". Und du salbaderst von "Manchester" - von Technik aus den 1940er? Holy moly - das war noch vor Shannon, noch vor der ENIGMA!!! Mit derart antiquiertem Geraffel lockst "Noisy" sicher nicht hinterm Ofen vor. Hatte er noch vor 'ner Woche ganz wild die Trommel gerührt - mimt er seither das exakte Gegenteil von "noisy", wirkt eher gelangweilt ob der altbackenen Diskussion hier.
Uwe K. schrieb: > So hat jeder seine eigene Meinung... ja so ist das wohl, wenn man von 2 verschiedenen 'U's spricht. Es gibt also (wie es scheint) bei manchen Protokollen ein synch 'U', das hat aber nichts mit dem 'U' von UART zu tun. Da bedeutet 'U' universell, wie schon oben irgendwo geschrieben.
:
Bearbeitet durch User
Moin, "U" ist doch voellig out zur Taktsynchronisierung. "G" ist der heisse Scheiss. So faengt schliesslich jedes Paket im MPEGTS an. Aus Gruenden. Zum Originalproblem: Fangt bloss nix eigenes, neues auf dem Gebiet mit eurem Wissenstand an. Es gibt schon fuer jede Anforderung zig Protokolle/Schnittstellen, in deren Entwicklung schon viel mehr Mannmonate geflossen sind, als ihr jemals aufbringen koennt. Gruss WK
Was ist an G besser? Ist das irgendeine Primzahl oder Magic-Sequenz? Außerdem wird ein mpeg-Stream sicherlich synchron als Packet abgearbeitet??
Hannes schrieb: > Einer meiner Kumpels plappert auch immer alles nach. Ist eigentlich ein > ganz lieber Kerl - eigentlich ... Die meisten meiner "Kumpels" haben die Angewohnheit, erst zu denken und dann zu plappern, falls es dir etwas sagt. Falls nicht: > dem TO nicht empfohlen, einen Nachrichtentechniker mit ins Boot Man braucht sicher keinen "Nachrichtentechniker" für derart triviale Anwendungen :-) > "Manchester" - von Technik aus den 1940er? Zu deiner Erhellung folgendes: a) Das etwas aus den 1940ern ist, heisst nicht dass es schlecht oder veraltet ist. Das meiste an Mathe was wir heute in FPGAs einbauen wurde vor 100 Jahren erfunden. b) Konkret ist Manchester und seine Derivate ganz genau DIE Lösung für das Problem, weil es nämlich die höchste Taktqualität im Bezug auf die Datenrate ermöglicht. Man ist ja nicht unbedingt an niedrige Raten gebunden, sondern kann an die Grenzen des jeweils im System Machbaren heran gehen. Manchester ist zudem auf einfachste Weise zu verarbeiten. > Mit derart antiquiertem Geraffel lockst "Noisy" sicher nicht hinterm > Ofen vor. Was wäre denn dein Vorschlag? Wenn es ein FPGA ist, dann hauen wir doch gleich Aurora mit 66 Bits rein. Dann hat etwas zu tun :-) Und zu dem Thema PC: Nicht ohne Grund habe ich den ins Spiel gebracht, weil solche Systeme ja auch irgendwie getestet und in Betrieb genommen werden müssen. Und dazu taugen PCs mit etwas Software noch am Besten. Konkret geht da nichts über S/PDIF, weil dies eben mit jeder Soundkarte zu senden und zu dekodieren ist. Und falls jemand immer noch meint, Manchester täte dafür nicht taugen: Genau das ist schon verwendet worden, um entfernt stehende Einheiten eines Teilchenbeschleunigers, welche denzentral agieren, perfekt zu synchronisieren.
Hi Leute, Sorry für die späte Rückmeldung! - War die Feiertage über unfreiwillig im Krankenhaus, mein Blinddarm ist mir-nichts/dir-nichts geplatzt :( Kann erst heute durch die doofe Naht erst wieder (ungut) am Tisch sitzen... Eure Diskussion zum UART und Co ging leider in eine falsche Richtung, oder schweifte etwas weiter, als ich es mir gedacht habe. Unsere Grundidee war es eigentlich, die Taktung der Logik mit Hilfe des FPGAs durch die Datenverbindung zu synchronisieren um so an mehreren Nodes zur selben Zeit - taktsynchron eben die selben Daten in den einzelnen CPUs zu haben um festzustellen, welche Node "falsch" liegt.
Noisy Boy schrieb: > taktsynchron eben die selben Daten in den > einzelnen CPUs zu haben um festzustellen, welche Node "falsch" liegt. Vielleicht solltest Du Deine genau Anforderung doch noch einmal spezifizieren. Wenn Du mit z.B. 20MBaud überträgst: - Willst Du quasi eine "Systemclock" mit 10MHz haben - oder reicht es, wenn der lokale Takt 2 Mio mal pro Sekunde auf 10 ns synchronisiert wird (das kann auch eine Uart-Verbindung, wenn das FPGA auf 100MHz läuft. ) Von welchen FPGA-Taktraten/Baudraten reden wir etwa?
Noisy Boy schrieb: > zur selben Zeit ... taktsynchron ... welche Node "falsch" liegt. Vergiss es. "taktsynchron" im Sinne von "1 Mastertakt im gesamten System" wird das nicht funktionieren, denn innerhalb der µC sind einige Dinge, die nicht völlig deterministisch sind. Allein die Signallaufzeiten auf der Leiterplatte oder innerhalb eines Chips machen dir da einen Strich durch die Rechnung. Und das natürlich besonders dann, wenn du kein völlig autistisches System hast, sondern auf asynchronen Input (Eingangssignale oder Daten) von "aussen" reagieren musst. Du musst dir also irgendeinen Mechanismus ausdenken, der dafür sorgt, dass so ein System auch mal ein paar "Takte" auseinanderlaufen kann, dann nicht gleich auf "Störung" geht, sondern die Abläufe dann auf den "langsamten" Teilnehmer synchronisiert. Dergute W. schrieb: > viele Mannmonate Viele Mannjahre. Von ausgewachsenen Ingenieuren, die dabei viel gelernt haben...
Noisy Boy schrieb: > Unsere Grundidee war es eigentlich, die Taktung der Logik mit Hilfe des > FPGAs durch die Datenverbindung zu synchronisieren um so an mehreren > Nodes zur selben Zeit - taktsynchron Siehe hier: Beitrag "Re: Taktrückgewinnung aus serieller Datenübertragung" - TimeCodes für die Tasks im Voraus übertragen, also Tasknummer + Timestamp - Prozess drauf warten lassen - Bei 192kHz bis 5us genau ... entscheidend dabei ist der time stamp und nicht etwas Echtzeitreaktion, wenn ein Ereignis eintrifft. Natürlich müssen die Uhren des System kalibriert werden, also Zähler, die sich anhand der CPU-Geschwindigkeiten entwickeln und synchrone Pulse vorgeben können, die dann durch eine "PLL" auf die eingehenden timestamps gesynched werden.
Lothar M. schrieb: > Vergiss es. "taktsynchron" im Sinne von "1 Mastertakt im gesamten > System" wird das nicht funktionieren, Naja, also beim Audio, das immer als so einfach und als niedrig anfordernde Technologie hingestellt wird, machen wir das schon seit 20 Jahren mit dem Word Clock und den kann man mit entsprechenden Methoden aufs Sample genau synchen. Damit sind Quellen wie digitale Mikrofone oder Pulte aufs Sample genau einstellbar und die Signale mischbar. Hab ich schon mit 2 scheinbar unabhängigen C414 gemacht, die als Stereo geschaltet waren. Man muss halt die Wandlerlatenzen ausmessen. Auch mit einem Microcontoller im System geht das, wenn der schnell genug abtastet nach dem o.g. Schema auf 2x 1/f = 10us genau.
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.