mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik USB Chip für schnelles Ping-Pong


Autor: Rolf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andre Adrian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?part...

Gruss

Andre

Autor: Thomas Burkhardt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andre Adrian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Thomas: Noch nicht, aber ist schon bei Reichelt bestellt. Kann bei
Erfolg ja mal kurz Bescheid geben.

Gruss

Andre

Autor: Dominik S. Herwald (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/

Autor: MichaelS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Dominik S. Herwald (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja wie gesagt, dass ist schon etwas her ... über ein Jahr mindestens

MfG,
DSH

Autor: Andre Adrian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rainer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas Burkhardt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Rainer,

schade nur, dass die nen 8051-Core haben. Ich mag momentan die AVRs
mehr :-)


Grüße

Autor: R2D2 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Von TI gibt's auch USB-µC, mit ähnlichen funktionen wie denen der
cypress-µCs.

Autor: Rainer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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 :-)

Autor: Sven (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sorry für die blöde Frage, aber wer bietet 32 Bit Mikroprozessoren an?

Autor: Andre Adrian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rainer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Thomas Zepf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Markus Burrer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Thomas Zepf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Rolf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: mmerten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Thomas Zepf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Rolf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Thomas Zepf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Rolf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: MichaelS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.