USB teriber für Cypress SX

[Dan Oprisan]

Auch wenn es ein bischen OT ist:
Ich habe schon seit längerer Zeit ein kleines USB2.0 Modul mit dem CY7C68001 Chip von Cypress
gebaut, um bei verschiedenen FPGA und uC Anwendungen eine schnelle Schnittstelle zum PC zu haben.
Bisher habe ich den Treiber von Cypress 'ezusb.sys' erfolgreich verwendet. Bei dem jetzigen Projekt
stosse ich aber auf das Problem, dass dieser Treiber nicht assynchron arbeitet und auch keinen
Timeout hat, d.h. er blockiert (u.U. die ganze Software) so lange bis die angefordertet Daten auch
ankommen. Meine Versuche den Treiber umzuändern oder den Microdsoft Demo-Treiber anstatt zu
verwendet, habe bisher gescheitert und ich will nicht viel mehr Zeit in dieser Sache investieren.
Kennt vielleicht jemand eine bessere (kostenlose) Aletrnative?

Danke, Dan

 

[Tassilo Heeg]

Hi!

On Fri, 4 Nov 2005 10:42:50 +0100, "Dan Oprisan" <dandy1313@yahoo.com>
wrote:

Bisher habe ich den Treiber von Cypress 'ezusb.sys' erfolgreich verwendet. Bei dem jetzigen Projekt
stosse ich aber auf das Problem, dass dieser Treiber nicht assynchron arbeitet und auch keinen
Timeout hat, d.h. er blockiert (u.U. die ganze Software) so lange bis die angefordertet Daten auch
ankommen. Meine Versuche den Treiber umzuändern oder den Microdsoft Demo-Treiber anstatt zu
verwendet, habe bisher gescheitert und ich will nicht viel mehr Zeit in dieser Sache investieren.
Kennt vielleicht jemand eine bessere (kostenlose) Aletrnative?

Klingt ja so, als stamme die Software, die den Treiber verwendet, von
Dir. Daher: Treiber so lassen wie er ist und Kommunikation mit dem
Treiber in einen eigenen Thread auslagern. Habe ich jedenfalls
seinerzeit bei einem ebenso kooperativen IEEE488-Treiber so gemacht.

Gruß

Tassilo

--
ľC Assembler-IDE für AVR, 8051, Z80, 8048 =>
http://www.theeg.de/aside/index.html
================================================================
de.sci.electronics FAQ: http://dse-faq.elektronik-kompendium.de/

 

[Dan Oprisan]

"Tassilo Heeg" <heeg@ph-cip.uni-koeln.de> schrieb:

Klingt ja so, als stamme die Software, die den Treiber verwendet, von
Dir. Daher: Treiber so lassen wie er ist und Kommunikation mit dem
Treiber in einen eigenen Thread auslagern. Habe ich jedenfalls
seinerzeit bei einem ebenso kooperativen IEEE488-Treiber so gemacht.

habe ich auch gemacht. Wenn z.B. die Lesefunktion aber blockiert (weil
der USB Chip mal keine Daten schickt), ist der ganze Treiber blockiert,
d.h. ich kann auch die anderen Pipes nicht mehr benutzen, um
zwischenzeitlich Daten zu senden. Ausserdem kann man den blockierten
Thread nicht einfach 'von Ausserhalb' terminieren.
Das bringt mich aber auf der Idee, in so einem Fall das ganze Device
zu schliessen und wieder zu öffnen. Muss ich versuchen.

bye, Dan