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?
Angehängte Dateien:
-
SynchronousBitBang_ByteArray_1.png
815 Bytes
Angehängte Dateien:
das zweite Bild mit "fehlerhafter" Übertragung.
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
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?
ein letzter bumb Wo sind die FTDI Experten geblieben? Hat keiner einen Rat, oder eine Idee was ich anders machen könnte?
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
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
Angehängte Dateien:
-
USB_BitBang.png
45 KB
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_FT232RBitBangModes.pdf 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.
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/D2XX_Functions_7.0.zip - die FTDI-Treiber: http://ftdichip.com/Drivers/D2XX.htm
Angehängte Dateien:
-
LabVIEW-Screenshot.png
9,5 KB
So hier noch für alle die evtl. kein LabVIEW besitzen oder es nicht ausführen wollen der Screenshot des Programms.
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?
>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.
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?
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).
@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?
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
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
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.
@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.
@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
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.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.