Hi Gibts nen uC der standalone (ohne ext beschaltung),mit mehr als mit 8 Mhz läuft? Am besten auch noch in DIL mit <=28pin (je weniger je besser)
ja attiny85 oder attiny861, das sind jeweils die Grössten in der Gruppe.
Bei den AVRs gibt es ein paar: z.B. Tiny261 - braucht dann aber relaitv viel Strom für den internen PLL. Sollte dann mit 16 MHz laufen. Der Tiny13 macht 9,6 MHz. Ein bisschen über die nominellen 8 MHz kann man ober Osccal auch noch hinaus. Die PIC33 sollten auch gehen. Wobei man da vermutlich gar keine 8 MHz mehr braucht, weil auch so schon recht schnell.
>Gibts nen uC der standalone (ohne ext beschaltung),mit mehr als mit 8 >Mhz läuft? Um dan damit was zu tun? Bedenke immer das der interne Takt nicht besonders genau ist.
super danke dir. Tiny85 ist genau was ich suche. Noch ne frage: mit rccal bringt man ja den PCK auf 85MHz was dan ne cpu freq von 21.25MHz ist. Läuft er mit dieser gesch noch stabil bei 5V (U tran min 4.8V)? Laufen die die sachen des PCK (timer usw.) mit 85 MHz?
holger schrieb: > Um dan damit was zu tun? Bedenke immer das der interne > Takt nicht besonders genau ist. Keine besondere Sache, will mir einfach n paar std. uCs anschaffen, die ich bei Bedarf für irgendwas brauchen kann. Die genauigkeit des osc ist egal, solange er möglichst schnell stabil läuft (mache keine Uhr), sonnst kann ich ja immer noch quarz anschliessen.
Ulrich schrieb: > Die PIC33 sollten auch gehen. Wobei man da vermutlich gar keine 8 MHz > mehr braucht, weil auch so schon recht schnell. PIC3 oder AVR welcher bietet mehr performance? AVR dachte ich hat doch alles single inst (bis auf division) oder? Ist der befehlssatz des pic3 mächtiger? oder wie kann der sonst an die Effizienz des avr rankommen?
2.0 Sound schrieb: > Läuft er mit dieser gesch noch stabil bei 5V (U tran min 4.8V)? Computer sagt nein.
Jedenfalls nicht laut Datenblatt, außerdem kann ich mich flüchtig daran erinnern das AVR bei der Taktrate nicht viel Luft nach oben, also zum Übertakten, haben.
Die PIC16F182x haben intern bis 32 MHz (u.a. 8 und 16 MHz direkt, 32 Mhz durch 4x8 Mhz PLL), gibt es mit 14, 18, 20 und 28 Pins, sowohl in DIP- als auch in SMD-Gehäusen. Gibt es auch als LF-Version, d.h. Vdd bis 3.6 Volt und extrem geringer Stromverbrauch im Sleep. Kosten ca 1 bis 1.50 Euro. Die eingebaute Peripherie-Hardware ist umfangreich.
usuru schrieb: > Die PIC16F182x haben intern bis 32 MHz (u.a. 8 und 16 MHz direkt, 32 Mhz > durch 4x8 Mhz PLL), Hmm interessant! Wie unterscheiden sich die PIC16 von den PIC33? Die Tacktrate ist ja nicht alles, wie sind die so im vergleich mit den AVRs (auch alles ausser DIV single cycle)?
Der PIC33 wird bei vielen Anwendungen bei gleichem Takt schneller sein. Das sollten auch mit dem Internen Takt noch 40 MIPS möglich sein. Vor allem wenn man mehr als 8 Bit braucht sollte der PIC33 wesentlich schneller sein als der AVR, aber selbst bei 8 Bit Zahlen wohl noch etwa 2 mal schneller. Allersdings braucht der auch einiges mehr an Strom.
Wenn man die 80 MHz beim PIC33 zu Grunde legt, sind fast alle Befehle 2 Zyklen lang - die Division ist aber wie üblich deutlich langsamer, aber immerhin gibt es sie. Beim PIC16 sind es 4 Taktperioden und selten 8 Perioden, keine HW Division. Beim AVR sind auch nicht alle Befehle 1 Zyklus, aber immerhin die meisten, es gibt aber einige (mehr als beim PIC) Ausnahmen die länger brauchen. Trotzdem ist der AVR meist schneller als ein PIC16 oder PIC18 mit dem 4 fachen Takt, denn die Befehle sind eher mächtiger.
2.0 Sound schrieb: > Hi > Gibts nen uC der standalone (ohne ext beschaltung),mit mehr als mit 8 > Mhz läuft? > Am besten auch noch in DIL mit <=28pin (je weniger je besser) Also bei den PICs gibt es alleine in der Familie der 18F Pics mehr als 20Typen die diese Anforderungen erfüllen. TEilweise sogar mit CAN oder USB. (Wobei die meisten USB für USB zwingend einen externen Quarz brauchen ->genauigkeit) Die erreichbaren Taktraten ohne externe Beschaltung liegt dank interner PLL dann je nach Typ bei max 20, max. 48 oder max. 64Mhz. Die Geschwindigkeit kann zur Laufzeit auf viele Werte zwaischen 31KHz und 64Mhz umgeschaltet werden Ein gutes Beispiel wäre der PIC18F25K22 (verwende genau diesen gerade, allerdings in SO) 28Pin P-Dip(u.a. SMD), Betriebsspannungsbereich von 1,8 - 5,5V, viele Taktraten von 31KHz bis 64Mhz rein Intern möglich. Kostet unter USD 2,00 Einiges an Peripherie. Zahlreiche Code & Pinkompatible Modelle mit "Spezieller" Peripherie verfügbar. http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en546240 Aber es gibt noch eine Menge mehr. GRuß Carsten
Danke für eure Antworten. Mehr als 8-bit brauch ich eigentlich nicht, (sehe eigentlich nur nachteile: Mehr stromverb, grösserer aufwand herstellung, mehr speicherplatzverbrauch usw.). Ich verstehe sowiso nicht, wesshalb viele kleine uC 16bit haben. Zumal 99% der variablen char sind und wenn dann mal ausnamsweise ne int kommt, machen die 2-3 zusatzinst um diese zu behandeln auch nicht viel auf die gesamtperformance aus. Gibts PIC33 der standalone (ohne watchdog, rst irgendwass, und clk) auf 80MHZ läuft? Und wenn möglich DIL8 oder SO8 :P, ne aber sagen wir mal mit anständiger (tiefer) Pinnzahl. Stromverbrauch ist mir ziemlich egal, da ich vermutlich nichts battriegespiesenes mache. Ulrich schrieb: > Der PIC33 wird bei vielen Anwendungen bei gleichem Takt schneller sein. > Das sollten auch mit dem Internen Takt noch 40 MIPS möglich sein. Hmm aber doch nur bei speziellen DSP operationen oder? "Algemeiner" code läuft doch nicht schneller (IPS) als CPU Zyklen. Zumal diese CPU kein SIMD (ausser evt. DSP zeugs) kann oder? Was ist eigentlich mit den 8051ern. Da gibts ja unterdessen auch 80+ MHz modelle (kenne jedoch keinen mit int osc). Die arch ist zwar ein bisschen in die jahre gekommen aber mit nem 16MHz AVR sollte ne 80MHz 8051 doch locker mithalten können oder?
Carsten Sch. schrieb: > Also bei den PICs gibt es alleine in der Familie der 18F Pics mehr als > 20Typen die diese Anforderungen erfüllen. Danke dir! Carsten Sch. schrieb: > Ein gutes Beispiel wäre der PIC18F25K22 Stimmt der läuft mit 64MHz, jedoch dann nur 16MIPS (laut DB) Ulrich schrieb: > Beim AVR sind auch nicht alle Befehle 1 Zyklus, aber immerhin die > meisten, es gibt aber einige (mehr als beim PIC) Ausnahmen die länger > brauchen. Trotzdem ist der AVR meist schneller als ein PIC16 oder PIC18 > mit dem 4 fachen Takt, denn die Befehle sind eher mächtiger. Also dann habe ich wohl meine Anforderungen etwas schwammig formuliert. In dem Fall doch eher AVR als PIC18. Der TINY mit DIL 8 sieht schon ganz schön aus :-). Mal sehen was sonnst noch für Vorschläge kommen. Ich kenn mich mit PIC überhaupt nicht aus, wie ist dort so die Entwicklungsumgebung?
Hmmm der kleinste pic33 hat 64Pins und kann nur 3.3V. Da könnt ich auch gleich nen AT91RM9200 nehmen, läuft dann jadoch nicht mehr mit internal osc, jedoch wesentlich mehr performance. (Ext ram ist nicht nötig, da L1 Cache vorhanden). Wieso gibts eigentlich keine 8-Bit uC mit 200Mips in SO8 oder DIL8? Machbar sollte das doch sein, denn mann schaffts ja auch mit 32 bit. (IO-Tackt evt. geringer (wegen EMV, Datenintegrität usw.))
Hi Irgendwie verstehe ich nach dieser Aussage deine Frage nicht: >Keine besondere Sache, will mir einfach n paar std. uCs anschaffen, die >ich bei Bedarf für irgendwas brauchen kann. Und da weißt du schon vorher, das 8MHz nicht ausreichen? Was ist mit Speichergröße, Anzahl Timer, PWMs, Schnittstellen.... ? MfG Spess
spess53 schrieb: > Und da weißt du schon vorher, das 8MHz nicht ausreichen? Was ist mit > Speichergröße, Anzahl Timer, PWMs, Schnittstellen.... ? Gerade weil ich noch nicht sagen kann, wofür ich den uC dann wirklich brauche, und wass ich alles für funktionalitäten benötige (UART usw.) möchte ich anstelle eines sehr umfangreich ausgestatteten uC leiber ein schneller, damit ich gegebenenfalls SW Mässig die benötigte Funktionalität erreichen kann (auch mit 16MIPS nur bedingt möglich (ist mir schon bewusst)). Aber wieso die uC Hersteller immer mehr sachen implementeiren und den Datenbuss verbritern anstelle der Tacktrate zu erhöhen ist mir immer noch unklar.
Die 16-bit PICs sind schon recht schnell und noch nicht alllzu kompliziert zu programmieren. IDE und C-Compiler sind kostenlos. Schau Dir doch mal die parametrische Suche an http://www.microchip.com/en_US/family/16bit/index.html dsPIC33 und PIC24 schaffen bis zu 60 MIPS, es gibt auch welche im DIL-Gehäuse (bis zu 14 Pins herunter).
bingo schrieb: > dsPIC33 und PIC24 schaffen bis zu 60 MIPS, es gibt auch welche im > DIL-Gehäuse (bis zu 14 Pins herunter). find ich nicht... 40MIPS mit 20 Pins (z.b. dsPIC33FJ12MC201) oder dsPIC33EP256MU806 mit 60 MIPS 100pins usw. Welcher typ hat 14 Pins mit 60Mips DIL??
Die PIC33 gibt es auch im 18 PIN Dip. Die 40 MIPS sind auch für das normale Programm. Die DSP-funktionen geben einem da nur ein paar besonders mächtige Funktionen wie MAC, Saturierte Arithmetik und Unterstützung für zirkulare Puffer. Es gibt auch µCs die in Richtung hoher Takt mit wenig Perepherie gehen: z.B. eine 8051 Version bis 100 MHz (single Cycle), oder etwas exotisch der Propeller Chip. Für viele Anwendungen braucht man keine hohe Geschwindigkeit, sondern eher wenig Stromverbrauch. Vermutlich laufen die meisten µCs auch eher mit 1 MHz und weniger, einfach weil es schnell genug ist und weniger EMV Probleme macht. Auch der 8 BIT AVR mit 8 MHz internem Takt ist schon ähnlich schnell wie die ersten IBM PCs vor 30 Jahren.
Hi >Gerade weil ich noch nicht sagen kann, wofür ich den uC dann wirklich >brauche, und wass ich alles für funktionalitäten benötige (UART usw.) >möchte ich anstelle eines sehr umfangreich ausgestatteten uC leiber ein >schneller, damit ich gegebenenfalls SW Mässig die benötigte >Funktionalität erreichen kann (auch mit 16MIPS nur bedingt möglich (ist >mir schon bewusst)). Die Funktionalität die man in Hardware erreicht, bekommt man in Software auch mit einem 4...16 mal schnelleren Controller nicht gebacken. Also ist die Diskussion mit über OSCCAL-Einstellungen sinnfrei. Mit Assembler kann man noch einiges hin bekommen. Mit 'Hochsprachen' bist du aufgeschmissen. Alles, was du in Software machen musst blockiert den Controller für andere für andere Aufgaben. Und das gilt (wertungsfrei) für AVRs wie auch für PICs. Ehrlich gesagt, finde ich den Ansatz, sich irgend etwas hinzulegen falsch. MfG Spess
Andreas K. schrieb: > außerdem kann ich mich flüchtig daran > erinnern das AVR bei der Taktrate nicht viel Luft nach oben, also zum > Übertakten, haben. Das Problem ist in aller Regel nicht der CPU-Kern, sondern der Flash. Der ist von Natur aus eher langsam. Bei 32-bit-Controllern schachtelt man dann oft zwei Flash-Bänke, die jeweils 33 MHz oder so schaffen, um auf 66 MHz für den ganzen Controller zu kommen.
spess53 schrieb: > Die Funktionalität die man in Hardware erreicht, bekommt man in Software > auch mit einem 4...16 mal schnelleren Controller nicht gebacken. Es kommt natürlich drauf an um was genau es sich handelt, zb. so ne UART oder sowas kommt man mit 16MIPS schon gebacken. Das praktische an den tinys ist, dass man sie für allerlei sachen verwenden ("Zweckentfremden") kann. Sollte ich gerade kein 74HC irgendwass und auch kein GAL usw zur hand haben und spielt die Latenzzeit nicht so ne rolle -> AVR tiny Sollte ich keinen externen AD-Wandler haben -> AVR tiny usw. Nur leider ist für gewisse solche "spezialanwendugen" die performance solcher uC zu knapp (Tiny kannte ich bis vor kurzem noch nicht, also ich hab immer ATMEGAs 8 verwendet). Für solche allgemeine Sachen bringts mir überhaupt nix wenn ich 16bit Anstelle von 8 habe usw. Die anzahl mips ist jedoch entscheidend. Desshalb versteh ich auch nicht wieso die uC hersteller nicht zumindest 1 "tiny" typ rausbringen mit 150 MIPS oder so. PS: Natürlich verwende ich uC auch für sachen wofür sie vorgesehen sind ich möchte einfach einen mögliochst einfachen flexibel einsetzbaren typ.
2.0 Sound schrieb: > Desshalb versteh ich auch nicht wieso die uC hersteller nicht zumindest > 1 "tiny" typ rausbringen mit 150 MIPS oder so. Weil du den nicht bezahlen willst.
Jörg Wunsch schrieb: > Das Problem ist in aller Regel nicht der CPU-Kern, sondern der Flash. > Der ist von Natur aus eher langsam. Bei 32-bit-Controllern schachtelt > man dann oft zwei Flash-Bänke, die jeweils 33 MHz oder so schaffen, > um auf 66 MHz für den ganzen Controller zu kommen. im DB von atmel hab ich vorhin gelesen, dass der PLL nicht mehr lockt wenn man mit OCCAL übertacktet. FLASH und EEPROM failen dann sowiso. Was für ne Flash technologie ist da eigentlich verbaut? Std NOR Flash oder haben die da noch was getrickst wegen bitaddressierbarkeit? Oder ist die Bitaddressierbarkeit nur vorgespielt und der Flash controller liest-modifiziert-schreibt Byte?
2.0 Sound schrieb: > Was für ne Flash technologie ist da eigentlich verbaut? Std NOR Flash Ja. > oder haben die da noch was getrickst wegen bitaddressierbarkeit? Da ist doch nichts bitadressierbar. > Oder > ist die Bitaddressierbarkeit nur vorgespielt und der Flash controller > liest-modifiziert-schreibt Byte? Beim EEPROM ist das so, der Flash wird nur seitenweise gelöscht und beschrieben.
2.0 Sound schrieb: > Ich verstehe sowiso nicht, wesshalb viele kleine uC 16bit haben. Umgang mit berechneten Adressen und Pointern. Es ist klar von Vorteil, wenn man die am Stück verarbeiten kann, nicht nur häppchenweise. > Zumal 99% der variablen char sind Zeichen sind zwingend 8 Bits breit? Auch im CJK Raum? Ausserdem sind 99% m.E. schwer übertrieben.
> dsPIC33 und PIC24 schaffen bis zu 60 MIPS, es gibt auch welche im > DIL-Gehäuse (bis zu 14 Pins herunter). > Welcher typ hat 14 Pins mit 60Mips DIL?? Es gibt den PIC24HJ12GP201 im DIL18 mit 40 MIPS und einige dsPIC33 mit 60 MIPS (aber nicht im DIL), z.B. den dsPIC33EP512MU810 u.a., der PIC24F04KA200 im DIL14 hat nur 16 MIPS. Es gibt so viele verschiedene PICs, die musst Du Dir für Deine spezielle Anwendung individuell suchen. DEN Universal-µC für alles gibt es nicht. Weder bei AVR noch bei PIC.
Jörg Wunsch schrieb: > Beim EEPROM ist das so, der Flash wird nur seitenweise gelöscht und > beschrieben. Also nor doch Zeilenweise. Nand sind doch Blockweise. Ich denke mal Zeile wird so 32-128bit sein bei den 8kB Flash uC
Hi >(Tiny kannte ich bis vor kurzem noch nicht, also ich >hab immer ATMEGAs 8 verwendet). Für solche allgemeine Sachen bringts mir ><überhaupt nix wenn ich 16bit Anstelle von 8 habe usw. Die anzahl mipsist >jedoch entscheidend Dann hast du also von AVRs eigentlich Null Ahnung. MfG Spess
A. K. schrieb: > Umgang mit berechneten Adressen und Pointern. Es ist klar von Vorteil, > wenn man die am Stück verarbeiten kann, nicht nur häppchenweise. Ok Pointer hab ich vergessen. Generell so datenumherschiebensachen sind mit grösserer Datbus breite besser. Jedoch wärs mir lieber nen 250MIPS 8-bit uC zu haben als irgend nen 150MIPS 16, 32 oder 64 biter. Vorteil alle SW bleibt kompatibel usw. Zumal es mit heutiger technologie sicherlich keine so grosse herausforderung ist nen 8biter auf 250MIPS zu bringen. Stütz C hat ja im SO... oder DIL auch noch Platz.
spess53 schrieb: > Dann hast du also von AVRs eigentlich Null Ahnung. Stimmt nicht ganz ich weiss, dass das AVRStudio 4 recht bescheuert ist :P 5 kenn ich noch nicht. von PICs weis ich noch weniger. @Admins, modz usw. bitte löscht diesen Post, da er nur Spam ist und nix zur Diskussion beiträgt
2.0 Sound schrieb: > Also nor doch Zeilenweise. Nand sind doch Blockweise. Ich denke mal > Zeile wird so 32-128bit sein bei den 8kB Flash uC AVRs haben eine Seitengröße von maximal 256 Byte. Ich denke schon, dass das blockweise ist und nicht zeilenweise, aber was für eine Rolle spielt das denn?
2.0 Sound schrieb: > Zumal es mit heutiger technologie sicherlich keine so grosse > herausforderung ist nen 8biter auf 250MIPS zu bringen. Stütz C hat ja im > SO... oder DIL auch noch Platz. Eine Herausforderung in sachen "Design" ist es grundsätzlich gesehen nicht mehr. Aber die technische Umsetzung ist etwas anderes, hohe Taktfrequenzen bedeuten dann schnell eine notwendige Umstellung der Poduktionsprozesse, ja - de rganzen TEchnologie. Als nebeneffekt kommen dann noch so dinge wie drastisch kleinere "Spannungsfenster" für mögliche Betriebsspannungen usw. Im Ergebniss hast du dann einen 20 Euro teuren 8Bitter der nur noch mit Spannungen zwischen 1,5V bis 1,9V läuft und deren Ports nicht mal mehr normale Logikbausteine treiben können. Und das ganze um eine Anwendungsgruppe zu erreichen wo nur Bastler den µC dafür einsetzen und für die es längst viel bessere andere Lösungsansätze gibt. Für die allermeisten µC Anwendungen wo man "REchenpower" braucht ist man mit höheren Busbreiten viel besser (und unkomplizierter/Günstiger) bedient. Wenn im komerziellen Bereich mal ein kleiner Teil des Ablaufs mit der Latenz des µC nicht hinkommt greift man halt auf einen externen zusätzlichen Logikbaustein zurück, z.B. der 4000er Serie. Wird es umfangreicher wird nimmt man dann PLDs wie GALs oder wenn es Complex wird auch CPLDs. ODer selbst wenn das nicht reicht dann greift man zum FPGA... Aber der REgelfall ist immer noch der µC ergänzt um etwas externe Logik. 2.0 Sound schrieb: > Ok Pointer hab ich vergessen. Generell so datenumherschiebensachen sind > mit grösserer Datbus breite besser. Jedoch wärs mir lieber nen 250MIPS > 8-bit uC zu haben als irgend nen 150MIPS 16, 32 oder 64 biter. Vorteil > alle SW bleibt kompatibel usw. Wenn du die SW in C schreibst musst du beim wechsel von 8 auf 32Bit auch nur den Compiler wechseln. Im Idealfall ist dann abgesehen von ein paar Konfigurationsbits keinerlei weitere Änderung notwendig. Ausserdem würden selbst bei reiner Assemblerprogrammierung die massiven nachteile der anderen Produktionstechnologie niemals die Vorteile der nicht notwendigen SW Änderung aufheben. Davon abgesehen das es ja sowieso eine völlig unpraktische Anwendung für µC ist. 2.0 Sound schrieb: > spess53 schrieb: >> Dann hast du also von AVRs eigentlich Null Ahnung. > > @Admins, modz usw. bitte löscht diesen Post, da er nur Spam ist und nix > zur Diskussion beiträgt NAja - ist zwar sicher nicht nett. Aber wenn man es etwas überspitzt ausdrückt trifft es den Kern schon recht genau. Du willst etwas was diejenigen die sich da schon etwas länger mit befassen, ja - sogar ihren Lebensunterhalt bestreiten, als völlig unsinnig erkennen. Wenn es dir darum geht auch die notwendige Lagerhaltung bei Logikbausteinen zu verringern, dann lege dir auch ein paar PAL/GAL zur seite. Ganz einfache Dinge kannst du ja gerne per µC machen, wenn dann aber die Anforderungen das als Unmöglich einstufen lassen nimm einen GAL. Im Übrigen würde ich es keinesfalls so sehen das die beste Wahl ist einfach irgendeinen möglichst schnellen µC zu wählen! Denn sobald irgendetwas mit diesem µC nicht mehr geht hast du dann ein RIESENProblem. Zudem zahlst in vielen Fällen evtl. für Leistung die du gar nicht brauchst. ICh würde stattdessen einen "günstigen Durchschnitts-µC" auswählen, der aus einer Familie stammt die mit dem selben Kern eine möglichst umfangreiche Peripheriepalette bietet und vor allem dessen Entwicklungstools so universell wie möglich sind. Und gerade als Hobbybastler der offensichtlich Probleme mit SMD-Bauformen bei µC hat würde ich noch zusehen das möglichst viele Vertreter auch in DIP zu bekommen sind. HAst du z.B. dann eine Anwendung wo echtes Hardware_USB notwendig ist, dein Ausgesuchter universal_µC das aber nicht bietet, dann nimmst du einfach den µC der mit demselben Kern -aber USB Modul- ausgestattet ist. Am Quellcode müssen manchmal nur wenige Änderungen gemacht sein. (Mein Minimalrekord liegt bei 5Minuten incl. Funktionstest für den Umstieg von einem Programm auf Standart-µC das über RS232 mit dem REchner Kommuniziert auf einen USB µC mit USB Kommunikation) Dasselbe gilt für CAN/Ethernet/ oder zusätzliche PWMs/TIMER usw. Aus meiner Sicht haben da die PICs etwas die NAse vorn, da es dort die Auswahl gibt, wesentlich mehr Typen in DIP zu bekommen sind. Auch solche mit SPezialfunktionen wie HW-USB oder CAN. Ausserdem kann man mit derselben Programmierhardware und in derselben IDE 8Bitter, 16Bitter und auch 32Bitter Programmieren und Debuggen. Die IDE gibt es für Windows UND für Linux. Aber das muss jeder für sich selbst entscheiden. In der 8Bit Welt setzte ich für neue Designs fast nur noch PICs ein, 16Bit habe ich nur selten und dann nur DSPics. Bei 32Bit überwiegen bei mir die diversen ARM knapp vor den PIC32. Gruß Carsten
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.