Ft2232: I2C-Bus am PC

[KlaRaw]

Hallo,
FDTI liefert den ft2232 und stellt in einen Projekt eine I2C-Schnittstelle bereit. Man beschreibt und liest einen 24C64. Das Protokoll ist hier schon recht anspruchsvoll.

Ich habe zum Testen einen einfachen Portbaustein, einen PCF8574, genommen und sende in einer Schleife Bytes von 0 - 255. Um es etwas zu erschweren habe ich 40m Leitung dazwischen geschaltet.

Das Schreiben geht wirklich gut. Ich kann bis auf 130 KHz hochgehen.

Wenn ich den Portbaustein auslesen will, so werden alle Ports auf HIGH gesetzt! Das Read liefert zwar dann ordnungsgemäss 255, damit kann man aber leider absolut nicht leben!!

Es ist eigentlich sehr schade. Fehler meinerseits kann ich guten Gewissens ausschliessen. Kann mir jemand dies verhalten bestätigen , gibt es eine Lösung oder habe ich doch etwas übersehen?

Gruss KLaus.

[linux_80]

Hi,

welches Kabel ist 40m ? Vom I2C ?
Dann ist das nicht im Sinne des Erfinders. Ist ja fast glück, das es dann so gut geht wie Du schreibst.

Beim 8574 ist es halt so, das man vor dem lesen die Ports alle auf High macht, um sie anschliessend zu lesen !
Was gefällt Dir da nicht ?

[KlaRaw]

Hallo,
in meinem Test - Aufbau habe ich vom Ausgang des I2C - Interface zur Platine mit dem PCF8574 eine längere Leitung dazwischengeschaltet. Es ist ein Kabelring, 8 Adern mit ca. 0,4 mm Litze. Mich hat es selber überrascht dass ich hier 40m mit 130 KHz schaffe. Aber ein Check mit den Oszi zeigte mir dass die Flanken noch recht steil waren. D.h., ich werde bei kürzeren Leitungen vielleicht die Grenze von 400 KHz erreichen können.

Aber dies ist nicht meine Absicht. Mir genügen langsamere Übertragungsraten. Der Flaschenhals liegt bei mir wo anders. Es kommt mir nur darauf an zu wissen wo die Grenzen der Zuverlässigkeit sind.

>> Beim 8574 ist es halt so, das man vor dem lesen die Ports alle auf High macht, um sie anschliessend zu lesen !

Ich musste hier tatsächlich noch einmal genau nachlesen. Was Du da sagst stimmt auch, ist aber nicht die ganze Wahrheit.

Es gibt eigentlich zwei Gründe die Ports auszulesen.

Zum einen führt man von einer externen Quelle ein Signal an den Port heran. Dies kann HIGH oder LOW sein. Hier muss man natürlich zuvor den Port selber auf HIGH gesetzt haben, sonst würde er im LOW - Zustand den zugeführten HIGH - Pegel herunterziehen.

In meinem Fall scheibe ich Werte von 0 - 255 und lese sie im zweiten Schritt wieder aus. Hiermit wird nicht nur die WRITE - Funktion getestet, sondern es wird geprüft ob wirklich im Baustein das Byte gesetzt ist. Erst der Zyklus Schreiben/Lesen gibt mir hier Sicherheit.

In der Praxis ist es bei mir wirklich so, dass ich in einigen Fällen mir zuvor die Portwerte erst auslese und dann bei Bedarf neu setze.

Vergewissert habe ich mich bei Burkhard Kaninka, Messen-Steuern-Regeln mit den C-Control/Basic-System Seite 164. Dies war vor ein paar Jahren meine Einstiegslektüre.

--------

Heute bin ich beim DLP2232, bzw. FT2232 von FDTI.
Die PC - I2C Schnittstellen mittles serieller Schnittstelle sind leider alle etwas langsam (20 - 50 Bytes/s). Ausserdem will ich auf USB umsteigen.
Selbst im asynchronen Bit Bang Mode mit einem FT232BM stösst man auf Grenzen. Die Ausführung eines Befehls dauert immer mindestens 2ms. Sicher, man kann hier wenn man nur Schreiben will alles in den Buffer laden und dann in einem Rutsch versenden. aber beim Lesen muss man die Clock - Signale ja erzeugen. D.h. WRITE-WRITE-READ, usw. Schlimmer sind hier vermutlich sogar die uneinheitlichen Impulslängen, so dass es hier unterhalb von 1200 Bit/s und oberhalb von 9600 Bit/s zu Störungen kommt.

Vielleicht verstehst Du mich jetzt besser dass ich mich beim FT2232 mit 130 KHz am Ziel meiner Wünsche sah.

Leider löscht der I2C-Treiber von FDTI mit dem I2C_READ alle Portwerte beim PCF8574.

Eine Anfrage beim FDTI -Support brachte mich bislang auch nicht weiter. Ich habe mich vermutlich nicht genau genug ausgedrückt. Hier die Antwort:

>>It is a common complaint that the MPSSE engine produces a slow I2C implementation.

>>The device itself is expecting data packets of 64 bytes or else it waits for the latency timer to trigger the transfer of a small packet.

>>The default latency is 16ms which should correspond to the delay you are observing.

>>Small packets are transferred as a result of waiting for the ACK bit. Ignoring this bit is the only significant speed up you will be able to achieve.

Ich würde sagen, Thema verfehlt. Ich werde mein Problem noch einmal besser formulieren.

--------

Hat jemat mir dem FT2232 oder dem neuen FT232R den Bit Bang Mode im synchronen Mode getestet? Die Dokumentation ist hier sehr sparsam. Einen Beispielcode habe ich noch nicht gefunden. Das einzige was zu finden ist ist eine Stelle unter den Application Notes.

· Pins start at 0xFF
· Send 0x55, 0xAA
· Pins go to 0x55 and then to 0xAA
· Data read = 0xFF, 0x55
· Pins start at 0xFF
· Send 0x55, 0xAA, 0xAA (repeat the last byte sent)
· Pins go to 0x55 and then to 0xAA
· Data read = 0xFF, 0x55, 0xAA


Schreiben kann ich ja mit FT_WRITE. Wie erhalte ich jedoch die eingelesenen Werte? Mit FT_READ hat dies noch nicht so funktioniert.
Und über FT_GetBitMode lese ich nur den letzten, aktuellen Portwert, als nur einen. Im oben aufgeführten Beispiel müsste ich mit dem letzten READ 3 Werte einlesen können.

Wer kennt sich mit dem "Synchronous Bit Bang Mode" unter dem FT2232 oder FT232R aus?

Gruss Klaus.