Kommentare zum Handbuch v17

[saft6luck]

S. 217, S. 223 (S.133f ?): settime(), setdate() und settimedate() falsch beschrieben. settime() etc. schreiben nicht auf den Bus.

[saft6luck]

S. 120: "read("Temperatur-1/2/1",22.3)" ist falsch

[saft6luck]

S. 118: Multithreading im Programmablauf -> Performance! Man beachte den Wiki Artikel hierzu, der die Sinnhaftigkeit bei einem einzelnen Prozessor darlegt: "Ohne weitere Hardwareunterstützung reduziert das Multithreading die Gesamtsystemleistung durch den bei Threadwechseln entstehenden Overhead."

-> Widerspruch in der Kausalkette

[saft6luck]

S.119: Am KNX Bus können mehr als 1 Telegramm pro 40ms eintreffen.

[saft6luck]

S.122 Beispiel: "Schreiben auf den BUS"
Es wird beschrieben, dass zweimal ein write angeregt wird -> es wird auf 1/2/3 zweimal der Wert 2 geschrieben.
Sollte es wirklich so sein, dass der eibPC den Wert von b für das write(x,b) erst nach der Abarbeitung der folgenden Befehle ließt?

edit: Ok, getestet: es ist wirklich so. Wer denkt sich so einen *.#+&% aus?

[enertegus]

S. 217, S. 223 (S.133f ?): settime(), setdate() und settimedate() falsch beschrieben. settime() etc. schreiben nicht auf den Bus.

Die Randnotiz dient zur Erläuterung "Wie schreibe ich die Zeit auf den Bus", sodass dies leicht gefunden wird. Die Doku der Funktionen stimmt.

[saft6luck]

Die Randnotiz dient zur Erläuterung "Wie schreibe ich die Zeit auf den Bus", sodass dies leicht gefunden wird. Die Doku der Funktionen stimmt.

Ist das deine Antwort auf alle aufgeführten Verweise oder nur der für S.133f?

[enertegus]

Ist das deine Antwort auf alle aufgeführten Verweise oder nur der für S.133f?

nur 133!

[enertegus]

S.119: Am KNX Bus können mehr als 1 Telegramm pro 40ms eintreffen.

Praktisch kann das kaum (welche kann mehr?) eine Schnittstelle, aber Du hast recht, so wie's formuliert ist, stimmt es nicht. [Ich glaube die theoretische Grenze ist bei 50 Telegrammen (20ms). ]

[saft6luck]

Theoretisch sollten doch ca. 1Telegramm/10ms möglich sein (9,6kBit/s, ~10Bytes bei kurzen Telegrammen), es geht ja nicht ums Senden eines einzelnen Gerätes und empfangen können das meine Schnittstellen.

[enertegus]

Theoretisch sollten doch ca. 1Telegramm/10ms möglich sein (9600kBit, ~10Bytes bei kurzen Telegrammen), es geht ja nicht ums Senden eines einzelnen Gerätes und empfangen können das meine Schnittstellen.

Ich glaube, da ist schon ein ACK notwendig (irgendwann hatten wir es schon im Forum darüber), welches an sich schon ein paar ms braucht.

[saft6luck]

Wenn der Artikel richtig ist gilt, dass ein Telegramm inkl. Pausen und ACK max. 40ms und min. 26ms benötigt -> alle 26ms könnte ein Telegramm kommen. Das ist doch mal eine Aussage

[MarkusL]

Der Telegrammaufbau und die genauen Zeiten sind auch im Lexikonartikel Paketaufbau erklärt.

[saft6luck]

Dort sind es inkl. ACK 20ms pro Telegramm.
Fehlt da nicht die Interbyte-Pause?

[bmx]

S.122 Beispiel: "Schreiben auf den BUS"
Es wird beschrieben, dass zweimal ein write angeregt wird -> es wird auf 1/2/3 zweimal der Wert 2 geschrieben.
Sollte es wirklich so sein, dass der eibPC den Wert von b für das write(x,b) erst nach der Abarbeitung der folgenden Befehle ließt?

edit: Ok, getestet: es ist wirklich so. Wer denkt sich so einen *.#+&% aus?

Ja, das ist schon recht blöd. Ich bin dafür das Argument eine write Befehls zwischenzuspeichern an der Stelle, wo es eingesetzt wird, so daß das Argument nicht später geändert werden kann und dann etwas völlig falsches auf den Bus gerät ...

Es gäbe vielleicht die Möglichkeit, für jeden write-Befehl das Argument zu kapseln der Art

statt write('1/2/3'c14, Msg ) dann write('1/2/3'c14, convert(Msg,$$c14) )

oder write('1/2/3'u32, Msg ) dann write('1/2/3'u32, convert(Variable,0u32) )

aber ob das funktioniert weiß ich nicht.

Gruß,
Bernd