Ankündigung

**mkoegler** · 15.01.2010, 23:08

Zitat von avajon Beitrag anzeigen

hSo, nach ein wenig googlen kam ich zu bcuaddrtab -w 0 ft12:/dev/ttyS0. Doch da bekomme ich nur "write failed" bzw. ohne dem -w 0 bekomme ich "read failed". Hin und wieder reagiert es aber gar nicht und ich muss es mit Strg-C beenden. Meine Frage nun: kann es sein dass die Schnittstelle damals keine eigene physikalische Adresse bekommen hat und es deswegen nicht funktioniert? Wie kann ich herausfinden ob die Schnittstelle eine Adresse hat? Oder hat jemand eine andere Idee die ich mal versuchen kann?

Einige Default-Applikationen für Interfaces (ich glaube von Gira war es damals) verhindern das Schreiben des Wertes. Es müßte in den bcusdk-list Archiv 1-2 solcher Fälle dokumentiert sein. Lösung ware damals ein Master Reset der BCU 2, um das Programm los zu werden.

**avajon** · 16.01.2010, 17:28

danke fuer die antwort. Ich habe eine Berker Schnittstelle. Ich werde mal in der bcusdk - liste suchen. Diesen Master Reset kann ich in der ets durchfuehren? Sonst hat so ein Reset ja keine Auswirkungen oder?

danke
avajon

**mkoegler** · 16.01.2010, 19:52

Zitat von avajon Beitrag anzeigen

Ich habe eine Berker Schnittstelle. Ich werde mal in der bcusdk - liste suchen. Diesen Master Reset kann ich in der ets durchfuehren? Sonst hat so ein Reset ja keine Auswirkungen oder?

Reset löscht die gesamte Programmierung der Schnittstelle. Individuelle Addresse muss man danach erneut zuweisen (sie wird auf 15.15.255 zurücksetzt).

Er geht ohne ETS mit einen Stück Draht. Wenn man Zugriff aufs PEI der BCU hat:

Connect pins 5 and 6 of the PEI. Then turn off the bus power (or disconnect the BCU from the bus). Keep the programming button pressed and restore the power.

PIN 5+6 liegen übereinander auf einer Seite auf den 2x5 Anschluss. Auf der andere Seite sind 1+10 0V, so das nichts passieren kann, wenn man die falsche Seite erwischt.

Das Funktioniert bei Schnittstellen, die aus einer BCU 2 mit daraufgesteckten einen Applikationsmodul für FT1.2 besteht.

**avajon** · 17.01.2010, 12:39

Zitat von mkoegler Beitrag anzeigen

Reset löscht die gesamte Programmierung der Schnittstelle. Individuelle Addresse muss man danach erneut zuweisen (sie wird auf 15.15.255 zurücksetzt).

Ich weiß das klingt jetzt blöd, aber danach muss ich mit einer zweiten Schnittstelle (die ich natürlich nicht habe) meine Schnittstelle wieder programmieren, oder?

Zitat von mkoegler Beitrag anzeigen

Er geht ohne ETS mit einen Stück Draht. Wenn man Zugriff aufs PEI der BCU hat:
PIN 5+6 liegen übereinander auf einer Seite auf den 2x5 Anschluss. Auf der andere Seite sind 1+10 0V, so das nichts passieren kann, wenn man die falsche Seite erwischt.

Das Funktioniert bei Schnittstellen, die aus einer BCU 2 mit daraufgesteckten einen Applikationsmodul für FT1.2 besteht.

Wenn ich dich richtig verstehe muss ich die Schnittstelle vom Busankoppler nehmen und dann die besagten Pins "kurzschließen"?

Vielleicht zur Info was ich vorhabe: Ich verwende zu Hause LinuxMCE (Welcome to LinuxMCE). Da gibt es derzeit zwei Implementierungen für das EIB. Die "alte" Version funktioniert nur per serieller Schnittstelle und kann nur senden. Die "neuere" Version funktioniert mit eibd und kann ebenfalls nur senden. Diese Version möchte ich nun erweitern, damit auch Telegramme empfangen werden können. Mein Problem ist aber hier, dass ich ja nicht mal mit den Tools von bcusdk die Telegramme lesen kann.
Die ets3f habe ich - aber mir fehlt halt teilweise das Wissen, da ich eher aus der Java-Software-Ecke komme und mit "Hardware" bzw. C++ nichts am Hut habe.

