mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Probleme mit FT245 Bit Bang Modus


Autor: Thomas (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich benutze zur Zeit den FT245 und möchte via BitBangModus ein 
Kommunikationsinterface mit 3 Datenleitungen (Enable,Clock,Data) 
nachbilden. Dazu benutze ich Labview und den von FTDIchip angebotenen 
FTD2XX.dll Treiber für Labview.

Bitbangmodus: Synchronous Bit Bang
Baudrate = 625 Symbole/sec

Zunächst habe ich versucht dem FT_Write jeweils ein Byte für den 
aktuellen Zustand zu übergeben dann eine Warteschleife zu nutzen, 
nächstes Byte schreiben, warten ... . Damit klappt prinzipiell, nur ist 
es ,wie hier im Forum schon angesprochen wurde, nicht besonders schnell. 
Bei einem Delay von 10ms schwankt allerdings die Bitdauer zwischen ca 
7ms und 13ms. Die erste Frage: Kann man das besser hinkriegen? Oder bin 
ich hier aufgrund des Betriebssystems Windows schon am Limit.

Schneller geht das ganze wenn ich FT_Write ein Bytearray übergebe. Für 
die oben genannte Baudrate ergibt sich eine Bitdauer von 
1sec/(625*16)=100µs Auch das klappt siehe erstes Bild im Anhang.
Die übergebenden Byte sind, siehe Bild:
100
000
011
000
011
000
011
000
100

Führe ich aber das Programm ein zweites, drittes, x-tes Mal aus ist die 
Bitstruktur nicht mehr wie gewollt, siehe das Bild im nächsten Post. 
Dort zu erkennen ist, dass die ersten Byte noch richtig (lila Marker 
delta = 100µs) erscheinen, dann aber eine längere Pause auftritt und 
auch die weiteren Byte eine höhere Dauer aufweisen. Das ganze ist nur 
ein Beispielbild, kann auch anders aussehen oder besser jedesmal ein 
bischen anders :).
Weiss jemand woran das liegen kann bzw. wie ich das behebe?

Autor: Thomas (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
das zweite Bild mit "fehlerhafter" Übertragung.

Autor: Thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hinweis: zu im ersten Post angegebenen Byte im Vergleich zum ersten 
Bild.
Habe die Werte von oben nach unten gezählt also 011 während der 
Logicanalyzer die Bitwerte von unten nach oben angibt (110).

Noch ein Nachtrag zum Programmablauf: Das Programm für das Bytearray 
macht im Prinzip nur folgendes:
Open Device
Reset Device
Set Baudrate
Purge RX/TX
Set Write/Read-Timout (3sec)
Set Bitmode and Bitmask (alles Ausgänge)
20ms warten
FT_Write(Bytearray)
Close Device

Autor: Thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Keiner eine Idee? falsches Unterforum gewählt? Zu kompliziert 
beschrieben? Fehlen nötige Informationen? Zu ungeduldig =)?

Am 64 Byte Limit für ein Datenpaket sollte es ja nicht liegen, da ich 
momentan weniger Bytes sende oder? Wird etwas auf dem FT245 
zwischengespeichert, so dass ich hier erst löschen müsste?

Autor: Thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ein letzter bumb

Wo sind die FTDI Experten geblieben? Hat keiner einen Rat, oder eine 
Idee was ich anders machen könnte?

Autor: peterguy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Thomas,

ich verwende zwar den gleichen FT245 Baustein und nutze PC-seitig auch 
LabVIEW + FTDI-Treiber, aber ich nutze den Chip asynchron. Kann dir also 
leider nicht konkret weiterhelfen.

Vielleicht kannst du einmal beschreiben, was du auf embedded Seite mit 
dem Chip anstellen möchtest, bzw was deine Anwendung ist.

Kannst Du auch mal deinen LabVIEW Code hier reinstellen, eventuell liegt 
dort ja bereits der Hund begraben.

Viele Grüße,
Peter

Autor: B e r n d W. (smiley46)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei einer syncronen Übertragung ist es doch erst mal egal, wenn der 
FT245 eine Pause einlegt, soweit diese nicht zu lange dauert und Du noch 
den angestrebten Datendurchsatz erreichst.

