Hallo, weiss jemend ein USB Chip (nicht FTDI) mit dem man ein schnelles Byte-Up/Byte-Down Verfahren machen kann? FTDI macht da extreme Probleme durch time-outs. Die Datenblöcke sind maximal 256 Bytes, in der Regel jedoch 2..4 Bytes up und down. USB1 oder USB2. Treiber auf der PC Seite spielt dabei keine Rolle. Das Interface zur lokalen CPU sollte SPI, I2C o.ä. sein, keine 8/16bit Ports. rolf
Wie wäre es denn mitd EZ-USB Chips von Cypress? Das sind zwar komplette 8051 Microcontroller, haben aber komplettes Full-Speed USB (1.1), I2C, nen paar serielle Schnittstellen und noch nen paar freie Ports. Zum Beispiel den AN2132SC, den bekommst du bei Reichelt auch schon 10,50 gesamteuropäische Währungseinheiten. http://www.cypress.com/products/datasheet.cfm?partnum=AN2131SC Gruss Andre
Hallo Andre, hast du mit diesem Controller schon (erfolgreiche) Erfahrungen gemacht? Ich hätte grosses Interesse daran, diesbezüglich mal mit Profis zu sprchen. Viele Grüße
@Thomas: Noch nicht, aber ist schon bei Reichelt bestellt. Kann bei Erfolg ja mal kurz Bescheid geben. Gruss Andre
Ich hab mal während meines Praktikums an der Uni PB kurz mit USB gearbeitet und dabei den AN2131SC eingesetzt - ist nun aber schon etwas her. Es hat aber eigentlich alles damit problemlos funktioniert. Treiber gibts aber nur für WinNT - für Win9x gibts aber soweit ich weiss auch welche - bin mir da aber nicht sicher. Linux wird leider nicht unterstützt. Wie die Datenblöcke usw. angelegt sind hängt aber ganz davon ab, ob man nun Control Transfer, Isynchronos Transfer oder Bulk Transfer benutzt. (so hiessen die Modi soweit ich richtig mich erinnere?) Jedenfalls muss man beim AN2131SC den 8051 Prozessor direkt über das eingebaute USB Interface bei jedem PowerOn neu programmieren, da dieser nur über einen RAM Speicher verfügt. An der Uni hatte ich eine Delphi Unit zur Verfügung in der auch eine Methode zu finden war war mit der man Intel Hex Files zum Prozessor schicken konnte. Wir haben da Bulk Transfer verwendet. Im Buch "MSR mit USB" von B. Kainka ist vieles über diesen und andere USB Interfaces beschrieben. MfG, Dominik S. Herwald http://www.dsh-elektronik.de/
keine linux treiber ? http://www.cypress.com/cfuploads/support/software_downloads/hexpad.tar.gz http://sourceforge.net/projects/ezusb2131/ http://sourceforge.net/projects/ezhid/
Ja wie gesagt, dass ist schon etwas her ... über ein Jahr mindestens MfG, DSH
Und das mit dem jedesmal über USB neu programmieren ist so auch nicht richtig. Man kann ein I2C EEPROM mit Programm dranhängen, dann läuft er auch Standalone. Gruss Andre
Die Cypress-Prozessoren sind genial, so einfach gibt's USB sonst nirgendwo :-).. Zur ursprünglichen Frage: das Ping-Pong-Transfers nicht besonders schnell sind liegt wahrscheinlich weniger an den FTDI-Schips als daran, dass USB nicht dafür ausgelegt ist.
Von TI gibt's auch USB-µC, mit ähnlichen funktionen wie denen der cypress-µCs.
@Thomas: gg Bin momentan eher auf der 16- bis 32-Bitter-Seite, aber der 8051 ist doch immer wieder mal nett... Vor allem der von Cypress - haben damit nen kompletten portablen MP3-Player gebaut :-)
Sorry für die blöde Frage, aber wer bietet 32 Bit Mikroprozessoren an?
Es gibt auch von Renesas (vormals Mitsubishi) den M16C mit integriertem USB. Deutscher Distributor dafür ist Glyn, zu finden unter http://www.m16c.de Mit dem M16C (ohne USB) habe ich schon sehr gute Erfahrungen gesammelt. Gruss Andre
@Sven: meinst jetzt Hersteller oder Distributor? Hersteller wären zB mit dem ARM-Core u.a. Atmel, Triscend, Intel uva, dann gibts den PPC, den MIPS, den i386 (ja, kann auch embedded eingesetzt werden). Als Distributoren gibts zB Ineltek für den ARM, für PPC/MIPS weiß ich momentan niemanden, lässt sich aber sicher finden. Ach ja, auch Reneasas hat mit dem M32R einen 32-Bitter - sollte es auch bei Glyn geben schätz ich.
Ja die FTDI Chips sind für solche Dinge ungeeignet. Das liegt an deren Treiber. Mit I2C Bus kenn ich nur den PDIUSB11 der ist aber abgekündigt weil er Probleme and USB 2.0 Hubs hat. Ansonsten fallen mir nur noch die Cypress Chips ein. Da must du die Datenübertragung nach I2C dann aber in der Firmware selbst machen. Die I2C Ports der TI Usb Chips sind nur Master fähig. Ein Slave Interface geht nur über die Ports. Thomas
Das langsame Ping/Pong liegt nicht an den FTDI Chips. Das liegt an USB. Und zwar lassen sich nur alle paar mS Datenpakete verschicken. Das gleiche Problem gibt es auch bei Bluetooth. Ich habe hier sowohl die FTDI als auch Bluetoothmodule im Einsatz. Für mich sind die FTDI Chips immer noch die einfachste Möglichkeit einen µC USB fähig zu machen Gruß Markus http://www.embedit.de
@Markus: Das liegt definitiv nicht am USB Protokoll sondern am Treiber, bzw an der Art wie FTDI die Bulk Requests behandelt. die USB Latenz beträgt max 1 mS (nächster Frame Start bei freiem Bus) Das wurde mir auch so von FTDI bestätigt Das Problem bei FTDI ist dass Sie immer entweder 1. 16 ms lange warten oder 2. warten bis 64 Bytes zür Übertragung anstehen und dann je nachdem was früher eintrifft ein Packet über den Bus senden. Deshalb sind die Chips nicht für PingPong Betrieb geeignet. Ich gebe dir recht trotz allem ist das eine billige Möglichkeit eine Schaltung USB fähig zu machen. Das ganze wäre auf Protokoll Ebene relativ einfach abzufangen aber leiter bietet der Treiber da nichts. Ich habe bei meinem Treiber mit VendorRequests eine max Antwortzeit von 3 mS für einen Request mit 8 Byte send + 8 Byte 8 Byte return. Allerdings benutze ich dabei ein properitäres Protokoll. Thomas
@Thomas, exakt, das ist das Problem. FTDI behauptet auch, dass diese Latency time von 16msec auf 1msec herabgesetzt werden kann (mit der neuen DLL), leider habe ich das noch nicht geschafft. Möglicherweise wäre das Problem damit erledigt. Es soll auch eine neue DLL geben, die isochron mode beherrscht. FTDI behauptet hierbei, dass dann !nur! 64bytes/msec übertragen werden können, und dass hier mit Byte Verlusten gerechnet werden muss. Hat jemend Erfahrungen mit dem Isochron Mode?? Rolf
@rolf Selbst bei 1ms Latenz, welche nach bisherigen Erfahrungen auf PC-Systemen arg geschönt ist, sind im Ping/Pong mode ja nur max. 1000 Byte Sekunde (was ca. 9600 bps eines Hardware UART entspricht) möglich. In deinem 1. Posting hast du geschrieben das die Treiber auf PC-Seite kein Problem wären. Deinem letzten Posting ist allerdings zu entnehmen, daß dieses wohl doch der Fall ist. Wie denn nun? Denn schnellen Single Byte Transfer in beide Richtungen kann USB niemals ersetzen, wurde ja auch nicht dafür konzipiert, egal welche Chips man im Endgerät einsetzt.
@Rolf: wie das mit der neuen DLL ist weis ich nicht. Eine ms ist m.E. nicht möglich. Isochron wäre eine Möglichkeit wobei folgendes gilt: 1. max 1023 Bytes / ms 2. kein ErrorCheck / kein Re Send wie bei Bulk die 64 Bytes kommen wohl von der FiFO Size des FTDI chips ich mache für Audio schon lange ISO (bis ca 800 Bytes pro Frame) Das geht normalerweise recht gut, es gibt aber keine Garantie , dass die Daten ankommen. Die Treiber dafür sind jedoch sehr komplex. Mit Interupt Requests sollte sich dein Problem erledigen lassen. Dort hat man die Möglichkeit die Polling Rate einzustellen. Eine Kombination von Interupt EP und Bulk EP stellt das Optimum dar. ACHTUNG: meines wissens ist dieses Verfahren von Cypress patent- geschützt. Thomas
@mmerten mit "Treiber kein Problem" meinte ich nicht FTDI sondern ganz allgemein. Dazu habe ich dieses WinDriver Packet. Das lässt sich allerdings auf FTDI nicht anwenden, da das USB Interface (Register etc) nicht offengelegt ist. Auch mit USB1.x ist sehr wohl highspeed möglich, im Up/Down isochron mode. @Thomas Offiziell isochron 1023byte/msec :-) Super! Deswegen sagt FTDI isochron "önly" 64bytes/msec. Aber das wäre für meinen Fall vollkommen ausreichend. 64kBytes/sec ~ 640kBaud... Wie ist das mit der Datensicherheit, viele falsche Bytes bzw. Byte Verluste?? Irgendwelche Erfahrungen? Rolf
@Rolf WinDriver würde ich ganz schnell vergessen. In deren Framework fehlen zu viele Dinge. (Power Managememt, korrektes PnP) Win Driver wurde für PCI Treiber Development entworfen der USB Support kamm relativ spät dazu. Fehler zu erkennen würde selbst bei ISO ja noch gehen (CRC16 Feld) Nur was machst du dann mit deinem Wissen? Den ACK NAK Handshake gibt es nicht, die Daten sind definitiv falsch und auch nicht mehr in der Fifo. ISO Daten werden in jeder CPU die ich kenne in HW wie DMA oder ähnlichem gesendet. In der Regel wird dann auch noch mit Double Buffer gearbeitet. Die CPUs sind einfach nicht schnell genug. Zur Fehler Rate: da habe ich schon alles gesehen von 1 x pro 10 sec bis 1 x pro h Dann ist immer der komplette ISO Frame futsch. Die Fehlerrate wird entscheidend vom USB Host/Hub mitbestimmt. Worst Case dabei ist OHCI von NEC. Auserdem sind bestimmte Video Karten mit Treibern die den PCI Bus nicht mehr korrekt freigeben tödlich für ISO. Das gleiche gilt für manche schlechten UDMA Treiber von VIA. Thomas
Hi Thomas, das ist ja alles zum Kotzen :-( Ich komme mit dem FTDI (non-VCP) auf eine effektive Datenrate von geschätzt 9600Bd bei soll Vorgabe 57600. Jede serielle Schnittstelle läuft mir da den Rang ab. Meine Packetchen sind 2..16bytes lang, immer eins runter, eins rauf. Manchmal auch zig kilobytes in eine Richtung, aufgeteilt in 256byte Packete mit Checksumme, Empfänger macht ein 3byte Handshake. Es ist zum auswachsen :-( Rolf
es gibt auch open-source linux-treiber für FTDI ... http://sourceforge.net/projects/ftdi-usb-sio/ http://sourceforge.net/projects/ftdifullspddrv/ vielleicht taugen die mehr. hab sie noch nicht angeschaut.
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.