LED auf Tastendruck

[mr.twister]

Hey Leute,

da ich laut dem DHL-Tracking morgen mein Nano-Board bekomme, habe ich angefangen, ein kleines Programm zu schreiben, mit dem ich auf Tastendruck 4 LEDs auf dem Board zum Leuchten bringen kann.
Doch beim Debuggen passiert folgendes:



Und einen Schritt weiter:



Warum komme ich immer nur in die if-Schleife? PINB5 ist doch eigentlich 0 bzw. LOW oder irre ich mich da?

Grüße mr.twister

 

[Dirk]

Guten Abend,

die Routine board_init() solltest du nicht ausführen. Ich weiß nun auch nicht, was in der Routine gemacht wird.
Du hast eigentlich auch erst einmal nichts zu initialisieren außer PB0..3 als Ausgang zu setzen und das machst du ja explizit in main().

Du möchtest PB5 als Input schalten (nach Reset sind alle IO-Pins Input), also das DataDirectionRegister DDRn = 0x00. Wenn ein Taster ohne externen Pullup-Widerstand angeschlossen ist (int bei dir der Fall), musst du den internen Pullup-Widerstand aktivieren. Das funktioniert so:

DDRB &= ~(1<<PB5); // input, nicht notwendig nach Reset
PORTB |= 1<<PB5;

Den logischen Zustand von dem Pin erhältst du, wenn du das Bit PINB5 in Register PINB untersuchst. PINB5 hat hier den Wert 5, deine Bedingung in der i-Abfrage ist also immer wahr!
Die Abgrage machst du so:

if (!(PINB & (1<<PINB5)))
{
//... low, Taste gedrückt
} else {
//... high, Taste nicht gedrückt
}

Schau dir auch vielleicht einmal das Thema GPIOs mit C an (leider funktioniert das Code-Highlighting wegen einem Update der Forensoftware nicht mehr).

Dirk


EDIT:
Die for-Schleife ist so schnell abgearbeitet, so schnell kannst du die Taste nach Reset gar nicht drücken. Dies solltest du anders lösen.

 

[mr.twister]

Hey Dirk, danke für die schnelle Antwort und den Link, habe die Abfrage verstanden, damit wird im Register überprüft ob die jeweilige Stelle 1 ist. Aber warum verneinst du das? Ist das einfach nur der Programmierstil oder liegt das an dem (low-aktiv?) Taster?

 

[Dirk]

Guten Morgen

... Aber warum verneinst du das? Ist das einfach nur der Programmierstil oder liegt das an dem (low-aktiv?) Taster?

Ja genau. Es ist eigentlich "Geschmacksache". Die Taster-Signale sind low aktiv. Wenn ich eine if-Abfrage mache, dann frage ich eher nach "Ist der Taster gedrückt?" als nach "Ist der Taster nicht gedrückt?".

Mit PINB & (1<<PINB5) maskierst du das einzelne Bit PINB5 (alle anderen Bits sind 0).

Ist der Taster gedrückt, der logische Zustand an PB5 low, also 0, dann ist der Ausdruck PINB & (1<<PINB5) unwahr. Ich möchte hier nun aber ein "wahr" haben, wenn der Taster gedrückt ist, das erreiche ich dann mit "!" vor dem Ausdruck.

Man könnte es auch so schreiben:

if ((PINB & (1<<PINB5)) != (1<<PINB5))

Du kannst dir auch ein Macro schreiben, um eine einfachere Schreibweise zu erhalten, aber das ist Geschmacksache und auch Gewohnheitssache

Dirk

 

[mr.twister]

Board ist jetzt angekommen und ich möchte diesen Code zum Laufen bekommen:

#include <asf.h>
#include <avr/io.h>


/* ---------------------------------------------------------------------------- */


int main (void)
{
	
	DDRB = 0xff;
        PORTB = 0x00;					

	
	while(1)		
	{								
		PORTB = 0xff;
	};
	 
	
	return 0;
}

Aber bereits der Debugger gibt ein Fehler aus... Also irgendwie peile ich gerade gar nichts mehr... Die Falschen Includes?

Muss ich auf dem Nano GND und UTG von PORTB auch mit LED verbinden? Eigentlich reicht doch der Strom der aus den Pins kommt, um die zum Leuchten zu bringen oder?
Startet der Taster START jedes mal das Programm?

 

[Dirk]

Hallo,

vergess einfach mal den Debugger, denk dir einfach den gibts nicht.

Welche Meldungen bekommst du beim Kompilieren?

Die Starttaste schaltet einfach VCC ein und aus. Sie startet nicht das Programm, das macht der Mikrocontroller durch den PowerOn Reset.

Sowohl Tasten wie auch LEDs sind low aktiv.

Die schaltest alle LEDs an PORTB so an:

PORTB = 0;

Die LEDs benötigen keine Betriebsspannungsverbindung, du verlegst hier einfach eine 10polige Flachbandleitung vom LED-Port zum PORTB.

Ich kann dir hierzu ja mal eine kleine LED Anwendung schreiben.

Dirk

 

[mr.twister]

Entschuldige, ich wusste nicht das auch die LEDs Low-Aktiv sind... War mir schon peinlich das ich nichtmal das hinbekomme... Jetzt funktionierts, JUHU

 

[Dirk]

Entschuldige, ich wusste nicht das auch die LEDs Low-Aktiv sind... War mir schon peinlich das ich nichtmal das hinbekomme... Jetzt funktionierts, JUHU

... ist doch kein Problem ich kann dir ja morgen nochmal eins oder zwei kleine Beispiele mit LEDs und Tastern schreiben Oder probiere einfach mal ein paar Sachen selber, da lernt man besonders gut Falls du irgendo hängst, dann frag ruhig.

Dirk

 

[LotadaC]

In der Bedienungsanleitung des "Entwicklungsbrettes" sind auf Seite 16 diesbezügliche Schaltplanausschnitte abgebildet. Wenn Du Gnd auf einen der LEDn-Pins von SV9 legst, sollte die entsprechende LED leuchten (also zB wenn man mit einem Jumper Pin9 und Pin7 verbindet)...

(Wenn ich mich recht erinner, war das beim STK500 ähnlich - nur eben mit einem Transistor dazwischen)

 

[Dirk]

Hat zwar nichts mit LED auf Tastendruck" zu tun ...

Mini Lauflicht:
(ich hoffe es funktioniert, habe es schnell getippt )

#define F_CPU 1000000UL

#include <avr/io.h>
#include <util/delay.h>

int main (void)
{
    uint8_t i;
    
    PORTB = 0xFF;
    DDRB = 0xFF;    // PortB output, high

    i = 1;
    while (1)
    {
                
        _delay_ms(100);
        i = i<<1;
        if (0 == i) i = 1;
        
        PORTB = ~i;
        
    }

}

@LotadaC: Ein Transistor ist nicht notwendig, da VCC konstant 5V. Beim großen Devboard haben wir dies ebenfalls, dadurch ist die Helligkeit der LEDs vei VCC5,0V genaus wie bei VCC1,8V.

 

[mr.twister]

Wie füge ich die delay.h ein? Ich würde gerne die Funktion

_delay_ms();

beutzen?

 

[Dirk]

Im Beitrag zuvor steht es drin:

Du bindest delay.h so ein:

#include <util/delay.h>


Noch ein Hinweis: Delay.h benötigt Informationen über den aktuellen Systemtakt. Du musst entweder vor #include die Konstante F_CPU definieren (siehe Beitrag zuvor) oder F_CPU in den Projekteinstellungen global definieren (Toolchain->AVR GNU C Compiler->Symbols, zum Beispiel "F_CPU=1000000UL" für 1MHz)

Dirk

 

[mr.twister]

Also ich habe mit den LEDs jetzt ein wenig rumgespielt. Habe Zustände, in denen bestimmte LEDs leuchten. Mit dem Taster 6 kann ich durch die Zustände schalten. Ich poste meinen Code damit ihr mal einen Blick darauf werfen könnt. Realisiert man die Schalthysterese (stimmt der Begriff hier überhaupt?) mit Delays?

/*
 * Include header files for all drivers that have been imported from
 * Atmel Software Framework (ASF).
 */

#define F_CPU 1000000UL

#include <asf.h>
#include <util/delay.h>

