mikrocontroller.net

Forum: PC-Programmierung FT232/245, ordentliche Programmierung für hohe Datenraten


Autor: Benedikt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kann es sein, dass der VCP Treiber die Datenübertragung etwas ausbremst
?
Selbst mit 3MBaud erreiche ich beim FT232 gerade mal etwa 70kByte/s.

Daher wollte ich das ganze über die D2XX Treiber machen, aber das
scheint etwas komplizierter zu sein.
Hat jemand ein schönes Beispielprogramm dafür, aus dem man erkennen
kann wie man den Port öffnet, und Daten sendet ?

Autor: Alex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da gibt es einen kompletten Programmer Guide mit Codebeispielen auf
ftdichip.com.

Die Datenrate wird auch damit nicht wirklich höher, von daher schenk
dir die Arbeit.

Autor: Μαtthias W. (matthias) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

also ich erreiche mit den VCP Treibern und einem FT245BM Datenraten von
etwa 6MBit/s mit einem normalen Terminalprogramm oder aus einem
Java-Programm heraus.

Matthias

Autor: Benedikt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist es eigentlich überhaupt möglich den D2xx Treiber und den VCP Treiber
gleichzeitig zu installieren ?
Ich bekomme nämlich immer 0 als Anzahl der gefundenen FT232s (es
müssten aber 3 sein).

Autor: Alex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Steht auch im Programmers Guide ...
- Nein.

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

Bewertung
0 lesenswert
nicht lesenswert
OK, dann scheidet das schonmal aus, denn ich benötige VCP für andere
Geräte die mit dem FT232 laufen.

Mit HTerm (das nicht auf hohe Datenraten optimiert ist), erreiche ich
mit 3MBit fast 1MBit Datenrate.
Mit meinen C Routinen nur etwa 600-700kBit.
Was mache ich falsch ?

Autor: Μαtthias W. (matthias) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

es sollte schon möglich sein VCP und D2xx gleichzeitig zu installieren
wenn man mittels EEPROM die VID und/oder DID manipuliert und die
inf-Dateien der Treiber entsprechend anpaßt. Wie das im Detail geht
weiß ich aber auch nicht da ich das selber auch noch nie probiert
habe.

Matthias

Autor: Alex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielleicht bringt es ja einen Performance-Vorsprung, wenn man das Senden
und Empfangen in einen extra Thread legt, welcher vom GUI getrennt ist.

Autor: Tobi H. (tobi-) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn man die non-blocking Routinen und Events benutzt gehts auch ohne
aber ein extra Thread ist schon was feines dafür

Autor: Benedikt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Tobi
Hättest du mal eine Codeausschnitt für sowas ?

Autor: chrigu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich empfehle euch einen Blick auf diese Homepage!
http://www.holger-klabunde.de/usb/usb.htm
VCP und D2XX Treiber laufen auf jeden fall nicht problemlos zusammen.
Jedoch hat FTDI ein Tool, welches den Treiber automatisch löscht.
Mich beschäftig seit längerer Zeit ein Problem mit dem 245er! Und zwar
kann ich die Buffergrösse nicht verändern. Eigentlich möchte ich
einzelne Bytes einlesen, und deshalb die Buffergrösse verkleinern. Mit
dem Befehl Ft_SetUsbParameters sollte die InTransferSize angepasst
werden können. Der Befehl wird bei mir ausgeführt, jedoch werden immer
no gleich viele Bytes eingelesen. Hat jemand im Forum schon einmal
erfolgreich die Buffer grösse angepasst?
gruss chrigu

Autor: Benedikt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe mich gerade mal durch die Application Notes von FTDI
gearbeitet, und fand da den Hinweis, dass pro USB packet 64Bytes Daten
übertragen werden, wovon 62Bytes die Nutzdaten sind.
Die Zeit zwischen 2 USB Time Frames liegt bei 1ms.
1000x62Bytes sind ziemlich genau die von mir erreichen 60kByte/s.

Welche Datenmengen sollte man dem COM Handler bei jedem Aufruf
übergeben um eine optimale Datenübertragung zu erreichen ?

