mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik UART und I2C: Interrupt oder nicht


Autor: TechInfo (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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?

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: TechInfo (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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?

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Warum sollte es sich beissen? Eines ist hoffentlich klar: In 
Interrupt-Handler gehören keine längeren Aktivitäten. Der übliche 
I2C-Handler macht das auch nicht.

Autor: TechInfo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Natürlich nicht. I2C ist ja sowieso ein sehr schmal gehaltenes 
Protokoll.

Was wäre denn der Vorteil von Interrupt-basierter I2C-Behandlung 
gegenüber Pollen auf das TWI-Interrupt-Flag?

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht 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 schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.