mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik USB2.0 High-Speed


Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute!

Ich suche einen USB2.0 High-Speed Baustein, den ich mittels
Mikrocontroller oder FPGA ansprechen kann, damit ich meine Messdaten
an den PC übertragen kann, die in einer Geschwindigkeit von ca. 10MByte
pro Sekunde angesaust kommen.

Diesen Baustein sollte man möglichst einfach ansteuern können, wie
z.B. FT245 oder FT232, damit die Implementierungszeit relativ kurz
ist.
Zusätzlich wäre es von Nutzem, wenn es für die PC-Seite vorgefertigte
USB-Treiber geben würde, die man relativ einfach in eine C-Umgebung
einbinden kann.

Ich freue mich schon auf eure Antworten.

Danke

Tschüss, Martin

Autor: Μαtthias W. (matthias) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

Mir ist kein solcher Baustein bekannt.

Alternativvorschlag:
Nimm einen 100MBit Ethernetbaustein und verschicke UDP-Packete. Du
brauchst auf dem PC keine Treiber schreiben, bist völlig Betriebssystem
unabhängig und der Aufbau eines UDP-Packets ist so simpel das du die
auch mit einem FPGA erzeugen kannst.

Matthias

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist aber eine super Idee!

Ich habe auf einem FPGA-Board den BCM5461-Baustein.
Es handelt sich um einen Giga-Bit-Tranceiverbaustein für Lan.

Soweit ich gehört habe müsste man das TCP-IP-Protokoll
selbst in VHDL implementieren, was sehr viel Zeit in
Anspruch nehmen würde.

Aus diesem Grund habe ich nach einem USB-Baustein gefragt,
weil ich nicht Ewigkeiten damit verbringen wollte, TCP-IP
einzubinden.

Aber ich habe nicht an UDP gedacht.
Hast du selbst eine Protokollbeschreibung, die du mir empfehlen
kannst?

Danke für deine Antwort.

Tschüss

Martin

Autor: Μαtthias W. (matthias) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

Wie gesagt IP/UDP ist primitiv.

Die beste Quelle ist immer noch die Originalquelle:

http://www.ietf.org/rfc/rfc768.txt (UDP)
http://www.ietf.org/rfc/rfc791.txt (IP)

Da der RFC von IP aber etwas länglich ist reicht evtl. schon
http://de.wikipedia.org/wiki/IPv4#Header-Format aus.

Fürs debuggen empfehle ich dann noch http://www.ethereal.com/

Matthias