Vielen Dank für die Hilfe und Geduld!
avajon

**avajon** · 17.01.2010, 12:49

ach ja, vielleicht helfen die Log-Ausgaben von bcuaddrtab:

Code:

dcerouter_1001968:~#  bcuaddrtab -t1023 ft12:/dev/ttyS0
Layer 1(0942B668,4B52F8EF) Open
Layer 1(0942B668,4B52F8EF) Opened
Layer 1(0942B668,4B52F8EF) SendReset
Layer 1(0942B668,4B52F8EF) Send(007): A9 00 12 34 56 78 0A
Layer 0(0942B668,4B52F8EF) Send(004): 10 40 40 16
Layer 1(0942B668,4B52F8EF) Send(006): 43 00 00 00 00 00
Layer 0(0942B668,4B52F8EF) Recv(001): E5
Layer 0(0942B668,4B52F8EF) Send(014): 68 08 08 68 73 A9 00 12 34 56 78 0A 3A 16
Layer 0(0942B668,4B52F8EF) Recv(001): E5
Layer 0(0942B668,4B52F8EF) Send(013): 68 07 07 68 53 43 00 00 00 00 00 96 16
Layer 0(0942B668,4B52F8EF) Recv(001): E5
Layer 0(0942B668,4B52F8EF) Recv(008): 68 07 07 68 F3 86 00 00
Layer 0(0942B668,4B52F8EF) Recv(005): 00 00 00 79 16
Layer 0(0942B668,4B52F8EF) Send Ack(001): E5
Layer 1(0942B668,4B52F8EF) Recv(006): 86 00 00 00 00 00
Layer 1(0942B668,4B52F8EF) Send(011): 41 00 00 00 00 00 03 02 01 01 16
Layer 0(0942B668,4B52F8EF) Send(018): 68 0C 0C 68 73 41 00 00 00 00 00 03 02 01 01 16 D1 16
Layer 0(0942B668,4B52F8EF) Recv(001): E5
Layer 0(0942B668,4B52F8EF) Recv(008): 68 0C 0C 68 D3 8E 00 00
Layer 0(0942B668,4B52F8EF) Recv(008): 00 00 00 03 02 01 01 16
Layer 0(0942B668,4B52F8EF) Recv(008): 68 0C 0C 68 D3 8E 00 00
Layer 0(0942B668,4B52F8EF) Recv(008): 00 00 00 03 02 01 01 16
Layer 0(0942B668,4B52F8EF) Recv(002): 7E 16
Layer 0(0942B668,4B52F8EF) Recv(008): 68 0C 0C 68 D3 8E 00 00
Layer 0(0942B668,4B52F8EF) Recv(008): 00 00 00 03 02 01 01 16
Layer 0(0942B668,4B52F8EF) Recv(008): 7E 16 68 0C 0C 68 D3 8E
Layer 0(0942B668,4B52F8EF) Send Ack(001): E5
Layer 1(0942B668,4B52F8EF) Recv(011): 8E 00 00 00 00 00 03 02 01 01 16
Layer 0(0942B668,4B52F8EF) Recv(005): 00 00 00 00 00
Layer 0(0942B668,4B52F8EF) Recv(008): 68 0C 0C 68 D3 89 00 00
Layer 0(0942B668,4B52F8EF) Recv(008): 00 00 00 03 02 40 01 16
Layer 0(0942B668,4B52F8EF) Recv(002): B8 16
Layer 0(0942B668,4B52F8EF) Recv(008): 68 0C 0C 68 D3 89 00 00
Layer 0(0942B668,4B52F8EF) Recv(008): 00 00 00 03 02 40 01 16
Layer 0(0942B668,4B52F8EF) Recv(008): B8 16 68 0C 0C 68 D3 89
Layer 0(0942B668,4B52F8EF) Send Ack(001): E5
Layer 0(0942B668,4B52F8EF) Sequence jump
Layer 1(0942B668,4B52F8EF) Recv(011): 89 00 00 00 00 00 03 02 40 01 16
read failed
dcerouter_1001968:~#  bcuaddrtab -t1023 ft12:/dev/ttyS0
Layer 1(09677668,4B52F8F4) Open
Layer 1(09677668,4B52F8F4) Opened
Layer 1(09677668,4B52F8F4) SendReset
Layer 1(09677668,4B52F8F4) Send(007): A9 00 12 34 56 78 0A
Layer 0(09677668,4B52F8F4) Send(004): 10 40 40 16
Layer 1(09677668,4B52F8F4) Send(006): 43 00 00 00 00 00
Layer 0(09677668,4B52F8F4) Recv(001): E5
Layer 0(09677668,4B52F8F4) Send(014): 68 08 08 68 73 A9 00 12 34 56 78 0A 3A 16
Layer 0(09677668,4B52F8F4) Send(014): 68 08 08 68 73 A9 00 12 34 56 78 0A 3A 16
Layer 0(09677668,4B52F8F4) Recv(001): E5
Layer 0(09677668,4B52F8F4) Send(013): 68 07 07 68 53 43 00 00 00 00 00 96 16
Layer 0(09677668,4B52F8F4) Recv(001): E5
<

