mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik EZ USB Flags Problem


Autor: Bernadette (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ich hab ein VHDL Modul, das 16 bit vom FIFO liest und in einem IN 
cypress EP Buffer  schreibt.
Der usb contoller ist in slave fifo Mode asynchron getrieben.

ich verwende SLWR, FIFOADR(10), PKEND = 1, SLRD = 1 als inputs (alle 
Flags Low activ)für den cypress
SLCS Flag hab ich weggelassen
als output bekomme ich FULL Flag Signal

Problem:
1-Die daten kommen nicht vollständig zu PC:
Ursache: Der Full Flag cypress output(Low activ), der mein VHDL Modul 
steuert bleibt zu lange auf null -> die Folge: Daten Stau in FPGA FIFO 
und FPGA Eingangsdaten gehen verloren.

Wie kann ich das Problem lösen?
Gruß
bernadette

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Darfst halt nur Daten aus dem FIFO lesen, wenn das Full-Flag nicht low 
ist. Datenstau ist noch kein Datenverlust. Wenn du streaming machen 
willst, also vorne schreibt einer Daten ins FIFO und du liest das FIFO 
per USB aus, kann es natürlich zu Datenverlust kommen, wenn die FIFOs zu 
klein sind. Das Betriebssystem hat gerne mal was anderes zu tun, als 
Daten vom USB abzuholen, besonders bei BULK Transfer. Willst du eine 
garantierte Bandbreite musst du isochronen Transfer machen, oder die 
FIFO Speicher drastisch erhöhen.
Arbeitest du mit doppelt-gepufferten IN_FIFO am Cypress? Wir haben wir 
4-fach gepuffert, davor einen riesen FPGA-Internen FIFO und trotzdem 
bleibts immer mal für 20ms stehen, weil das OS gerade nix abholen mag.

Autor: Bernadette (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ christian
Vielen Danke für deine Antwort!
ja ich arbeite mit double buffering
Bulk mode
FPGA FIFO 8K groß
am Eingang vom usb controller ist die Datenrate 21,2 Mbit/s
in meiner PC Anwendung die datenrate ist auch 21,2 Mbit/s.

sowie ich das verstanden hab, du meinst dass der usb controller 
unschuldig ist?

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, das ist halt das Problem. Standard-Windows und Standard-Linux sind 
nicht echtzeitfähig. Deshalb kann das abholen der Daten nicht garantiert 
werden. Bei BULK sowieso. BULK Transfer wird gemacht, wenn sonst nix 
anderes auf dem Bus ist. Man erreicht damit zwar durchschnittlich die 
höchsten Datenraten, aber eben nicht in genauen Abständen. Bei unseren 
Intel-Bürorechnern hier hab ich Lücken von max. 25ms ausgemessen, in 
denen keinerlei USB Transfer von/zum FX2 stattfindet. Das solltest du 
mit einem Osziloskop mal messen. Dementsprechend müssen die FIFO-Puffer 
dimensioniert sein. Bei dir wären das mindestens 54 kByte FIFO, wenn du 
20ms überbrücken willst! In der Praxis aber eher noch mehr. Ich denke, 
mit 128kByte FIFO wirst du eventuell deine Datenrate kontinuierlich 
schaffen (also auf der FIFO-Schreib-Seite).
Ansonsten schafft der FX2LP durchschnittlich etwa 41 MByte/s im BULK 
Modus mit Slave FIFO und Quad-Bufferung bei 512 Byte Paketgröße.
Vielleicht solltest du über isochronen Transfer nachdenken. Da kann man 
ziemlich genau 24 MByte/s erreichen. Allerdings wird dann bei 
Datenverlust nix wiedrholt, lediglich gemeldet, dass ein Fehler 
aufgetreten ist.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Übrigens....wieso asynchron....das macht man doch nicht, wenn´s keinen 
zwingenden Grund gibt.

Autor: Bernadette (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na ja!
asynchron Mode hab ich nicht ausgewählt, und niemand will das ändern. es 
ist ein standard für andere applictions, die nicht mit meiner aufgabe zu 
tun haben.
mit dem Oszi hab ich 384 ms Lücken, das heisst ich soll ein sehr sehr 
grossen FIFO verwenden und so viele ressourcen hab ich nicht zu 
verfügung.

hat die synchrone betriebsart einfluß auf die full flag lücken?

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernadette wrote:
> Na ja!
> asynchron Mode hab ich nicht ausgewählt, und niemand will das ändern. es
> ist ein standard für andere applictions, die nicht mit meiner aufgabe zu
> tun haben.

Achso. Synchrones Interface macht das FPGA Design aber leichter...

> mit dem Oszi hab ich 384 ms Lücken, das heisst ich soll ein sehr sehr
> grossen FIFO verwenden und so viele ressourcen hab ich nicht zu
> verfügung.

Hm....mal schnelleren Rechner und/oder anderen USB Host Controller 
auswählen? Welche Software holt denn die Daten ab? Sowas wie LabView? 
Wir holen hier über den Cypress-Treiber asynchron mit C# Programm die 
Daten. Da haben wir bisher maximal 25ms Lücken gehabt.

> hat die synchrone betriebsart einfluß auf die full flag lücken?

Nö.

Autor: Bernadette (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
eine C# applikation liest die usb daten, sie hat einen direkten zugriff 
auf den treiber, und damit verliert sie nicht viel zeit

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hm komisch. Das geht bei uns deutlich schneller. Zumindest auf den 
aktuellen Rechnern. Sind hier HP-Rechner mit Intel Board und ICH9. Hast 
du mal versucht, die Kernel-Transfer-Size hochzusetzen? Bei uns läufts 
am schnellsten mit 128k TransferSize.

Autor: Bernadette (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich hab einen fujitsu siemens rechner (intel core 2 vpro),
OS windows xp
Tranfersize untersuche ich gerade

Autor: Bernadette (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
die anwendung ist so programmiert, dass sie jedes mal nur 512 Byte liest
Könnte das die ursache von diesen grossen lücken sein?

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, das ist äußerst unklug. Wir haben dann nur etwa 3...5MB/s geschafft. 
Man muss schon in großen Blöcken lesen und die Transfer Size 
hochschrauben. Dann wirds besser. Aber die 20ms Lücken sind bei uns 
trotzdem da.

Autor: Bernadette (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ christian
Das werde ich in den näschten tagen tun.
vielen vielen dank für deine hilfe
frohe feiertagen!

Autor: Thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammmen,

ich habe eine kurze frage.

Ich habe mir den Thread hier gerade durchgelesen und verwende auch den 
FX2.
Ich kann im FX2 einen Buffer pro EP nur einen Buffer von X(512,1024) 
einstellen. Richtig ?

In der C# Applikation kann ich angeben wieviele Bytes gelesen werden 
sollen.

Dem Thread hier habe ich entnommen, dass es Sinn macht die zulesenden 
Bytes größer zu wählen als die in der Firmware eingestellt sind.

Beispiel(1. Frage):

Firmware EP2 IN 512 bytes Doublebufferd
PC liest immer nur Blöcke der größe 512 byte. Dann ist die max. 
Übertragungsgeschwindigkeit 3-5 Mybte/Sek. RICHTIG?

Beispiel(2. Frage):

Firmware EP2 IN 512 bytes Doublebufferd
PC liest immer nur Blöcke der größe 1024 byte. Dann ist die max. 
Übertragungsgeschwindigkeit größer als im Beispiel 1 RICHTIG?

Gruß

Thomas

Autor: Mars (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Chris!

Wie genau liest du die Daten vom FX2? Bei heutigen Quadcore-CPUs à 3GHz 
kann ich mir die Verzögerung von 25ms nur schwer vorstellen, zumal die 
eigentliche Arbeit ja der USB Host Controller in Hardware erledigt. 
Verwendest du mehrere Threads zum Lesen?

Grüße

Autor: Mars (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Thomas

Nein, es mach Sinn so viele Bytes zu lesen, wie du vom µC erwartest.
Falls deine Firmware Daten zum PC streamt d.h. dauernd mit hohem 
Datendurchsatz sendet kannst du den Lesepuffer gar nicht groß genug 
machen.
Bedenke, dass du alle ~10us bei HS einen Block liest. Um den 
Datendurchsatz zu erhöhen, solltest du so selten wie möglich die Read 
Methode aufrufen. Somit große Puffer anlegen und oder mehrere Threads 
zum Lesen verwenden.

In der FX2 FW kannst du den EP-Puffer nur auf 512(BULK) bzw. 1024(ISO) 
einstellen, jedoch hindert dich niemand daran weniger Bytes zu senden 
auch 0 Bytes sind erlaubt.

Grüße

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mein Bürorechner hat einen C2D mit 1,833GHz, außerdem jede Menge 
Software installiert. Das hindert sicher auch den Transfer. Zumal die 
Pausen ziemlich genau alle 1 Sekunde auftreten, wie ich gestern gemessen 
habe. Wer weiß, was Windows da spielt....

Aber da wir genug Puffer vorgesehen haben und auch mehrere Datensätze 
zusammenfassen können, wird das sicher nicht mehr auftreten, sobald die 
PC-Software diese Pufferung kann. Ist alles noch in Arbeit...

Autor: Thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo nochmal
@ Mars
wie soll ich folgende Aussagen verstehen :

Ja, das ist äußerst unklug. Wir haben dann nur etwa 3...5MB/s geschafft.
Man muss schon in großen Blöcken lesen und die Transfer Size
hochschrauben. Dann wirds besser. Aber die 20ms Lücken sind bei uns
trotzdem da.


Wenn ich die Firmware auf Bulktransfer einstelle (512 Byte, double 
bufferd) und aus einem EP jeweils 512 Byte blöcke lese komme ich auf ca. 
3 Mbyte / sek.

Welches ist die richtige schraube an der gedrecht werden soll damit ich 
auf 20 Mbyte komme? Oder komme ich nur auf solche datensätze wenn ich 
aus mehreren EP lese?

Gruß

Thomas

Autor: Mars (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nein, auf der PC Seite solltest du nicht nur 1KB lesen, sondern 1MB oder 
mehr. Und auf der µC Seite musst du natürlich den GPIF oder Slave FIFO 
Modus verwenden. Der 8051 alleine schafft nie 480MBit.

Grüße

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn du für jedes 512 Byte Stückchen einen neuen Transfer startest, 
gehts nicht schneller, weil ja immerfort ein neues Paket angerfordert 
werden muss. Wenn die Daten auf der Hardware-Seite verfügbar sind, dann 
kannst du gleich viel mehr anfordern, der USB Host-Controller bzw. USB 
Stack kümmert sich dann selbständig um die Paketbildung und sammelt die 
Pakte ein, bis alles da ist oder Timeout kommt.
Der Hintergrund ist der: Wenn du für jedes 512 Byte Paket eine extra 
Anfrage stellst, kann nur dieses eine Paket in einem Microframe 
transportiert werden. Ein Microframe ist 125µs lang. Jetzt bekommst du 
alle 125µs 512 Byte, was etwa 4MB/s sind. Stellst du jetzt eine Anfrage 
über sagen wir mal 12 Pakete a 512 Byte, dann kann der USB Controller 
den Microframe voll packen, da gehen maximal 11 Pakete zu je 512 Byte 
rein. Und schwupps, ist man bei über 40 MB/s. Das paraktische Maximum 
ist 42MB/s, weil die Auslastung mal 10 und mal 11 Pakete ist. Warum, 
weiß ich aber auch nicht. Kann man schön mit einem schnellen Oszilloskop 
direkt an D+ oder D- beobachten.

Autor: Bernadette (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!
Mars wrote:
Nein, auf der PC Seite solltest du nicht nur 1KB lesen, sondern 1MB oder
mehr. Und auf der µC Seite musst du natürlich den GPIF oder Slave FIFO
Modus verwenden. Der 8051 alleine schafft nie 480MBit.

Speicher im Kernel ist begrenzt. Gibt es keine andere alternative?

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Speicher begrenzt? Die Kernel Transfer Size kann man bis auf 3MB 
hochsetzen, erst dann gehts nicht mehr. Außerdem kannst du beim Lesen 
viel mehr als 1k anfordern, und das bekommst du auch, wenn die Daten 
schnell genug von der Hardware angeliefert werden und das Timeout nicht 
abläuft.

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.