Der FT245 macht erst mal seinen Job, bis er seinen Buffer gesendet hat. 
Dann wartet der Computer, bis der nächste USB Frame bei der nächsten 
vollen Millisekunde erreicht ist. Möglicherweise wird auch 
Rechenleistung anderswo verbraten.

Versuch mal rauszufinden, ob von Lücke zu Lücke ungefähr volle ms 
vergehen.

Gruß, Bernd

Autor: Thomas (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
So hier im Anhang ein Bild für mehr Übersicht (1000*800Pixel, 68KB, 
PNG-Format).
- Unter "zu realisieren" sollte man erkennen, was ich eigentlich machen 
will, d.h. Enable während der Transmission auf LOW-Pegel, 
"Clock-Bitdauer" entspricht der doppelten Zeit eines Datenbits. Die 
Bitdauer sollte eben einigermaßen konstant sein, ob jetzt 10ms, 1ms, 
100µs, 10µs ist mir momentan noch egal. Schneller ist natürlich besser. 
Die Daten werden von einem Chip gespeichert, bzw. ein Chip wird mit den 
Daten konfiguriert.

Zu Testzwecken hab ich um die Kommunikation erstmal zu testen (USB ist 
für mich noch Neuland) daher ein Labview-Programm geschrieben (wird im 
nächsten Post verlinkt) wovon ich erwartet hätte, dass es die 
gezeichnete Bitfolge nach "momentanes Beispiel" produziert. D.h. alle 
100µs werden die FT245 Portdaten aktualisiert. (Entspricht auch dem im 
ersten Post verlinkten Bild, ab und zu scheints ja zu gehen, zuverlässig 
aber momentan noch nicht).

Desweitern im Bild sind Testmessungen sowohl für die Option synchrones 
Bit Bang als auch asynchron. Ich hab in die Messkurven die Delays mit 
CorelDraw eingezeichnet, alle roten Beschriftungen passen nicht bzw. 
sind zu lange. Besonders im Fall synchrones Bit Bang - Run 2 kann man 
die 1ms Dauer erkennen (gelb nochmal verdeutlicht). D.h. ich nehme an 
meine Daten werden "zufällig" auf verschiedene Pakete aufgeteilt und vor 
dem Eintreffen eines neuen wird der alte Wert natürlich gehalten. Ich 
dachte ein Paket wären 64 Byte bzw. bei Abzug der zwei vom FTDI Chip 
selbst genutzten 2 Byte effektiv 62 Byte. Ich sende aber in diesem 
Beispiel ja nur 10 Byte. Sofern man nur die dem FT_Write_Byte_Data.vi 
übergebenen Daten summiert. Sofern die Einstellungen auch zu den 64 Byte 
zählen, kann ich das momentan nicht genau sagen.

Nachdem ich jedenfalls von euch den Hinweis auf die 1ms Dauer bekommen 
habe und diese im Beispiel auch zum Teil erkenne bzw. mit 10*100µs ja 
1ms erreiche habe ich probiert statt der 625 Baud eben 6250 Baud für 
10µs zu nehmen, hier ist die Gesamtdauer der Abarbeitung zwar kürzer als 
1ms aber dennoch wird das ein oder andere bit gestreckt.

Auch weil peterguy asynchrones und synchrones Bit Bang erwähnt, hier bin 
ich mir ehrlich gesagt nicht sicher welchen Modus ich brauche.
In der Application Note: Bit Bang Modes for the FT232R and FT245R 
http://ftdichip.com/Documents/AppNotes/AN232R-01_F... 
wird anschaue ist der relevante Satz zur Unterscheidung für
- Asynchrones Bit Bang: Any data written to the device in the normal 
manner will be self-clocked onto the data pins which have been 
configured as outputs. The rate that the data is
clocked out at is controlled by the Baud rate generator.
- Synchrones Bit Bang:
-- data is only read from the device when the device is written to
-- With Synchronous Bit Bang mode, data will only be sent out if there 
is space in the device for data to be read from the pins. This 
Synchronous Bit Bang mode will read the data bus pins first, before it 
sends out the byte that has just been transmitted. It is therefore 1 
byte behind the output and so to read the inputs for the byte that you 
have just sent, another byte must be sent.
Zunächst möchte ich nur schreiben, später sollte mir das gelingen 
zusätzlich lesen, d.h. hier würden während des Enable Abschnitts nach 
ein paar Ansteuerdaten die geforderten Daten vom Chip ausgegeben. Denke 
deshalb, dass der synchrone Modus der richtige wäre. Berichtigt mich 
falls ich falsch liege. Momentan würds mir aber reichen einfach nur zu 
schreiben, zur Not lese ich eben nix aus.

Autor: Thomas (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Im Anhang das LabVIEW USB-BitBang Testprogramm, nix großes. Wollte wie 
gesagt erstmal testen ob es funktioniert. (Was es ja leider nicht tut)
W:\ProjektDateien\USB-Programmierung\USB-Upload\FT245_BitBang_FTWrite.vi

Für das Programm braucht man:
- die FTDI D2XX LabVIEW Function Library: 
http://ftdichip.com/Projects/CodeExamples/LabVIEW/...
- die FTDI-Treiber: http://ftdichip.com/Drivers/D2XX.htm

Autor: Thomas (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
So hier noch für alle die evtl. kein LabVIEW besitzen oder es nicht 
ausführen wollen der Screenshot des Programms.

Autor: Thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
bump

Anfängerfehler im Programm? Wichtige Abfrage vergessen?
Oder ist das was ich erreichen will mit Bit Bang mode eher schlecht als 
recht zu realisieren?

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Oder ist das was ich erreichen will mit Bit Bang mode eher schlecht als
>recht zu realisieren?

Was willst du eigentlich realisieren?
Die Signale werden per Bitbang schon
passend zueinander übertragen. Allerdings
mit mehr oder weniger Pausen dazwischen.
So ist USB nun halt mal. Konstante Zeiten
bekommst du mit dem BitBang nicht hin.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das was du erreichen willst, ist doch so eine Art SPI mit 22 Bit 
Datenlänge...geht das nicht eventuell mit der MPSSE im FT2232?

Autor: Mars (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja die MPSSE im FT2232 ist für synchron serielle Protokolle wie SPI 
ausgelegt und funktioniert auch sehr gut.
Nur die von FTDI zur Verfügung gestellten Bibliotheken würde ich nicht 
verwenden(FTCSPI.dll).

Autor: Thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@holger: siehe Bild USB_BitBang.png in einem der obigen Posts die 
Schemazeichnung "zu realisieren" zeigt was ich erreichen wollte.

Schade dass das mit BitBang für meinen Fall nicht geht, dann richte ich 
mal die Fühler Richtung des von euch vorgeschlagenen FT2232 aus und 
verwende solange den BitBangMode in sehr langsam :). Vielen Dank an 
alle!

Gibt es eigentlich eine Übersicht über die bzw. einen Vergleich der 
verschiedenen Übertragungsmodi und deren Eigenschaften, 
Anwendungsbereich?

Autor: Guido Körber (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Grundannahme, dass man sowas auf dem USB zuverlässig mit stabilen 
Latenzzeiten hinbekommen kann ist falsch. Die Kommunikation über den USB 
geschieht je nach Geräteart in mehr oder weniger echtzeitfähiger Form, 
meist weniger. Die FTDI Chips benutzen Bulk-Transfers, diese Transfers 
müssen sich praktisch hinten anstellen und werden bearbeitet wenn gerade 
Kapazität auf dem Bus frei ist, dafür können sie aber so viel Bandbreite 
bekommen wie da ist.

Also sollte man solche Dinge prinzipiell im Microcontroller bearbeiten 
und nicht über den USB schicken.

Die IO-Warrior können auch SPI direkt im Chip:
http://www.codemercs.com/index.php?id=64&L=0

Autor: B e r n d W. (smiley46)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Thomas

Der Buffer müßte 4096 Bytes groß sein, wenigstens ist das beim FT232 so. 
Wieviele Bytes musst Du maximal am Stück übertragen, innerhalb derer das 
Timing simmen muss? Falls die Anzahl 4096 Bytes nicht übersteigt, sollte 
es gehen. Einfach den Buffer voll nutzen. Wenn der FT245 ein Packet 
bekommen hat, kann er dieses ohne Lücke abarbeiten. Bis zum nächsten 
Packet entsteht dann aber doch eine kurze Pause.

Bei 3 Takten pro Bit können pro Packet ~1360 Bits bzw. 170 Bytes 
übertragen werden.

Für sowas ist Windows ungeeignet und Labview mainer Meinung nach erst 
recht.

MfG, Bernd

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
B e r n d W. schrieb:

> Für sowas ist Windows ungeeignet und Labview mainer Meinung nach erst
> recht.

Das ist mit Linux genauso, und mit MacOS auch. Das liegt einfach am 
Konzept der USB Übertragung. Man braucht große Puffer und externe 
Hardware, wenn man kontinuierliche Sachen übertragen will.

Autor: Thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Bernd W.:
Es sind 21 Datenbits, wobei pro Bit einmal der Takt wechselt also 
2*21=42
und letztlich noch am Anfang einmal Enable auf Low und am Ende auf High
also 42+2 = 44 Bit bzw Portbytes.
D.h. das müsste schon in den Buffer passen und wie ich oben schon 
schrieb in das kleinste USB-Paket von 64 Byte - 2 Byte von FTDI = 62 
Byte Nutzdaten.

Wo kommt der Wert von 4096Byte her? Lese hier im Datasheet Seite 1: 
128Byte TransmitBuffer sowohl bei FT232 als auch bei FT245.

Autor: B e r n d W. (smiley46)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Christian
Am USB auch, aber es liegt hauptsächlich am Betriebssystem. Sonst würde 
es immer genau 1ms dauern, es dauert aber mal auch 3 oder 4 ms. Starte 
mal das Office Deiner Wahl und mach gleichzeitig dieses Bitbang. Z.B. 
Zugriffe auf die Festplatte werden einfach bevorzugt.

@Thomas
Ok, danke für den Hinweis, die 128 Bytes hab ich jetzt auch gefunden. 
4096 ist die maximale Größe beim virtuellen Comport.

Du darfst die Funktion nicht für jedes Byte neu aufrufen, sonst sendet 
Labview das Packet ab und das nächste erst nach einer ms oder noch 
später. Du musst einen Puffer füllen und alles auf einmal lossenden.

Gruss, Bernd

Autor: Thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Bernd,

meines Wissens mach ich durch die Verknüpfung der Daten zu einem 
Bytearray genau das. Siehe LabVIEW-Screenshot.png. Hier übergebe ich ein 
Array von 10 Byte der Funktion FT_Write_Byte_Data aus der FTDI Labview 
Lib. Diese Funktion entspricht der Funktion FT_Write der FTD2XX.dll. 
(Bzw. ist ein Link auf diese)

Wie im ersten Screenshot dieses Posts zu sehen, kann es ja auch so 
klappen. Nur sehr selten :). Werde noch ein bischen rumprobieren 
vielleicht bewirkt ja die ein oder andere Option Wunder und verbietet 
das Aufteilen auf mehrere Pakete trotz einmaliger Übergabe der Daten. 
Sollte ich es doch noch hinbekommen sag ich bescheid.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
B e r n d W. schrieb:
> @Christian
> Am USB auch, aber es liegt hauptsächlich am Betriebssystem. Sonst würde
> es immer genau 1ms dauern, es dauert aber mal auch 3 oder 4 ms. Starte
> mal das Office Deiner Wahl und mach gleichzeitig dieses Bitbang. Z.B.
> Zugriffe auf die Festplatte werden einfach bevorzugt.

Ja sicher. Aber es liegt nicht spezifisch an Windows. Unter Linux ist 
das teilweise noch schlimmer. Sowas bekommt man nur mit einem 
Echtzeit-OS halbwegs in Software hin.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.