int main (void)
{
	
/*--------------------- Variablen deklaration + Register initialisieren ------------------------------*/	
	
	DDRB = 0x8F;		//	Datenrichtungsregister: 10001111
	PORTB = 0xFF;		//	PORT B: 11111111
	
	uint8_t i = 0;
	
	/*
	Zustand i=0: Alle LEDs aus;
	Zustand i=1: LED 1 ein
	Zustand i=2: LED 1+3 an
	Zustand i=3: LED 1+3+7 an
	*/

/*----------------------------------------------------------------------------*/	

	while (1)
	{
		if ( i==0 & !(PINB&(1<<PB6)) )		// Zustand 0 und Taster 6 aktiv?
		{
			
			PORTB &= ~(1<<PB1);
			_delay_ms(1000);				// Verzögerungszeit für Schalthysterese?
			i++;
		}
		else if ( i==1 & !(PINB&(1<<PB6)) ) // Zustand 1 und Taster 6 aktiv?
		{
			PORTB &= ~(1<<PB3);
			_delay_ms(1000);
			i++;
		}
		else if ( i==2 & !(PINB&(1<<PB6)) ) // Zustand 2 und Taster 6 aktiv?
		{
			PORTB &= ~(1<<PB7);
			_delay_ms(1000);
			i++;
		}
		else if( i==3 & !(PINB&(1<<PB6)) ) // Zustand 3 und Taster 6 aktiv?
		{
			PORTB = 0xFF;
			_delay_ms(1000);
			i=0;
		}
	}
}

Wenn es Verbesserungsvorschläge oder Methoden gibt, wie man das Ganze seriöser lösen kann, dann unbedingt posten

 

[LotadaC]

...Realisiert man die Schalthysterese (stimmt der Begriff hier überhaupt?) mit Delays?...

Das kommt darauf an, was der Controller sonst noch so machen soll. Mit dem Delay dreht sich der Controller quasi 'ne Zeitlang im Kreis, hüpft auf der Stelle rum. Üblicherweise wird so'ne Warteschleife so implementiert, daß ein (oder mehrere geschachtelte) Zähler hoch/runtergezählt werden, bis irgendein wert erreicht ist (zb Überlauf). Wenn dieser Zähler keine weitere Funktion hat, ist das quasi nur 'ne Beschäftigungstherapie für den Controller. Das restliche Programm ist solange blockiert (interrupts mal ausgenommen).
Wenn Deine Aufgabenstellung für so eine Schleife sinnige Aktionen anbietet, kannst Du auch die in die Zählschleife einbauen.