hier "hängt" es und lässt sich nur mehr mit Strg-C beenden.

avajon.

**mkoegler** · 17.01.2010, 17:41

Zitat von avajon Beitrag anzeigen

Ich weiß das klingt jetzt blöd, aber danach muss ich mit einer zweiten Schnittstelle (die ich natürlich nicht habe) meine Schnittstelle wieder programmieren, oder?

Über die ETS, nein (aber nur physikalischer Addresse programmieren - kein Applikationsprogramm). Addresszuweisung über den EIBD, ja.

Zitat von avajon Beitrag anzeigen

Wenn ich dich richtig verstehe muss ich die Schnittstelle vom Busankoppler nehmen und dann die besagten Pins "kurzschließen"?

Ja (wenns so eine BCU mit PEI ist). Mangels Typenbezeichnung (oder auch Foto von der Schnittstelle) kann ich nicht unterscheiden, was es für eine Typ von Schnittstelle ist.

Danke für die Traces. Mich würde interessieren, was auf welcher Hardware die Traces erzeugt wurden. Es scheinen Bytes auf der seriellen Schnittstelle verloren zu gehen.

Mach bitte einmal ein "cat /proc/tty/driver/serial" (als root).
Gibt es "oe:", "fe:" "brk:", oder "pe:" Eintrage für die tty Schnittstelle?

Alternativ: Gibt es noch andere Programme, die auf die Schnittstelle parallel zugreifen?

Die Traces zeigen aber auch, das der Zugriff auf die Speicherfelder vom aktuellen Applikations-Programm in der BCU nicht erlaubt wird.

Zitat von avajon Beitrag anzeigen

Vielleicht zur Info was ich vorhabe: Ich verwende zu Hause LinuxMCE (Welcome to LinuxMCE). Da gibt es derzeit zwei Implementierungen für das EIB. Die "alte" Version funktioniert nur per serieller Schnittstelle und kann nur senden. Die "neuere" Version funktioniert mit eibd und kann ebenfalls nur senden. Diese Version möchte ich nun erweitern, damit auch Telegramme empfangen werden können. Mein Problem ist aber hier, dass ich ja nicht mal mit den Tools von bcusdk die Telegramme lesen kann.

Als eibd Schnittstelle für deine Zwecke wären GroupSockets (vgl groupsocketlisten) bzw. der GroupCache (groupcachereadsync) geeignet. In welcher Sprache wird die EIBD Client Library gebraucht?

**avajon** · 17.01.2010, 17:57

also die Schnittstelle ist von Berker, hier der Link: Berker: Katalog

Der Befehl "cat /proc/tty/driver/serial" ergab folgenden Output:

Code:

dcerouter_1001968:/usr/pluto/bin# cat /proc/tty/driver/serial
serinfo:1.0 driver revision:
0: uart:16550A port:000003F8 irq:4 tx:2238 rx:37612 RTS|DTR
1: uart:unknown port:000002F8 irq:3
2: uart:unknown port:000003E8 irq:4
3: uart:unknown port:000002E8 irq:3

Du hattest Recht, anscheinend ist die alte Version parallel gelaufen; hab nun alle Prozesse gekillt und funktioniert leider trotzdem nicht: hier nochmal der Aufruf von bcuaddrtab:

Code:

dcerouter_1001968:/usr/pluto/bin# bcuaddrtab -t1023 ft12:/dev/ttyS0
Layer 1(09E71668,4B5340E3) Open
Layer 1(09E71668,4B5340E3) Opened
Layer 1(09E71668,4B5340E3) SendReset
Layer 1(09E71668,4B5340E3) Send(007): A9 00 12 34 56 78 0A
Layer 0(09E71668,4B5340E3) Send(004): 10 40 40 16
Layer 1(09E71668,4B5340E3) Send(006): 43 00 00 00 00 00
Layer 0(09E71668,4B5340E3) Recv(001): E5
Layer 0(09E71668,4B5340E3) Send(014): 68 08 08 68 73 A9 00 12 34 56 78 0A 3A 16
Layer 0(09E71668,4B5340E3) Recv(001): E5
Layer 0(09E71668,4B5340E3) Send(013): 68 07 07 68 53 43 00 00 00 00 00 96 16
Layer 0(09E71668,4B5340E3) Recv(001): E5
Layer 0(09E71668,4B5340E3) Recv(008): 68 07 07 68 F3 86 00 00
Layer 0(09E71668,4B5340E3) Recv(005): 00 00 00 79 16
Layer 0(09E71668,4B5340E3) Send Ack(001): E5
Layer 1(09E71668,4B5340E3) Recv(006): 86 00 00 00 00 00
Layer 1(09E71668,4B5340E3) Send(011): 41 00 00 00 00 00 03 02 01 01 16
Layer 0(09E71668,4B5340E3) Send(018): 68 0C 0C 68 73 41 00 00 00 00 00 03 02 01 01 16 D1 16
Layer 0(09E71668,4B5340E3) Recv(001): E5
Layer 0(09E71668,4B5340E3) Recv(008): 68 0C 0C 68 D3 8E 00 00
Layer 0(09E71668,4B5340E3) Recv(008): 00 00 00 03 02 01 01 16
Layer 0(09E71668,4B5340E3) Recv(002): 7E 16
Layer 0(09E71668,4B5340E3) Send Ack(001): E5
Layer 1(09E71668,4B5340E3) Recv(011): 8E 00 00 00 00 00 03 02 01 01 16
Layer 0(09E71668,4B5340E3) Recv(008): 68 0C 0C 68 F3 89 00 00
Layer 0(09E71668,4B5340E3) Recv(008): 00 00 00 03 02 40 01 16
Layer 0(09E71668,4B5340E3) Recv(002): D8 16
Layer 0(09E71668,4B5340E3) Send Ack(001): E5
Layer 1(09E71668,4B5340E3) Recv(011): 89 00 00 00 00 00 03 02 40 01 16
read failed

Da mich das ganze nun langsam zum verzweifeln bringt: macht es sinn eine andere Schnittstelle (USB oder IP) zu kaufen? Wenn ja, welche wäre denn für eibd am Besten?

**mkoegler** · 17.01.2010, 19:39

Zitat von avajon Beitrag anzeigen

also die Schnittstelle ist von Berker, hier der Link: Berker: Katalog

Da mich das ganze nun langsam zum verzweifeln bringt: macht es sinn eine andere Schnittstelle (USB oder IP) zu kaufen? Wenn ja, welche wäre denn für eibd am Besten?

Du hast also eine Schnittstelle aus BCU + Applikationsmodul.

Mach den Master-Reset der BCU wie oben beschrieben (PIN 5+6 kurzschliessen, bcu stromlos machen, Programmiertaster gedrückt halten und Stromversorung von BCU wiederherstellen) und bcuaddrtab sollte gehen.

Vgl Seite 3 von http://www.dehof.de/eib/pdfs/BIM_Schaltplan.pdf für die Lage der PINs am PEI Interface.

Zur Frage einer neuen Schnittstelle: Es besteht im Moment kein Anlass für eine neue Schnittstelle. Mit einen Stück Draht und ein paar Handgriffen solllte das Problem in 5 Minuten lösbar sein.

