VCP unerkennbar STM32F4

[Lalo (Gast)]

Guten Tag,

Ich möchte das Protocol USB mit dem Board STM32F4 implementieren.

Hier mein Code:

uint8_t  Data[] = "0123456789qwertzuioP";

int main(void)
{

  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)
  {

    HAL_GPIO_WritePin(GPIOB, GPIO_PIN_12, 1);
    CDC_Transmit_FS(Data,strlen((const char*)Data));
    HAL_GPIO_WritePin(GPIOB, GPIO_PIN_12, 0);
    HAL_Delay(100);

  }
}



1) Mein Problem liegt daran, dass wenn ich mehr als 97 Zeichen in Data[] 
sende, ist mein VCP nicht mehr im Computer erkennbar.
Was kann es sein?

2) Wie könnte ich die Geschwindigkeit für das senden von einem Block 
messen?  Hättet ihr eine Idee?

Ich versuche mit einer I/O Pin die Dauer der Ausführung der Funktion 
CDC_Transmit_FS zu messen, aber hat das etwas mit der Geschwindigkeit 
der Übertragung etwas direkt zu tun?


Vielen Dank

[jo (Gast)]

>Wie könnte ich die Geschwindigkeit für das senden von einem Block
>messen?  Hättet ihr eine Idee?

Moin. Freien pin als ausgang konfigurieren. pin auf high setzen. ZU 
messende aktion ausführen. pin auf low setzen. Mit Qszi / Frequenzzähler 
am freien Pin die ON Zeit messen.

>Mein Problem liegt daran, dass wenn ich mehr als 97 Zeichen in Data[]
>sende, ist mein VCP nicht mehr im Computer erkennbar.
>Was kann es sein?

Bufferoverflow auf pc seite.



Gruß J

[Lalo (Gast)]

jo schrieb.
> Moin. Freien pin als ausgang konfigurieren. pin auf high setzen. ZU
> messende aktion ausführen. pin auf low setzen. Mit Qszi / Frequenzzähler
> am freien Pin die ON Zeit messen.


Auf diese Webseit
http://mikrocontroller.bplaced.net/wordpress/?page_id=1263

Sag er:

Bei einer Geschwindigkeitsmessung für das senden von einem Block von 
1024 Bytes vom PC zur CPU bin ich auf ca. 4ms gekommen, was ca. 
256kByte/sec entspricht (ca. 2Mbit/sec)

Wie könntet man das messen?

[jo (Gast)]

>Wie könntet man das messen?

>>Moin. Freien pin als ausgang konfigurieren. pin auf high setzen. ZU
>>messende aktion ausführen. pin auf low setzen. Mit Qszi / Frequenzzähler
>>am freien Pin die ON Zeit messen.

So schwer?

[Lalo (Gast)]

Ich habe so das konfiguriert:

  while (1)
  {

    HAL_GPIO_WritePin(GPIOB, GPIO_PIN_12, 1);
    CDC_Transmit_FS(Data,strlen((const char*)Data));
    HAL_GPIO_WritePin(GPIOB, GPIO_PIN_12, 0);
    HAL_Delay(100);

  }


Ist das denn meiner Geschwindigkeitsmessung ?

[W.S. (Gast)]

Lalo schrieb:
> CDC_Transmit_FS(Data,strlen((const char*)Data));

Lalo schrieb:
> Mein Problem liegt daran, dass wenn ich mehr als 97 Zeichen in Data[]
> sende, ist mein VCP nicht mehr im Computer erkennbar.
> Was kann es sein?


Was das sein kann?
Nun, du hast dich weder mit dem Procedere als solchem noch mit der 
tatsächlichen Funktionalität des Treibercodes befaßt, den du da 
eingebunden hast.

Ich bin da recht mißtrauisch gegenüber sowas. Meist ist es so, daß in 
solchen grandiosen Treibern grundsätzlich nur blockweise agiert wird und 
gerade bei einem CDC ist das extrem kontraproduktiv, denn es fehlt 
komplett die Funktionalität des Zwischenspeicherns und somit des 
Pufferns eines asynchron funktionierenden Datenstromes.

In dem von dir beschriebenen Fall vermute ich, daß das Gerät sehr wohl 
erkannt wird, aber das Senden seitens des Gerätes zum Host hin wird 
entweder schon vor oder spätestens nach dem Abschluß des ersten 
Nutz-Paketes zum Host hin nicht gemerkt, daß man für neue Daten einen 
der Transfer-Puffer sendebereit machen müßte. Das ist so ähnlich wie bei 
manchen UART-Cores, die einen Interrupt nur dann liefern, wenn der 
TX-Puffer leer geworden ist, aber nicht, wenn er bereits leer ist.

Ich hatte in meinem VCP-Code den 1 ms Tick vom USB dazu benutzt, um 
sowas zu testen und in solchen Fällen den Sende-Transfer wieder 
anzuwerfen, falls er zuvor zum Stillstand gekommen war und jetzt neue 
Daten anliegen.

W.S.