Um flexibel zu bleiben, läßt man den Controller im Hintergrund sinnige ereignisse erzeugen, auf die Du (wenn sie mal endlich eingetreten sind) reagieren kannst. Statt zu warten schaust Du ab und zu mal vorbei. Üblicherweise verwendet man dazu einen irgendwie gesetzten Timer-Interrupt - es gehen aber auch andere ereignisse, die ab und zu eintreten (zb abgeschlossene ADC-Conversionen. Ich selbst habe bei einem Phasenanschnittsdimmer auch mal die Nulldurchgänge (alle 10ms) als (ungefähren) Zeitzähler verwendet.
Dann kann der Controller zwischendurch mit anderen Sachen weitermachen...

 

[mr.twister]

Hey LotadaC,

wie man mit Interrupts umgeht, würde mich als nächstes interessieren, aber erstmal habe ich die Delays benutzt, damit wenn ich auf den Taster drücke bei der Taktfrequenz von 1MHz nicht gleich alle Schritte mit einem Druck auf Key 6 durchgearbeitet werden. So schnell kann ich nicht leider nicht drücken

Beherrschen die ATmega's MultiTasking?
Ich weiß leider noch nicht wie ich den Timer bzw. Counter benutze, aber ich habe mir überlegt, das man eine Funktion schreibt, die den Timer startet, man nebenbei in dem Hauptprogramm weiterarbeitet, aber erst in einen nächsten Schritt übergeht, wenn im Timer ein bestimmter Wert erreicht ist.
Klingt das machbar oder rede ich da Unsinn?

 

[LotadaC]

...wie man mit Interrupts umgeht, würde mich als nächstes interessieren...

Mal etwas vereinfacht formuliert:
Jeder AVR besitzt mehr oder weniger interne Hardware, die in der Lage ist, einen entsprechenden Interrupt auszulösen. Ist der entsprechende Interrupt freigegeben (Interrupt enable), die Interrupts global zugelassen (globales Interrupt-enable -> I in SREG), und das triggernde Ereignis eingetreten (welches auch ein Flag setzt - sind also alle 3 Flags aktiv->), dann wird nach Abarbeitung der gerade laufenden Maschinencodeinstruktion die nächste Programmposition (Programmzähler) auf den Stack geschrieben, die globalen Interrupts gesperrt (I in SREG=0) und der Programmzähler auf den Bereich im Flash gesetzt, der dem jeweiligen Interrupt zugeordnet ist. Diese sind quasi "fest mit dem Interrupt verbunden", Suchstichwort fürs Datenblatt: "IVT" "Interruptvektortabelle". Da dort nur eine/zwei word-Befehle platz haben, steht dort üblicherweise ein Sprungbefehl, der zur jeweiligen Interrupt-Service-Routine verzweigt. In dieser platzierst Du dann Deinen Code, abgeschlossen wird die ISR durch ein ReturnFromInterrupt (RETI), wodurch die Rücksprungadresse wieder vom Stack geholt wird, und wieder dem Programmzähler zugewiesen, und die Interrupts global wieder zugelassen werden.
Eine Hochsprache wie C oder Bascom legt diese Codesegmente mehr oder weniger automatisch an, wenn Du die entsprechenden Befehle einfügst, da sollte vielleicht jemand der C kann noch was zu sagen - aber ich meine, daß Du trotzdem wissen solltest, was der Controller da wirklich macht.

...Beherrschen die ATmega's MultiTasking?
Ich weiß leider noch nicht wie ich den Timer bzw. Counter benutze, aber ich habe mir überlegt, das man eine Funktion schreibt, die den Timer startet, man nebenbei in dem Hauptprogramm weiterarbeitet, aber erst in einen nächsten Schritt übergeht, wenn im Timer ein bestimmter Wert erreicht ist.
Klingt das machbar oder rede ich da Unsinn?

Die Frage kann man so nicht beantworten...
Kommt darauf an, was genau Du unter Multitasking verstehst.
Der Controller selbst hat nur eine ALU (Arythmetic Logical Unit oder so), einen Programmzähler -> einen Rechenkern quasi -> kann also immer nur einen Befehl gleichzeitig abarbeiten. (Strenggenommen ist das bei singleCoreCPUs ja auch so). Wenn Du sowas wie Multitasking simulieren willst, mußt Du halt zwischen den Tasks hin und her springen. Das ist dann aber keine Fähigkeit des Controllers, sondern des Programmes. Wie sagt Dino immer: Ein Mikrocontroller ist kein PC - Du schreibst das Programm, das Betriebssystem und alle Treiber selbst (bzw kopierst die Dir irgendwoher zusammen). Damit läßt sich auch in einem AVR sowas wie preamptives/competetives Multitasking realisieren. Manfred Schwabl-Schmidt hat da bereits dicke Bücher drüber geschrieben.
Jetzt kommt das große ABER:
Neben dem simplen Probrammlogik beherbergt jeder AVR mehr oder weniger integrierte Hardware. Und diese ist mehr oder weniger autark:
-wenn Du 'ne Analog Digital Conversion startest, kann das Hauptprogramm weitermachen, der ADC arbeitet unabhängig davon, und schreibt irgendwann seinen Status und das ergebnis in entsprechende Register (man kann ihn auch im Dauerlauf arbeiten lassen...)
-wenn Du den UART entsprechend konfiguriert hast, und ein byte an den Transmitter übergibst, beginnt der (entsprechend seinen Einstellungen) dieses Byte über den TxD zu senden - während Dein Programm weitermacht
-ahnliches beim UART-Reciever, beim SPI, beim TWI...
-wenn du einen der Timer konfigurierst und startet, läuft der (entsprechend) im Hintergrund durch, unabhängig von Deinem Programm. Insbesondere mit den OutputCompareUnits lassen sich da im Hintergrund interessante Dinge einrichten, PWM etc).

Du kannst jetzt einerseits lesenden/schreibenden Zugriff auf diese Hardware nehmen (zB den Timer lesen, das letzte ADC-ergebnis lesen, den PWM-duty umsetzen etc), andererseits kannst Du aber der Hardware auch die Fähigkeit geben, dein Laufendes Programm gegebenenfalls zu unterbrechen (mit den Interrupts eben) - zB wenn ein Timer überläuft, wenn der ADC ein ergebnis hat, wenn über UART/SPI/TWI ein Byte empfangen/gesendet wurde , ...

