Hallo Zusammen, Ich habe mir für mein Notebook ein USB-RS232 Adapter gekauft. Dieser enthält genau wie alle anderen, die ich bis jetzt ausprobiert habe einen Prolific Chip. Bei fast allen Anwendungen funktioniert das auch wunderbar, nur halt nicht bei der für die ich das Teil eigentlich gekauft habe (mit einer reellen seriellen Schnittstelle funktionierts). Weiß jemand woran das liegen könnte? Ist das ein generelles "Virtueller COM Port" Problem, oder kann ich da mit einem FTDI Chip mehr Glück haben? Gruß, Thomas
Das ist abhängig davon, wie die entsprechende Anwendung mit der Schnittstelle umgeht und was für eine Art Protokoll verwendet wird. FTDI hat wohl nicht umsonst den Ruf, bessere und sauberere Treiber zu liefern als ausgerechnet Prolific, aber ohne Deine spezifische Anwendung zu kennen, ist eine Aussage, ob's mit FTDI besser funktioniert, nicht möglich. Was ist das für eine Anwendung? Ist das ein Windows-Programm oder sogar noch ein DOS-Programm?
Hallo, ich arbeite mit Matlab 7 und dem Phytec phyCORE-MPC565 Entwicklungskit, ist also eine WIN32 Anwendung, hätte nicht gedacht, dass das wichtig ist. Mit Protokollfragen kenn ich mich leider gar nicht aus, ich will damit einfach nur meine Programme übertragen. Gibt es denn vertige FTDI Adapter oder muss ich mir sowas selber basteln? Dem zuständigen Mathworks Entwickler ist das Problem übrigens bekannt, nur weiss er leider auch keine Lösung. Meine Hoffnung ist halt, dass FTDI es besser macht. Danke, Thomas
Das Problem ist USB selber, das arbeitet im Polling-Mode und hat dadurch immer eine große Latenzzeit. Wenn die RS-232 Anwendung ein zu kleines Timeout hat, kann sie denken, die Verbindung ist gestört. Bzw. wenn die Anwendung immer nur einzelne Bytes sendet, bricht die Transferrate dramatisch ein. Eventuell kann es helfen, die Latenzzeit mittels entsprechender Tools geringer einzustellen. Peter
so, nach fast einem Jahr habe ich es nun endlich mal geschafft mir den FTDI-Adapter zu basteln. Die Treiber bieten auch eine Option die Latenzzeit herabzusetzen, und mit 4ms statt der standartmäßigen 16ms klappt es dann auch (danke Peter). Jetzt würde mich noch interessieren, ob ich mir damit irgendwelche Nachteile einfange und ob jemand einen sauberen Weg kennt diese Latenzzeit auch für andere Adapter (Prolific) herabzusetzen, die diese Option nicht in den Treibereinstellungen haben. Peter sprach ja von "entsprechenden Tools". Verstehe ich das richtig, dass USB zwar deutlich schneller als RS232 ist, aber dafür auch langsamer (Latenz) reagiert? Gruß, Thomas
Hallo Thomas, mit diesem Thema 'Latenzzeit' muss ich mich gerade rumärgern. Die Aktuellen Treiber akzeptieren zwar Einstellungen runter bis zu 1 mS, aber nachdem ich ein kleines Testprogramm geschrieben habe, ist klar es tut nicht. Man schafft immer nur maximal 64 Zeichen pro Sekunde im 'Einzelzeichen Echo' Betrieb. Mit den älternen Treibern (Build 2154) waren das mal 100 Zeichen. Im Moment korrespondiere ich mit dem FTDI Support, da ich für einen Kunden eine Anwendung umzusetzen habe, die durch diese Eigenschaft bis zur Unbrauchbarkeit ausgebremst wird. Leider kommt da bisher noch nix Brauchbares bei raus. Die Frage, um die es eigentlich geht ist folgende: Warum nicht ein empfangenes Byte einfach dann über USB weiter zu senden, wenn der nächste USB timeslot ansteht. Dann dürfte es eigentlich für den echo Betrieb maximal 2mS dauern bis ein einzelnes Byte ankommt. Es gibt nunmal einige Anwendungen die diesen Modus fahren, Bootloader für Controller, Telefonanlagen etc. Mit dieser 'genialen Eigenschaft, die sicher auch nichst mit Windows zu tun hat, schafft man dann in diesem Scenario unabhängig von der Baudrate 64 Zeichen/sek. Das entspräche 640 Baud. Tja falls keiner eine Idee hat, wie das Verhalten geändert werden kann, wird das neu entwickelte Interface wohl nie eingesetzt werden. Denn was bisher über einen COM Port 15Sec dauerte, kommt jetzt auf 10Min. Robert
Warum komme ich nur wenn ich das durchrechne mit deinen 64 Zeichen pro Sekunde genau auf die 16ms Latenzzeit? Vielleicht solltest du dein Protokoll mal überdenken. Wenn du in Blöcken senden würdest statt jedes Byte einzeln steigt die Datenrate.
Wolfram, das Protokoll ist eine Kundenvorgabe. Das Ganze zu ändern ist der Kunde leider nicht bereit. Robert
Kontrolliere nochmal genau ob da nicht doch 16ms eingestellt sind. Ansonsten gibt es noch die CP21xx Chips die können noch geringere Latenzzeiten. >das Protokoll ist eine Kundenvorgabe. Das Ganze zu ändern ist der Kunde >leider nicht bereit. In anbetracht dessen das serielle Schnittstellen verschwinden und nur noch USB-Seriell Adapter da sind, kann man sagen, wenn jemand sich unbedingt aus dem Markt herauskatapultieren will, viel Spass dabei...
Das ist schon geschehen, die Latenzzeit zu vergrößern geht ja klaglos, aber wer braucht das schon?? Vermutlich murks im FTDI WHQL Treiber. Wir errinnern uns, RS232 ist eine zeichenorientierte Schnittstelle... mal sehen, vielleicht finde ich ja noch eine Lösung diese FTDI Krücke in Schwung zu bringen...
Noch ein Nachtrag: in der Registry wird der eingestellte Wert übernommen, aber nach wie vor vom Treiber ignoriert. - leider. PS: hat jemand schon mal probiert, wie sich die D2xx Treiber hier verhalten?
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.