| Zeile 1: | Zeile 1: | ||
Grundsätzlich ist ja im Artikel [[TWI Praxis]] alles dargestellt, war der Mensch braucht, um die Hardware TWI eines AVR zu verwenden. | Grundsätzlich ist ja im Artikel [[TWI Praxis]] alles dargestellt, war der Mensch braucht, um die Hardware TWI eines AVR zu verwenden. | ||
| − | *Wenn "Multimaster" lediglich darin besteht, daß sich mehrere Master die I2C-Perpherie gewissermaßen teilen, reicht das auch völlig, da das TWI-Modul des Avr immer automatisch wartet, bis der Bus frei ist | + | *Wenn "Multimaster" lediglich darin besteht, daß sich mehrere Master die I2C-Perpherie gewissermaßen teilen, reicht das auch völlig, da das TWI-Modul des Avr immer automatisch wartet, bis der Bus frei ist. |
*Im Multimasterbetrieb mit gegenseitigem Zugriff treten allerdings Situationen auf, die die Sache dann leicht ins Stocken bringen | *Im Multimasterbetrieb mit gegenseitigem Zugriff treten allerdings Situationen auf, die die Sache dann leicht ins Stocken bringen | ||
| − | = | + | =Konflikte= |
| + | ==Bus Lost== | ||
| + | Die TWI-Hardware verfolgt ja immer den Bus, und wenn ein Master bei einem gerade besetzten Bus ein START absetzen will, wird einfach gewartet. Innerhalb eines kurzen Zeit-Fensters wird das allerdings zu spät bemerkt, da tritt dann die "Arbitrierung" in Kraft (ganz genau steht das im Datenblatt). Irgendwann merkt ein Master, daß ein anderer auch gerade Daten sendet und bricht dann seine eigene Übertragung ab. Status: Irgendeine Variante mit "Bus Lost". | ||
| + | Das einzig Sinnvolle ist es dann zu warten, bis der andere seine Übertragung beendet hat, und es dann ganz einfach wieder zu versuchen. Genauso ist es, wenn andere Störungen aufgetreten sind (Es reicht völlig, wenn ein anderer µC mit den Bascom-I2C Soft-Funktionen einfach irgendwann zu senden beginnt). | ||
| − | = | + | ==Deadlock== |
| − | + | Wenn so ein Multimaster gleichzeitig auch als Slave fungiert, kann aber auch ein Deadlock entstehen. Wenn wir einfach eine Sendeschleife definieren, bis wir mit unserer (Master) Sendung durchgekommen sind, und zur selben Zeit will ausgerechnet der Master, den wir gerade adressieren, mit der gleichen Strategie auf UNS zugreifen, finden beide Prozessoren kein Ende in ihrer Schleife. Jeder wartet, bis der andere endlich zuhört. | |
| + | In diesem Fall müssen wir den Sendeversuch eigentlich abbrechen und erstmal schauen, ob wir nicht selbst adressiert worden sind. Wenn ja, müssen wir erstmal das verarbeiten, was wir gekriegt haben und erst dann können wir nochmal einen Sendeversuch starten. | ||
| + | =MyTWI.LIB= | ||
| + | Diese Bascom-Library versucht nun, diese Konflikte soweit abzuhandeln, daß der User nicht allzuviel damit konfrontiert ist. | ||
=Demo-Programm= | =Demo-Programm= | ||
Version vom 30. August 2006, 13:54 Uhr
Grundsätzlich ist ja im Artikel TWI Praxis alles dargestellt, war der Mensch braucht, um die Hardware TWI eines AVR zu verwenden.
- Wenn "Multimaster" lediglich darin besteht, daß sich mehrere Master die I2C-Perpherie gewissermaßen teilen, reicht das auch völlig, da das TWI-Modul des Avr immer automatisch wartet, bis der Bus frei ist.
- Im Multimasterbetrieb mit gegenseitigem Zugriff treten allerdings Situationen auf, die die Sache dann leicht ins Stocken bringen
Inhaltsverzeichnis
Konflikte
Bus Lost
Die TWI-Hardware verfolgt ja immer den Bus, und wenn ein Master bei einem gerade besetzten Bus ein START absetzen will, wird einfach gewartet. Innerhalb eines kurzen Zeit-Fensters wird das allerdings zu spät bemerkt, da tritt dann die "Arbitrierung" in Kraft (ganz genau steht das im Datenblatt). Irgendwann merkt ein Master, daß ein anderer auch gerade Daten sendet und bricht dann seine eigene Übertragung ab. Status: Irgendeine Variante mit "Bus Lost".
Das einzig Sinnvolle ist es dann zu warten, bis der andere seine Übertragung beendet hat, und es dann ganz einfach wieder zu versuchen. Genauso ist es, wenn andere Störungen aufgetreten sind (Es reicht völlig, wenn ein anderer µC mit den Bascom-I2C Soft-Funktionen einfach irgendwann zu senden beginnt).
Deadlock
Wenn so ein Multimaster gleichzeitig auch als Slave fungiert, kann aber auch ein Deadlock entstehen. Wenn wir einfach eine Sendeschleife definieren, bis wir mit unserer (Master) Sendung durchgekommen sind, und zur selben Zeit will ausgerechnet der Master, den wir gerade adressieren, mit der gleichen Strategie auf UNS zugreifen, finden beide Prozessoren kein Ende in ihrer Schleife. Jeder wartet, bis der andere endlich zuhört.
In diesem Fall müssen wir den Sendeversuch eigentlich abbrechen und erstmal schauen, ob wir nicht selbst adressiert worden sind. Wenn ja, müssen wir erstmal das verarbeiten, was wir gekriegt haben und erst dann können wir nochmal einen Sendeversuch starten.
MyTWI.LIB
Diese Bascom-Library versucht nun, diese Konflikte soweit abzuhandeln, daß der User nicht allzuviel damit konfrontiert ist.
Demo-Programm
- m32slave.bas demo/testprogramm
- twi_show_state.bas Twi-Status printen
- mytwi.bas includefile für die library
- mytwi.lib Bascom library, gehört natürlich ins Bascom LIB directory
Funktionen der Demo
- Das Demo definiert sich als Slave und sendet oder empfängt auf diese Weise Daten.
- Jede Sekunde aber sendet er selbst als Master Daten an einen anderen I2C-Slave und holt dann gleich auch Daten von dort ab
Autor
Siehe auch
WebLinks / Download
