Hallo zusammen!
Ich bins mal wieder...
Ich würde gerne etwas über die UART schicken. Diesmal verwende ich den
168er, einen externen Quarz (4MHz). Das komische daran (ich arbeite mit
Docklight): das Terminalprogramm empfängt etwas... aber immer nur 3F 00
00. Immer das gleiche (hin und wieder schleicht sich ein C0 rein, wenn
ich aber UDR0 = 'x' "sende" bekomme ich ich immer 3F 00 00). An was kann
es liegen???? Muss ich noch eine Frequenz umstellen????
Danke!!!
Gruß Christian
Folgenden Code habe ich verwendet (ist nicht von mir):
#define F_CPU 4000000
#define USART_BAUD_RATE 9600
#define USART_BAUD_SELECT (F_CPU/(USART_BAUD_RATE*16L)-1)
#include <avr/io.h>
#include <avr/interrupt.h>
void sendUart(char* cmd)
{
do
{
while (!(UCSR0A & (1<<UDRE0))) {} // Warten bis
mansenden kann
UDR0 = *cmd++; // senden und
zumnächsten zeichen wechseln
}
while(*cmd); // so lange bis
dasende erreicht ist
}
unsigned char USART_Receive( void )
{
/* Wait for data to be received */
while ( !(UCSR0A & (1<<RXC0)) )
;
/* Get and return received data from buffer */
return UDR0;
}
void USART_Init( unsigned int baud )
{
/* Set baud rate */
UBRR0H = (unsigned char)(baud>>8);
UBRR0L = (unsigned char)baud;
/* Enable receiver and transmitter */
UCSR0B = (1<<RXEN0)|(1<<TXEN0) | (1<<RXCIE0);
/* Set frame format: 8data, 2stop bit */
UCSR0C = (1<<USBS0)|(3<<UCSZ00);
}
ISR(USART_RX_vect)
{
PORTC = 0xFF;
}
int main(void)
{
USART_Init(USART_BAUD_SELECT);
sei();
DDRC = 0xFF;
sendUart("Programm gestartet\n");
PORTC = 0x00;
//USART_Receive();
//PORTC = 0xFF;
for(;;){}
}
Christian Beuge wrote: > Ich würde gerne etwas über die UART schicken. Diesmal verwende ich den > 168er, einen externen Quarz (4MHz). ... Ja, hast du den auch wirklich in Betrieb genommen (per fuse bit)?
Hallo Jörg! Ich hoffe doch. Eingestellt ist der ATMega 8, da der 168 der Nachfolger sein soll. Den 168 direkt angeben konnte ich nicht (ich hoffe nicht, das dies der Hacken ist!). Bei den Fuse Bits ist der Hacken bei SPI Enable gesetzt, sonst bei keinem weiteren Punkt. Als Oszilator ist "Ext STAL, Medium frequency" angegeben (Was ist der Unterschied zwischen: High - Medium - Low - es geht bei keinem...). Startup: 1K CK; No BOD function (was ist das??) und Boot block ist 128 Words angegeben. Ich hoffe das stimmt alles. Gruß Christian
Uff, was hast du denn fürn altmodischen Programmer? Nein, die ATmegax8 sind zwar aufwärtskompatibel zum ATmega8, aber alles andere als fusebit-kompatibel. Das fängt schon damit an, dass die neue Serie debugWire kann (und damit eine DWEN-Fuse braucht). Außerdem besitzt sie nur noch einen einzigen (mit 8 MHz laufenden) RC-Oszillator statt 4 davon sowie eine CKDIV8-Fuse, die den clock prescaler auf 1:8 voreinstellt, sodass die CPU wieder im Auslieferungszustand mit 1 MHz getaktet wird und damit im gesamten Betriebsspannungsbereich nutzbar ist. Nein, ohne einen Programmer, der deinen ATmega168 unterstützt, wirst du da nicht weit kommen. Übrigens, Haken und Hacken sind im Deutschen zwei sehr verschiedene Dinge. Ich nörgele ungern an der Rechtschreibung, aber hier haben einfach beide Worte eine Bedeutung.
Hallo! Kommen immer nur diese 3 Bytes (auch wenn du einen ganzen String senden willst??) Ansonsten: hast du bei deinem Terminalprogramm auch 2 Stoppbits eingestellt (vl liegts ja daran) wie sieht der Hardwareaufbau aus (Störeinflüsse => dieses Problem hatte ich letztens mit dem RS485 Bus... ) vl. kannst du dir das ganze mal mit nem Oszi anschauen mfg Markus
Mein "Hardwareprogrammer" ist der mysmartUSB (http://www.myavr.de/shop/artikel.php?artID=42) von www.myavr.de . In der Beschreibung steht, das man einen 168er damit programmieren kann. Als Software verwende ich AVR-Studio. Und laut AVR habe ich auch die aktuellste Version. Hm.... ist schon etwas komisch. Soll ich mir dann (extra...) einen neuen kaufen? Welchen empfiehlst Du mir? Ich hätte zwar gerne einen mit JTAG, aber die sind sehr teuer und leider sind meine (studentischen) Mittel begrenzt. Gruß Christian
@markus: ich habe gerade mit den stopbits "gespielt". Außerdem habe ich ein programm geflasht, das nur ein 'x' schreibt (siehe Tutorial / Forum). Leider schreibt er bei mir nur 0xE8. Das komische daran ist, egal wie viele Stopbits ich beim Terminalprogramm einstelle. Das kommt mir auch etwas komisch vor. Kann es wirklich am Programmer liegen, wie Jörg meinte? Wäre sehr schade (und kostenaufwendig). Gruß Christian P.S.: Welchen µC verwendest Du? Und welchen Programmer?
Christian Beuge wrote: > Mein "Hardwareprogrammer" ist der mysmartUSB > (http://www.myavr.de/shop/artikel.php?artID=42) von www.myavr.de . Hmm, AVR910-Style. AVR910 ist ein uraltes und ziemlich dummes Protokoll, und die entsprechenden device IDs sind einfach mal nicht mehr gepflegt worden. Ggf. liefert der Hersteller ja auch Firmware-Upgrades. > Als Software verwende ich AVR-Studio. Hmm, AVR Studio kann mit AVR910 aber nicht selbst umgehen. Was wählst du denn dort genau aus? > Welchen empfiehlst Du mir? Ich hätte zwar gerne einen mit JTAG, aber > die sind sehr teuer und leider sind meine (studentischen) Mittel > begrenzt. AVR Dragon. Kostet bei Sander Electronic in Berlin EUR 68. Weiß nicht, wer ihn sonst noch hat, bei dem man auch privat und mit mäßigen Versandkosten bestellen kann. Der kann ISP, JTAG, debugWire, und high-voltage programming. Die JTAG-Emulation ist dabei limitiert auf AVRs mit <= 32 KiB ROM. > Das komische daran ist, egal wie viele Stopbits ich beim > Terminalprogramm einstelle. Das kommt mir auch etwas komisch vor. Dann hast du die Asynchronübertragung einfach nicht verstanden. Das ist alles andere als komisch: der Empfänger hört sowieso beim ersten Stopbit auf zu empfangen. Die folgenden Stopbits ignoriert er dann einfach, da sie ja keine Startbits sein können. 1,5 oder 2 Stopbits mag in Zeit klappriger mechanisch abtastender Fernschreiber einen Zweck gehabt haben (Zwangssynchronisation des Empfängers auch bei geringfügig abweichender Empfängerdrehzahl), heutzutage ist es eigentlich nur noch Verschwendung einer Bitzeit pro Symbol. Der einfachste Weg herauszufinden, ob deine Oszillatorfrequenz stimmt ist, dass du damit erstmal einen Timer programmierst. Entweder mit Oszillograph oder Zählfrequenzmesser messen, oder halt so weit runterteilen, dass du im 1-s-Takt eine LED blinken lässt und dann mit der Uhr nachmessen kannst. Ach, noch einfacher wäre es natürlich, die CKOUT-Fuse zu programmieren und die Oszillatorfrequenz an port B0 nachzumessen...
Hi Jörg (und auch Hi Rest!!) Also... ich stelle bei AVR-Studio nichts besonderes ein. Jedoch sind Deine Einwände, bezüglich der Einstellung des Prozessors (8er / 168er) durch aus nachvollziehbar. Daher habe ich jetzt das Programm Burn-o-mat (siehe Forum) sowie myAVR workpad installiert. Damit kann ich (lt. Anleitung) direkt auf die FUSE Bits des 168er zugreifen. Der Prozessor wird sogar automatisch erkannt. Folgedes habe ich eingestellt: Ext. Crystal Osc.; Frequency 3.0-8.0 MHz; Start-up time PWRDWN/RESET: 16K CK/14 CK + 65 ms; [CKSEL=1101 SUT=11] Also, ich hoffe, das passt für einen 4 MHz Quarz Leider weiß ich nicht ob ich das richtige eingestellt habe. Besonders mit den" Start-up und 16k CK/14...." ... ich weiß nicht was das heißt. Wäre super, wenn mir das jemand erklären könnte. Ich werde auch gleich noch mal im tutorial nachsehen. Außerdem habe ich jetzt folgendes Programm "draufgebrannt": #include <avr/interrupt.h> #include <avr/io.h> #include <avr/iom168.h> #include <avr/portpins.h> #include <avr/sfr_defs.h> #include <stdint.h> #define BAUD 9600 #define FOSC 4000000 //Taktgeschwindigkeit 4 Mhz #define MYUBRR FOSC/16L/BAUD-1 //Formel.... // Receive Interrupt ISR(USART_RX_vect ) // veraltet: SIGNAL(SIG_OVERFLOW0) { // ISR: Zeichen wurde empfangen while ( !( UCSR0A & (0x20)) ); //Warten bis UART Data empty UDR0 = UDR0 + 1; // Gesendet: 0xFF Antwort: 3F 7F 00 // UDR0 = 0xe8; // Antwort: Endlosschleife E1 warum??? } //Zeichen wurde komplett gesendet ISR(USART_TX_vect ) // veraltet: SIGNAL(SIG_OVERFLOW0) { } void USART_Init (unsigned int ubrr) { // zuerst Baudrate setzen UBRR0H = (unsigned char) (ubrr>>8); UBRR0L = (unsigned char) (ubrr); //nun Sender und Empfänger initialisieren UCSR0A = 0x00; UCSR0B = 0xF8; //Frameformat setzen: 8 Datenbits, 1 Stopbits UCSR0C = 0x86; } int main(void) { DDRD = 0xff; //enable PortD as output sei(); //enable Interrupt USART_Init (MYUBRR); while (1) { }; } Mein Hardwareaufbau ist folgender: Verwende XP-Laptop (DELL) der keinen Seriellen Port hat. Dafür habe ich einen USB Adapter. Wenn ich RX und TX am Adapter "kurzschließe" kommt das Gesendete auch an (erste Fehlerquelle beseitigt?). Den Adapter habe ich mit einer RS232 Buchse und 3 "freirumliegenden", ca. 22 cm langen Drähten (0,2mm²?) verbunden (TX,RX,GND). Das Störungen auftreten können, ist mir klar, aber ich habe mein Handy draufgelegt und es angerufen... dabei änderte sich bei der Übertragung nichts. Die Spannungsversorgung übernimmt mein "Programmmierboard". Was evtl. noch wichtig wäre: Mir ist absolut klar, das ich meinen Hardwareaufbau nicht sehr Störungsfrei gestaltet habe. Auch möchte ich kein Bild von dem "Board" ins Netz stellen... das sieht beschämend aus. Aber: Ich habe (in der Arbeit: Praxissemester) einen Aufbau mit einem Xc164 Evaluation Board (CM?). Eingestellt habe ich das mit DAVE. Das funktioniert einwandfrei! Daher denke ich, es kann doch nicht so schwer sein, einem Atmel Prozessor beizubringen anständige Info's via UART zu senden (ok, kann auch sein, das ich es nicht verstehe....). Ich werde morgen mal das "Board" mit in die Arbeit nehmen und am Oszi ansehen, was genau ausgegeben wird. Vielleicht ändere ich das Programm noch ein wenig ab, so das er "automatisch" alle x-sec einen Wert sendet. Was mir jedoch nicht ganz klar ist, warum ich bei 0x08 (nach dem senden eines beliebigen Wertes) eine Endlosschleife bekomme.... schließlich sende ich ja nur was im "Receive-Interrupt..." ?! So, mehr fällt mir leider nicht dazu ein... Aber wie gesagt... ich bin dankbar für jeden TIP!!!! Gruß Christian
Christian Beuge wrote: > Also... ich stelle bei AVR-Studio nichts besonderes ein. Naja, irgendwas musst du doch als Plattform auswählen, mit der du arbeiten willst. Ist das ein STK500? > Folgedes habe ich eingestellt: > Ext. Crystal Osc.; Frequency 3.0-8.0 MHz; Start-up time > PWRDWN/RESET: 16K CK/14 CK + 65 ms; [CKSEL=1101 SUT=11] Klingt erstmal OK. > Also, ich hoffe, das passt für einen 4 MHz Quarz Ja. > Leider weiß ich nicht ob ich das richtige eingestellt > habe. Besonders mit den" Start-up und 16k CK/14...." ... ich weiß > nicht was das heißt. Der Prozessor wartet nach einem Power-down sleep 16K (= 16384) Zyklen, damit sich der Oszillator stabilisieren kann, nach einem Reset noch zusätzlich weitere 14 Zyklen plus 65 ms. Das ist die konservativste Variante, in der auch der gemütlichste Quarz auf Touren gekommen sein sollte. Diese Werte möchte man vor allem dann optimieren (d. h. auf den wirklichen Quarz anpassen), wenn man mit Power-down oder Power-save sleep arbeitet, da der Controller während der Anlaufphase halt schon Strom zieht, ohne was machen zu können. > #include <avr/iom168.h> > #include <avr/portpins.h> > #include <avr/sfr_defs.h> Die drei sind überflüssig. > #define FOSC 4000000 //Taktgeschwindigkeit 4 Mhz Ist nicht falsch, aber mittlerweile hat sich als Konvention hier der Name F_CPU durchgesetzt. Solltest dich vielleicht einfach dran gewöhnen. > // Receive Interrupt > ISR(USART_RX_vect ) // veraltet: SIGNAL(SIG_OVERFLOW0) Der Kommentar passt nicht zum Vektornamen... > { > // ISR: Zeichen wurde empfangen > while ( !( UCSR0A & (0x20)) ); //Warten bis UART Data empty Im Prinzip musst du das nicht tun: du kannst ja sowieso maximal so schnell empfangen, wie du auch senden kannst. > //Zeichen wurde komplett gesendet > ISR(USART_TX_vect ) // veraltet: SIGNAL(SIG_OVERFLOW0) > { > > } Wofür hast du diesen IRQ überhaupt aktiviert? Wenn man schon interruptgesteuert senden will, ist übrigens der UDRE-Interrupt sinnvoller: damit kann man das nächste Zeichen bereits vorbereiten, während das aktuelle Zeichen gerade rausgeschoben wird. Wenn keine Zeichen mehr zu senden sind, muss man diesen Interrupt allerdings abschalten. > UCSR0A = 0x00; Das ist ein NOP. Die Interruptflags werden dadurch nicht angefasst, und der Rest des Registers bleibt auch auf Voreinstellung. > UCSR0B = 0xF8; Das ist tödlich und ist möglicherweise dein tatsächlicher Fehler. Gewöhn dich lieber an die symbolische Schreibweise, dann steht da:
1 | UCSR0B = _BV(RXCIE0) | _BV(TXCIE0) | _BV(UDRIE0) | _BV(RXEN0) | _BV(TXEN0); |
Du aktivierst den UDRE-Interrupt, für den du aber keinen Handler definiert hast! Dieser Interrupt triggert in diesem Moment dann sofort (da das TX-Datenregister natürlich leer ist), und springt in den __vector_default, der auf Adresse 0 springt. > //Frameformat setzen: 8 Datenbits, 1 Stopbits > UCSR0C = 0x86; 0x06 übrigens die Voreinstellung. Bit 7/6 = 0x80 wählen als Betriebsmodus einen aus, der ausdrücklich als reserviert markiert ist. Ich denke, hier hast du etwas gedankenlos das 0x80-Bit von einem AVR übernommen, bei dem UBRRHn mit UCSRnC zusammenfällt und dann das Bit 7 zur Unterscheidung beider Register benutzt wird. Nach meiner Erfahrung fasst man das Steuerregister C der USART am Besten einfach gar nicht an, wenn man sowieso nur das Standardframing 8N1 haben will, da dieses bei AVR immer voreingestellt ist. Einen ATmega168 habe ich nicht, aber ich hab' das Ganze mal mit einem ATmega48 auf einem STK500 nachgestellt. Dort muss man zwar statt des externen Quarzes in den Fuses einen Externoszillator einstellen (low fuse also 0xe0), aber danach konnte ich das mit 4 MHz einwandfrei so benutzen, nachdem ich das UDRIE0 rausgeschmissen hatte.
Hey Jörg!
vielen Dank, für Deinen Einsatz. Könntest Du bitte Dein Programm posten,
oder mir per E-Mail schicken (ChristianBeuge@gmx.de) ? Ich bekomme es
einfach nicht hin. Ich habe das Programm nun folgendermaßen geändert:
#include <avr/interrupt.h>
#include <avr/io.h>
#include <stdint.h>
#define BAUD 9600
#define F_CPU 8000000 //Taktgeschwindigkeit 4 Mhz
#define MYUBRR F_CPU/16L/BAUD-1 //Formel....
// Receive Interrupt
ISR(USART_RX_vect ) // veraltet: SIGNAL(SIG_OVERFLOW0)
{
// ISR: Zeichen wurde empfangen
while ( !( UCSR0A & (0x20)) ); //Warten bis UART Data empty
UDR0 = 0xFF; // Immer noch Endlosschleife
}
void USART_Init (unsigned int ubrr)
{
// zuerst Baudrate setzen
UBRR0H = (unsigned char) (ubrr>>8);
UBRR0L = (unsigned char) (ubrr);
UCSR0B = _BV(RXCIE0) | _BV(TXCIE0) | _BV(RXEN0) | _BV(TXEN0);
}
int main(void)
{
DDRD = 0xff; //enable PortD as output
sei(); //enable Interrupt
USART_Init (MYUBRR);
while (1)
{
};
}
Ich hoffe, ich habe nichts übersehen. Ich werde auf jedenfall morgen das
Ding in die Arbeit mitnehmen und mir mal ansehen, was es sendet....
vielleicht werde ich ja schlauer...
Gruß Christian
Christian Beuge wrote: > vielen Dank, für Deinen Einsatz. Könntest Du bitte Dein Programm > posten, oder mir per E-Mail schicken Sorry, dürfte schon dem Schredder anheim gefallen sein. > UCSR0B = _BV(RXCIE0) | _BV(TXCIE0) | _BV(RXEN0) | _BV(TXEN0); Du hast zwar den USART_TX_vect entsorgt aber das TXCIE0-Bit trotzdem noch gesetzt. Damit knallt's dann genauso wie vorher mit dem UDRIE0. > UDR0 = 0xFF; // Immer noch Endlosschleife Bist du dir sicher, dass dein Terminalprogramm dieses Zeichen überhaupt anzeigen kann? Ich hatte deine Version
1 | UDR0 = UDR0 + 1 |
übernommen. Sinnvoller wäre jedoch:
1 | uint8_t c = UDR0; |
2 | if (c >= 'A' && c <= 'z') |
3 | c = c + 1; |
4 | UDR0 = c; |
Damit würden wenigstens Steuerzeichen wie CR und LF einfach nur als Echo ausgegeben und lediglich bei den Buchstaben die +1-Magie vorgenommen.
Guten Morgen Jörg! So, in der Arbeit angekommen habe ich mich sofort daran gemacht, zu messen was da raus kommt, aus meiner UART. Dummerweise sendet die wirklich 00. Ich werde Deine Änderungen auf jedenfall berücksichtigen und heute abend das Ding neu flashen. Melde mich spätestens heute abend wieder!!! Gruß Christian
Christian Beuge wrote: > So, in der Arbeit angekommen habe ich mich sofort daran gemacht, zu > messen was da raus kommt, aus meiner UART. Dummerweise sendet die > wirklich 00. "Gemessen" klingt ja nicht nach Terminalprogramm. Womit misst du denn? Dein 0xFF müsste so aussehen: ----+ +--------------------------- | | +--+ . . . . . . . . . Bit: S 0 1 2 3 4 5 6 7 T S - Startbit, T - Stopbit Das zeigt den TTL-Pegel am AVR. Der V.28-Pegel am Stecker ist dazu negiert.
Hallo Jörg.... Also, ich möchte mal ganz schwer behaupten: Shame on me!!!!! Aber der Reihe nach: Ich bin in der Arbeit und messe mit einem Tektronix DPo 4034 Speicheroszi. Außerdem bekomme ich genau das Bild, welches Du oben "gezeichnet" hast. Dabei dauert das "Startbit" 208µsec (müssten das nicht 104µsec sein - bei 9600 Baud). Also genau das, was es soll. Was ich an der ganzen Sache natürlich nicht bedacht habe ist, das der AVR "nur" einen TTL Pegel verwendet und RS232 +/- 12 V. Das es hier zu "komplikationen" kommen kann... ich denke, das wäre vorprogammiert. Kann es sein, wenn ich einen UART Treiber "zwischenschalte" das ich die richtigen Daten an meinem Rechner bekomme? Leider kann ich meinen Atmel hier nicht programmieren, da wir hier Infineon µCs verwenden. Aber ich werde versuchen, von meinem Kollegen einen Treiberbaustein (evtl. heute noch) zu bekommen und dann das ganze zu testen. Deshalb: Shame on me... habe zwar was gelernt, brauchte dazu aber knapp 2Wochen und habe dabei einige µCs verfused.... (und viele Leute wahrscheinlich in den Wahnsinn getrieben...) Gruß Christian
> Kann es sein, wenn ich einen UART Treiber "zwischenschalte" das > ich die richtigen Daten an meinem Rechner bekomme? Wenn mit "UART Treiber" so etwas wie ein MAX232 oder ein SN75188/SN75189-Pärchen gemeint ist, dann besteht eine realistische Chance.
Christian Beuge wrote: > Außerdem bekomme ich genau das Bild, welches Du oben "gezeichnet" > hast. Dabei dauert das "Startbit" 208µsec (müssten das nicht 104µsec > sein - bei 9600 Baud). Ja, das klingt noch nach falschem Takt irgendwie. Warum, das musst du selbst analysieren. Denk an die CKOUT-Fuse, zusammen mit einem Oszi kann die Dir gut helfen. Kann ja auch sein, dass du den Quarz zu sehr (kapazitiv) belastet hast und er dann ,,irgendwie'' wild schwingt. > Was ich an der ganzen Sache natürlich nicht bedacht habe ist, das > der AVR "nur" einen TTL Pegel verwendet und RS232 +/- 12 V. Das es > hier zu "komplikationen" kommen kann... ich denke, das wäre > vorprogammiert. Nu ja, wenn's denn nur die Pegelunterschiede wären... Insbesondere sind die Signale aber negiert, d. h. logisch 1 (das auch TTL high entspricht) ist auf der V.28-Seite die negative Spannung, während logisch 0 die positive Spannung ist. Die meisten PC-Schnittstellen kommen heutzutage sogar mit TTL-Pegel zurecht, aber du musst das Signal eben noch negieren. > Leider kann ich meinen Atmel hier nicht programmieren, da wir hier > Infineon µCs verwenden. Naja, wenn du noch irgendwo eine stinknormale Parallelschnittstelle hast und 'nen DB25-Stecker dafür, kannst du dem abhelfen. ;-)
Hallo Jörg! Ok... shame on me, Teil 2.... Gerade eben habe ich den Unterschied zwischen 4MHz und 8 MHz entdeckt... Ähm... bis jetzt funzt es, also, mit MAXIM 232 Baustein... an dem UART Ausgang liefert er weiterhin Mist.... also, zumindest zeigt das das Terminalprogramm an. So, jetzt bin ich gespannt, wie lange das so weiter geht und wie das nächste Problem sich darstellt. Ich danke Euch, besonders Dir Jörg, für Deine Hilfe und hoffe, das ich Euch auch mal mir Rat und Tat zur Seite stehen kann. Wie gesagt, ich hoffe, es klappt jetzt.... wenn nicht, würde ich mich nochmal per Mail melden... wenn ich darf.... Gruß Christian
> Gerade eben habe ich den Unterschied zwischen 4MHz und 8 MHz entdeckt... :-) Ja, den MAX232 o. ä. brauchst du natürlich wirklich, oder wie geschrieben, zumindest einen simplen Inverter. Naja, hast ja auch einiges gelernt dabei (z. B. hilft eben ein Oszi doch manchmal ein gutes Stück weiter). Na dann mal noch beste Erfolge!
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.