FTDI dll vs. Virtual Com Port

Oh ja.

Ich habe für meine Bachelorarbeit eine provisorische 
Kommunikationsstrecke aufgebaut. Daten loggen mit höchstmöglicher 
Geschwindigkeit.
Nur als Vergleichswerte gedacht, da Systemabhängig:

VCP :
15% CPU; Datenverlust ~ 15 Byte pro übertragene 1 KByte
D2XX:
~1% CPU; kein Datenverlust

(FT232RL @ 1 Megabaud)

EDIT: Achja, ich habe mein Interface in C# mit .NET 4.0 programmiert

Markus schrieb:
> Hallo,
>
> weiß jemand ob es irgendwelche Vorteile hat den FTDI-Chip (FT232RL) über
> die API Funktionen zu nutzen anstatt einfach als COM-Port?

Das ganze COM-Port Gedöns ist nur eine Krücke. USB ist eine 
blockorientierte Schnittstelle, d.h. jedes Device wird in einem 
bestimmten Raster (meist 1ms) gepollt und kann einen Block an Daten 
senden/empfangen. Die USB-Treiber und die USB-RS232 Bridges am anderen 
Ende müssen jetzt mit Hilfe von zusätzlichen Puffern und Timeouts 
versuchen, die zeichenorientierte, unstrukturierte RS232-Verbindung an 
den USB-Transport anzupassen. Dass das alles andere als optimal ist, ist 
leicht einzusehen.

Die Benutzung der spezifischen API-Funktionen erspart schon einmal einen 
Teil der beschriebenen Umsetzungsschicht auf Host-Seite.

Bestmögliche Ergebnisse erzielt man nur mit einer nativen 
USB-Kommunikation. Sowas ist jedoch nicht ganz einfach zu programmieren, 
und das ist der Markt für solche Umsetzerbausteine.

Wenn die absolute Datenrate nicht allzu hoch ist, kannst Du ja auch mal 
überlegen, ob Du mit HID nicht eine geringere Latenz hinbekommst. Die 
FTDI-Teile können das aber nicht, hier brauchst Du einen echten 
USB-Mikrocontroller wie z.B. den PIC18F26J50 oder den Atmega32u2 oder 
so. Finger wech von diesen ganzen Software-only Lösungen ala v-usb, die 
können nur Low Speed und sind nicht 100% standardkonform.

fchk

rico schrieb:
> Frank K. schrieb:
>> Du einen echten
>> USB-Mikrocontroller wie z.B. den PIC18F26J50 oder den Atmega32u2 oder
>> so.
>
> da ich mich auch die selbe problematik besitzen wollte ich fragen ob
> dies z.B mit dem AN2131 von Cypress funktionier?!? weil den habe ich
> zuhause liegen, jedoch müsste ich dann erst recht
> PC<-->AN2131<-->hauptµC ob das sinnvoll ist?^^


nein. Werf Deinen hauptµC raus und ersetze ihn durch einen mit USB 
Device Port. Eigentlich gibts für jede Architektur passende Controller.

fchk

rico schrieb:
> jedoch müsste ich dann erst recht
> PC<-->AN2131<-->hauptµC ob das sinnvoll ist?^^

Kann bei Deiner Aufgabe nicht der AN2131 die Aufgabe des "HauptµC" 
übernehmen?

mar IO schrieb:
> Wie wurde gelesen? DataReceived-Event + entsprechenden
> ReceivedBytesThreshold?

zu COM:
Receive-Anweisung des Com-Ports in separatem Thread.
zu D2XX:
Es wurde mit der Receive-Anweisung vom D2XX-Treiber empfangen.

> Wie groß war denn ReadBufferSize?

zu beiden:
Die Buffersize und Anzahl zu lesender Bytes ist optimiert auf die 
Blockgröße der USB-Datenpakete und den FIFO des FTDI.

mar IO schrieb:
> ... im seperatem Thread. -> Quasi so: die Receive-Methode blockiert
> nicht und der Thread schläft für eine gewisse Zeit, wenn keine Daten
> vorhanden sind. Das soll ca. 15% CPU-Auslastung verursachen, kann ich
> mir fast nicht vorstellen.

Probiers mal selber. Auf meinem eigenen Rechner klappt es auch, aber 
nicht auf der Krücke die ich für meine Arbeit benutzen sollte.

> den Buffer optimiert auf Blockgröße der USB-Datenpakete und den FIFO des
> FTDI??? - Versteh ich nicht ganz, was beim Empfangsbuffer auf dem
> Rechner zu optimieren gibt. Nicht zu klein machen, sonst Überlauf...
> Wenn das zu empfangene Datum vom Datenlogger auf dem Rechner übertragen
> worden ist, dann kann man sich mit der Weiterverarbeitung Zeit lassen.
> Datenlogger ist ja nichts zeitkritisches und 100 ms früher oder
> später...

Schau mal bei den AppNotes von FTDI, da gibts nen Thema zu.
Die Weiterverarbeitung ist auch kein Problem, es geht nur um den 
Transfer. (Eventuell liegt es gar an der Schnittstelle vom FTDI-Treiber 
nach Windoof, und ich beschwere mich Grundlos über MS, wer weiss..)
Wenn man mal mit dem ProcessExplorer o.Ä. zuschaut, sieht man schön an 
den I/O-stats, dass Windoof die COM-Port Daten einmal quer durchs System 
schiebt, bevor sie im eigenen Programm ankommen.

Zumindest was das Resultat des Ersetzens von knapp 10 Programmzeilen 
eine deutliche Reduktion der CPU-Last und eine ununterbrochene 
Kommunikation.