freebus.org

Salut zusammen.

Bin grad dabei, ein einfaches System mit Ein-, Ausgängen, einem FT1.2 und Original-Drossel aufzubauen.
Kommunikation über den Bus scheint zu funktionieren, hab zunächst mal mitm Oszi mitgelesen und dann nen Sniffer rangehängt. Nur Programmieren kann ich die Module nicht, da bekomme ich immer ne Fehlermeldung von der ETS.

Konkret habe ich:
- 4TE-Board (teilbestückt) mit Optokopplern, MAX232 und FT1.2 Firmware (Kommunikationstest in der ETS: "OK")
- AVR-Grundschaltung mit 8x-IN-Firmware (V1617)
- AVR-Grundschaltung mit 8x-OUT-Firmware (V1746)

Beim Programmieren der PA in eines der beiden Module erhalte ich folgende Fehlermeldung:
"Die physikalische Adresse des Geräts wurde erfolgreich programmiert, aber die abschließende Prüfung ist fehlgeschlagen. Bitte überprüfen Sie die Topologie. Sie müssen den Programmiermodus (LED) des Geräts manuell ausschalten."

Der Sniffer sagt dazu folgendes (hex):
TX: B0 11 0A 11 02 60 80 A7 - CC (T_CONNECT_REQ_PDU)
TX: B0 11 0A 11 02 61 43 00 65 - CC (T_DATA_REQ_PDU)
RX: B0 11 02 11 0A 60 C2 E5 - CC (T_DATA_ACK_PDU)
RX: B0 11 02 11 0A 63 43 40 00 12 35 - 0C (T_DATA_REQ_PDU ?)
TX: B0 11 0A 11 02 60 81 A6 - CC (T_DISCONNECT_REQ_PDU)

- 1.1.2 ist der AVR mit 8x-IN
- 1.1.10 ist der FT1.2
- Checksummen sehen gut aus

Habt ihr noch ne Idee, wo ich suchen kann - mir gehn langsam die Ideen aus...

Vielen Dank!

Grüße,
Bammboo

Die AVR Module sollten eigentlich funktionieren.
Sobald in der ganzen Mimik ( Versuchsaufbau ) ein einziger LPC beteiligt ist, funktioniert es nicht mehr und es kommt zu dieser von dir genannten Fehlermeldung.
ES LIEGT ABER NICHT AM LPC.

Es gibt wohl noch ein Problem beim ATmega. Er kommt mit dem Mischbetrieb LPC / ATmega nicht klar.

Ich hatte das gleiche Problem wie ich den WRT ( Controllerboard mit LPC ) an meine Testanlage angeschlossen habe.
Alles was vorher ging, ging dann nicht mehr.

Es lag daran weil der ATmega ( in meinem 230 V-OUT ) dran war. Sobald der aus der Testanlage war, funktionierte alles wieder und die komischen Fehlermeldungen in der ETS waren weg.

Das erklärt auch eines meiner Probleme bei der Entwicklung meiner ATMega Applikation. Ich habe genau die Konstellation die puckelmuckel beschrieben hat (Testaufbau mit WRT54GL mit LPC als FT 1.2 und den Rest als ATMega). Zum Glück habe ich in meiner Hausinstallation eine FT 1.2 über BCU2 realsiert.

Gibt es schon eine Idee woran es liegen könnte ?

Gibt es eine funktionierende FT 1.2 Firmware für ATMega168P ? Im SVN sehe ich nur eine recht alte Version für den ATMega8.

Gruß,
Michael

FT1.2 für den ATmega8 - klingt spannend, damit könnte ich das Kompatibilitätsproblem zwischen LPC und AVR ausschließen. Ist der SW-Stand funktionstüchtig und kann mir den dann evtl. jemand zukommen lassen?

Hi,

es ist toll, dass wohl nicht nur ich das Problem habe, sondern andere Personen auch.
Hab schon mit einigen gesprochen, die den AVR auch einsetzen und dort klappt er wunderbar, allerdings haben die Personen nur Originalgeräte und dem AVR im Einsatz.
Ich kann aus eigener Erfahrung bestätigen, das es mit LPC und AVR zu Problemen kommt.

Ich bin mir sicher es liegt an einem Timingproblem. Bald ist Ostern, da sind ein paar freie Tage.
Bammboo hat mir schon angeboten mit unter die Arme zu greifen, wenn sich noch mehr Leute finden, die z.B. ein Originalbusinterface und eine Möglichkeit haben das Timing zu messen, würde ich mich über jede Hilfe freuen, da ich selber kein Originalbusinterface mehr habe um hier Vergleichswerte zu haben.

Ich schlage vor wir fangen mit dem programmieren der PA an, wenn das klappt, sollte der Rest auch gehen.

_________________
Gruß
Matthias

Ein Original FT 1.2 Interface (Merten) und ein "normales" Interface (ABB) habe ich zum Testen zu Hause liegen. Über Ostern hätte ich sogar Zeit. Nur mit dem Messen des Timings sieht es derzeit nicht gut aus. Ich bin noch auf der Suche nach einem brauchbaren Ersatz für ein Digital Oszilloskop, aber bis Ostern werde ich das wohl nicht mehr schaffen.

Gibt es kurzfristig eine andere brauchbare Lösung das Timing hinreichend genau zu messen ?

Mal so ein spontaner Gedanke:
Wenn du nen Mikrocontroller rumliegen hast - du musst ja nur eine oder zwei digitale Signale mitloggen (Sampling im Timer-Interrupt); das dann über RS232 o.ä. an den Rechner... - sollte von der Geschwindigkeit reichen. Auswertung dann z.B. in Tabellenkalkulation als Diagramm

Hallo,
also ich bekomme diese Fehlermeldung auch teilweise mal angezeigt, jedoch habe ich ausschließlich LPC-Komponenten an meinem Testbus auf dem Basteltisch.
Das hat mich aber bisher nicht weiter gestört, weil nach dem manuellen Ausschalten der Programmier LED die PA korrekt vergeben war und die Module anschließend einwandfrei funktionierten.

Bei mir leider nicht... die PA scheint tatsächlich vergeben zu sein (bei der Kommunikation wird die PA angesprochen), aber das war auch leider schon alles

Ich habe heute Nachmittag mal ein wenig getestet (hatte ich auch schon im Chat geschrieben).

Ich habe jeweils versucht die physikalische Adresse aus der ETS neu zu schreiben. Angeschlossen an einem Test Bus waren dabei neben einer FT 1.2 Schnittstelle:

Test 1: Merten BCU 2.1
Test 2: Merten BCU 2.1, FreeBus LPC
Test 3: Merten BCU 2.1, FreeBus AVR
Test 4: Merten BCU 2.1, FreeBus LPC und FreeBus AVR

Solange ich eine Merten FT 1.2 Schnittstelle für das Programmieren aus der ETS benutze, geht es ohne Probleme und ich kann alle Geräte (Test 1 bis 4) ohne Fehler Programmieren.

Wenn ich jetzt ein FreeBus LPC mit FT 1.2 Software anstelle der Merten FT 1.2 Schnittstelle einsetze, dann fangen die Unterschiede an. Test 1 und 2 kann ich noch ohne Probleme wiederholen. Test 3 meldet das bekannte Problem (physikalische Adresse wurde programmiert, aber die Prüfung ist fehlgeschlagen). Bei der Programmierung des AVR im Test 4 bekomme ich die Meldung, dass mehr als ein Gerät die gleiche physikalische Adresse benutzt.

Auch die ETS Software verhält sich bei Test 3 und 4 mit FreeBUS FT 1.2 Schnittstelle teilweise merkwürdig. Sie wurde teilweise extrem langsam und reagierte nicht mehr. Neustart der ETS hat nicht geholfen -> Reboot des PCs.

Aufgrund der bekannten Probleme mit falsch kalibrierten LPC Controllern laufen meine LPCs alle mit einem externen Quarz. Damit sollte ein falsch kalibrierter LPC zumindest nicht die Ursache für Timing Probleme sein.

Zum Teil habe ich die Busdaten im Rohformat mit einer Auflösung von 13µs (ziemlich genau 8 samples pro bit) über einen weiteren AVR als Log-Dateien aufgezeichnet. Mal sehen, ob sich daraus noch weitere Erkenntnisse ergeben. Die Auswertung wird allerdings etwas Zeit in Anspruch nehmen, da ich erstmal ein wenig Software dafür brauche.

Gibt es an der Stelle schon was Neues?
Es klingt ja so, als ob die LPC FT1.2 Schnittstelle einen dicken Bug hätte. Wie kann ich dann am einfachsten meine Atmel Komponenten im EIB programmieren?

Mode

Hast du die neuen Hexfiles in den AVR Kontrollern?

_________________
Gruß
Matthias

Ich hab noch überhaupt keine EIB Komponenten.

Ich würde am liebsten alles auf ATMega Basis bauen. Nur weiss ich nicht, wie ich dann meine Applikationen mit der ETS in die Hardware bekommen, da ich kein FT1.2 Interface besitze, und mit der LPC Version soll es ja Probleme geben. Und ich möchte mir ungerne die ganzen Sachen kaufen / aufbauen und kann sie dann nicht nutzen weil ich sie nicht mit der ETS erreichen kann. Daher meine Frage.

es gibt viele Möglichkeiten sich so einen Zugang zu besorgen, ein paar:
Du ersteigerst dir ein Interface auf ebay.
Du kaufst dir ein IP Interface von Siemens (hab ich gemacht, kostet 180EUR heisst 5WG1 148-AB22).
Du besorgst dir eine BCU2 und schliesst die mit einem Pegelwandler an deinem Rechner an.
Du versuchst es mit dem LPC Interface.

Was du machst, liegt daran wieviel Geld du ausgeben willst/kannst.

_________________
Gruß
Matthias