Hallo zusammen,
Ich arbeite gerade mit dem Evaluation Board STM32446 um den Protocol USB
CDC FS zu nutzen. Ich kann schon Daten am Computer senden bzw. empfangen
aber jetzt möchte ich wissen, mit welcher Geschwindigkeit die
Übertragung der Daten wirklich ist. Kann ich das am besten per Software
oder Hardware durchführen?.
Kann ich diese Zeit der Übertragung in den Pins PA12 (Data+) und
PA11(Data-) in einem Oszilloskop messen?
uint8_t mystring[] = "Hello";
int main(void)
{
/* STM32F446xx HAL library initialization */
HAL_Init();
/* Configure the system clock to 180 MHz */
SystemClock_Config();
MX_GPIO_Init();
/* Init Device Library */
USBD_Init(&USBD_Device, &VCP_Desc, 0);
/* Add Supported Class */
USBD_RegisterClass(&USBD_Device, USBD_CDC_CLASS);
/* Add CDC Interface Class */
USBD_CDC_RegisterInterface(&USBD_Device, &USBD_CDC_fops);
/* Start Device Process */
USBD_Start(&USBD_Device);
/* Run Application (Interrupt mode) */
while (1)
{
CDC_Transmit_FS(mystring,strlen((const char*)mystring));
HAL_Delay(1000);
}
}
Hallo zusammen,
Ich arbeite gerade mit dem Evaluation Board STM32446 um den Protocol USB
CDC FS zu nutzen. Ich kann schon Daten am Computer senden bzw. empfangen
aber jetzt möchte ich wissen, mit welcher Geschwindigkeit die
Übertragung der Daten wirklich ist. Kann ich das am besten per Software
oder Hardware durchführen?.
Kann ich diese Zeit der Übertragung in den Pins PA12 (Data+) und
PA11(Data-) in einem Oszilloskop messen?
uint8_t mystring[] = "Hello";
int main(void)
{
/* STM32F446xx HAL library initialization */
HAL_Init();
/* Configure the system clock to 180 MHz */
SystemClock_Config();
MX_GPIO_Init();
/* Init Device Library */
USBD_Init(&USBD_Device, &VCP_Desc, 0);
/* Add Supported Class */
USBD_RegisterClass(&USBD_Device, USBD_CDC_CLASS);
/* Add CDC Interface Class */
USBD_CDC_RegisterInterface(&USBD_Device, &USBD_CDC_fops);
/* Start Device Process */
USBD_Start(&USBD_Device);
/* Run Application (Interrupt mode) */
while (1)
{
CDC_Transmit_FS(mystring,strlen((const char*)mystring));
HAL_Delay(1000);
}
}
Ich implementiere das Beispielprogramm (USB CDC Standalone) von dem EvaluationBoard STM32446E um Daten nur per USB senden bzw empfangen zu können. Das scheint gut zu funktionieren, aber jetzt möchte ich wissen, wie hoch diese Geschwindigkeit der Datenübertragung ist. Wie könnte ich das messen?
Student schrieb: > Wie könnte ich > das messen? Am PC die einen Zeitstempel nehmen, dann viele Daten senden, dann wieder einen Zeitstempel nehmen?
Das ist was ich sende,
uint8_t mystring[] = "Hello";
int main(void)
{
/* STM32F446xx HAL library initialization */
HAL_Init();
/* Configure the system clock to 180 MHz */
SystemClock_Config();
MX_GPIO_Init();
/* Init Device Library */
USBD_Init(&USBD_Device, &VCP_Desc, 0);
/* Add Supported Class */
USBD_RegisterClass(&USBD_Device, USBD_CDC_CLASS);
/* Add CDC Interface Class */
USBD_CDC_RegisterInterface(&USBD_Device, &USBD_CDC_fops);
/* Start Device Process */
USBD_Start(&USBD_Device);
/* Run Application (Interrupt mode) */
while (1)
{
CDC_Transmit_FS(mystring,strlen((const char*)mystring));
HAL_Delay(1000);
}
}
Auf der Datei des Boards steht, dass die Geschwindigkeit bei 12Mbts
beträgt, Das ist das ich messen möchte.
Student schrieb: > Auf der Datei des Boards steht, dass die Geschwindigkeit bei 12Mbts > beträgt, Das ist das ich messen möchte. Das ist nicht die Datenrate, die Du per CDC erreichen kannst, das ist die Bruttodatenrate von "Full-Speed"-USB. Die hat "Full-Speed"-USB immer. Und daher kannst Du diese Bruttodatenrate auch nicht sinnvoll messen.
Ja, stimmt. Dann wenn ich zB das per USB sende uint8_t mystring[] = "Hello"; oder wenn ich etwas in dem Board per Hterminal empfange, Kann ich irgenwie die Zeit messen, die mein Board um diese Daten zu übertragen benötigt?
Du kannst messen, wie lange die Ausführung der Funktion "CDC_Transmit" dauert - dazu verwendest Du einen I/O-Pin, den Du als Ausgang konfigurierst, legst den unmittelbar vor Aufruf der Funktion auf High und unmittelbar nach Aufruf der Funktion auf Low. Mit einem Oszilloskop kannst Du die Dauer des High-Pulses bestimmen.
1 | while (1) |
2 | {
|
3 | SetMyIoPin(1); |
4 | CDC_Transmit_FS(mystring,strlen((const char*)mystring)); |
5 | SetMyIoPin(0); |
6 | |
7 | HAL_Delay(1000); |
Anstatt von "SetMyIoPin" musst Du natürlich was zu Deinem µC passendes einfügen.
Rufus Τ. F. schrieb: > Du kannst messen, wie lange... Ach Rufus, laß mal. Der TO hat noch nicht kapiert, daß all seine Zeiten und Durchsätze zum größten Teil davon abhängen, wie doof man sich auf der µC-Seite beim zuständigen Handler anstellt. Auch bei den USB-Cores von ST gibt es die Möglichkeit, mit mehreren verschiedenen Blockpuffern zu arbeiten, so daß der µC einen Puffer füllt (oder leert), während der andere gerade im USB-Procedere hängt. Aber das ist bei stinknormalen CDC eher unüblich, weil's dort eigentlich nicht benötigt wird. Jetzt versucht der TO mit einem Standard-Zeugs von ST's Stange zu arbeiten und sendet "hello". Als ob's das bringen könnte... Wäre was anderes, wenn er mit 4..8K großen Blöcken anrücken würde. W.S.
Rufus Τ. F. schrieb: > Du kannst messen, wie lange die Ausführung der Funktion "CDC_Transmit" > dauert Das wird nichts bringen denn wahrscheinlich kopiert die einfach nur die paar Bytes in den nächsten freien TX Puffer des betreffenden Endpoints und setzt ein paar bits um den Puffer für den DMA des USB-Controllers als abholbereit zu markieren.
Was wäre denn sinnvoll schicken oder empfanden um eine beachtliche Zeit der Übertragung per USB messen zu können? ... Ich kenne mich nicht so gut mit dem USB CDC Protocol,
Etwas GROßES wäre angebracht. Irgendwas zwischen 10 und 100 MB an Daten müssen es mindestes sein um halbwegs verlässlich sagen zu können was genau Dein PC mit der aktuellen Auslastung im Durchschnitt kann. Der STM32F4 schafft mit FS USB und original ST-Stack nach dem Fixen einiger Bugs knapp 1 MiB/s (was echt gut ist für FS USB). Mit HS USB gehen ca 7,5 MiB/s, aber da limitiert der Standard-Treiber auf PC-Seite. Messen Kannst Du mit irgendeinem selbstgeschriebenen Programm oder auch Wireshark. Und jetzt sag bloß Du wolltest nicht den Durchsatz sondern die Latenz...
Karl schrieb: > Mit HS USB gehen ca 7,5 MiB/s, aber da limitiert der Standard-Treiber > auf PC-Seite. > > Messen Kannst Du mit irgendeinem selbstgeschriebenen Programm oder auch > Wireshark. > > Und jetzt sag bloß Du wolltest nicht den Durchsatz sondern die Latenz... Vielen Dank für die Antwort, Ich habe gerade das Programm für HS USB, Hättest du eine Idee, wie ich zwischen 10 und 100 MB an Daten senden kann um die 7,5 MiB/s, messen zu können?
Bitte die https://www.mikrocontroller.net/user/conditions berücksichtigen! Keine Teilname an einer Diskussion unter zwei verschiedenen Namen! (Und es ist im übrigen sinnlos, die exakt gleiche Frage im Abstand von drei Stunden zu wiederholen, nur weil noch niemand in der Zwischenzeit geantwortet hat)
Danke für eure Antworten, und Entschuldigung für die Störung (Ich bin neu hier)
Noch mal , vielen Dank an alle für eure nette Antworten. Ich habe schon eine Lösung für das gefunden, und jetzt habe ich die Geschwindigkeit gemessen und komme auf ca. 8,23MByte pro Sekunde. Ich hätte zuerst alle über USB- Protokoll lesen müssen. ... Ich möchte auch euch alle mich zu entschuldigen, weil ich hier auf der Webseite mit verschiedenen Namen die gleiche Frage gestellt habe, ich wollte nur Ruckmeldungen bekommen.
Ist für mich schon lange her jedoch bin ich mir sicher das du da mit deinen 8,xx MByte/s nur falsch liegen kannst.. Im Standard CDC (auch bei ST) sind für Daten ein Bulk IN und ein Bulk OUT inplementiert. Bulk entpunkte können ein mal je ms Daten senden bzw empfangen. Die Paketgröße beträgt 64 byte, wirst du sicher rechnen können wieviel KByte/s du da maximal erreichen kannst..
Zero schrieb: > Bulk entpunkte können ein mal je ms Daten senden bzw > empfangen Geht das an USB 2 oder mit einem USB-2 Hub nicht auch im 1/8 ms Raster?
Rufus Τ. F. schrieb: > Und daher kannst Du diese Bruttodatenrate auch nicht sinnvoll messen. Außerdem hat die zusätzlich nichts mit der CDC-Übertragungsrate zu tun. Man muss sich von dem Gedanken verabschieden, dass eine USB-CDC das eine irgenwie isochrone Geschichte wäre. Will heißen: Zeitverhalten und Übertraungsrate ist nicht vorhersagbar. Das ist USB Bulk-Tranfer, wenn ich mich richtig erinnere, und damit per Definition nicht vorhersagbar. Denn da wird übertragen "wenn gerade mal Zeit frei ist". Was das für das Verhalten bedeutet, wenn man hinter einem Hub hängt (wie fast immer!), kann sich jeder denken - Abhängig vom Host und Hub. Was ich aus eigenen Projekten weiß: Große Datenmengen gehen üblicherweise realtiv "schnell". Also viel schneller als RS232, MBIT sind drin. Aber unkonstant. Die Laufzeiten sind dagegen völlig unvorhersagbar. Manchmal geht es schnell, manchmal dauert es >100ms. --> Eine CDC eignet sich für zeitkritische Übertragungen einfach nicht. Für sowas macht man ein "richtiges" USB-Device.
Zero schrieb: > Ist für mich schon lange her jedoch bin ich mir sicher das du da mit > deinen 8,xx MByte/s nur falsch liegen kannst.. > Im Standard CDC (auch bei ST) sind für Daten ein Bulk IN und ein Bulk > OUT inplementiert. Bulk entpunkte können ein mal je ms Daten senden bzw > empfangen. Die Paketgröße beträgt 64 byte, wirst du sicher rechnen > können wieviel KByte/s du da maximal erreichen kannst.. rolleyes Bulk kann einmal pro Frame (1 ms) Daten übertragen und ein Paket ist auch max. 64 Bytes wenn man so will, aber wenn man die Übertragung nicht mit einem Paket < 64 Byte oder einem ZLP abbricht, kann man den ganzen Frame über Pakete übertragen. uwebonnes schrieb: > Geht das an USB 2 oder mit einem USB-2 Hub nicht auch im 1/8 ms Raster? Ja. Microframe nennt sich das dann. Hat aber mit der obigen Fehlinterpretation nichts mehr zu tun. Gästchen schrieb: > ... > --> Eine CDC eignet sich für zeitkritische Übertragungen einfach nicht. > Für sowas macht man ein "richtiges" USB-Device. Jain. Kommt wie immer auf die Anforderungen an. Es gibt haufenweise "professionelle" Messtechnik die auch gut funktioniert und dann doch einen FTDI drauf hat der CDC macht. Garantieren kann natürlich niemand nichts aber in der Regel klappt es sehr gut. Ein ausrechend großer Puffer auf Device-Seite muss natürlich sein. Atomkraftwerke aber bitte doch mit dem Parallelport steuern ;-)
Karl schrieb: > Atomkraftwerke aber bitte > doch mit dem Parallelport steuern ;-) Genau! Dazu gibt es doch den FT245 :-)
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.