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?
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.
>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?
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.
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?
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.
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.