Ich empfehle Dir ganz stark, Dir mal so'n (komplettes) Datenblatt eines Kontrollers durchzulesen (überfliegen reicht, die interessanten Stellen liest man dann eh genauer), ggf mehrmals - damit Du überhaupt erstmal ein Gefühl für die Möglichkeiten, das Konzept eines AVR bekommst - das ist dann nämlich bei allen AVR irgendwie ähnlich...

 

[dino03]

Hallo,

wie man mit Interrupts umgeht, würde mich als nächstes interessieren, ...

Beherrschen die ATmega's MultiTasking?
Ich weiß leider noch nicht wie ich den Timer bzw. Counter benutze, aber ich habe mir überlegt, das man eine Funktion schreibt, die den Timer startet, ...

Klingt das machbar oder rede ich da Unsinn?

Sorry aber ... das klingt für mich wieder nach nem Anfänger der zuerst nen Wolkenkratzer und danach die Hundehütte baut.
Ich fürchte das endet im Frust.

Eigne dir erstmal die Kenntnisse über Interrupts, Timer, ... an.

Gruß
Dino

 

[mr.twister]

@LotadaC: Wow, danke für deine Antwort, ist ja richtig viel geworden

Nochmal zu meiner Frage mit dem Delay und den Tastern. Mein ATmega8 läuft ja jetzt mit den Werkseinstellungen, d.h. mit dem internen Takt von 1MHz. D.h. die Abarbeitung des Programms geschieht einmal pro us (stimmt das so?). Da ich aber meinen Taster nicht so schnell drücken kann, d.h. er z.B. 100ms betätigt ist, arbeitet sich das Programm innerhalb dieser Zeit 1000mal ab. Um das zu vermeiden, habe ich das Delay eingebaut, damit ich immer nur einen Zustand weiterschalte und nicht mit einmal drücken alle Zustände durchlaufe.
Die Frage ist, wird das Programmtechnisch wirklich so gemacht? oder gibt es da andere Methoden, schließlich ist der MC, wie LotadaC das schon ein paar Beiträgen früher geschrieben hat, für diese Zeit "lahm" gelegt.




@dino3:

Ich habe deinen Thread "Ein paar Gedanken, Anregungen, Ideen, ... (Tips + Mini-Knigge)" gelesen und mir vorgenommen, es genau so zu machen, d.h. mich langsam vortasten und mit der Zeit den Schwierigkeitsgrad erhöhen. Die Interrupts möchte ich noch ein bisschen nach hinten schieben, dass scheint nicht so einfach sein wie es am Anfang aussah, habe mich ein bisschen belesen, aber diese ganzen Bits die gesetzt werden müssen, dass ist im Moment noch ziemlich verwirrend.


Ich bräuchte eine kleine Hilfestellung bei meinen nächsten Schritten. Was sollte ich mir als nächstes anschauen, was nicht? Dazu ist vielleicht für euch noch ganz interessant, das ihr wisst, was ich kann und was nicht.

Also ich bin Student im jetzt bald 2. Semester (im Moment habe ich "Semesterferien"). Studieren tue ich Elektrotechnik. Im ersten Semester haben wir "nur" Gleichstrom behandelt, d.h. über Wechselstromvorgänge weiß ich leider noch nicht bescheid. Programmieren hatten wir auch noch nicht, aber ich habe früher relativ viel PHP-Skripte geschrieben (das ging bis zu den Anfängen eines eigenen CMS) und habe mich mal durch alles durchgearbeitet (Delphi in der Schule, C, C++, Java, Python). Das ist zwar schon ein bisschen her, aber ich komme da denke ich mal relativ schnell wieder rein. Mit Mikrocontrollern habe ich noch nicht gearbeitet. In der Uni werden wir das wahrscheinlich auch erst im 3. Semester machen. Das war es auch erstmal so im groben.

Ich wäre auch dankbar für kleine Denkanstöße was Mini-Projekte angeht, was kann man noch alles mit LEDs und Tastern machen? Da ich im Moment noch nichts anderes habe müsste ich damit zunächst auskommen

 

[dino03]

Hallo,