Wenn du trotzdem eine andere Schnittstelle willst:
* Persönlich mag ich den TPUART am liebsten, da er die flexibelste Schnittstelle ist. Achtung: die ETS kann nur über den EIBD als KNXnet/IP Server darauf zugreifen. Je nach Preis, gibt es verschiedenste Lösungen (zB Siemens BTM + Pegelwandler wie RS232-SPW FM ~40 € exkl. Versand). Für Praxisfragen würde ich mich an makki hier im Forum wenden.
* IP gibt es als Inteface (billiger, nur Tunneling) und als Router (Routing+Tunneling). Als Anwender kommt man nur mit Tunneling durch (notfalls kann der EIBD als Umsetzer auf Routing verwendet werden). Routing ist eher zum Verbindung von KNX Installationen über IP interessant.
* Ein USB Interface entspricht vom Verhalten/Features her einen seriellen Interface, nur eben mit anderen Anschluss.

Von den Fehlerzenarien her, ist USB etwas schlechter als die beiden anderen.

**avajon** · 17.01.2010, 19:55

vielen Dank!! Ich werde es morgen mal mit dem Kurzschließen probieren.

Ich bin da immer etwas vorsichtig da ich nichts ruinieren möchte

**avajon** · 18.01.2010, 09:51

JUHUUUU! Es funktioniert! Jetzt kann ich auch über die ets den Busverkehr lesen.

Nochmals vielen, vielen DANK! Die Lösung mit dem kurzschließen hats gebracht; hatte zwar anfangs etwas angst (immerhin mag ich nix kurzschließen, denn da sitz ich dann meistens im dunkeln

) aber es hat wunderbar funktioniert. Nochmals vielen Dank Martin!

**martin.neu** · 24.02.2010, 21:25

@mkoegler

Deine Frage "Mach bitte einmal ein "cat /proc/tty/driver/serial" (als root).
Gibt es "oe:", "fe:" "brk:", oder "pe:" Eintrage für die tty Schnittstelle?"

interessiert mich, ich habe nämlich folgenden Output:

root@OpenWrt:~# cat /proc/tty/driver/serial
serinfo:1.0 driver:5.05c revision:2001-07-08
0: uart:16550A port:B8000300 irq:3 baud:19230 tx:3697 rx:0 RTS|CTS|DTR|DSR|CD
1: uart:16550A port:B8000400 irq:3 baud:19230 tx:159582 rx:9830 fe:47 pe:1837 RTS|CTS|DTR|DSR|CD

und die Kommunikation dauert oft sehr lange, bis ein Befehl ausgeführt wird.

Hast du evt. eine Idee?

mfg
Martin

**mkoegler** · 24.02.2010, 22:07

Zitat von martin.neu Beitrag anzeigen

root@OpenWrt:~# cat /proc/tty/driver/serial
serinfo:1.0 driver:5.05c revision:2001-07-08
0: uart:16550A port:B8000300 irq:3 baud:19230 tx:3697 rx:0 RTS|CTS|DTR|DSR|CD
1: uart:16550A port:B8000400 irq:3 baud:19230 tx:159582 rx:9830 fe:47 pe:1837 RTS|CTS|DTR|DSR|CD

Man kann sagen, das es mit /dev/ttyS1 ein Problem gibt, sonst würden dort nicht parity errors & Co auftreten.

**martin.neu** · 25.02.2010, 04:54

Irgend eine Ahnung, an was das liegen könnte?

frühe Grüße
Martin

**mkoegler** · 25.02.2010, 07:27

Zitat von martin.neu Beitrag anzeigen

Irgend eine Ahnung, an was das liegen könnte?

Die Port-Nummer sieht mir nicht nach einer x86 Plattform aus. Da fehlt mir die Erfahrung.

Wenn ich den Fehler eingrenzen müßte, würde ich /dev/ttyS1 durchtesten.
Also Verbindung mit einen PC, auf beiden Systemen eine Terminal-Emulation laufen lassen und viele sehr Daten austauschen. Über die Statistik der seriellen Schnittstelle kann man dann nachverfolgen, ob weitere Fehler auftauchen bzw. bei schon vorhanden Fehlern deren Zahl weiter steigt.

Ankündigung

Problem mit eibd/bcuaddrtab

Problem mit eibd/bcuaddrtab

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar