Frage(n) zur seriellen EIB-Schnittstelle mit FT1.2-Protokoll

Seit einiger Zeit verwenden wir zur Anbindung an den EIB die serielle Schnittstelle (z.B. MERTEN 6816) mit FT1.2-Protokoll, PEI Type 10. Die Übertragungsrate auf serieller Seite (FT1.2-Protkoll) beträgt 19200 Baud, auf dem EIB 9600 Baud.

Es besteht die Anforderung, unter bestimmten Umständen viele Schalttelegramme (Gruppen schreiben) möglichst schnell über diese Schnittstelle auf den EIB zu schicken.

Nach der Dokumentation im EIBA Handbook kann erst nach dem Erhalt eines ACK-Telegramms das nächste Telegramm an die Schnittstelle geschickt werden. Sollte das ACK-Telegramm fehlen, so muss die Timeoutzeit (ca. 510 Bits Länge) abgewartet werden bis das Telegramm erneut (max. 3x) geschickt werden kann.

Folgende Fragen sind dabei entstanden:

1. Sendet die Schnittstelle das ACK erst dann, wenn das Telegramm auf den EIB geschickt wurde oder bereits dann, wenn es auf serieller Seite korrekt empfangen wurde?

2. Kann es passieren, dass der Eingangsbuffer der Schnittstelle durch viele aufeinanderfolgende Telegramme überschrieben wird? D.h. noch bevor das im Buffer stehende Telegramme auf den EIB geschickt wird, wird es durch ein neues überschrieben.

3. Wie kann sichergestellt werden, dass bei einer Situation wie unter Punkt 2 beschrieben Telegramme vom EIB zur seriellen Seite sicher durchgelassen werden und nicht verloren gehen?

4. Ist es sinnvoll beim Senden von vielen aufeinanderfolgenden Schaltaufträgen zwischen den einzelnen Telegrammen eine Wartezeit (?ms) einzuhalten um somit evtl. Telegramme vom EIB (siehe Punkt 3) durchzulassen?

5. Besteht die Möglichkeit, die Schnittstelle gezielt nach ihrem Zustand abzufragen (Status, Bufferlevel...)?



Vielen Dank für die Mühe!


Roland Mücke

Hallo Roland,

1. Sendet die Schnittstelle das ACK erst dann, wenn das Telegramm auf den EIB geschickt wurde oder bereits dann, wenn es auf serieller Seite korrekt empfangen wurde?

Die Schnittstelle sendet in dem Sinn gar kein ACK, sondern Du erhählst das ACK das vom Bus, also dem (oder den) angesprochenen Teilnehmer, zurück kommt. Da sheisst Du bekommst das ACK erst wenn das ganze Telegram auf den Bus gesendet wurde, ein Gerät auf die entsprechende Adresse höhrt und das Packet Fehlerfrei empfangen hat und somit bestätigt.

2. Kann es passieren, dass der Eingangsbuffer der Schnittstelle durch viele aufeinanderfolgende Telegramme überschrieben wird? D.h. noch bevor das im Buffer stehende Telegramme auf den EIB geschickt wird, wird es durch ein neues überschrieben.

Im Ausgangs Puffer kann immer nur ein Telegram stehen da dieses ja beim ACk schon verschickt wurde. Eingangs und Ausgangspuffer müssen separate Puffer sein, das gilt für alle EIB Geräte da während des Aufbaus eines zu sendenden Telegrams immer ein anderes Empfangen werden kann.

3. Wie kann sichergestellt werden, dass bei einer Situation wie unter Punkt 2 beschrieben Telegramme vom EIB zur seriellen Seite sicher durchgelassen werden und nicht verloren gehen?

Da die eingangs Geschwindigkeit vom Vus halb so gross ist als die Uebertragungsgeschwindigkeit zum PC kann ein Packet niemals überschrieben werden, es sei denn es gibt Probleme auf der seriellen Verbindung.

4. Ist es sinnvoll beim Senden von vielen aufeinanderfolgenden Schaltaufträgen zwischen den einzelnen Telegrammen eine Wartezeit (?ms) einzuhalten um somit evtl. Telegramme vom EIB (siehe Punkt 3) durchzulassen?

Wie bei anderen EIB Geräten mit hohem Telegramaufkommen sollte man die Anzahl der Telegramme pro Zeiteinhei (Sekunde, Minute, etc...) begrenzen um anderen auch eine Chance zu lassen.

5. Besteht die Möglichkeit, die Schnittstelle gezielt nach ihrem Zustand abzufragen (Status, Bufferlevel...)?

Soweit ich weiss nein. Aber wie erklärt spielt der Buffer level keine Rolle. Rein theoretisch könnten verschiedene FT1.2 Schnittstellen auch verschiedengrosse Puffer (oder andere Parameter) haben, da nur die funktionsweise festgelegt ist, nicht aber die Implementation, auch wenn dies wohl in der Realität eher nicht der Fall ist.

Gruss,
Gaston

Hallo Gaston,

vielen Dank für die schnelle Antwort!

zu 1.:
Nach der Dokumentation im EIBA Handbook Volume 3 Kap. 6.4 schickt die Schnittstelle nach jedem auf serieller Seite empfangenen Telegrammm ein ACK (E5h). Später erst kommt die Telegrammbestätigung vom Busteilnehmer. Die Frage ist nun die, ob das ACK (E5h) bedeutet, dass das nächste Telegramm an die Schnittstelle geschickt werden kann.

