UART und I2C: Interrupt oder nicht

TechInfo Gast #582621
Lesenswert?
• ▲
▼ 
Hallo,

ich möchte mir folgende Konfiguration aufbauen:

Am TWI eines Atmega128 hängen I2C-Display und I2C-Tastatur. Tastatur und 
Display sind Slaves, der Atmega der Master. Da die Tastatur ein Slave 
ist, wird sie also vom Master gepollt auf Änderungen an den Ports.
Wenn die Tastatur gedrückt wird, soll dies zur Folge haben, dass ein 
Befehl über den USART verschickt wird. Gleichzeitig sollen Befehle über 
USART empfangen werden können, die dann eine Änderung des Displays 
bewirken.

Der TWI bietet ja nun die Möglichkeit, "interrupt-driven" oder mit 
Polling zu arbeiten. Bei Interrupt-Steuerung wird, wenn das 
TWI-Interrupt-Flag gesetzt ist (passiert immer dann, wenn das 
TWI-Interface Daten erhalten oder grade rausgeschickt hat), ein 
Interrupt im Controller ausgelöst. Beim Polling wird eben kein Interrupt 
ausgelöst, sondern das Interrupt-Flag wird dauernd abgefragt.

Die USART-Geschichte möchte ich auf alle Fälle mit Interrupts 
realisieren, indem beim Empfangen von einem Zeichen in die ISR 
gesprungen wird, und falls das Ende-Zeichen angekommen ist, ein Flag 
"Befehl angekommen" gesetzt wird, dass wiederum vom Hauptprogramm 
gepollt wird.

Jetzt meine Fragen:

Ist es sinnvoll, sowohl für I2C als auch für USART den Interrupt-Modus 
zu benutzen? Oder könnte es da Probleme geben und ich fahre besser, wenn 
ich I2C nur polle?

Was passiert, wenn zwei Interrupts genau gleichzeitig ankämen?

Und was passiert, wenn der USART ein Zeichen empfängt, während er am 
Senden ist?
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
A.K. Gast #582644
Lesenswert?
• ▲
▼ 
Alternative: Der Tastatur-Slave wird mit einer separaten 
Interrupt-Leitung ausgestattet. Die sagt dem Master, eben per Interrupt, 
dass es an der Zeit ist, mal wieder nachzuhaken. Erspart das Polling, 
wenn das stören sollte.

I2C ist langsam genug, dass man die entsprechenden Routinen per 
Interrupt betreiben sollte. Zumal die State-Machine ohnehin die gleiche 
ist und der entsprechende Code in irgendwelchen AppNotes sowieso schon 
rumliegt.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
TechInfo Gast #582652
Lesenswert?
• ▲
▼ 
>Alternative: Der Tastatur-Slave wird mit einer separaten
>Interrupt-Leitung ausgestattet. Die sagt dem Master, eben per Interrupt,
>dass es an der Zeit ist, mal wieder nachzuhaken. Erspart das Polling,
>wenn das stören sollte.

Der Interrupt-Ausgang liegt bei der mir zur Verfügung stehenden Tastatur 
brach, Änderungen kommen da nicht in Frage.

>I2C ist langsam genug, dass man die entsprechenden Routinen per
>Interrupt betreiben sollte. Zumal die State-Machine ohnehin die gleiche
>ist und der entsprechende Code in irgendwelchen AppNotes sowieso schon
>rumliegt.

Also deiner Meinung nach sollte ich sowohl USART-Behandlung als auch I2C 
per Interrupt betreiben, und das beißt sich nicht?
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Andreas K. #582746
Lesenswert?
• ▲
▼ 
Wenn du einen extrem zeitkritischen Interrupts hast, aber einen 
Controller ohne priorisierierte Interrupts, dann kann es tatsächlich 
sinnvoll sein, nur ebendiesen einen Interrupt als solchen zu 
implementieren und alle anderen Ereignisse zu pollen.

Ansonsten verzögert deine Variante nur die I2C-Aktivitäten der Slaves, 
die dann u.U. auf den Pollzyklus vom Master warten. Geht freilich 
beides, und deine Variante ist weniger nebenläufig, etwas mit dem manche 
Leute Probleme haben.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren