Hallo Forum, ich suche auf diesem Weg einen SoC oder µC mit sehr vielen IOs. Die IOs sollen nicht gemultiplext sein oder ähnliches, da es auch auf die Schaltgeschwindigkeit ankommt. Als ersten Ansatz kam der Radxa CM3I in Frage, ich suche aber noch Alternativen. Danke!
Arduino UNO hat sehr viel I/O : 14 digitale ein/ausgaenge Und sehr groszer geschwindigkeit : 16MHz Ich nehme an deine meinung ueber "sehr viel" und "Groszer Schaltgeschindigkeit" lasst sich auch in eine Nummer ausdruecken ? Nicht boese gemeint, nur Zielorientiert... Patrick aus die Niederlaende
Der Radxa CM3I hat einen 4x 100Pin Header, es könnten somit theoretisch wahrscheinlich > 100 Pins benutzt werden. Gebraucht werden mindestens > 100...
Moin, Nimm lieber irgendein superbilliges SoC, auf dem du dich gut auskennst, mit gutem Support, etc. und irgendein popeliges FPGA fuer deine vielen IOs. Gruss WK
> Nimm lieber irgendein superbilliges SoC, auf dem du dich gut auskennst, > mit gutem Support, etc. und irgendein popeliges FPGA fuer deine vielen > IOs. Es gibt auch SoC und FPGA unter einem Deckel, pins mhr als tausend: * Xilinx/AMD zynq; * Altera/intel Cyclone-V; * GoWin GW1NS. * ...
Sven H. schrieb: > Das ist eine gute Idee, hast du einen Vorschlag für eine SoC + FPGA > Kombination? Microchip Polarfire SoC. Nur ein Device.
Da fast alle notwendigen Infos fehlen werfe ich jetzt einfach mal die S32K-Serie von NXP in den Ring. Die S32K314-Variante hat z.B. bis zu 218 GPIOs. https://www.nxp.com/products/processors-and-microcontrollers/s32-automotive-platform/s32k-auto-general-purpose-mcus/s32k3-microcontrollers-for-automotive-general-purpose:S32K3
> Als ersten Ansatz kam der Radxa CM3I in Frage, ich suche aber noch Das ist kein SoC sondern ein SoM (system on a Module), da gibt es auch andere Anbieter wie Trenz electronic oder enclustra. * https://www.enclustra.com/en/products/system-on-chip-modules/ * ...
> Da fast alle notwendigen Infos fehlen werfe
Jau, das ist mal wieder so eine TO hat keine Ahnung thread.
Es gibt da draussen vermutlich hunderte bis tausende MCUs
in irgendeinem BGA Gehaeuse mit 200-300pinnen.
Ein beliebiges Beispiel waere z.B der STM32F777xx mit 168 IOs..
Vanye
Moin, Sven H. schrieb: > Das ist eine gute Idee, hast du einen Vorschlag für eine SoC + > FPGA > Kombination? Woher soll ich wissen, an welche SoCs/FPGAs und deren Support du guenstig kommst, wo du dich auskennst und was du ueberhaupt mit deinen vielen IOs vorhast? Im uebrigen: Guter Rat ist teuer ;-) Gruss WK
Geht es um die nackte Schaltgeschwindigkeit, oder nur darum, den Jitter begrenzt zu halten?
Sven H. schrieb: > Die IOs sollen nicht gemultiplext sein oder ähnliches, da es auch auf > die Schaltgeschwindigkeit ankommt. Dann wäre vermutlich eher ein FPGA oder SoC mit FPGA-Anteil angesagt. Sven H. schrieb: > Der Radxa CM3I hat einen 4x 100Pin Header, es könnten somit theoretisch > wahrscheinlich > 100 Pins benutzt werden. > > Gebraucht werden mindestens > 100... Hast Du überhaupt schon einmal einen Blick auf die Pinbelegungen dieser ominösen Steckverbinder geworfen? Vermutlich nicht, denn ansonsten hättest Du gleich gesehen, dass da keineswegs 100 freie GPIO zusammenkommen. Im Gegensatz zu Dir habe ich nämlich nachgeschaut: https://dl.radxa.com/cm3i/docs/hw/ Ich würde bei den Anforderungen eher einen Blick auf die Vielzahl von AMD/Xilinx Zynq werfen, d.h. als Modul oder Einzelchip. Beim Trenz TE0813 gäbe es z.B. 204 "GPIO" am PL und 65 "GPIO" am PS. https://shop.trenz-electronic.de/de/Produkte/Trenz-Electronic/TE08XX-Zynq-UltraScale/TE0813-Zynq-UltraScale/ Und selbst das leistungsmäßig deutlich kleine TE0715 hätte immer noch 132 "GPIO" am PL und 14 "GPIO" am PS: https://shop.trenz-electronic.de/de/Produkte/Trenz-Electronic/TE07XX-Zynq-SoC/
Sven H. schrieb: > sehr vielen Ah ja, die Einheit "viele" in ihren Einteilungen: "etwas viele". "ziemlich viele" "sehr viele" "extrem viele".
Cyblord -. schrieb: > Sven H. schrieb: >> sehr vielen > > Ah ja, die Einheit "viele" in ihren Einteilungen: > "etwas viele". > "ziemlich viele" > "sehr viele" > "extrem viele". Nach unten könnte man die Skala noch mit "nicht so viele" und "gar nicht viele" abrunden.
Danke für die Inputs, ich werde mir Gedanken machen für eine genauere Beschreibung und Anforderungen und melde mich ggfs. nochmal.
Natürlich wird jede Rückfrage, welches Problem der Threadstarter meint, mit seinen Anforderungen lösen zu müssen, als unnötig zurückgewiesen werden, wie auch die Rückfrage nach benötigter "Schaltgeschwindigkeit".
Harald K. schrieb: > Natürlich wird jede Rückfrage, welches Problem der Threadstarter meint, > mit seinen Anforderungen lösen zu müssen, als unnötig zurückgewiesen > werden, wie auch die Rückfrage nach benötigter "Schaltgeschwindigkeit". So wird das sein. Montag ist der neue Freitag. Apropos: https://www.mikrocontroller.net/user/show/sv_ha die 4 Beiträge (derzeit) sind in diesem Thread. Ein Schelm, wer denkt ...
> So wird das sein. Montag ist der neue Freitag. Apropos: > > https://www.mikrocontroller.net/user/show/sv_ha > > die 4 Beiträge (derzeit) sind in diesem Thread. > Ein Schelm, wer denkt ... jeder hat mal mit vier Artikeln angefangen ...
Die Ausgangsspannung und Eingangspegel könnten auch nicht ganz unwichtig sein.
Bis jetzt tut's auch ein kleiner uC im normalen Gehäuse: z.B. STM32L496ZET, 109 bis 114 GPIO, LQFP-144. Der dürfte etwas einfacher zu programmieren sein als ein Radxa oder ein uC plus FPGA.
Sven H. schrieb: > ich suche auf diesem Weg einen SoC oder µC mit sehr vielen IOs. > > Die IOs sollen nicht gemultiplext sein oder ähnliches, da es auch auf > die Schaltgeschwindigkeit ankommt. Verrate blos nicht wieviele IOs es mindestens sein müssen, man könnte dir noch helfen sonst. Gut ist auch, dass du nicht verrätst wie schnell geschaltet werden soll. Hauptsache schnell. Was immer du tust, werd bloss nicht konkret. Am Ende hilft man dir auch noch, nicht auszudenken wohin das führen würde. Am Ende noch zu einer brauchbaren Lösung für deine Aufgabe.
Danke für die konstruktiven Beiträge. Das System soll am Ende mit einer GUI auf einer Yocto Distro laufen (kein QT). Deshalb ist die Performance doch schon entscheidend. Ebenso soll ein Monitor über HDMI angeschlossen werden können.
Sven H. schrieb: > Das System soll am Ende mit einer GUI auf einer Yocto Distro laufen > (kein QT). Klar, das definiert, was mit den I/Os und mit welcher Geschwindigkeit passieren soll. > Deshalb ist die Performance doch schon entscheidend. Ach, deshalb? Ja, nee, is' klar. Sven H. schrieb: > Ebenso soll ein Monitor über HDMI angeschlossen werden können. Über die I/Os? Per Bitbanging? Oder wie stellst Du Dir das vor?
Jaja, schnell kann viel heissen, mit FPGA/CPLD geht 100+MHz ohne Probleme, da nen schnellen Mux/Shiftreg ran, dann bist immer noch bei 10+Mhz und 1000+I/O pro Chip Beim Arduino ist 1MHz schnell..... Und dann noch die Frage, was man überhaupt machen will, Bitgebastel ist spassig mit CPLD/FPGA, irgendnen LCD-Cluster mit Video eher weniger.
:
Bearbeitet durch User
Sven H. schrieb: > Das System soll am Ende mit einer GUI auf einer Yocto Distro laufen > (kein QT). Deshalb ist die Performance doch schon entscheidend. Ebenso > soll ein Monitor über HDMI angeschlossen werden können. Das ist doch glasklar ein Troll!
Bradward B. schrieb: > jeder hat mal mit vier Artikeln angefangen ... Und jeder Troll verwendet für seine Trollposts einen frischen Account (meistens weil der alte dann weg ist). Oder anders ausgedrückt: nicht jeder frische Account ist ein Troll. Aber jeder Troll kommt mit einem neuen Account.
:
Bearbeitet durch User
Jetzt weiß ich warum ich zumindest kurz drüber nachgedacht habe diesen Beitrag überhaupt zu schreiben. Ich habe diesen Account seit Jahren. Mit Troll hat das wenig zutun,... Aber gut, ich werde mich anderweitig umschauen, mit diesen Reaktionen habe ich nicht gerechnet. An Destruktivität kaum zu überbieten, Sorry.
Völlig falsche Rangehensweise, wenn die Hardware nicht kennst, bist erstmal nen halbes Jahr beschäftigt, bis überhaupt einigermassen damit zurechtkommst, wenn es SOIC ist. FPGA/VHDL ist überall das gleiche, dafür nix mit QT. Und irgendwelche QT Kram laufenlassen ist mehr Skriptkiddie als wirklich programmieren, IMO & btw.
Sven H. schrieb: > Aber gut, ich werde mich anderweitig umschauen, mit diesen Reaktionen > habe ich nicht gerechnet. An Destruktivität kaum zu überbieten, Sorry. So kann man das natürlich auch machen. Man könnte aber auch versuchen, die in diesem Thread durchaus gestellten Fragen zu erkennen und zu beantworten. Die Klassifikation als Troll erfolgte übrigens konsequenterweise, weil Du genau das nicht getan hast.
Sven H. schrieb: > Jetzt weiß ich warum ich zumindest kurz drüber nachgedacht habe diesen > Beitrag überhaupt zu schreiben. Ich habe diesen Account seit Jahren. Mit > Troll hat das wenig zutun,... > > Aber gut, ich werde mich anderweitig umschauen, mit diesen Reaktionen > habe ich nicht gerechnet. An Destruktivität kaum zu überbieten, Sorry. Ein einfache Angabe in der Frage hätte die Sache entspannt. So etwas wie: "Ich suche einen SoC oder µC mit 37 IOs, die parallel in 10 Nanosekunden geschaltet werden können." Und wenn du diesen Account schon so lange hast, dann weißt du doch, wie hier die Leute auf unspezifizierte Allgemeinfragen reagieren. Danke, dass du wenigstens konsequent bist.
Ein klassischer Duennhauttroll. Eigentlich haette klar sein sollen, dass ueber hundert I/O schnell zu schalten nicht von nichts kommt. Denn bevor man die Pegel anlegen kann, muessen sie auch irgendwo her kommen. zB aus einer Tabelle. Was ist die Update Rate dieser Tabelle, woher kommt der Inhalt? Allenfalls werden ein paar Werte gerechnet, woher kommen die ? Auf einer Yocto Distro laufen lassen ... Entweder Echtzeit, oder Betriebssystem. Betriebssysteme, welche etwas wie Echtzeit versprechen meinen allenfalls 10ms Zykluszeit.
Sven H. schrieb: > mit diesen Reaktionen > habe ich nicht gerechnet. An Destruktivität kaum zu überbieten Stimmt. Bei so guter Beschreibung des gesuchten SoC / µC. War ja schließlich offensichtlich, dass "mit sehr vielen IOs" und "nicht gemultiplext sein oder ähnliches, da es auch auf die Schaltgeschwindigkeit ankommt" bedeutet, dass da ein Linux drauf soll und auch HDMI notwendig ist. SATA, M.2, PCIe, USB3.1, GBE, ... brauchts auch noch? Aber ist ja mit "vielen schnellen" IOs kein Problem. Ach ja, und 16GB RAM, oder mehr? Aber halt. Die PINs werden da dann ja vielleicht gar nicht direkt angesprochen. Ein FPGA ist nichts als ein großer schneller Multiplexer. Und die schnelleren CPUs haben gerne ne langsamere IO-Clock. Also alles ungeeignet. IO-Standards sollen die IO natürlich jeweils alles beherrschen, oder? LVDS, CMOS 1.8-5V, CML, SSTL, HSTL, PECL, ... Aber das ist ja schließlich selbstverständlich. Und nochmal halt. Mit Linux (auch RT) liegt die Latenz ja immer noch bei typisch 10µs und 50µs+ worst case. Da ist die "Schaltgeschwindigkeit" ja gar nicht hoch sondern ziemlich lausig. Hmm. Dann hätten ja doch gemultiplexte IOs genügt, oder Linux muss weg. Oder mit Linux brauchts dann vor allem X mal SPI, X mal UART, ... weil Bitbanging mit der Latenz ja gar nicht funktioniert. Blöd. Aber eigentlich war doch von Anfang an alles klar ...
Sven H. schrieb: > Das System soll am Ende mit einer GUI auf einer Yocto Distro laufen > (kein QT). Deshalb ist die Performance doch schon entscheidend.
1 | Studies have shown that users lose patience and retry an operation |
2 | after around 2s of inactivity (in the absence of feedback), e.g. |
3 | clicking on a confirm or action button. So plan on using some kind |
4 | of animation if the action takes longer than 1s. |
Da gibt's noch mehr zum Thema GUI und Performance: https://stackoverflow.com/questions/536300/what-is-the-shortest-perceivable-application-response-delay
Angehängte Dateien:
-
sanduhr.gif
34 KB
Bauform B. schrieb: > So plan on using some kind > of animation if the action takes longer than 1s. Deswegen gibt die ganzen völlig sinnlosen und frustrierenden "Prokrastinationskreisel", die nichts tun, außer sich zu drehen. Besser ist eine echte Fortschrittsanzeige, die also eine Rückmeldung über den tatsächlichen Fortschritt einer Operation zurückgibt und dem Benutzer idealerweise auch die Information vermittelt, /wie lange es noch dauert/, bis die Operation abgeschlossen ist. Stundenlang auf "99%" zu hängen ist nämlich auch kaum besser als das Bildchen im Anhang ... (ok, die Vorschau hat's verkackt ... https://www.mikrocontroller.net/attachment/637881/sanduhr.gif in neuem Tab/Fenster angucken)
:
Bearbeitet durch User
Harald K. schrieb: > /wie lange es > noch dauert/, bis die Operation abgeschlossen ist. Das ist in Computerkreisen erstaunlich oft nicht festzustellen. Ein "17 von 34 Schritten erledigt" ist leicht, aber es kommt Frust auf wenn der 33. Schritt im Gegensatz zu den anderen 32 davor halt 4 Minuten braucht, weil die Festplatte rödelt, die anderen Schritte waren nur "setze eine Variable in einer ini-Datei" und zusammen in 4 Sekunden erledigt. Aber auf einem anderen Rechner mit 32 Kernen und 4-lane PCIe5.0 NVMe ist der 33. Schritt in 150ms durch. Welche Zeit zeigt man an? Siehe alle Softwareuhren "noch ... Minuten", egal unter welchem OS. Harald K. schrieb: > "Prokrastinationskreisel", die nichts tun, außer sich zu drehen. Leider auch wenn abgestürzt wurde. Das konnte selbst chkdsk besser, das alle paar Dateien einmal aktualisiert. Man sieht es geht vorwärts, aber es dauert eben auch.
Jens M. schrieb: > Das ist in Computerkreisen erstaunlich oft nicht festzustellen. Deswegen schrieb ich ja "idealerweise". Die dumme sich drehende Sanduhr oder der dumme hin-und-herwabbelnde Prokrastinationsbalken ist jedenfalls fast nicht besser als ... einfach gar nichts zu tun. Es gibt einfache Gemüter, die allerdings auch schon so etwas glauben und meinen "der macht ja was" ... Seufz.
Ich habe gerade an einem Tester zu sitzen, den ein Kunde gebastelt hat. Da sind viele Schritte mit wenigen Sekunden, und einer mit 5 Minuten. Völlig ohne Rückmeldung. Leider ist die Software dermaßen instabil, das es auch ab und an mal einfach abstürzt, ohne Meldung, ohne "Reagiert nicht", ohne alles. Da brauchts also tatsächlich eine Stoppuhr und nach 7 Minuten weiß man "ist tot, kannste abschießen" Da wäre eine Fortschrittsmeldung egal welcher Art sinnig, zumal was programmiert wird, da gäbe es sicherlich Speicherblöcke o.ä., die man zählen könnte. Aber: der Inschinör der sich das ausgedacht hat muss es selbst nicht benutzen, daher kommt er nicht drauf. Und das ist bei Softwareschreibern oft auch so, hab ich den Eindruck.
Sven H. schrieb: > Danke für die Inputs, ich werde mir Gedanken machen für eine genauere > Beschreibung und Anforderungen und melde mich ggfs. nochmal. Das solltest du tun, bevor du hier einen nichtssagenden Thread mit "sehr vielen I/O" und undefinierter Schaltgeschwindigkeit anzettelst. Es kann doch nicht sein, dass dein Problem vom Verlauf des Threads abhängt. Schildere dein Problem und nicht irgendeine vermeintliche Lösung, zu der du dann keine Ahnung hast, was es da für Bauelemente gibt.
:
Bearbeitet durch User
Gustl B. schrieb: > Stephan schrieb: >> Ein FPGA ist nichts als ein großer schneller Multiplexer. > > Man lernt nie aus (-; Ok. Er kann viel mehr. Aber als "IO-Erweiterung" hier verkommt er zu etwas in der Richtung. Zumindest hatte sich in meinem Kopf das so dargestellt. ;)
Motopick schrieb: > Silabs C51F020 64 IOs ATmega2560: 86 IOs Viele bevorzugen aber IO-Expander (74HC165, 74HC595, PCF8574/A). Das macht dann das PCB deutlich einfacher, da nicht sämtliche IOs bis zum µC geführt werden müssen. Bzw. reduziert erheblich die Pinanzahl von Steckverbindern zwischen den Platinen. Auch entkoppelt es den µC von Störimpulsen.
Angehängte Dateien:
-
C8051.PNG
24 KB
Motopick schrieb: >> µC mit sehr vielen IOs gesucht > > Silabs C51F020 Du meinen C8051F020 ? https://www.silabs.com/documents/public/data-sheets/C8051F02x.pdf Scheint gerade bei Analog-pins mehr als Standard aufzufahren.
Sven H. schrieb: > Aber gut, ich werde mich anderweitig umschauen, mit diesen Reaktionen > habe ich nicht gerechnet. An Destruktivität kaum zu überbieten, Sorry. https://de.wiktionary.org/wiki/Destruktivit%C3%A4t Destruktiv ist : - Nicht auf Fragen antworten - Keine präzise Informationen mitteilen - Sich noch nicht einmal einsichtig zeigen und Motzen anstatt Infos nachzureichen.
Obelix X. schrieb: > Destruktiv ist hier gar nichts - wo nichts ist, kann auch nichts zerstört werden. Das Verhalten des TEs, der ja etwas wissen will, aber mit diesem Verhalten nichts (sinnvolles) bekommt, würde ich eher "dumm" nennen.
Jens M. schrieb: > Das ist in Computerkreisen erstaunlich oft nicht festzustellen. > Ein "17 von 34 Schritten erledigt" ist leicht, ... > Aber auf einem anderen Rechner mit 32 Kernen und 4-lane PCIe5.0 NVMe ist > der 33. Schritt in 150ms durch. > Welche Zeit zeigt man an? Eine sauber abgeschätzte. Der Rechner ist die ganze Zeit dabei, irgendetwas zu tun. Da sollte es doch für ein gutes Betriebssystem möglich sein, ein paar Skalierungsfaktoren für charakteristische Vorgänge vorzuhalten, die aus Erfahrungswerten für diesen Rechner abgeleitet sind. Dann kann der Programmierer den Arbeitsaufwand anhand dieser Skalierung in Zeiten umrechnen und vernünftig anzeigen. Ein Rechner mit 32 Kernen sollte doch selber feststellen können, wie schnell er ist.
:
Bearbeitet durch User
Rainer W. schrieb: > Ein Rechner mit 32 Kernen sollte doch selber feststellen können, wie > schnell er ist. Ähem, das solltest Du mal den Herren Turing, Gödel und von Neumann erzählen. Die drehen sich dann so schnell in ihren Gräbern, dass man damit alle Energieprobleme dieser Welt lösen könnte. Andere Leute beschäftigen sich vor solchen Behauptungen lieber erst einmal mit Komplexitätsklassen, insbesondere NP und dem P-NP-Problem. Nein, das hat nix mit Halbleitern zu tun.
Weil man das so gut schätzen kann, ist die Windows-Uhr schon seit Modemzeiten legendär: - 32 Minuten verbleibend - 14 Sekunden verbleibend - 3 Tage 16 Stunden 7 Minuten verbleibend - 4 Minuten verbleibend ... 20 Minuten später - 20 Sekunden verbleibend - 19 18 17 5 4 3 2 45 44 42... - noch 4 Minuten - 20 Minuten später - Download abgebrochen! Und die Linuxer auch, und daher wird das heute nicht mehr gemacht.
Jens M. schrieb: > Weil man das so gut schätzen kann, ist die Windows-Uhr schon seit > Modemzeiten legendär: Hat aber nichts mit vielen IO-Pins zu tun. Und Sven bringt das eh nichts, da er raus ist.
:
Bearbeitet durch User
Sven H. schrieb: > Jetzt weiß ich warum ich zumindest kurz drüber nachgedacht habe diesen > Beitrag überhaupt zu schreiben. Du bist auf keinen Vorschlag ein gegangen und hast nicht ansatzweise Randbedingungen genannt, was hast du also erwartet? Das hat nichts mit diesem Forum zu tun, sondern es liegt ganz bei dir. Gruß Ps.: Ich bin überrascht wieviel konstruktive und gute Vorschläge hier aufgekommen sind, trotz der quasi null konkreten Angaben zu den Anforderungen. Aber du bist ja eh schon lange über alle Berge...
Harald K. schrieb: > Sven H. schrieb: >> Ebenso soll ein Monitor über HDMI angeschlossen werden können. > > Über die I/Os? Per Bitbanging? Oder wie stellst Du Dir das vor? HDMI via Bitbanging...YMMD :D Wie bekommt man am besten Kaffee aus einer Tastatur? Ich frag...ähm...für einen "Freund"...verflixt :D
Sven H. schrieb: > Jetzt weiß ich warum ich zumindest kurz drüber nachgedacht habe > diesen > Beitrag überhaupt zu schreiben. Ich habe diesen Account seit Jahren. Mit > Troll hat das wenig zutun,... > > Aber gut, ich werde mich anderweitig umschauen, mit diesen Reaktionen > habe ich nicht gerechnet. An Destruktivität kaum zu überbieten, Sorry. Wir wissen, dass du viele IOs brauchst aber, trotz mehrfacher Nachfrage, wissen wir bis jetzt immer noch nicht wieviele es mindestens sein müssen. Wir wissen, dass du schnell schalten willst, aber, trotz mehrfacher Nachfrage, wissen wir bis jetzt immer noch nicht wie schnell du mindestens schalten willst. Schau mal, ein simples Beispiel: Ich arbeiten fast nur mit Gleichspannung. Aber was ist Gleichspannung für mich? Nunja, in meinem konkreten, aktuellen, Fall/Projekt ist alles, was langsamer als 10 Hz ist, als Gleichspannung anzusehen. Mein Studiumskollege ist in der Nachrichtentechnik unterwegs, für den ist Gleichspannung alles, was nicht mindestens MHz hinten dran stehen hat und größer 1 ist. Solange du nicht konkret wirst kann man dir nicht helfen, weder hier noch sonst wo. Ist halt wie beim Arzt, dem reicht es auch nicht zu sagen, dass man Schmerzen hat, der muss halt auch zumindest wissen wo die Schmerzen sind um einem helfen zu können.
M. K. schrieb: > HDMI via Bitbanging...YMMD :D Der RP2040 kann das, mit Hardwareunterstützung durch seine mit einer einfachen Statemachine programmierbaren I/Os. https://github.com/Wren6991/PicoDVI
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.