TWI Implementierung / Protokoll [gelöst]

Hallo zusammen,

ich bastel momentan an einer Art TWI-Protokoll. Ich möchte in einer MultiMaster-Umgebung(muss sein, da MC's von sich aus Nachrichten verschicken müssen) Nachrichten senden und empfangen. Nach der KeepItSimple-Regel habe ich erstmal MR/ST rausgenommen(Master kann nur senden und Slave nur empfangen). Die Implementierung via TWI.h habe ich eigentlich im Griff. Mein Problem ist das Protokoll selbst. Ich stelle mir das momentan so vor. Ein MC entscheidet eine Nachricht zu versenden, prüft ob der Bus frei ist, und sendet seine Nachricht, die vom Empfänger mit einer eigenen Nachricht quitiert wird(Eine Art ACK auf Software Basis). Kommt kein ACK vom Empfänger, so wird die Nachricht n-mal wiederholt.

Jetzt mein Problem:

Ich muss andere Ereignisse in Echtzeit abarbeiten, die Nachrichten müssen nicht in Echtzeit erfolgen. Wenn sich Nachrichten aufstauen, weil z.B. der Bus belegt ist, oder entsprechend viele Ereignisse auftreten, kann ich nicht warten bis der Bus wieder frei ist, und muss die Nachrichten erstmal queuen. Mir schwebt da ein FIFO-Speicher vor. Nur wie realisiere ich den. Es könnte auch vorkommen das sich Nachrichten an verschiedene Empfänger stauen.

Wie realisiere ich einen FIFO-SendeSpeicher mit Empfänger-Adressen in C?
Wie realisiere ich einen FIFO-Empfangsspeicher in C?
Wie fange ich einen Speicherüberlauf des FIFO's ab? (Ich werde wohl experimentiell ermitteln müssen wie groß der FIFO sein muss)
Eventuell muss ich noch anderen MC's die Möglichkeit geben zu senden, also den BUS kurzfristig freigeben, bevor die nächste Nachricht verschickt wird

Bitte Anworten am Besten mit BeispielCode um Missverständnissen vorzubeugen.

Gruß

Martin

Es wäre fein, wenn du da mal rumtöbern könntest, wieweit irgendwas von diesem Project in deinem Kram paßt. (da ist auch I2C dabei)
https://www.roboternetz.de/wissen/in...pezifikationen

https://www.roboternetz.de/wissen/in...is_Multimaster

Ich kann mit der Info leider nix anfangen. Es geht hier definitiv nicht um die Realisierung von TWI! Das funzt bei mir! Mir geht es um die Realisierung des FIFO's(oder einer anderen Lösung) für TWI in C.

Ich benötige einen Sende-Puffer (FIFO?) der auch die Empfänger-Adressen puffert, und einen Empfangspuffer der die einzelnen Nachrichten trennen kann.
Eventuell benötige ich noch eine Funktion(Timer?) die den BUS kurzfristig freigibt, damit andere MC's ihre Nachrichten auch versenden können.

Gruß

Martin

"FIFO" mittels RIngspeicher gibt's da
https://www.roboternetz.de/wissen/in...FO_mit_avr-gcc

Btw: Ich selbst mach bei I2C KEINEN Ringpuffer, weil auch der ein Limit hat, bei dem es nicht mehr weitergeht. D.h. ich verschiebe das Problem nur. Daher hab ich es bleiben lassen. Bei einem Multimastersystem kann ein Sender sowieso nicht sicher sein, daß er gleich dran kommt, bzw. das der andere nicht gerade selbst sendet. Also bleibt die Message immer dort im Buffer, der sie gerade senden will.

getimete Busfreigabe: hat nur sinn, wenn die anderen wissen, daß einer gerade definitiv pause macht. Und dann müssen sie auch grad dann überhaupt was zum senden haben.
Es ist einfach so, daß jeder warten muß, bis er den Bus kriegt.
Und die Datenmenge, die insgesamt (von allen Teilnehmern) über den Bus gesendet werden kann, hat Grenzen, und kannst du auch berechnen, nach message-länge und Bus-speed.
Das ist einfach eine Sache der Bilanz: wenn mehr gesendet wird als verarbeitet, kommst du in troubles.

Schau dir die Methoden bei anderen Collision-Bussen an (Ethernet), für µC ist das alles schwere Kost.

Genau das hab ich gebraucht... THX erstmal. Ich werde das wohl erstmal so lösen wie du das machst. Sollte ich nen FIFO brauchen, werde ich mir das mal zu Gemüte führen. Ich denke das ich mit nem Zeiger auch das Adressierungsproblem lösen kann.

THX

Martin

Zitat:

---

..Sollte ich nen FIFO brauchen, werde ich mir das mal zu Gemüte führen

---

FIFO's und alle Varianten gehören immer in die Werzeugkiste, genauso wie Sort-Algoritmen.
Sowas solltest du dir auf jeden Fall einverleiben.

@PicNick da hast Du sicherlich recht, jedoch darfst du nicht vergessen, daß ich meine Zeit einteilen muss -> bedeutet, ich werde mir den FIFO erst zu Gemüte führen wenn ich ihn brauche oder einfach Zeit dafür habe :-)

Warten tut man eh nicht :-)

Deine I2C-ISR kannst du für IRQs öffnen, damit sinkt die Interrupt Respond Time (IRT) der anderen IRQs deutlich.

Mehrere Master werden nie senden. Falls doch, gibt's ne Arbitration und einer der Master hält den Mund (wird Slave) und versucht's wieder, wenn der Bus frei ist. Ausserdem weiß ja jeder, ob der Bus gerade belegt ist oder nicht. START/STOP hört ja jeder.