Hat jemand schon erfolgreich den Umstieg vom AVR-> ARM geschafft? Ich will wissen wie Zeitintensiv es wird. Naturlich habe ich mich schon mal vor gewagt. Da sind Einstellungen von der PLL und die Interruptserviceroutiene ist auch nicht in C gehalten.
Das hängt vielleicht auch ein bisschen davon ab, worin Du bislang Deine Programme geschrieben hast. Der Umstieg AVR-Assembler -> ARM-Assembler dürfte 'ne übelst haarige Angelegenheit sein, der Umstieg avr-gcc -> arm-gcc sollte schon um einiges leichter fallen; zu bedenken ist allerdings, daß der ARM (glücklicherweise) eine von-Neumann-Maschine ist. Ganz zuletzt kommt's natürlich auch darauf an, was Du bislang mit dem AVR getrieben hast und was Du mit welchem ARM anstellen willst; es gibt ja nicht den ARM, sondern aberzig* Varianten. *) schönes Wort, nicht?
"Hat jemand schon erfolgreich den Umstieg vom AVR-> ARM geschafft?" Was heißt hier Umstieg, die spielen doch in einer völlig anderen Liga ! Projekte, die auf einem AVR laufen können, würde ich nie auf einen ARM umrubeln und umgekehrt. Du mußt Dich auch erstmal für einen ARM entscheiden (Atmel, Philips, ST,...). Z.B. der ST-ARM hat 16 Interruptprioritäten (!!!), aber dazu mußt Du erstmal die 37 Seiten im Reference-Manual durcharbeiten und verstehen und hoffen, daß sie stimmen und hoffen, daß der Chip keine Bugs hat. Peter
Oder soll es gar ein ARM-9 mit MMU werden? Wenn Du den IAR Compiler benutzt, kostet es Dich einen vierstelligen Betrag und ein paar Klicks, dann kannst Du Deine Projekte übernehmen. Am Anfang steht ja wohl die Frage: warum willst Du umsteigen? Und davon hängt dann auch die Antwort ab, wie aufwendig es wird und ob es sich überhaupt lohnt. Wenn ein Projekt einfach nicht mehr in die dicken Atmegas "paßt", ist eine intelligente Überarbeitung des Codes vielleicht weniger Aufwand (doch, auch Dein Code kann besser werden! (-; ). Wenn die Rechenleistung der AVRs nicht reicht, mache Dir vorher Gedanken, ob die ARMe da wirklich den erhofften Schub bringen. Wenn Du doch vor allem mit Bitoperationen, aber vielen Interrupts schaffst, wirst Du enttäuscht sein.
"Wenn Du doch vor allem mit Bitoperationen, aber vielen Interrupts schaffst, wirst Du enttäuscht sein." Ganz genau ! Der ARM7 ist für viel Datendurchsatz und viel 32-Bit Rechnen und wenig Float oder Divisionen (hatter nich). Als Bitschubser oder Statemachine bringt er keine Punkte, aber dafür ne viel teuere Platine und höheren Stromverbrauch. Peter
Es bieten zunehmend Hersteller ARM als CPU an. ST, Philips, NetSilicon, TI, cirrus logic, Freescale und so weiter. Ich will auch an größere Projekte ran. Bis jetzt habe ich immer die PC-Beistellvariante. Eigentlich ist das eine Vergewaltigung des PCs, weil der eine Grafikkarte zum schönen Darstellen und eine Netzwerkanbindung hat. Außerdem ist immer zusätzlich noch ein PC zuwarten. Ich hatte jetzt an den ARM7TDMI gedacht. In die nähere Auswahl habe ich die von Analog genommen, da es dort einen richtigen 3 Kanal DAC gibt. Die Philips LPC210x Serie und die ST sind auch nicht schlecht.
"viel teuere Platine und höheren Stromverbrauch" Neee, jetzt muß ich den ARM doch in Schutz nehmen: Warum sollte die Platine viel teurer sein? Solange man sich im selben MHz-Bereich bewegt, tun die Platinen sich doch nichts gegenüber einem dicken 8-Bitter. Und Stromverbrauch? Mein Philips LPC2194 trinkt bei Vollast ziemlich genau ein 1 mA pro MHz; mein ATmega128 über das doppelte, ohne doppelten Befehlsdurchsatz zu schaffen. Also: man kann durchaus auch ohne großen Datendurchsatz ARM nehmen, aber nur bitte nicht in der falschen Hoffnung auf Parformance-Wunder beim "Bit-Schubsen". @dose: Bei der Typenauswahl kann ich mangels breiter Erfahrung nicht wirklich behilflich sein, aber der Wechsel zwischen ARMen verschiedener Hersteller ist ja zum Glück nicht so ein Drama.
Sieh' Dir mal die ARM7-Varianten von ... Atmel an. Da gibt es mittlerweile auch ganz nette (AT91SAM7Sxxx) mit integriertem USB-Device-Controller. http://www.atmel.com/dyn/products/param_table.asp?family_id=605&OrderBy=part_no&Direction=ASC OKI stellt auch ARM7-Versionen her (ML67Q5003); interessant hieran ist der SDRAM-Controller. Olimex hat wohl zwei Platinen mit diesem Controller in Arbeit.
Danke für den Tipp. Ich habe bereits ein Board von Olimex mit dem LPC2106 und eine Jtag Connector. Ich wollte über den Jtag programmieren und die hardware Debuggen. Im netz habe ich gefunden, das es nicht möglich ist über den Jtag in den Flash zu schreiben. es ist halt teortisch alles möglich, doch dann doch wieder ein Trauerspiel. Leider bekommt man bei Olimex die nackte Platine ohne Beispielprogramme. Sei es als CD oder Downloadbereich der Homepage.
. "Im netz habe ich gefunden, das es nicht möglich ist über den Jtag in den Flash zu schreiben." Das ist, zumindest in Bezug auf den LPC2106, vollkommener Quark. Selbstverständlich lässt sich über das JTAG-Interface das Flash-ROM des LPC2106 programmieren. Das geht auch mit dem JTAG-Parallelport-Adapter von Olimex, der auch hier im Shop verkauft wird. Den kann man sich auch selberbauen, das ist nämlich ein Nachbau des "Wiggler" von Macraigor. Leider taugt die meiste Software, die unter Windows mit dem "Wiggler"-JTAG-Interface zusammenarbeiten soll, recht wenig; eine lobenswerte Ausnahme ist Crossworks for ARM von Rowley. Das ist eine IDE mit integriertem Debugger, gcc als Compiler-Backend und einer vorzüglich funktionierenden Unterstützung für "Wiggler"-Clones. Leider ist diese Software mit 500 UKP ziemlich teuer, und die Demoversion funktioniert nur für 30 Tage, und das auch erst nach Freischaltung. Beiliegend sind Beispielprojekte für LPC2106 und auch direkt für die Olimex'sche Platine. Selbstverständlich lädt Crossworks das Programm via JTAG ins Flashrom ... Der "OCD Commander" von Macraigor, der angeblich mit dem "Wiggler" zusammenarbeiten soll, ist -zumindest unter neueren Windows-Versionen- annähernd nutzlos, selbst wenn man die vielen Nachbauten fehlende Brücke im Parallelportstecker nachlötet.
"Der "OCD Commander" von Macraigor, der angeblich mit dem "Wiggler" zusammenarbeiten soll, ist -zumindest unter neueren Windows-Versionen- annähernd nutzlos, selbst wenn man die vielen Nachbauten fehlende Brücke im Parallelportstecker nachlötet." Genau davon habe ich gesprochen. Der gleiche Treiber wird für insight genutzt und schmiert ständig ab. Ich hoffe auf alternative Treiber wie jtagpack http://sourceforge.net/projects/jtagpack/ Leider ist der auch noch nicht lauffähig. Ich habe es nicht geschafft ihn unter Windows zu kompilieren. Die Macraigor Umgebung gefällt mir nicht, weil sie unter der Cygwin Umgebung läuft. Da gibt es Probleme mit einer cyg...1.dll, weil ich auch den Winavr auf meinen Rechner habe. Es bekriegen sich die DLLs mit unterschiedlichen Versionsnummer. Ich habe es schon gesehen, dass Winavr diese DLL auf die todo Liste gesetzt hat. Rowley ist mir zuteuer. Bei mir läuft das eher immer so ab. Privat brauche ich einen technologischen Vorlauf, und wenn ich es drauf habe wird es auf Arbeit genutzt. Ich brauche den Einstieg privat. Hier in der Frima muss man alle Finanzen hinterlegen und wenn man nicht gleich die Summe Umlegen kann springt die Buchhaltung mir an den Hals. Leider verdirbt das einem manchmal den Spaß.
Wenn es darum geht eine preiswertes grosses Display zu haben könntest Du auch den Propeller-Chip von Parallax nehmen Der Cchip kostet ca. 30 Euro Die IDE mit allem drum und dran gibt es kostenlos von Parallax Die kann Assembler und eine objektorientierte Sprache namens SPIN Er hat 8 CoProzessoren Der hat IM PROZESSOR hardware eingebaut mit der man über drei IO-PINS ein NTSC-Signal erzeugen kann. Mit entsprechend mehr PINS auch VGA Es gibt von Parallax dazu einen 2,5-Zoll NTSC-TFT-Monitor für schlappe 80 Euro
Mal eine Frage am Rande... Wenn die ARM7/9 für Bitopearationen und zum Pintogglen nicht den extremen Schub bringen, welche Controller sind dann dafür am besten ausgelegt?
Hi, >Mal eine Frage am Rande... >Wenn die ARM7/9 für Bitopearationen und zum Pintogglen nicht den >extremen Schub bringen, welche Controller sind dann dafür am besten >ausgelegt? Als Bitschubser bzw. IO Toggler sind die SX Mikrocontroller(?) interessant. http://www.parallax.com/sx/index.asp . Die Mikrocontroller schaffen im Turbo Mode 75Mips. Leider haben die Mikrocontroller kaum internen Speicher, aber gegenüber ein CPLD eine sehr schoene Loesung. Dirk
@Christian, die 8051 sind darauf optimiert. Z.B. beim C8051F120 dauert ein Pintogglen (CPL P1.7) 2 Zyklen, also 20ns bei 100MHz interner CPU-Takt. Mehrere Pins togglen (XRL P2, #0A5h) dauert 3 Zyklen (30ns). Peter
Der Intel Pentium Quad Core :-) Ne...im Ernst, alles was 8bit hat, ist für einfaches Bitschubsen schon am Besten geeignet. Nihct weil sie das jetzt viel schneller machen würden als die ARM, sondern einfach weil das Verhältnis von Aufwand und Nutzen stimmt.
Das ist jetzt aber Leichenfledderei, oder? Datum: 19.05.2005 09:05 -> Datum: 27.09.2006 14:54 Noch dazu ging es in dem Thread doch nie um Displays? Zu Christians Frage: Die neueren LPCs (z.B. 214x, LPC210[12]) können mit bis zu 15 MHz Toggeln - d.h. gerade mal zwei Takte pro Schaltvorgang. In meinen Augen macht es wenig Sinn, für Aufgaben, die ein noch schnelleres Bitbanging erfordern, einen uC zu nehmen - programmierbare Hardware kann Bits mit zig-Mhz Schubsen. Gruss, Dominic
Hi, >In meinen Augen macht es wenig Sinn, für Aufgaben, die ein noch >schnelleres Bitbanging erfordern, einen uC zu nehmen - >programmierbare Hardware kann Bits mit zig-Mhz Schubsen. Ich sehe das nicht so, ein CPLD / FPGA kostet viel Arbeitszeit. Code schreiben, Testbench schreiben und Simulieren, danach die Constraints prüfen usw. bedeutet viel Arbeitszeit. Ich würde dann eher die SX Mikros nehmen und der Programmer für 15 Dollar ist auch billiger als ein USB Blaster bei Xilinx.
Hallo alle zusammen, weiß nicht wie weit Euer Bit-Toggle Thema ARM versa XXX ist. Nur ein kleinen Beitrag von mir. Ich weiß nicht, ob Ihr Euch schon mal die Mini ARM's von NXP LPC2103 Serie angeschaut habt. Die Teile gibt es von 8kB Flash + 2KB RAM bis 16kB Flash + 8kB RAM mit 70 MHz. Die Teile bekommt man selbst bei Reichelt, Schuricht und Digitkey in kleinen Stückzahlen. Bei Digikey den LPC2101 für 2.44€ (ab 25 Stück unter 2€) und den LPC2103 ab 3.64€ (ab 25 Stück unter 3€). Dafür bekommt Ihr keinen vergleichbaren 8Bitter mit dieser Performance/Speicher. Bis 32K könnt Ihr die IAR Kickstart Version kostenlos nutzen (einfach IAR Embedded Workbench for ARM von IAR herunterladen), dazu braucht Ihr dann noch ein J-Link von IAR oder Segger. Was das Bit-Toggeln angeht, die Mini-ARM's von NXP haben FAST-GPIO implementiert (was zur Zeit nicht bei Atmel, ST und Co zu finden ist), daß heißt, Ihr konnt mit vollen 17MHz von der SW aus die Bit Toggeln - und das mit vollen 32Bit Ausgängen. Die NXP Teile sind die schnellsten - laufen mit vollen 70MHz aus dem Flash heraus in ARM und Thumb Mode. Auch das schafft nur der NXP, nicht aber der Atmel oder ST ARM7. Das schafft kein 8Bitter. Nebenbei könnt Ihr noch andere Sachen machen. Komplette Beispiele findet Ihr auch nach der Installation. Und auf dem Netz tausend andere auch. By the way, man schafft auch ein 480x480 VGA display anzusteuern - nur mit dem ARM in SW - findet Ihr auch auf der Webseite. Ich selber arbeitet nur noch mit ARM7 Derivaten, weil die Teile günstiger und schneller sind als vergleichbare 8Bitter mit gleichem Speicher. Schönen Gruß
Nicht alle kleinen ARMe von Philips* haben Fast-GPIO implementiert; der sehr beliebte LPC2106 beispielsweise kann seine I/O-Leitungen nur mit etwa einem MHz wackeln lassen. Fast-GPIO gibt es nur in neueren ARMen. Ansonsten hast Du recht optimistisch die Werbaussagen von Philips abgeschrieben - natürlich laufen LPCxxx nicht mit vollem Takt aus dem Flash, sondern nur meistens, dank des 128Bit-breit organisierten Flash-ROMs und des MAM (was eine Art primitivster Cache-Controller ist). Unter realen Bedingungen kann da dann eine geringere Verarbeitungsgeschwindigkeit draus resultieren. Volle Lotte gibt's nur bei Codeausführung aus dem internen RAM. *) jaja, und Raider heißt jetzt Twix.
Torsten wrote: > Die Teile gibt es von 8kB > Flash + 2KB RAM bis 16kB Flash + 8kB RAM mit 70 MHz. Die Teile bekommt > man selbst bei Reichelt, Schuricht und Digitkey in kleinen Stückzahlen. > Bei Digikey den LPC2101 für 2.44€ (ab 25 Stück unter 2€) und den LPC2103 > ab 3.64€ (ab 25 Stück unter 3€). Dafür bekommt Ihr keinen vergleichbaren > 8Bitter mit dieser Performance/Speicher. Ein 8kB 32Bit-RISC dürfte vom Applikationsumfang etwa einem 2kB AVR entsprechen, also z.B. ATtiny2313, bloß, daß der AVR viel billiger ist und keine 2 Spannungsregler braucht. Sowas lohnt sich also nur dann, wenn man mit den ARMs schon total super fit ist und die gleiche Entwicklungsumgebung auch für Miniprojekte nehmen will und der höhere Preis und die zusätzlichen 2 Spannungsregler nicht ins Gewicht fallen und keine 5V-Ausgänge gebraucht werden. Bei mir ist davon nicht eines der Fall und daher haben die ARMs nur den Platz jenseits der 128kB Flash. Peter
>Bei mir ist davon nicht eines der Fall und daher haben die ARMs nur den >Platz jenseits der 128kB Flash. Warum 128kB Flash - die AVRs gibt es inzwischen auch mit 256kB. Ich bin im Moment auch am überlegen, ob es sich 'lohnt' sich näher mit ARM zu beschäftigen. Bis jetzt konnte ich alles mit AVRs 'erschlagen' und wenn es eng wurde, dann meist nur der Speicher oder die IOs, nicht so sehr die Rechenleistung.Und wenn man sich das Datenblatt von so einem AT91SAM7 anschaut, da zuckt man dann schon etwas. Für mich wäre ein ARM in erster Linie für Anwendungen interresant, wo viele Daten verrechnet und/oder übertragen werden müssen und evtl. eine Ausgabe auf ein größeres Display erfolgen müsste. Die Fragen die sich mir stellen: 1. Wie viel muss ich invetsieren, um erste Schritte mit einem ARM (AT91) machen zu können - ich nehme mal an, von meinen AVR-Tools (ISP, JTAG) kann ich nichts verwenden. 2. Mit was für einem Zeitaufwand muss ich ungefähr rechnen, bis man einfachere Sachen auf einem ARM zum laufen bringt? Wenn ich mir das Blockdiagramm von dem AT917S anschaue, kommen mir sehr viele Sachen (ADC, SPI, UART, Timer, TWI) bekannt vor - wenn sie ähnlich arbeiten, wie bei den AVRs, sollten die neuen Sachen sein: PWM, SSC, USB, PLL, ROM+SAMBA und der neue Kern. Da ich nicht vorhabe in Assembler zu programmieren, sind die grössten schwwarzen Löcher: SAMBA und USB. bye
@Peter falls die Rechenleistung tatsaechlich interessant ist, dann wuerde wohl eher ein 2k ARM einem 8k AVR entsprechen, denn die Sache mit integer, 32-bit word oder gar float ist natuerlich oberuebel mit einem 8-bitter. Wenn's nicht ums bit-schupsen geht, dann ist ein ARM im Thumb mode der Massstab fuer Codekompaktheit. Dann gibt es da noch die Kleinigkeit mit der RAMgroesse. Der 8k ARM hat immerhin 2k SRAM, 16k/4k, 32k/8k, das ist viel flexibler als die mini-RAMs in den AVR. Just my 2 cents, Robert
Robert Teufel, NXP wrote: > falls die Rechenleistung tatsaechlich interessant ist, dann wuerde wohl > eher ein 2k ARM einem 8k AVR entsprechen, denn die Sache mit integer, > 32-bit word oder gar float ist natuerlich oberuebel mit einem 8-bitter. Hast Du mal ne Hausnummer, wie groß die float-lib aufm ARM-GCC für die 4 Grundrechenarten ist ? Dieser Unterschied tritt aber nur einmalig auf, die Aufrufe dürften sich kaum unterscheiden. > Dann gibt es da noch die Kleinigkeit mit der RAMgroesse. Der 8k ARM hat > immerhin 2k SRAM, 16k/4k, 32k/8k, das ist viel flexibler als die > mini-RAMs in den AVR. Naja, ist genau doppelt so groß. Aber ob das nun auch soviel flexibler ist, hängt stark von der Programmierung ab: Wenn man beim ARM Variablen default als int (32Bit) anlegt, kommt sogar weniger raus. Nur wenn man strikt char nimmt, wenn char ausreicht, ists auch wirklich das doppelte. Den größeren Stackverbrauch (Call, Push) bei ARM noch nicht mal eingerechnet. Peter
@ray: >1. Wie viel muss ich invetsieren, um erste Schritte mit einem ARM (AT91) >machen zu können - ich nehme mal an, von meinen AVR-Tools (ISP, JTAG) >kann ich nichts verwenden. vom avr kannst du nichts weiterbenutzen. es gibt allerdings günstige jtag-ice (von olimex) und auch starterkits (ebenfalls olimex). die gnu tools sind ebenfalls vorhanden, auf www.yagarto.de findest du das komplette paket. >2. Mit was für einem Zeitaufwand muss ich ungefähr rechnen, bis man >einfachere Sachen auf einem ARM zum laufen bringt? Wenn ich mir das >Blockdiagramm von dem AT917S anschaue, kommen mir sehr viele Sachen >(ADC, SPI, UART, Timer, TWI) bekannt vor - wenn sie ähnlich arbeiten, >wie bei den AVRs, sollten die neuen Sachen sein: PWM, SSC, USB, PLL, >ROM+SAMBA und der neue Kern. Da ich nicht vorhabe in Assembler zu >programmieren, sind die grössten schwwarzen Löcher: SAMBA und USB. die in den at91sam7s integrierte peripherie hat nichts mit der im avr gleich (das kommt aus 2 verschiedenen "ecken" bei atmel). im gegensatz zum avr, wo in jedem derivat die peripherie wieder anders funkt. oder die bits wieder mal anders verteilt sind, ist beim at91sam7s die peripherie immer die gleiche. auch bei den anderen familien (at91sam7x, at921sam7se, at91sam9xxx) findest du nahezu die gleiche peripherie wie deim at91sam7s. so gesehen ist der zeitaufwand für den einstieg in den arm kurzfristig sicher höher aber langfristig ersparst du dir zeit. wenn due mit den für dich neuen komponenten (noch) nichts anfangen kannst dann spielt das keine rolle. lass sie einfahc unbenutzt. nach einem reset ist keine der peripherien aktiv. du kannst dich also stück für stück an die neuen dinge herantasten. eine große hilfe sind auch die beispiele auf www.at91.com (sind allerdings für dir iar worklbench vorbereitet). gruss gerhard
@Gerhard Hatte ich mir schon gedacht, dass es nicht ganz so einfach läuft, aber schaun wir mal, wird schon klappen, habe ja keinen Zeitdruck, dass ich schnell damit klar kommen müsste. Noch eine andere Frage: ich habe mich vorher ein bisschen bei elmicro.de umgeschaut, die verkaufen neben relativ teuren (für privat) Compilern von Keil auch einen günstigeren von Imagecraft, hat jemand Erfahrung damit: wie gut/schlecht ist das Teil im Vergleich zu teureren Compilern oder zu den gnu sachen? danke für die antworten Ray
@Peter, 2x ist korrekt fuer ATmega8, ansonsten ist es 4x. Woher kommt eigentlich die Info, dass der ATmega bei vergleichbarem Speicher billiger ist als ein ARM7? Wahrscheinlich ist meine Info von Digikey etwas vorgepolt aber ich finde da im Einzelstueck z.B. keinen ATmega16x im 44-pin Gehauese unter 5 Euro in Einzelstueck. Wenn ich z.B. den LPC2103 damit vergleiche, 32k Flash, 8k SRAM, doppelt soviele serielle Kanaele, mehr und hoeher aufloesende Timer, ca. 4-fache MHz, je nach Anwendungen sind das locker 10x performance und der LPC2103 kostet dieselbe Stueckzahl beim selben Distributor 3.64 Euro. Bei groesseren Speichern ist das (Miss)verhaeltnis noch wesentlich gravierender. Ich versteh einfach nicht wie es noch Diskussionen ueber Preis/Leistung geben kann, wier auch in deisem Thread. Die Diskussion ob sich ein Umstieg lohnt im Bezug auf "Time to Market", die ist jedoch sehr berechtigt. Robert
Robert Teufel, NXP wrote: > Woher kommt eigentlich die Info, dass der ATmega bei vergleichbarem > Speicher billiger ist als ein ARM7? Wahrscheinlich ist meine Info von > Digikey etwas vorgepolt aber ich finde da im Einzelstueck z.B. keinen > ATmega16x im 44-pin Gehauese unter 5 Euro in Einzelstueck. Also Reichelt will für nen ATmega16 2,18€ haben. Bei mir spielt allerdings der Preis nicht so die Rolle, sondern daß sie leicht handhabbar sind. Es passiert schon, daß mal schnell was auf ne Uniplatine dazugepappt werden muß ohne extra Spannungsregler, Quarz, Reset-IC. Ein AVR läuft halt mit nix zusätzlich außer der 100nF Pille an VCC. Und erst später kommt dann ein richtiges Layout. Peter
Also ich hab mit den AVRs schon einige Geschichten realisiert, zum Teil einfach fast and dirty, Punktraster, ISP-Stecker drauf, Saft dran und los gehts. In C oder Bascom mal schnell nen Code gepfiemelt und ab geht die Post. Ich hab nun hier 3 verschiedene Devboards liegen AT91SAM7S256, AT91SAM7X256 und LPC2148 und bin nahe am Verzweifeln. Beim AVR GCC unter Studio4, prima zu simulieren und zu debuggen, mit Ponyprog flashen und gut ist. Bei den ARM siehts da ganz anders aus. Keil IAR GCC Eclipse hitop und und und ... und Samplecodes portieren von A nach B nur ätzend. Bei den Atmels will mir vor allem nicht in den Sinn warum da zigtausendmal AT91C_ in den Libs vertippt wurde !!!! Also mir fällt der Umstieg definitiv nicht leicht, aber ich bräucht für n Projekt ziemlich geballte Rechenpower und da währen die ARM7TDMI n guter Ansatz dafür.
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.