Hallo, weiß jemand ob es irgendwelche Vorteile hat den FTDI-Chip (FT232RL) über die API Funktionen zu nutzen anstatt einfach als COM-Port? Vor allem im Bezug auf Geschwindigkeit? Ich habe hier das Gefühl das bei meinen Programme (VB6 und C#) der PC die bremse ist. Die einzustellende Baudrate dürfte sich dabei ja nur auf die kurze Verbindung zwischen FTDI und µC beziehen. Der PC braucht dabei doch deutlich mehr zeit zum Antworten als der Controller. Bis her nutze ich immer die einfachen COM-Port Funktionen. Danke
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
Matthias N. schrieb: > 15% CPU; Wie wurde gelesen? DataReceived-Event + entsprechenden ReceivedBytesThreshold? > Datenverlust ~ 15 Byte pro übertragene 1 KByte Wie groß war denn ReadBufferSize?
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
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?^^ gruß!
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.
... 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. 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...
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.
Bitte 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.