Hello ich bin auf der suche nach einem µC oder µP mit 32Bit Datenregister und Adressregister (wie z.B. der uralte MC68000) nur mit insgesamt 40 Datenregister und 15 Adressregister (mind. 8 Adressregister) mit 32Bit PeterK
Den gibt es wahrscheinlich nicht. Es sei denn, du definierst den Bergiff "Register" etwas weitläufiger und nennst RAM-Speicherzellen ebenfalls Register. Dann hast du plötzlich ganz viele davon :-) Was ich damit sagen möchte: Du hast vergessen zu schreiben, welche Eigenschaften von Prozessorregistern für dich so wichtig sind, bspw.: - Viele Register machen manchmal den Einsatz von externem RAM überflüssig, damit kann Platz eingespart werden. Alternative: Nimm einen Prozessor mit internem RAM. - Die Zugriffszeiten auf die Daten sollen sehr kurz sein. Alternative: Nimm schnelles RAM und einen schnellen Prozessor. Andere Gründe, warum man so viele Register bräuchte, fallen mir nicht ein. Aber dir vielleicht.
Besser du beschreibst was du machen willst, nen 32 BITter ist für viele Standardaufgaben völlig oversized. Gibt es irgendeinen zwingenden Grund für deine 32 BIT Entscheidung ?
AMD 29000 (tot) und Intel Itanium erfüll(t)en diese Bedingungen. Andere nur wenn man Fliesskommaregister grosszügig mitzählt.
ich möchte gerne 32Bit zeitgleich (ohne Verzögerung) in einem Assemblerbefehl rausjagen; Im µC werden die Bits zuerst richtig angeordnet in einem 32Bit Register, damit schon mal alle 32 Werte die zeitgleich rausmüssen in einem Register liegen die bits werden alle 20ms rausgeschickt und müssen zueinander synchron sein PeterK
nimm ne 32Bit lange Schieberegisterkette (4stk 595), lade die und latche sie alle gemeinsam, damit haste auch alle Zeitgleich am Bus... dafür reicht auch locker ein 8bitter. Und bei "alle 20ms" ist der mit 1Mhz noch gelangweilt. Gruß Fabian
Also die 20 mSec. sind ja eher gemütlich, wie sieht es mit 4 8 BIT Latches aus welche ein gemeinsames enable Signal verwenden. Du kannst dann deine 32 BIT beliebig einlatchen (asynchron) und mittels gemeinsamen enable Signal freischalten. Schon geht ein 8 BITter ;-)) gibt es weitere Gründe für 32 BIT ?
über ein Sync-Signal werden die 32Bits rausgeschickt - zeitgleich... zuvor liegen sie an den Datenregistern nur an
das mit den Latches hab ich mir auch schon überlegt, aber ich hab drei mögliche Synchronquellen, mit denen der Sendeimpuls ausgelöst werden kann - je nach dem welche halt ausgewählt wird. Die Impulse sind extern (z.B. über SMPTE)... deshalb dachte ich, wenn ich eh schon einen µC oder µP benötige, der auch noch gewisse Pausen generieren muss (deshalb 10MHz Takt, damit exakt die Zeiten ausrechnen kann, indem ich den Takt viertel etc.) PeterK
PeterK wrote: > die bits werden alle 20ms rausgeschickt und müssen zueinander synchron > sein Also 20ms is ja ne ganze Ewigkeit. Ein AVR braucht um 4 Bytes rauszujagen 0,0002ms. Das sollte doch dann synchron genug sein. Ich würde allerdings 4 * 74HC595 dranpappen, dann isses auf mindestens 5ns (= 0,000005ms) synchron. Peter
>> (z.B. über SMPTE)
Reden wir hier von TimeCode ? das ist doch sehr gemütlich und locker mit
nem 8 BIT MC zu schaffen.
Beschreib doch mal dein Idee ;-))
die 20ms sind die Abstände zwischen den Signalen - aber nicht zu verwechseln mit den Toleranzen innerhalb diese Signale liegen müssen... die sind deutlich kleiner... Zum Thema: es kommen über 8 Datenleitungen Bits an, die im µC richtig sortiert werden müssen und dann via Impuls (SMPTE etc.) rausgejagt werden. Zusätzlich müssen die Pausen etc. im µC generiert werden - aber nebnsache, ,mit 10MHz kann ich die mir alle genau herstellen. @Joe ja über Timecode (SMPTE oder anderen) werden die Signal getriggert bzw. zu andere Quellen synchronisiert @Peter die 4Bytes werden über separate Leitungen rausgeschickt, nicht über eine. d.h. 32Pins für die Ausgabe. Wie berechnen sich die 0,0002ms, nur damit ich das überschlagen kann? PeterK
Nochmal, das Ganze ist mit nem 8 BIT MC locker zu schaffen. Es gibt jede Menge 8 BIT Typen die Maschinentakte im nSec. Bereich schaffen. Deine 32 BIT lassen sich über Latches oder Schieberegister lösen. Wie rechnet man so etwas ? Schau dir die Anzahl der Maschinentakte pro Befehl an und dann rechne es aus.
nur noch eine frage - wieso brach ich dann noch Latches? Also wenn dann würd ich über einen 8Bit µC den ich brauch wegen den externen Signalen und der Auswahl über welchen Timecode das ganze laufen soll, und fertig. 4Ports mit 8Pins --> ca. 0.0008ms zeitlicher Abstand zwischen dem ersten 8Pins und den letzten 8Pins. Die Pins von einem Port können zeitgleich - also ohne Verzögerung - mit einem Inhalt eines Registers befüllt werden, oder? @Joe das mit der zeit ist mir auch grad aufgefallen - krggs... PeterK
PeterK wrote: > die 4Bytes werden über separate Leitungen rausgeschickt, nicht über > eine. d.h. 32Pins für die Ausgabe. Wie berechnen sich die 0,0002ms, nur > damit ich das überschlagen kann? Bei 20MHZ dauert ein OUT 50ns also 4 OUTs = 200ns Die Asynchronität ist dann die Zeit für 3 OUTs (150ns) bzw. 0,00075%. Oder mit den 4 * 74HC595 kann man alle Ausgänge gleichzeitig latchen, die Asynchronität dürfte weit unter 5ns liegen (Laufzeitdifferenz der CMOS-Gatter). Peter
Du willst 32 BIT synchron ausgeben. Mit einem 8 BIT Controller ist es nicht möglich diese Synchron in die Latches zu schreiben z.B. 4x 8 BIT auf die Latches schreiben. Beispiel: Du verwendest Schieberegister wie z.B. das 4094 und kaskadierst die zu 32 BIT. Nun muß der MC dein 32 BIT Datenwort in die Schieberegister hineinschreiben, das benötigt Zeit. Ist das 32 BIT Datenwort in die Schieberegister übertragen so lassen sich die 32 BIT mittels einem Freigabesignal auf einen Schlag herausschrieben (so wie du es brauchst). Das Ganze ist also nur eine Denksportaufgabe für ein entsprechendes Design.
Joe wrote: > Du willst 32 BIT synchron ausgeben. Mit einem 8 BIT Controller ist es > nicht möglich diese Synchron in die Latches zu schreiben Doch, wenn man Synchron definiert als Verhältnis zum Ausgabetakt und da sind 150ns alle 20ms schon verdammt synchron. Exakt synchron ist auch mit nem 32Bit-Register absolut unmöglich (unterschiedliche Gatterlaufzeiten, Leiterzuglängen, Schaltungskapazitäten, Schaltschwellen). Peter
Synchron ist Synchron und das was ich beschrieben habe kann mittels Synchronsignal die 32 BIT aus den Schieberegistern entlassen. Da wo ich arbeite sind 150 nSec. nicht synchron. Allerdings reden wir am Thema vorbei.
hallo Joe, das mit den Schieberegistern klingt gut - jedoch muss ich ja ein paar Formatierungen machen an den einzelnen Bits in punkto Reihenfolge und noch ein paar andere sachen, so dass ich einen µC oder µP auf jeden fall benötige, bevor ich die 32bit ausgeben kann. Das is genau das Problem, ich brauch einen µC mit dem ich 32Bit gleichzeitig synchron ausgeben kann. PeterK
Joe wrote:
> Da wo ich arbeite sind 150 nSec. nicht synchron.
Bezogen auf was ?
Alles klar, Deine Wohnungsheizung muß auch auf 0,0001°C genau regeln,
sonst wären es ja nicht "genau" 20°C.
Kein numerischer Wert steht nur so im Raum, es braucht immer eine
Bezugsbasis, um ihn zu beurteilen.
Peter
PeterK wrote: > Das is genau das Problem, ich brauch einen µC mit dem ich 32Bit > gleichzeitig synchron ausgeben kann. Nein, Dein Problem ist, daß Du nicht definierst, was "gleichzeitig synchron" in Deiner Aufgabenstellung überhaupt bedeutet. Viele Projekte scheitern schon am Pflichtenheft (d.h. am Fehlen desselben). Peter
sorry vergessen anzugeben - natürlich gibt es vorgaben, ansonsten könnte man ja nichts rechnen etc. also zwischen den signalen liegen 20ms Zeitdifferenz und die Synchronität zwischen den 32 Signalen muss innerhalb von 100ns liegen - da die sensoren 200 Signale innerhalb dieser 20ms wahrnehmen können; d.h. ich benötige eine genauigkeit von max. 100ns besser im bereich von 50ns, damit die sensoren genau feststellen von wo das signal wann kam. PeterK
PeterK wrote: > d.h. ich benötige eine genauigkeit von max. 100ns besser im bereich von > 50ns, damit die sensoren genau feststellen von wo das signal wann kam. Na das is doch schonmal ne Hausnummer. Kann der AVR nicht ohne externe Register. Wenn Dir fine-pitch Löten nichts ausmacht, würde ich zur LPC2xxx-Serie raten (von NXP), das ist ein populärer preiswerter 32Bitter (ARM7-TDMI). Peter
hallo Peter, das fine-pitch löten ist sekundär - wichtig ist echt, diese zeiten einzuhalten sprich das wirklich alle synchron sind und nicht als andere signale gewertet werden können. der preis spielt nahezu keine rolle - manchmal kann man ja auch mit einem intel z.B. ziemlich gut werben etc. und der preis wird zur nebensache, wenn die ware so funktioniert wie man es haben möchte PeterK
@ Peter Danegger
>> Bezogen auf was ?
Bezogen auf Video SDI Signale ;-)) Damit beschäftige ich mich z.B., war
auch nur nen Beispiel, synchron ist synchron und nicht irgend etwas.
@ Peter K
Zu irgendeinem Zeitpunkt müssen deine 32 BIT Synchron zur Verfügung
stehen und das tun sie dann auch. Zu einem anderen Zeitpunkt bereitest
du deine 32 BIT in den Schieberegistern vor. Das bedeutet das dass
Enable Signal aus dem Sync. Signal generiert wird und somit paßt alles.
Kannst du mal nen Flußdiagramm mit Timing erstellen ? dann ergibt sich
auch ein ganzes Bild für mich.
Was muß in welcher Zeit ausgewertet werden. Mach mal exakte Angaben.
Vielleicht teilt man die Aufgabe auch auf 2 MC's auf.
Zu irgendeinem Zeitpunkt müssen deine 32 BIT Synchron zur Verfügung stehen und das tun sie dann auch. Zu einem anderen Zeitpunkt bereitest du deine 32 BIT in den Schieberegistern vor. Das bedeutet das dass Enable Signal aus dem Sync. Signal generiert wird und somit paßt alles. Kannst du mal nen Flußdiagramm mit Timing erstellen ? dann ergibt sich auch ein ganzes Bild für mich. Was muß in welcher Zeit ausgewertet werden. Mach mal exakte Angaben. Vielleicht teilt man die Aufgabe auch auf 2 MC's auf. Hallo Joe, mit SDI-Signalen gehts bei dem Projekt, an dem ich arbeite unter anderem auch zur sache - hat aber mit meinem gerät nichts zu tun; im Prinzip gibt es ein Netzwerk 1000Base-T über welches viele Geräte talken (deshalb 1000Base-T) - mein Gerät besitzt auch eine solche Ethernet-Schnittstelle (mit einem Intel-Ethernet-Controller - nur das beste). über diese Schnittstelle kommen die daten rein und müssen zwischengespeichert werden. Es kommen zwei Protokolle vor - UDP und TCP. Über UDP wird nur zwischendurch abgefragt, wer denn so im netzwerk ist und wo die daten somit hingehen sollen. Mit dem TCP gehen die Daten dann nur an diese IPs und MACs. die TCP-Pakete beinhalten neben dem Header 544Byte an Daten. In meinem Gerät müssen diese ausgewertet werden und zwar steht im Header drinnen welche Bits für welches Gerät (welcher Anschluss von den 32 Stück verwendet werden soll) übertragen werden sollen. Die Daten über die Ethernet-Schnittstelle kommen max. mit einer Rate von 0.2ms an. Zu einem Paket welches dann an den 32 Outputs liegt gehören max. 32 Pakete -> 6.4ms dann ist alles da --> jetzt kann ich die arbeiten machen und hab dafür noch 13.6ms Zeit. Alle 32 Pakete müssen also gespeichert werden - (muss ich mir noch überlegen ob externer SRAM oder interner RAM ca. 60kB). Eine Aufteilung zwischen zwei µC - der eine für Ankunft der Daten zuständig + Usereinstellungen im Meenü und der andere für die synchrone ausgabe ist dahingehend eine alternative, weil mann ja ziemlich viele Pins benötigt. Das Ethernet läuft ja über 4 Doppel-Adernpaare. Über I²C das Display, 32Pins für den Output der Daten, plus vielleicht externer SRAM (8 Datenleitungen, 15 Adressleitungen) oder anders organisiert. Die Arbeit die nach Ankunft der 32 Pakete - können auch weniger sein, je nachdem wieviele Geräte an meinem angeschlossen sind - max. halt 32 Geräte, daher 32 Outputs etc. Die Pakete müssen alle richtig zusammengestellt werden in Registern oder SRAM damit ich schnell draufzugreifen kann und zur gleichen Zeit alles richtig rausgeschickt wird. zwischen den Signalen bestehen ja 20ms Abstand - d.h. natürlich, dass ich in dieser Zeit sämtliche Operationen versuche abzubilden, um wieder 32Bit an den Ausgängen zu haben, um diese synchron rausschicken zu können. Dann kommt das Sync-Signal (SMPTE) und losgehts - raus damit. und immer so weiter - der user kann zwischen drei verschiedenen Sync-Signalen auswählen. An jedem Output gehen also stets 17Bits raus - alle mit einer genauigkeit von 5ns. -> dann gehts wieder von vorne los 20ms Pause während wieder die neuen Pakete vom Ethernet kommen. PeterK
@ PeterK >das fine-pitch löten ist sekundär - wichtig ist echt, diese zeiten >einzuhalten sprich das wirklich alle synchron sind und nicht als andere >signale gewertet werden können. Nun bring doch mal Butter bei die Fische! Es haben mehrere Leute schon mehr als genug gesagt, dass ohne KONKRETE ZAHLEN diese Diskussion zu einem Stammtischgelaber wird. Also. Wieviel Nanosekunden sind für dich "Synchron"? 1ns? 5ns? 100ns? 1us? 1ms? Und sag jetzt nicht so genau wie möglich! Was soll dabei eigentlich rauskommen? Gehts um das hier? http://de.wikipedia.org/wiki/SMPTE-Timecode Wenn ja, ist die Lösung per Schieberegister mit <5ns Zeitversatz mehr als ausreichend. Ein 8Bit uC langweilt sich dabei zu Tode. >der preis spielt nahezu keine rolle - manchmal kann man ja auch mit Klingt für mich nach "Ich hab keine Ahnung aber viel Geld". Sowas sieht man öfter. Tut mir leid, aber das musste jetzt sein. MFG Falk
@Falk
>Und sag jetzt nicht so genau wie möglich!
versteh deine frage nicht --> steht doch schon längst alles in diesem
thread drinnen! bitte zuerst lesen und dann antworten...
Datum: 02.06.2007 18:27
SMPTE = SMPTE-Timecode --> ja, richtig; was anderes gibt es meines
Wissens unter SMPTE nicht.
Bei der Genauigkeit spielt der SMPTE-Synchronimpuls nur sekundäre Rolle
- steht auch in diesem Thread. Wichtig ist die Genauigkeit der Sensoren
bzw. deren Auflösungsvermögen. der SMPTE sagt nur wann die Bits
losgeschickt werden, aber nicht mit welcher Genauigkeit...
PeterK
@ PeterK >versteh deine frage nicht --> steht doch schon längst alles in diesem >thread drinnen! bitte zuerst lesen und dann antworten... Uuups, das hab ich wohl übersehen. Naja, dann ist doch alles klar. Enweder 4 Schieberegister oder 4 Latches mit gemeinsamen Strobe. MFg Falk
Wo stehst du denn jetzt bei deinem Projekt ? Den Netzwerk Anteil hast du derzeit auch noch nicht auf MC Ebene gelöst ? Mit anderen Worten der gesamte Netwerkanteil muß erst einmal gelöst werden. Selbst wenn du ein schönes GIGABIT Netwerk verwendest sagt das noch nichts darüber aus ob du die "Sensor Daten" (welche das auch sein mögen) in dem von dir gewünschten Zeitfenster angeliefert bekommst (will sagen Netwerkapplikationen haben nichts mir "real time Anwendungen" gemein ;-)) sorry, ist aber so. Du könntest ja im ersten Schritt deinen Netwerkanteil mal auf einem PC programmieren und austesten. Dein 32 BIT Register ist jedenfalls das kleinste Problem. Hast du dich schon mit UDP / TCP/IP, respektive mit MC's und Netzwerk beschäftigt ? Das wäre zumindestens der erste Schritt.
>> Zu einem Paket welches dann an den 32 Outputs liegt gehören max. 32 Pakete >> -> 6.4ms dann ist alles da --> Das ist reine Theorie oder hast du das getestet und am laufen ?
hab das ganze schon am laufen - allerdings nicht auf µC-Ebene sondern mit C# programmiert auf einem standard-windows-rechner. Daher stammen auch die Werte. >Das ist reine Theorie oder hast du das getestet und am laufen ? natürlich ist das viel Theorie, weil ich keinen einfluss darauf habe wie lange es dauert, dass alle 32 Pakete ankommen. Hängt ja auch vom letztendlichen Traffic ab - denn ich nicht simulieren kann, weil die anderen Komponenten (Rechner etc.) nicht da sind - z.B. werden über das gleiche Netzwerk zeitgleich auch videodaten übertragen. >Hast du dich schon mit UDP / TCP/IP, respektive mit MC's und Netzwerk > beschäftigt ? Das wäre zumindestens der erste Schritt. TCP / IP u. UDP sind keine Fremdwörter für mich - will heißen, ich weiß wie die Pakete aufgebaut sind (hab die Daten ja in der C#-Lösung auch aufgebrochen und neu zusammengewürfelt etc. Mit µC und Ethernet hab keinen so großen Erfahrungsbereich. Ich weiß, dass die Checksummen-Auswertung der einzelnen Pakete bereits auf einem Ethernet-Controller ausgewertet wird und um den Rest muss sich der µC selbst kümmern. PeterK
>> natürlich ist das viel Theorie, weil ich keinen einfluss darauf habe wie >> lange es dauert, dass alle 32 Pakete ankommen. Genau das wird dein Hauptproblem werden. >> hab das ganze schon am laufen - allerdings nicht auf µC-Ebene sondern >> mit C# programmiert auf einem standard-windows-rechner. Na, das ist doch ne Grundlage. Eigentlich wäre der nächste Schritt nun exakt diesen Anteil auf einen MC zu implementieren, hast du hier schon eine Entscheidung getroffen ? Erste Gehversuche ? Ansonsten wäre ein embedded LINUX Board vielleicht die bessere Wahl !?!?
>> z.B. werden über das gleiche Netzwerk zeitgleich auch videodaten >> übertragen. Wenn die mit priorisierung laufen dann wirds schwer. Können in diesem Netwerk bis zu 32 Devices Video Daten schaufeln ? Was sind das für Daten ? MXF ? welche Bandbreite ? Unter Umständen muß man auch das Nutzdatennetz vom "Steuernetz" trennen !?!?
das problem wie lange es dauert, dass die daten ankommen, muss wenn notwendig im netzwerk geregelt werden über prioritäten etc. Das hat mit meinem Gerät erstmal so nichts zutun; das gerät muss nur in der lage sein, die daten in dieser geschwindigkeit aufnehmen zu können und verarbeiten zu können. >diesen Anteil auf einen MC zu implementieren, hast du hier schon >eine Entscheidung getroffen ? Erste Gehversuche ? da bin ich gerade dabei - allerdings noch auf der theoretischen ebene. Suche mir quasi die einzelnen Komponenten gerade aus, um möglichst ohne viel aufwand das zu bewerkstelligen. - Ethernet Controller (z.B. Intel 82573EI mit Checksum-Berechnung für TCP, UDP, TCP Segmentation) - externer SRAM für den Webserver + Daten-Pakete - µC: Hier steh ich grad - schon etwas länger; ist es sinnvoll alles auf einem µC abzuwälzen oder lieber zwei µC (der zweite z.B. nur für die reine Ausgabe der Daten und der Bitumwandlung + SMPTE-SyncSignal zuständig; der erste µC für die Annahme der Daten-Pakete, Display u. Webserver-Aktivitäten) oder doch nur einen µC - oder doch nur einen großen µC - die ARMs gefallen mir ganz gut... PeterK
Das kann man pauschal nicht beantworten. Aus dem Bauch heraus würde ich das Ganze mit mindestens 2 MC's machen. Einer Grundweg für die Netwerkaufgaben und alle anderen Aufgaben mit nem 2ten.
nein, über dieses netzwerk laufen ganz viele verschiedene sachen - unter anderem auch videodaten, aber mit einer geringen priorität... also kein live-stream.
mit den zwei µC wäre auch so mein vorschlag - allerdings auf den zweiten würde ich nur die Daten-Pakete bearbeiten und rausschicken und mit dem ersten die Daten-Pakete entgegennehmen und Webserver + Display abwälzen. Gibt es eine Möglichkeit (wahrscheinlich nicht) die 600Byte daten in einem RAM abzuspeichern, worauf der zweite µC zugreifen könnte und zwar auf die einzelnen Bits? das wäre aus meiner sicht die genialste lösung, weil dann brauch ich keine Bits umändern mit mehreren Befehlen sondern hol sie mir aus dem RAM so wie ich sie brauch. PeterK
hmm wahrscheinlich scheitert das an der anzahl der adressleitungen...
Ja und nein. Für so etwas hat man früher einmal dual port RAM's verwendet, damit geht so etwas. Im Prinzip kann man das aber auch mit nem Standard RAM machen. Du mußt nur sicherstellen das zum Zeitpunkt des Zugriffs von MC2 auf die RAM Daten, MC1 sozusagen seine Anschlüsse gegenüber dem RAM abschaltet. Beispiel: Eine leere Speicherzelle (RAMzelle) = 0xFF. Wenn zum Zeitpunkt des Zugriff von MC2, MC1 an seinen Anschlüssen logisch 1 oder hochohmig führt dann gehts. Die Enable Leitung des RAM mußt du nur an beide MC's führen und so etwas wie ein MC1 busy an MC2 melden. So etwas habe ich schon gemacht und ist im Prinzip keine große Sache.
gut ein SRAM zum Datenaustausch zwischen den beiden µC klingt gut - die verwaltung wann wer sprechen darf, kann ich mir auch nicht so shcwer vorstellen. welche MHz-Zahl würdest du beim ersten µC wählen? Beim zweiten hab ich sie bis jetzt sogewählt, dass ich mir jegliche Timer sparre und über nop() die Zeiten / Pausen alle genau erzeugen kann. und für die Ausgabe der 32 Datenpakete am zweiten µC würdest du jetzt Latches oder Schieberegister verwenden?
Die Geschwindigkeit des MC's in MHz ist nicht entscheidend, kommt darauf an wie schnell ein MC mit entsprechenden Takt arbeitet. Bei einem 8 BITter würde ich z.B. einen Silabs Typ aus der 8x51 Familie wählen (der ist schnell genug ;-)) http://www.silabs.com/tgwWebApp/public/index.htm >> und für die Ausgabe der 32 Datenpakete am zweiten µC würdest du jetzt >> Latches oder Schieberegister verwenden? Mit Latches bist du eindeutig schneller. Es kommt nun auf das konkrete Timing an. Mit Schieberegistern gehts ebenso. Mal unterstellt du clockst die 32 BIT mit ner uSec. pro BIT herein dann benötigst du zum Laden des SR 32 uSec.
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.