@dino3:
Ich habe deinen Thread "Ein paar Gedanken, Anregungen, Ideen, ... (Tips + Mini-Knigge)" gelesen und mir vorgenommen, es genau so zu machen, d.h. mich langsam vortasten und mit der Zeit den Schwierigkeitsgrad erhöhen. Die Interrupts möchte ich noch ein bisschen nach hinten schieben, dass scheint nicht so einfach sein wie es am Anfang aussah, habe mich ein bisschen belesen, aber diese ganzen Bits die gesetzt werden müssen, dass ist im Moment noch ziemlich verwirrend.

das was mir aufgefallen ist, das war diese Frage nach "Multitasking". Dafür benötigt man zwangsweise Interrupts für den Scheduler wenn was Vernünftiges bei rauskommen soll. Und in Multitasking steckt noch weit mehr Frustpotential drin als in so einem kleinen Interrupt.

Irgendwo gibt es ne Multitasking-Umgebung für Atmels. Ich werde mir das aber nicht antun weil ...
1. Es frißt zusätzlichen Speicher, Resourcen, Geschwindigkeit, ... wo sowieso immer zu wenig von da ist.
2. Es verkompliziert die ganze Sache noch zusätzlich was bei so einer kleinen Büchse nix bringt (meine Meinung)

Multitasking bei den größeren Atmels mit Linux Unterbau (32Bit, ...) ist was anderes. Bei den kleinen Dingern würde ich aber nach meiner Meinung von echtem Multitasking die Finger lassen.

Gruß
Dino

 

[LotadaC]

...Nochmal zu meiner Frage...Mein ATmega8 läuft ja jetzt mit den Werkseinstellungen, d.h. mit dem internen Takt von 1MHz. D.h. die Abarbeitung des Programms geschieht einmal pro us (stimmt das so?)...

Nein, der Mega wird mit 1MHz betaktet. Für einen eine 1-Takt-Instruktion benötigt er dann also eine µs. Für eine 2-Takt-Instruktion halt 2 usw. Du verwendest aber mit C (Hochsprache) schon komplexere Befehle, die sich ggf aus mehreren/vielen Instruktionen zusammensetzen. Wie gesagt, Lies Dir das Datenblatt des Mega8 mal in Ruhe durch (Warum eigentlich keinen aktuelleren Controller? den Mega88, oder gleich den 168 zB?)
Bevor ich hier weitermache:
Du verwendest dieses Nano-Board.
Darauf einen ATmega8 (ohne L).
Hast Du Dich bereits auf C als Programmiersprache festgelegt?
Zum Datenblatt:
Gleich auf der ersten Seite findest Du eine ganz grobe Zusammenfassung des Controllers (also der Hardware). Unter dem Stichpunkt Memory Segments stehen dort unter anderem die 512Bytes Eeprom (quasi sowas wie 'ne interne Festplatte), 1024Bytes SRAM (Arbeitsspeicher) und 8kBytes ProgramFlash. Da der Programmspeicher Word-basiert ist, mußt Du Dir das als 4096 Zeilen lange Liste vorstellen, die zu einem Ring zusammengeklebt ist (am Ende gehts wieder von vorne los).
Dein Programm wird also in entsprechende Maschinenkodeinstruktionen übersetzt (words), und beginnend ab Adresse0 in diese Liste eingetragen.
Nehmen wir jetzt mal vereinfacht an, es gäbe nur 1-Takt-Instruktionen, und alle würden je 1 Word im Speicher belegen:
Nach einem Reset des Controllers (also auch beim Powerup) wird jetzt bei jedem Taktzyklus eine Instruktion aus dem Programmspeicher (der Word-Liste) beginnend bei Adresse0 geladen, und ausgeführt. Danach wird der Programmzähler auf das nächste Word gesetzt, im nächsten Taktzyklus wird dann die nächste Instruktion abgearbeitet. Insbesondere kannst Du den Controller also auch nicht anhalten lassen, wenn die Clock läuft. Du kannst ihn halt nur 'ne Zeit lang mit mehr oder weniger unsinnigen Sachen beschäftigen. Wait-Instruktionen sind sowas wie 'ne For-To-Schleife, in der nix sinniges gemacht wird, außer die Zeit totzuschlagen.
Das kann man natürlich so machen, klar. Man kann es aber auch umgehen. Und da kommen Interrupts, Polling usw ins Spiel.