Autor: Christian Schotzko (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,
hast Du schon einmal über den PSoC cy8c24794 von Cypress nachgedacht.
Ist zwar höllisch zu löten aber funktioniert wunderbar.

lG
Chris

Autor: Μαtthias W. (matthias) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

und wie bekommt er seine 80MBit/s durch die 12MBit/s von USB Full
speed?

Matthias

Autor: crazy horse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
oder wieder mal den Beck-Chip. Da hast du auch TCP/IP gleich dabei (das
selbst zu programmieren würde ich mir nie antun...)

Autor: Μαtthias W. (matthias) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

ob ein 100MHz Rechner dazu in der Lage ist zwei Datenströme a 10MByte/s
(einmal rein in den Chip und wieder raus) zu verarbeiten? Dazu dann noch
CRC und die Verpackung in UDP/IP Packete? Ich weiß nicht. Dann doch
lieber auf den eh vorhandenen GBit-Ethernet-Chip am FPGA setzen.

Matthias

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das selbst zu programmieren kommt für mich auch nicht in Frage.

Ich habe mir das UDP mal angesehen und wie ich das verstanden habe,
befindet sich unter dem UDP das IP, welches man dann auch
implementieren muss.

Ich weiß zwar theoretisch ein bißchen bescheid, aber praktisch
habe ich vom Protokoll keine Ahnung. Es geht ja dann nicht nur
darum, das Protokoll richtig zu verstehen und zu implementieren,
es geht auch dann darum, den Baustein richtig anzusteuern, damit
dieser dann die Daten korrekt rausschickt.

Das bedeutet, dass dies alles nicht so einfach ist.

@crazy horse
Was ist der Beck-Chip?
Ist dieser einfach anzusteuern und wie lautet die genaue Bezeichnung?
Gibt es hierfür ein Datenblatt?

@Matthias
Ich muss mich mal ganz genau umschauen. Ich kann mir nicht vorstellen,
dass es keine VHDL-Bibliothek für den TCP-IP-Standard gibt.

Tschüss

Martin

Autor: Bastel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie wäre es mit einem Cypress EZ USB FX2. Der Chip unterstützt USB High
Speed und wird über eine parallele Schnittstelle angesprochen.
Auf der PC Seite würde ich ein Treiber von Jungo oder Thesycon
empfehlen.

Autor: Μαtthias W. (matthias) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

@Martin
Du mußt das ja garnicht komplett implementieren. Du nimmst deine
Nutzdaten und setzt vornedran ein paar Bytes die den TCP Header bilden.
Dann nimmst du diesen Block und setzt wieder ein paar Byte vornedran die
den IP Header bilden. Dann nochmal ein paar Byte vornedran die den
Ethernet-Header bilden. Und damit dann ab an den Ethernetchip. UDP Port
und IP Adresse kannst du hart reinkodieren. Das anspruchsvollste dürfte
noch die CRC Prüfsumme sein. Für einen geübten VHDL-Programmierer
dürfte das alles kein großes Ding sein.

Aber der FX2 ist evtl. eine Alternative.

Matthias

Autor: Uwe Bonnes (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wer USB zum Pumpen von Daten verwenden will, sollte sich die FX2
Projekte Gnuradio/USRP/SSPR (http://www.gnu.org/software/gnuradio/,
www.comsec.com/wiki und http://oscar.dcarr.org/ssrp/index.php)
anschauen.

Autor: Ppp Mmm (sanic)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Für ein kleines Projekt brauche ich eine mögliche Antwortzeit von ca.
100-200 µs. Ist dafür nur USB 2.0 geeignet ?
Es ist kein großartiger Datenverkehr nötig, nur bei "Events" müssen
die Daten schnell zum Host gelangen.
Welche Möglichkeiten gibt es da ?

Grüße

Autor: René König (king)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ist dafür nur USB 2.0 geeignet ?

Kleiner Version 2.0 ist jedenfalls nicht geeignet, wenn Du das meinst.
Version 2.0 selbst reicht aber noch nicht, es muß auch High-Speed sein.
Mit Low-Speed kommst Du nur auf max. 8 Bytes alle 10 ms, Full-Speed auf
64 Bytes jede ms und High-Speed schafft max. 1024 Bytes alles 125 µs,
zumindest theoretisch. Aktuelle Spezifikation, 5.7.4, Seite 51:

"High-speed endpoints can specify a desired period (2bInterval-1)x125
μs, where bInterval is in the range 1 to (including) 16. The USB
System Software will use this information during configuration to
determine a period that can be sustained. The period provided by the
system may be shorter than that desired by the device up to the
shortest period defined by the USB (125 μs microframe or 1 ms
frame). The client software and device can depend only on the fact that
the host will ensure that the time duration between two transaction
attempts with the endpoint will be no longer than the desired period.
Note that errors on the bus can prevent an interrupt transaction from
being successfully delivered over the bus and consequently exceed the
desired period."

Autor: Tobias O. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Patrick

eine Antwortzeit von 100 - 200µSekunden wirst du mit USB nicht
erhalten.
Die Datenübertragung über USB ist packetorientiert, und in 125µSekunden
kleine Zeitabschnitte aufgeteilt. Dazu kommt noch die Verzögerung durch
das Betriebsystem und die Schichten des Betriebsystems zwischen deinem
Programm und dem Host Controller. Rechne mal eher mit 250µSekunden,
eher etwas mehr. Vergiss nicht, das der USB-Controller erst einmal das
Datenpacket erzeugen muss, bzw. seine Pins abfragen muss, ob der event
vorliegt, bis der das Packet dann auf die Reise geschickt hat, vergeht
auch nochmal eine gewisse Zeit.

G. Tobias

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Bustle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bin gerade dabei auf einen Mikrocontroller (CY7C68013A) zuzugreifen und
hab Bastel's Rat gefolgt und mal bei Theyscon und Jungo wegen Treibern
vorbeigeschaut.  Mit dem Tool von Theyscon konnte ich schon einige
Information aus dem Mikrocontroller lesen (VendorID, Endpoint
Descriptor,...). Die Preise sind nur nicht gerade billig für eine
Vollversion.

Gibt es billigere Alternativen auf einen Mikrocontroller zuzugreifen?
Es sollte High Speed fähig sein, da ich meine Geschwindigkeit nicht
schon von Anfang her einschränke.

Möchte eigentlich erstmal ganz klein Anfangen. Mal was in einen
Endpoint reinschreiben und was rauslesen,...

Autor: Ppp Mmm (sanic)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Rene:
Mein Fehler, ich meinte natürlich USB2.0 Highspeed ;-)

@Tobias O:
Ich habe mal gelesen dass man bis zu 3 Pakete in 125 µS bekommen
kann(theoretisch). Sicherlich ist dieses Zeitfenster verdammt eng.

Welche Monitoring/Debugging Möglichkeiten habe ich eigentlich wenn ich
ein USB Device implementiere ? Gibt es irgendwelche Programme die die
Kommunikation zwischen Device und Host aufzeichnen ?

Grüße,
Patrick

Autor: Bastel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Patrick
Es sind dreizehn 512Byte Pakete bei Bulktransfer(HS)pro Frame.

Autor: René König (king)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Allerdings: "There is no time guaranteed to be available for bulk
transfers as there is for control transfers. Bulk transfers are moved
over the bus only on a bandwidth-available basis. If there is bus time
that is not being used for other purposes, bulk transfers will be moved
over the bus."

Für kleine Datenmengen, die schnell zum Host müssen, eignet sich das
IMO nicht.

> Welche Monitoring/Debugging Möglichkeiten habe ich eigentlich wenn
> ich ein USB Device implementiere ? Gibt es irgendwelche Programme
> die die Kommunikation zwischen Device und Host aufzeichnen ?

Sinnvolle USB Entwicklung ist ohne Hardware-Analyzer nicht möglich,
IMO. Preisgünstig sind beispielsweise die hier:
http://www.ellisys.com/

Autor: Bastel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Bulk Transfer ist die schnellste Möglichkeit Daten über USB
auszutauschen, aber nur wenn keine andere Transfers auf dem Bus
ausgeführt werden. Z.B. wenn nur ein Divice am PC angeschlossen ist.

Es gibt eine "USB Monitor" Software von Hdd Software.

Autor: René König (king)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Der Bulk Transfer ist die schnellste Möglichkeit Daten über USB
> auszutauschen,

Darum geht es hier aber gar nicht, sofern ich Patrick richtig verstehe.
Er muß zu jeder Zeit schnell mit dem Gerät kommunizieren können, um
kleine Datenmengen zu tauschen. Das Übertragen der Daten sollte in
allen Modi schnell genug sein.


> aber nur wenn keine andere Transfers auf dem Bus ausgeführt werden.

Und genau das ist im vorliegenden Fall nicht akzeptabel. Es ist aber,
wie gesagt, möglich, daß ich das Problem noch nicht verstanden habe.


> Es gibt eine "USB Monitor" Software von Hdd Software.

Einen in Hardware gegossenen Protokoll-Analyzer ersetzt das nicht, IMO.

Autor: Ppp Mmm (sanic)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Genau so sieht es eigentlich aus.
Die "nötigen" Daten sind vielleicht 1-3 Bytes.
Beispiel:

- Gerät überwacht einen Pin.
- Pin ändert seinen Zustand -> Host soll das mitgeteilt bekommen

Dieser Spaß soll eben innerhalb von 100-300 (Schmerzgrenze) µS
passieren.

Bis jetzt habe ich daran gedacht einen AT91RM9200 und einen USB2.0
Highspeed Chip von Cypress oder Philips zu nehmen.
Hat da jemand Erfahrung welcher Hersteller die praktischeren Chips hat
?

Grüße

Autor: Μαtthias W. (matthias) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

und was macht der Host dann damit?

Du mußt dir im Klaren sein das Windows kein Echtzeitbetriebsystem ist.
D.h. ein verarbeitender Prozess kann schonmal 100ms einfach nicht
drankommen. Allein ein Prozesswechsel kann locker zehnmal so lange
dauern wie deine geforderten 300µs. (z.B. bei ausgeswaptem Speicher)
Wenn du das Ganze natürlich in einem Kerneltreiber verarbeitest ist das
was anderes wobei ich mir nicht ganz sicher bin ob Windows nicht auch
Code aus dem Kernelbereich ausswapt.

Wenn also der Host nicht auf den Pinzustand irgendwie innerhalb einer
bestimmten Zeit reagieren muss ist eine Übertragung von Pinzustand mit
einem Zeitstempel wahrscheinlich das günstigere.

Matthias

Autor: Ppp Mmm (sanic)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wer redet denn von einem Windows Host ? ;-)

Grüße

Autor: Μαtthias W. (matthias) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

was ist das dann für ein Host? Was läuft da für ein OS? Ist dieses OS
fähig in den geforderten 300µs auf ein Ereignis zu reagieren? Definier
doch einfach mal deine Umgebung.

Matthias

Autor: Bustle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn du von Cypress einen USB Highspeed Mikrocontroller nimmst. Was für
einen Treiber bastelst du dir denn?

Hab immer noch Probleme auf meinen Mikrocontroller zu zugreifen.

Autor: Ppp Mmm (sanic)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Bustle:
Ich habe nur mal gelesen dass Cypress auch Highspeed Controller
vertreibt, nachgeschaut habe ich bis dato nicht.

@Matthias:
Als Host haben wir ein recht schnelles 2-CPU System auf dem ein
Echtzeit-Linux läuft. Allerdings betreue ich diese Kiste nicht. Die
Entwickler des Systems haben mir bereits versichert (und gemessen),
dass sie innerhalb dieses engen Zeitrahmes das USB Paket bearbeiten
können.

Grüße,
Patrick

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.