zu 2.:
Gemeint war folgendes: Auf serieller Seite wird ein Telegramm an die Schnittstelle geschickt und von dieser mit E5h bestätigt. Sofort danach wird erneut ein zweites Telegramm geschickt. Kann es nun passieren, dass das 1. Telegramm noch nicht 'bearbeitet' wurde und noch im Eingangsbuffer liegt und durch das 2. Telegramm überschrieben wird? Was ist z.B. wenn die Schnittstelle das 1. Telegramm nicht auf den Bus schicken konnte (z.B. wegen zu hoher Buslast)?

zu 3.:
Was passiert, wenn es Probleme bei der seriellen Übertragung gibt? Speichert die Schnittstelle eingehende EIB-Telegramme? Wie groß ist der Buffer?

zu 4.:
Welche Pausenzeiten haben sich als sinnvoll erwiesen? Gibt es Erfahrungswerte?

6.:
Gibt es eine detailiertere technische Beschreibung der Schnittstelle (Zeitdiagramme, Kommunikation...) als die, welche im EIBA Handbook Volume 3 veröffentlicht ist?


Danke und Gruß!

Roland Mücke

Hallo Roland,

vielen Dank für die schnelle Antwort!

Die war wohl etwas zu schnell, hätte die Spezifikationen besser nochmal gelesen ;)

zu 1.:
Nach der Dokumentation im EIBA Handbook Volume 3 Kap. 6.4 schickt die Schnittstelle nach jedem auf serieller Seite empfangenen Telegrammm ein ACK (E5h). Später erst kommt die Telegrammbestätigung vom Busteilnehmer. Die Frage ist nun die, ob das ACK (E5h) bedeutet, dass das nächste Telegramm an die Schnittstelle geschickt werden kann.

Richtig, die FT1.2 Schnittstelle schickt ein ACK (sorry mein Fehler), allerdings kannst du nach dem ACK gleich wieder eine Frame schicken. Natürlich musst Du dann das FCB bit "umschalten".

zu 2.:
Gemeint war folgendes: Auf serieller Seite wird ein Telegramm an die Schnittstelle geschickt und von dieser mit E5h bestätigt. Sofort danach wird erneut ein zweites Telegramm geschickt. Kann es nun passieren, dass das 1. Telegramm noch nicht 'bearbeitet' wurde und noch im Eingangsbuffer liegt und durch das 2. Telegramm überschrieben wird? Was ist z.B. wenn die Schnittstelle das 1. Telegramm nicht auf den Bus schicken konnte (z.B. wegen zu hoher Buslast)?

Wenn der Puffer voll ist bekomst du kein ACK. Du kannst also nicht zwischen Fehler und Pufferüberlauf unterscheiden. Mann könnte sie nun "einmessen", aber das geht nicht da die Interne Pufferbehandlung (1Puffer=1Frame, oder Puffer abhängig von Frame-Länge?) nicht spezifiziert ist. Könnte also theoretisch von der Schnittstelle abhängen.

Aber wenn Du ein Packet auf den Bus sendest solltest Du sowieso auf das ACK vom Bus warten, somit kann der Fall nicht eintreten.

zu 3.:
Was passiert, wenn es Probleme bei der seriellen Übertragung gibt? Speichert die Schnittstelle eingehende EIB-Telegramme? Wie groß ist der Buffer?


Wie schon gesagt, ist zu erwarten dass die Schnittstelle zumindest zwei Wingangspuffer hat. Bei spezifikationen muss man immer aufpassen dass man nur das annimmt was auch geschrieben steht. Alles was nicht spezifiziert ist ist der Implementation überlassen. So könnte eine FT1.2 Schnittstelle 2 Puffer haben, eine andere jedoch 10. Und morgen kann es wieder anders sein.

Wenn es auf der seriellen Schnittstelle ernste Probleme gibt, ist zu erwarten dass Telegramme (wie beiu jedem EIB Gerät in dem Fall) verloren gehen wenn zuviele "gleichzeitig" ankommen.

zu 4.:
Welche Pausenzeiten haben sich als sinnvoll erwiesen? Gibt es Erfahrungswerte?


Das glaube ich nicht. Die EIB Spezifikationen sehen eigentlich vor dass ein Gerät keine Frame schickt bevor es ein ACK (vom Bus) erhalten hat. Ausserdem ist eine Pause von 53 bits minimum einzuhalten, hierum kümmert sich aber dioe FT1.2 Schnittstelle, sowie um das Retransmit.

Wenn Du also kein ACK erhälst solltes Du zumindest so lange warten wie die Schnittstelle potentiell minimal braucht um die Retransmits auszu führen.

Also maximal hat eine Frame 23 bytes, 1 Byte sind 13 Bit, und ein bit dauert 104us. Zwischen Frame und retransmit liegen (mindestens) 50bits (wenn kein anderer Busteilnehmer sendet). Das ergibt also 3x(23x13+50)*104 us=109 ms. Ich würde also mindestens eine viertel Sekunde auf ein ACK warten bevor ich die nächste Frame schicken würde.



6.:
Gibt es eine detailiertere technische Beschreibung der Schnittstelle (Zeitdiagramme, Kommunikation...) als die, welche im EIBA Handbook Volume 3 veröffentlicht ist?


Soweit ich weiss nicht, und das ist auch nicht nötig. Nur das spezifizierte ist festgelegt, alles andere Implementationssache.

Gruss,
Gaston