Autor: Thomas Stütz (tstuetz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wie wäre es mit 62 Bytes ? (Die 2 Bytes die fehlen sind das Modemstatus
und Leitungsstatusregister).

Gruss

Autor: Tobi H. (tobi-) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auf PC-Seite kann es doch sicher auch mehr sein, da sind doch Puffer
zwischen. Dann ist auch immer Nachschub da

Autor: Benedikt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Tobi
Weist du zufällig, wie groß der Windows Puffer ist ?
Wenn ich einen Datenblock an den COM-Port handle übergebe, dann gibt es
dort den Eintrag "Number of bytes written". Muss ich da wirklich
überprüfen, ob Windows mir alle Bytes auch abgenommen hat, wenn ich zu
viele auf einmal sende

Ich habe es jetzt mal mit >1kByte Daytenblöcken probiert, und muss
sagen es bringt echt was ! Ich bin jetzt bei konstant 200kByte/s, ich
denke die Begrenzung liegt nun auf der Hardwareseite beim uC der die
Daten entgegen nimmt.

Es gibt bei dem COM handle auch noch eine Einstellung
Overlapped/Non-Overlapped.
Außerdem habe ich gelesen, dass man die Übertragung bzw. die Wartezeit
bis die Übertragung beendet ist, in einen anderen Thread verlegen kann,
damit das Programm nicht auf das Ende der Übertragung wartet, sondern
andere Daten vorbereiten kann die übertragen werden sollen. Das soll
sich auch positiv auf die CPU Auslastung auswirken.

Allerdings ist das ganze etwas zu kompliziert für micht, hat jemand
einen Beispielcode, oder am besten eine fertige Routine, der ich ich
Prinzip nur den Datenblock übergeben muss, und die diese dann im
Hintergrund überträgt ?

Autor: Tobi H. (tobi-) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mit SetupComm kann man die Grösse der internen Puffer setzen und mit
GetCommProperties auslesen.
Ich arbeite beim Datei senden mit 128 Byte, bremst spürbar.

Die geschriebenen Bytes würde ich überprüfen, da es manchmal vorkommt,
dass bei einem Aufruf von Write garnichts geschrieben wird. Warum weiss
ich nicht sicher, evtl zu viel auf einmal. Aber andere Werte als 0 und
die gewünschte Anzahl habe ich noch die zurück bekommen. Ich teste
deshalb nur auf 0 und sende dann neu.

Threads sind sehr zu empfehlen, zwar lässt sich das ganze auch mit
Overlapped und Event lösen, aber ein Thread ist da wesentlich
elleganter und besser zu warten. Ob es wirklich so viel schneller ist
sei dahin gestellt. Das einzige was auf jeden Fall schlecht ist, ist
Non-Overlapping zu benutzen und dann über die Commtimeouts die Pollzeit
einzustellen. Dadurch wird es sehr schnell sehr sehr langsam.

Irgendwo hier im Forum gabs mal einen recht guten Beispielcode auf
Thread-Basis, ich werd nachher mal was suchen

Autor: Tobi H. (tobi-) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Ich arbeite beim Datei senden mit 128 Byte, bremst spürbar."

Ich meinte natürlich, dass alles darunter spürbar bremst. Ab 128 Byte
merkt man subjektiv nichts mehr

Autor: Benedikt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
128Bytes für USB sind ein Witz.
Unter 1kByte braucht man da garnicht anfangen, wenn man hohe Datenraten
braucht.


PS: Habe mal hier im Forum gesucht, und eine Datei gefunden, die über
einen anderen Thread ein Byte vom COM Port empfängt. Leider verstehe
ich in dem Programm nicht viel...

Autor: flownfluid (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Benedikt,

auch ich arbeite momentan mit einem ft245 und bin an deinen ergebnissen
sehr interessiert. kannst du mal schreiben wie weit du bist?

vielen dank

gruss

Autor: Benedikt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe den FT245 mit VCP Treiber voll ausgereizt, ich bin sogar höher
gekommen, als die Herstellerangabe. Momentan liege ich bei etwa über
300kByte/s, begrenzt durch den uC der die Daten verarbeiten muss.

Bevor ich Daten an den COM Port übergebe, sammele ich diese in ein
Array und übergebe dieses komplett.
Ab etwa 1000Byte Arraygröße aufwärts, kann man kaum noch eine
Steigerung der Geschwindigkeit erzielen.
Unter 100Byte bremst es ziemlich.

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.