Hallo Leute, ich wollte mal fragen ob jemand der mit Serialconvertern unter Windows werkelt, schonmal auf folgende Probleme gestoßen ist: Ich setze in meinen Projekten unter anderem USB-Serial-Converter ein (FTDI oder auch eigene auf STM32 basierend). Nun hab ich schon öfters folgendes das problem gehabt, dass einzelne Bytes zwar unter Windows im COMPORT-Buffer liegen, diese aber kein event auslösen und man sie "von Hand" aus dem Buffer "Rauskratzen" muss. Besonders häufig tritt das problem auf wenn man einzelne Bytes versendet oder aber in einem Schwung 64Bytes. Da ich ebenfalls einen USB-Tracer habe, kann ich relativ sicher behaupten, dass in den meisten Fällen die Daten über den Bus gehen aber einfach kein event auslösen. Ich hab auch beobachten können, wenn einzelne Bytes kein event ausgelöst haben, und man nochmal mit einigen Bytes "nachspült" zum teil dann events ausgelöst werden. Das problem tritt immer nur dann auf wenn man mit Serialconvertern arbeitet. Bei einer Hardware-Rs232-Schnittstelle konnte ich das Verhalten, bei gleichem Code nicht beobachten. Nochmal konret: Kennt jemand das problem? oder kann sich jemand darauf einen reim machen? Grüße Tarkan
Wie sieht denn die Software auf dem PC aus?
Tarkan D. schrieb: > aber einfach kein event auslösen. Was für ein Event?
Gast
#2540063
USB-Converter wurden hier schon öfter behandelt. Nicht jeder macht glücklich.
Gast
#2540064
Eine Hardware RS232 hatte einen relativ kleinen Buffer und eigenen Interrupt. USB arbeitet Paketweise. Wie gut/schlecht der Treiber den USB UART emuliert ist schwer zu sagen. Mit BT UARTs kenne ich das Problem, dass man Daten, die von einem µC System kontinuierlich gesendet werden, dann in Blöcken erhält. Ich denke bei USB wird das etwa das selbe sein. Mit Buffergrößen, Timeouts und ähnlichen Einstellungen müsste sich da aber schon etwas machen lassen. FTDI Treiber lassen sich auf jeden Fall in dieser Beziehung konfigurieren.
Hallo Ein prinzipielles Problem mit USB-Adaptern kenne Ich nicht. Gerade, wenn du auch verschiedene Hersteller verwendest und den gleichen Fehler bekommst, würde mein Verdacht eher bei der PC-Software liegen. Gruß Klaus
Lothar Miller schrieb: > Was für ein Event? http://de.wikipedia.org/wiki/Ereignis_%28Programmierung%29 Arc Net schrieb: > Wie sieht denn die Software auf dem PC aus? Meinst du ein Stück sourcecode? Also das Problem mit den 64 Bytes lässt sich reproduzierbar mit "H-Term terminalprogramm" erzeugen. Für sourcecode müsste ich erst ein paar quellcodeschnipsel aufbereiten
Klaus Kloos schrieb: > Ein prinzipielles Problem mit USB-Adaptern kenne Ich nicht. Gerade, wenn > du auch verschiedene Hersteller verwendest und den gleichen Fehler > bekommst, würde mein Verdacht eher bei der PC-Software liegen. Tendentiell richtig. Wäre ich auch von ausgegangen. Nur das problem ist, das PC-Programm wurde von zwei verschiedenen Kollegen unter 2 verschiedenen Frameworks zu 2 verschiedenen Zeitpunkten entwickelt. Und beidesmal lässt sich dieses Problem feststellen. :-S
Gast
#2540329
Auch auf 2 verschiedenen PCs ?
Wenn du das Problem auch mit dem unbeschreiblichen h-Term reproduzieren kannst scheidet deine Programmierung ja schon aus. Bei allem was H-Term nicht kann, habe Ich damit trotzdem nicht die von dir beschriebenen Probleme. Hast du dir das zu empfangende Signal mal mit einem Ossi angesehen? Evtl. fehlt hinten ein Stopbit oder ... ? Bei nicht Standart-konformen Signalen kann ein USB-Adapter schon ein anderes Ergebnis bringen als ein richtiger UART. Gruß Klaus
Gast
#2540378
> Ich hab auch beobachten können, wenn einzelne Bytes kein event ausgelöst > haben, und man nochmal mit einigen Bytes "nachspült" zum teil dann > events ausgelöst werden. Hört sich für mich nach den Triggerschwellen an. Im Gerätemanager kann man die Interrupt-Schwellen einstellen, setz die mal runter. Ist wenn überhaupt nur ein WorkAround, aber einen Versuch ist es wert, bei echten RS232-Schnittstellen konnte man damit zumindest früher auf älteren Maschinen positive Ergebnisse erzielen. > Also das Problem mit den 64 Bytes lässt sich reproduzierbar mit "H-Term > terminalprogramm" erzeugen. Sowohl mit dem FTDI als auch mit dem STM32? Kann ich fast nicht unbesehen glauben, denn der FTDI wird wahrscheinlich einen anderen VCP-Treiber nutzen als der STM32. Abgesehen davon, du testest mit H-Term, okay. Gegenprobe mit BrayTerminal, TeraTerm, HyperTerminal, etc. gemacht? Ich frag deswegen, weil die unterschiedlichen Terminalprogramme mit Sicherheit andere Arten der COM-Port-Ansteuerung verwenden, die einen vielleicht das .NET-Framework, die anderen direkt die Windows-API, die nächsten vielleicht was ganz eigenes, etc... Ralf
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.