Hallo, ich möchte in einem Projekt zur Datenerfassung die USB-Schnittstelle des ARM 7 Controller AT91SAM7X als Interface zum PC nutzen. Die Datenerfassungsplatine mit dem ARM besitzt einen großen Speicher (ca. 256MB oder mehr) deshalb möchte ich wegen der geringen Geschwindigkeit keine virtuelle COM-Schnittstelle implementieren. Fragen: 1. Welche Device Class wäre zu empfehlen? Ich möchte dabei unbedingt auf etwas wie z.B. dem USB-Framework von Atmel aufbauen. 2. Welche Datenrate kann man dann erwarten. Danke und Gruß - Frank
Kennt sich damit wirklich niemand aus? Gebt Euch doch mal 'nen Ruck - Ihr wisst's ;-)
1. Die Frage ist, wo du dir wieviel Arbeit machen willst, du musst ja dann auch nen Treiber für die Windows Seite haben. Für CDC, MSD und so gibts natürlich Windows Standard USB Treiber, aber ich würde dir eher BULK Transfer empfehlen. Willst du denn unbedingt alles selber programmieren oder auch Middleware kaufen? Ich weiß, das SEGGER (www.segger.com) nen sehr guten USB Stack hat, mit allem drum und dran und narrensicher zu benutzen. Kostet so um die 1600,- Euro. http://segger.com/emusb.html
@ Til: Danke für die Antwort! Geld wollte ich für die Software eigentlich nicht ausgeben. Welche Datenraten kann man denn mit den zur Verfügung gestellten Klassen erreichen?
Naja, der hat doch eh nur FullSpeed....da wird 256MByte Daten auslesen sehr lustig. Bau doch lieber einen Cypress FX2 an die Kiste, da hast du sehr simpel Bulk-Datentransfer bis zu 40 MByte/s je nach PC.
@Frank, dir ist schon klar dass 256MB selbst bei theoretischem Betrachten mehrere Minuten dauert!? Realistisch mit einem guten Stack und der PC macht in der Zeit nichts anderes ueber USB sind im Bereich von 500 kB / sec, das waeren also > 8 Minuten. Es geht allerdings auch VIEL langsamer wenn die Implementierung nicht so dolle ist. Robert
>Ich weiß, das SEGGER >(www.segger.com) nen sehr guten USB Stack hat, mit allem drum und dran >und narrensicher zu benutzen. Kostet so um die 1600,- Euro. den preis kann ich mir beim besten willen nicht vorstellen. vor allem wenn man weiß das der stack von hier "stammt" (wie auch der von IAR): http://www.micrium.com/products/usb/usb-device/overview.html und die preisliste von micrium weist "etwas" höhere beträge aus. gruss gerhard
@Robert, nein Robert, das ist mir nicht klar - genau das ist die Frage - also warum geht's nicht schneller? Was wäre die Lösung? Also mir wären Erklärungen lieb, wenn alles klar wäre, würde ich das Thema nicht ins Forum stellen. Vorschläge sind also herzlich willkommen. Gruss - Frank
@frank: welche "wunderdinge" erwartest du dir den von einem usb full speed device? gruss gerhard
Also Du musst jetzt mal etwas genauer entscheiden, was Du willst. Das CDC Device ist recht leicht implementiert und wird von ATMEL als Grundegrüst schon mitgeliefert. Es kommt ohne Windows-Seitigen Treiber aus, jedenfalls ohne einen, den man erst selber schreiben muss. Dafür kann man vermutlich nur eine theoretische Datenrate von 12MBit erreichen, die durch Framing und andere Overheads wohl eher bei 7..9Mbit liegt. Das sind geschätzte und gerundete 8MByte/s. Die Übertragung Deiner 256MB würden damit 32s dauern. Wenn Du damit leben kannst, dann ist das der einfachste Weg. Ein Missverständnis ist beim CDC Device ( COM-Port via USB), dass die USB Datenrate mit der für die Schnittstelle eingestellten Datenrate überein stimmt. Die Datenrate des virtuellen COM-Ports definiert die Rate des am USB angeschlossenen UARTs aber nicht die des USBs. Der USB sendet immer mit der Geschwindigkeit seiner eigenen Klasse, also 1Mbit/12MBit... 470?Mbit Das CDC Device kann auch effektiv oder langsam genutzt werden. Man kann jedes einzelne Byte in ein USB Frame packen und versenden. Das erzeugt jede Menge Overhead und bremst ein 12Mbit Device vermutlich auf 500kByte herunter. Besser ist es da, sein CDC Device so zu implementieren, dass immer vollständige Frames gepackt werden, die nur einmal Overhead erzeugen. Ein einfacher Weg große Datenmengen komfortabel zu übertragen kann aber auch das Memory-Device sein ( weiß die Abkürzung jetzt nicht). Dazu emulierst Du ein Pseudo-Dateisystem, dass Deine Messwerterfassungs-Datei abbildet. Du ziehst dann im Explorer Deine Messwertdatei einfach irgendwo hin und es wird kopiert. Ob Du das Schreiben auch implementierst, oder das ganze als ReadOnly machst und per Knopfdruck an Deinem gerät die Datei löschst / auf Länge 0 setzt, das ist Deine Entscheidung. Auch dazu gibt es ein Code-Gerüst von ATMEL zum Download für die AVR, ARM7 und ARM9. Auch hier ist kein spezieller Treiber auf der Windows Seite nötig. Leider gibt es bei den Klassen von Windows einige Probleme, weswegen es vom Hörensagen her nicht geht über einen Device Port ein Memory und ein CDC Device gleichzeitig abzubilden. Hier muss dann ein eigener Treiber geschrieben werden. Du musst also entscheiden, ob Du nur die Daten übertragen willst, oder ob Du das gerät auch über diesen Port steuern willst. Grundsätzlich ist zum USB noch zu sagen, dass es ein Zeitmultiplex System ist. Alle angeschlossenen geräte teilen sich die Bandbreite. Ergo ist verschieben von Daten auf einem USB-Bus stark davon abhängig, wer da noch so alles dran hängt. Gruß, Ulrich
@ulrich: >Dafür kann man vermutlich nur eine theoretische Datenrate von 12MBit >erreichen, die durch Framing und andere Overheads wohl eher bei 7..9Mbit >liegt. Das sind geschätzte und gerundete 8MByte/s. kann es sein, daß du da bit und byte ein bischen durcheinander bringst? und eines ist auch sicher, der overhead einer usb verbindung ist sicher größer als deine geschätzten 25%. mein tipp für alle die nicht die zeit haben sich mit 600 seiten usb spezifikation zu beschäftigen: http://www.beyondlogic.org/usbnutshell/usb-in-a-nutshell.pdf gruss gerhard
> >Ich weiß, das SEGGER > >(www.segger.com) nen sehr guten USB Stack hat, mit allem drum und dran > >und narrensicher zu benutzen. Kostet so um die 1600,- Euro. > den preis kann ich mir beim besten willen nicht vorstellen. > vor allem wenn man weiß das der stack von hier "stammt" (wie auch der > von IAR): > http://www.micrium.com/products/usb/usb-device/overview.html > > und die preisliste von micrium weist "etwas" höhere beträge aus. > > gruss > gerhard Es ist relativ uninteressant was du dir vorstellen kannst oder nicht, schau doch einfach bei Segger auf die Website, da stehen die Preise, die sind doch kein Geheimnis und du musst dir nichts vorstellen ;-). Wieso stammt der Segger USB Stack von Micrium? Wie kommst du da drauf? Und wenn du von IAR redest, meinst du wohl das IAR PowerPac, und du meinst, das kommt von Micrium?? ;-)
>Es ist relativ uninteressant was du dir vorstellen kannst oder nicht, >schau doch einfach bei Segger auf die Website, da stehen die Preise, die >sind doch kein Geheimnis und du musst dir nichts vorstellen ;-). wenn ich mir die segger-preisliste ansehen dann sehe ich, das ich um 1600€ die "USB core component" bekomme und damit eigentlich nichts anfangen kann. die "emUSB MSD component" kommt noch dazu (750,-€). und vermutlich werde ich auch einen "emUSB target driver AT91SAM7X" benötigen (650€). noch fragen zum thema kosten? >Wieso stammt der Segger USB Stack von Micrium? >Wie kommst du da drauf? ist anhand der vorhandenen sourcecode auszüge und der tatsache, das micrium den usb stack schon länger anbietet, naheligend. >Und wenn du von IAR redest, meinst du wohl das IAR PowerPac, und du >meinst, das kommt von Micrium?? ;-) wer den iar stand auf der embedded world sich genau angesehen hat kann das wohl bestätigen. gruss gerhard
Also bei der ganzen Diskussion über USB-speed denke ich, wer bis ins letzte Detail wissen will warum netto keine 12Mbit fullspeed übrig bleiben, sollte wohl doch mal die USB-spec. genauer lesen. Da gibts alles zu "Transfers", "Transactions", "Packets" , ACK/NAK, SOF, EOP-times, Idle-times usw... Wer dann auch noch verstanden hat, daß jedes Paket (64byte üblich bei Bulk-EPs) in ein Framing verpackt ist, mit 12Mbit phys. übertragen wird, gehandshaked wird und dann die Pause beginnt, die die meinsten Vergessen - der Absender muß das nächste Paket bereitstellen / der Empfänger muß das Paket verdauen - kann selbst errechnen, was netto bleibt. Und wenn dann die Software noch "ne" Aufgabe bekommt wie TCP/IP bricht dieser Wert weiter ein (siehe bereitstellen/verdauen). Also meine Erfahrung besagt, es sind bis zu netto 6,5Mbit erreichbar bei DMA-support am USB und "fast" ohne zuätzliches Protokoll wie MassStorage mit hervorragender FTL. Alle anderen Use-cases lagen darunter. Wer dann den Protokoll-Overkill sucht nimmt RNDIS (44byte overhead) + Ethernet + TCP/IP + Applikation. Oder man macht es wie einige USB-seriell Adapter, die jedes Byte einzeln in USB-Frames verpacken und transportieren. Und wer nun eindeutig mehr netto-speed braucht sollte sich für USB-highspeed mit 480Mbit brutto entscheiden (bereitstellen/verdauen - also CPU-speed aber nicht vergessen).
> wenn ich mir die segger-preisliste ansehen dann sehe ich, das ich um >1600€ die "USB core component" bekomme und damit eigentlich nichts > anfangen kann. >die "emUSB MSD component" kommt noch dazu (750,-€). und vermutlich werde >ich auch einen "emUSB target driver AT91SAM7X" benötigen (650€). >noch fragen zum thema kosten? Ja, das das nur die Core Komponente ist, gebe ich dir recht, klar, brauchste noch Bulk oder was auch immer und nen Treiber. Ging mir ja auch mehr um die Aussage das der Stack von Micrium ist und deine Argumentation dafür ;-). > ist anhand der vorhandenen sourcecode auszüge und der tatsache, das > micrium den usb stack schon länger anbietet, naheligend. Das mit den Sourcecodeauszügen musst du mir mal näher erklären, was du da meinst. Micrium bietet den schon länger an...glaub ich irgendwie nicht...;-)... aber lass dich bitte nicht von mir ärgen, ich bin da wohl etwas näher dran. > wer den iar stand auf der embedded world sich genau angesehen hat kann > das wohl bestätigen. Auch das würde ich dich bitten etwas näher zu erklären, ich habe mir den Stand auch recht genau angesehen (hab auf dem Stand nebenan gearbeitet... ich denke wir verstehen uns jetzt ;-) ) gruss Til
>Also meine Erfahrung besagt, es sind bis zu netto 6,5Mbit erreichbar
Kann ich nur bestätigen, auf einem AT91SAM7S256 habe ich auch knapp über
800 kB/s erreicht. Bulk mit libusb "Treiber". Der µC ist dann aber auch
schon gut beschäftigt.
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.