Hallo Leute, ich bin mit den 8-Bit AVRs eigentlich recht zufrieden. Ich will aber auch nicht in die "Was der Bauer nicht kennt"-Falle laufen und vielleicht etwas verpassen. Ich habe mir deshalb diese Seite http://www.mikrocontroller.net/articles/Mikrocontroller_Vergleich einmal angesehen und auch sonst noch etwas recherchiert. Vielleicht können mir Leute, die sich mit anderen Familien auskennen, meine Vorurteile bestätigen oder zerstreuen. Es geht um Basteleien, wichtig sind daher auch die Verfügbarkeit (Reichelt &Co.) und die Lochrastertauglichkeit (DIP-Gehäuse). 8051: Angefangen habe ich einmal damit. Die Akku-zentrierte Architektur kann einem unter C eigentlich Wurscht sein. Die Rechenleistung/Takt ist aber aus meiner Sicht nicht so toll und es gibt auch eher weniger On-Board-Hardware als beim AVR. (z.B. SPI, I²C etc. fehlen) PIC: Als ich vor Jahren nach einer Alternative zu 8051 suchte, wurde mir davon abgeraten. Es würden zwar viele verschiedene Controller angekündigt, die seien aber dann schwer zu bekommen. Außerdem unterscheiden sich die einzelnen Typen teilweise sehr und man muss quasi bei jedem IC mehr oder weniger von vorne anfangen. MSP430: Wirbt mit "16-Bit". Im DIP-Gehäuse sind aber nur wenige zu erhalten, so auf ATTiny-Niveau, was den Speicherausbau betrifft. Die Rechenleistung ist trotz "16-Bit" eher mau, dafür stromsparend. Auch eher sparsam, was die Ausstattung mit On-Board-Hardware betrifft. 8-Bit AVR: Kenne ich inzwischen sehr gut. Die ATMegas sind in den Grundfunktionen einander sehr ähnlich - kennt man erst einmal einen, fühlt man sich auch auf den anderen schnell zu Hause. Im DIP-Gehäuse kommt man bis 128k Flash und 16k SRAM. Viele Typen bei den üblichen Verdächtigen verfügbar. XMEGAs: Kein DIP-Gehäuse :(. Nur wenige Typen erhältlich. Mehr Funktionen als die normalen Megas, aber irgendwie nur der halbe Weg zum AVR32, der auch nicht teurer ist. AVR32: Ebenfalls kein DIP-Gehäuse und nur wenige Typen frei verfügbar. Bieten aber mehr Rechenleistung als die 8-Bit (32 Bit und höhere Taktrate). Wäre daher meine erste Wahl, wenn es mit den ATMegas nicht mehr reicht. R8: Keine Ahnung R32: Keine Ahnung. Bin jetzt schon gespannt, was an Kommentaren kommt. (Aber bitte keine Flame-Wars etc. Jede Architektur hat ihre Existenzberechtigung und den "besten" Controller gibt es sowieso nicht, weil es immer auf die Anforderungen ankommt.) Gruß, DetlevT
Die diversen ARMs fehlen in deiner Auflistung. Von der Forderung, alles noch in einem DIP-Gehäuse zu bekommen, nur damit du das auf ein Steckbrett nageln kannst, darfst du dich wohl allmählich trennen. QFP lässt sich allemal brauchbar mit der Hand löten, sogar auf selbstgemachten Platinen, zumindest in den größeren Rastermaßen (bei 0,5 mm braucht man dann schon ein bisschen Löt- erfahrung, wobei der Entlötlitzentrick allemal funktioniert). Sieh's positiv: dank SMD werden auch die Baugruppen der Hobbyisten viel kleiner, als man sich das vor 20 Jahren je hätte vorstellen können.
Detlev T. schrieb: > PIC: Als ich vor Jahren nach einer Alternative zu 8051 suchte, wurde mir > davon abgeraten. Es würden zwar viele verschiedene Controller > angekündigt, die seien aber dann schwer zu bekommen. Außerdem > unterscheiden sich die einzelnen Typen teilweise sehr und man muss quasi > bei jedem IC mehr oder weniger von vorne anfangen. Ich wäre hier mit solchen Themen sehr vorsichtig. Ich sag dir ehrlich ich bin auch ein PIC-Verfechter. Die PICs sind genauso leicht zu bekommen wie die AVRs. Das die sich unterscheiden wäre mir auch neu - okay man muss manchmal Controllerspezifisches im Datenblatt nachschlagen aber es ist genau das gleiche wie bei den ATMEGAs (mit denen ich auch schon gearbeitet habe). Bei den AVR hat mich ehrlich gesagt aufgeregt, dass sie so kleine Kinderkrankheiten wie die Möglichkeit des Verfusen bieten. Ansonsten sind AVR und PIC gleichzusetzen. PICs sind leicht teurer dafür in meinen Augen ausgereifter. Deine Liste möchte ich in diesem Sinne noch mit anderen PIC-Typen ergänzen die mit den normalen PICs recht wenig zu tun haben. (Weder vom Aufbau noch von der Programmierung) dsPICs (mit DSP Unit) PIC32
Lehrmann Michael schrieb: > Das die sich unterscheiden wäre mir auch neu - Die Typen mit 12/14-Bit und 16-Bit Codewortbreite unterscheiden sich im Befehlssatz signifikant. Infolgedessen sind dafür unterschiedliche C-Compiler nötig. Bei den 16-Bit Typen existieren dann noch zwei signifikant verschiedene Generationen, die älteren arbeiten mit direkter Adressierung, die neueren beherrschen alternativ die Compiler-freundlichere Offset-Adressierung. > dsPICs (mit DSP Unit) Interessant ist die ganze PIC30 Familie, ob mit oder ohne DSP: dsPIC30, PIC24, dsPIC33, wobei sich die bis 40pin in DIP erhältlichen dsPIC30 aufgrund ihres Stromverbrauchs auch als Kaffeewärmer eignen ;-). Allerdings sollte man vorher das betreffende Errata-Sheet lesen. Insbesondere wenn man bisher nur AVRs kannte. Die PIC30 sind in der Hinsicht ähnlich ergiebig wie die 32-Bitter anderer Anbieter.
Thomas Kiss schrieb: > PIC Programmer sind auch wesentlich teuerer oder ? Nein. Wobei vor dem Auftauchen des AVR-Dragon die Programmer/Debugger-Kombis bei PICs deutlich günstiger waren als der sauteure JTAG-Mk2 der AVRs. Die diversen als Programmer und Debugger einsetzbaren ICD2-Clones für die PICs liegen in ähnlicher Preisklasse wie der Dragon. Allerdings ist die Programmiertechnik der AVRs etwas freundlicher in der Systemintegration, denn die Programmierpins sind da nur bei aktivem Reset aktiv, wodurch sich diese Pins oft problemlos mit einer anderen Funktion ausserhalb des Resets kombinieren oder alternativ per Reset-Signal unterscheiden lassen. Bei den 8-Bit PICs ist das allein schon aufgrund des völlig andersartigen Reset-Signals nicht ganz so einfach.
Detlev T. schrieb: > MSP430: Wirbt mit "16-Bit". Im DIP-Gehäuse sind aber nur wenige zu > erhalten, so auf ATTiny-Niveau, was den Speicherausbau betrifft. Die > Rechenleistung ist trotz "16-Bit" eher mau, dafür stromsparend. Auch > eher sparsam, was die Ausstattung mit On-Board-Hardware betrifft. Deine MSP430-Interpretation ist nur dann korrekt, wenn man sich auf die im DIP-Gehäuse verfügbaren Typen beschränkt. Diese aber machen nur einen verschwindend geringen Bruchteil der MSP430-Familie aus, die in Sachen Speicherausbau bis 16 kByte RAM und 256 kByte Flash-ROM geht, mit bis zu 25 MHz Taktfrequenz, einem "barrel shifter" (der Schiebeoperationen beschleunigt) und einem Hardwaremultiplikator durchaus einiges an Rechenleistung hinbekommen kann. Auch die Peripherie ist bei den ernstgemeinten MSP430-Varianten durchaus sehenswert, beim derzeitigen "Dickschiff" 'F5438 beispielsweise gibt es vier USCI_A/B-Pärchen, die simultanen Betrieb mit vier seriellen Schnittstellen und vier SPI- oder I2C-Schnittstellen erlaubt. Ein 16kanaliger 12-Bit-ADC mit mehreren hundert kHz Samplerate kommt noch dazu. Was es bei keinem einzigen MSP430 gibt, ist ein externes Speicherinterface. Anwendungen, die nicht mit den 16 kBye RAM der größten Familienmitglieder auskommen, sind somit eher 'ne Sache für andere Controllerfamilien. Die 16 Bit sind durchaus ernstzunehmen, das "Dickschiff" kann auch echte 16-Bit-Portzugriffe durchführen, was, wenn man so etwas wie eine IDE-Festplatte oder eine CF-Karte ansteuern möchte, einiges an Performance gegenüber sequentiellen 8-Bit-Zugriffen mit sich bringt. Die MSP430-Reihe wird im Bastelsegment ziemlich stiefmütterlich behandelt, Olimex beispielsweise ignoriert seit Jahren alle neu auf den Markt gekommenen Controller - das "Dickschiff" beispielsweise kennen die nicht, nach den Platinen für die schon etwas angejahrten 'F169-12 ist nichts wesentliches mehr geschehen. Die neue Platine für den 'F2618 ist auch nur ein Aufguss der Platine für den 'F169, denn die Dinger sind weitestgehend pinkompatibel. Auch das Angebot bei Händlern wie Reichelt ist ziemlich dürftig, einerseits rufen die völlige Phantasiepreise für den 'F1611 auf, andererseits haben sie nichts neueres. Der 'F5438 ist trotz erheblich gesteigerter Leistung gegenüber dem 'F1611 deutlich günstiger (TI selbst nennt etwa den halben Preis). Möglicherweise belebt sich die Situation mit der Launchpad-Aktion etwas, immerhin lässt sich das Launchpad auch als Debug- und Programmierinterface für den 'F5438 verwenden und dürfte damit so ziemlich das kostengünstigste JTAG(artige) Interface auf dem Markt sein.
Hallo Leute, vielen Dank für eure Hinweise. Das hat mir schon weiter geholfen. ARM hatte ich tatsächlich noch nicht auf dem Radar. Irgendwie verbinde ich damit "da muss Linux drauf laufen", aber dem ist ja nicht so. Sollte ich irgendwann mit AVR32 liebäugeln, werde ich ARM als Alternative in Betracht ziehen. Mit PIC brauche ich mich dann wohl wirklich nicht beschäftigen, da es den großen Vorteil zu AVR8 offenbar nicht gibt. Das ist wohl eher wie der Unterschied von Coke und Pepsi. ;) Die volatile Entwicklung der PIC-Controller gefällt mir da wirklich nicht, auch wenn es im Zweifelsfall der Compiler ist, der sich damit herum ärgern muss. Da finde ich die konservative Einstellung beim AVR besser, auch wenn das zunehmend Probleme macht. (z.B. bei Flash größer 128kB und Ports jenseits von 0x3F, die nicht mehr via OUT/IN erreichbar sind). BTW: So manches Mal hat mich auch gestört, dass externe Speicherinterfaces so selten sind. Ist aber auch eine zweischneidige Sache, weil Parallel-Interfaces natürlich Pinfresser sind. Ich freunde mich da zunehmend mit dem Gedanken an, SRAM auch einmal per SPI anzubinden. Mit dem 23K256 (3,3V) von Microchip gibt es da immerhin 32kiB, sogar im DIP-Gehäuse. Mit etwa 20 Takten/Byte (AVR8) beim sequentiellen Zugriff ist das zwar lange nicht so schnell wie parallel und vom Compiler wird das natürlich auch nicht direkt unterstützt. Aber für manche Anwendungen vielleicht doch ganz brauchbar und wahrscheinlich immer noch besser als ein Parallelinterface, das man in Software implementieren muss. Gruß, DetlevT
Detlev T. schrieb: > PIC: Als ich vor Jahren nach einer Alternative zu 8051 suchte, wurde mir > davon abgeraten. Es würden zwar viele verschiedene Controller > angekündigt, die seien aber dann schwer zu bekommen. Außerdem > unterscheiden sich die einzelnen Typen teilweise sehr und man muss quasi > bei jedem IC mehr oder weniger von vorne anfangen. Bitte nicht alle PICs über einen Kamm scheren. PIC10/12 sind wirklich nur für Dinge geeignet die als einzige Vorrausetzung ein möglichst kleines Gehäuse haben. Auch die PIC16 Reihe ist total veraltet. Wenn dann musst du die PIC18 Reihe als Vergleich nehmen. Die sind ähnlich schnell wie AVR, es gibt MASSIG Typen (auch in DIP) mit sehr interessanter Peripherie: CAN, USB, Ethernet. CAN und USB Controller gibts in DIP und z.B. bei R Programmiertools sind günstig: Pickit3 (Programmer und Debugger) 69€ und nicht so leicht tot zu bekommen wie ein Dragon Ich kann jetzt nur von C sprechen und da geben sich AVR und PIC18 nix. Außerdem muss ich der Aussage widersprechen, dass sich die Typen stark unterscheiden. Das Gegenteil ist der Fall: Du hast durchgängig von PIC10 (8biter, 12bit Wortbreite) über Pic18 (8biter) über PIC24 (16biter), dsPIC(16bit DSP) und PIC32 (32biter) die gleiche Oberfläche. Der Wechsel von PIC18 zu PIC24 gestaltet sich (zumindest in C) sehr einfach... Aber wirklich rentieren tut es sich nicht wenn du dich mit den AVRs gut auskennst würde ich mich eher nach "oben" (also z.B. ARM, PIC32) und nicht zur Seite orientieren.
Kuck Dir unbedingt den STM32 mal an http://www.mikrocontroller.net/articles/STM32 Das ist mein aktueller Liebling vor allem wegen der komfortablen C Firmwarebibliothek. http://www.mikrocontroller.net/articles/STM32F10x_Standard_Peripherals_Library Gruß Tom
Detlev T. schrieb: > vielen Dank für eure Hinweise. Das hat mir schon weiter geholfen. ARM > hatte ich tatsächlich noch nicht auf dem Radar. Irgendwie verbinde ich > damit "da muss Linux drauf laufen", Kannst ja auch NetBSD nehmen. ;-) > aber dem ist ja nicht so. ARM != ARM. Es gibt halt welche, die mit einem virtuellen Speicher- system aufwarten, auf denen sich dann wirklich ein OS wohl fühlt (ARM9). Das sind aber nicht mehr wirklich Controller, sondern regelrechte Prozessoren (Speicher komplett extern). Die kleineren ARMs (ARM7TDMI, Cortex M3) sind jedoch "echte" Controller und passen daher an vielen Stellen, wo man etwas mehr Rechenleistung haben will. > BTW: So manches Mal hat mich auch gestört, dass externe > Speicherinterfaces so selten sind. Ist aber auch eine zweischneidige > Sache, weil Parallel-Interfaces natürlich Pinfresser sind. Ich freunde > mich da zunehmend mit dem Gedanken an, SRAM auch einmal per SPI > anzubinden. Naja, es ist ja nicht nur SRAM, was man da anschließen kann. Ein FT245 lässt sich dann einfach mit memcpy() beschreiben, und man muss sich um keine Datenrate und Quarzfrequenz und sowas Gedanken machen (wie beim FT232). Ich baue im Moment gerade ein Interface für einen Signalgenerator, der auf 10 Stellen mit BCD parallel gefüttert werden möchte. Eine Reihe 74HC574 an den Speicherbus gehängt, und ab geht die Post: ein Frequenzupdate ist in 3 µs durch (der Generator braucht 20 µs dann zum Einpegeln der neuen Frequenz). Manchmal ist MMIO schon praktisch.
Die MSP430 sind wirklich einen Blick wert, insbesondere die ez430-Chronos. Im Vergleich zu den AVRs sind die MSP430 jedoch IMHO relativ komplex, man sehe sich nur das Powermangament an. Auch die Taktverteilung ist im Vergleich zu den AVRs sehr umfangreich. Besonders gelungen ist auch das Portmapping, man kann also z.B. den PWM-Ausgang auf beinahe jeden Pin routen, das gibt einem bestimmt enorme Freiheiten beim Layout.
Detlev T. schrieb: > Mit etwa 20 Takten/Byte (AVR8) beim > sequentiellen Zugriff ist das zwar lange nicht so schnell wie parallel > und vom Compiler wird das natürlich auch nicht direkt unterstützt. Aber > für manche Anwendungen vielleicht doch ganz brauchbar und wahrscheinlich > immer noch besser als ein Parallelinterface, das man in Software > implementieren muss. Also so ein Parallelinterface ist sehr, sehr einfach implementiert und je nach Speicher auch sehr schnell.
Luk4s K. schrieb: > Auch die Taktverteilung ist im Vergleich zu den AVRs sehr umfangreich. Ja, aber dafür hat man auch keine "Fuses", die die Takterzeugung betreffen und geschätzte 30 % aller Anfängerprobleme beim AVR ausmachen. Vielmehr ist es möglich, im Betrieb die Taktquelle zu ändern, was reizvolle Möglichkeiten zum Stromsparen ergibt. Luk4s K. schrieb: > Besonders > gelungen ist auch das Portmapping, man kann also > z.B. den PWM-Ausgang auf beinahe jeden Pin routen Das ist leider eher Zufall denn üblich, normalerweise gibt es da gar keine Freiheitsgrade.
Gastino G. schrieb: > Also so ein Parallelinterface ist sehr, sehr einfach implementiert und > je nach Speicher auch sehr schnell. Für den wahlfreien Zugriff ist das sicher der Fall, weil man beim SPI-SRAM sonst erst die Adresse übertragen muss. Deswegen schrieb ich ja explizit von sequentiellem Lesen/Schreiben. Parallel mit dem üblichem Latch komme ich da auf folgende Rechnung (AVR8): Adresse an Ports ausgeben (2 Takte), Latch triggern (2 Takte), AD-Port auf Input (1 Takt) OE auf low (1 Takt) auf SRAM warten (1-2 Takte) Byte einlesen (1 Takt) OE auf high (1 Takt), AD-Port auf Ausgang (1 Takt), 16-Bit Adresse inkrementieren (2 Takte), das Ganze von vorn. Macht 12-13 Takte vs. 18 bei maximaler SPI-Geschwindigkeit. (Eventuell sogar nur 16, wenn man ein doppelt gepuffertes USART dafür missbrauchen kann) Parallel ist man da also nur etwa 33% schneller. Rufus t. Firefly schrieb: > Vielmehr ist es möglich, im Betrieb die Taktquelle zu ändern, was > reizvolle Möglichkeiten zum Stromsparen ergibt. Bei den neueren AVRs kann man im Betrieb den Prescaler für den Takt ändern.
Den Prescaler. Aber kann man auch zwischen internem RC-Oszillator, externem LF-Oszillator und externem HF-Oszillator hin- und herschalten?
Detlev T. schrieb: > Parallel ist man da > also nur etwa 33% schneller. PS: Ich vergaß: Dann hat man das Byte ja noch nicht abgespeichert (2 Takte). Das kann man bei SPI tun, während die Hardware schon nächste Byte holt. Bei dem Software-Parallelinterface aber nicht. Also steht es für diese spezielle Anwendung (mehrere Bytes sequentiell lesen) nur noch 14-15 zu 18 für Software-Parallel. Da kommt man schon ins Grübeln, oder? Rufus t. Firefly schrieb: > Aber kann man auch zwischen internem RC-Oszillator, > externem LF-Oszillator und externem HF-Oszillator hin- und herschalten? Nö. Habe ich aber auch noch nie gebraucht. ;)
Rufus t. Firefly schrieb: > Luk4s K. schrieb: >> Besonders > gelungen ist auch das Portmapping, man kann also >> z.B. den PWM-Ausgang auf beinahe jeden Pin routen > > Das ist leider eher Zufall denn üblich, normalerweise gibt es da gar > keine Freiheitsgrade. Habe ich da etwas falsch verstanden?
Rufus t. Firefly schrieb: > Den Prescaler. Aber kann man auch zwischen internem RC-Oszillator, > externem LF-Oszillator und externem HF-Oszillator hin- und herschalten? Seit Xmega ja, davor nur vereinzelt (beispielsweise bei den kleinen AT90USBxx).
Detlev T. schrieb: > Parallel mit dem üblichem > Latch komme ich da auf folgende Rechnung (AVR8): Adresse an Ports > ausgeben (2 Takte), Latch triggern (2 Takte), AD-Port auf Input (1 Takt) > OE auf low (1 Takt) auf SRAM warten (1-2 Takte) Byte einlesen (1 Takt) > OE auf high (1 Takt), AD-Port auf Ausgang (1 Takt), 16-Bit Adresse > inkrementieren (2 Takte), das Ganze von vorn. Macht 12-13 Takte vs. 18 > bei maximaler SPI-Geschwindigkeit. (Eventuell sogar nur 16, wenn man ein > doppelt gepuffertes USART dafür missbrauchen kann) Parallel ist man da > also nur etwa 33% schneller. Die Rechnung stimmt aber nur wenn du es "von Hand" machst und nicht bei echtem ext. RAM Port. Schau mal ins Datenblatt von z.B. 8515 wie da das Timing ist. Und von Hand kann man ja außerdem mit jedem µC mit ausreichend Portpins, also keine Frage der µC-Familien. frank
Hallo frank, da hast du recht, aber darum ging es hier auch gar nicht: Gastino G. schrieb: > Detlev T. schrieb: >> für manche Anwendungen vielleicht doch ganz brauchbar und wahrscheinlich >> immer noch besser als ein Parallelinterface, das man in Software >> implementieren muss. > > Also so ein Parallelinterface ist sehr, sehr einfach implementiert und > je nach Speicher auch sehr schnell. Thema war also explizit Parallelinterface in Software vs. SRAM via SPI. Und da schneidet aus meiner Sicht SPI überraschend gut ab, was die Geschwindigkeit betrifft. Bei wahlfreiem Zugriff hat selbst Software-Parallel die Nase weit vorn (14-15 Takte vs. 54), Nur wenn man regelmäßig auf mehrere Bytes sequentiell zugreift, kommt SPI näher heran. Dafür braucht es weniger Pins (4 statt 19) und auch weniger Platz auf der Platine. Was da am Ende wirklich besser ist, hängt dann halt von den Anforderungen ab. Gruß, DetlevT
Detlev T. schrieb: > Mit PIC brauche ich mich dann wohl wirklich nicht beschäftigen, da es > den großen Vorteil zu AVR8 offenbar nicht gibt. Sehe ich auch so. Besonders die kleinen PICs sind extrem umständlich zu programmieren (Hardwarestack, keine Interrupts), da beißen sich die Compilerbauer die Zähne aus. Die AVRs sind dazu im Gegensatz schon ab 6 Pins voll ausgerüstet, nur der MUL-Befehl fehlt bis zu den 20-Pinnern. Ein AVR-Projekt läßt sich also wesentlich bequemer downsizen. > (z.B. bei Flash größer 128kB Da würde ich ganz konsequent sein, 8Bit nur bis max 64kB, darüber nur 32Bit mit 32Bit Adresssen. Ich denke, der ARM-Cortex-M3 ist da zu empfehlen. Schließlich haben den mindestens 4 Firmen im Programm (Atmel, NXP, ST, TI/Luminary), Peter
Peter Dannegger schrieb: >> (z.B. bei Flash größer 128kB > > Da würde ich ganz konsequent sein, 8Bit nur bis max 64kB, darüber nur > 32Bit mit 32Bit Adresssen. Da beim AVR8 der Programmzähler auf 16-Bit Wörtern arbeitet, sehe ich hier die natürliche Grenze bei 128k, davon maximal 64k Daten. Aber das ist bei Controllern ja schon eine ganze Menge.
> R8: Keine Ahnung > R32: Keine Ahnung. Diese japanischen Microcontroller sind an und für sich ziemlich coole Typen. Sie basieren von der Architektur auf dem Motorola 68000, der Prozessor vom Mac/AtariST/Amiga, mal abgespeckt, mal aufgerüstet, und sind deswegen sehr angenehm zu programmieren, sowohl in Assembler als auch in höheren Sprachen einfach für die Compilerbauer. Die Japaner haben also nicht den Fehler gemacht, auf eine bis zum geht-nicht-mehr reduzierte Spararchitektur zu setzen die dann nur noch Problem macht, wie bei PIC oder 8051. Zudem waren sie schon lange vor den amerikanischen (oder, falls man den MSP mitzählt, deutschen) Microcontrollern NÜTZLICH, d.h. sie hatten sinnvolle Stromsparfunktionen und vor allem wieder Aufwachfunktionen, liefen an 2 Batteriezellen, konnten LCDs direkt ansteuern, Sonderfunktion für Drehstrommotorsteuerung etc. Nur leider sind gerade die R8/M16/R32 ziemlich blöd und geizig bei den Ports. Statt jedes als I/O nutzbar zu machen, sind die in Gruppen organisiert um ein paar Bits zu sparen.
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.