Wie VCP Daten einlesen? STM32f072 STM32CubeMX Projekt

Wenn du mit CubeMX dein Projekt erzeugt hast: Suche in der
Datei usbd_cdc_if.c diese Funktion

1

static int8_t CDC_Receive_FS(uint8_t* Buf, uint32_t *Len)

Diese Funktion wird vom USB-Interrupt-Ereignis für empfangene
Daten aufgerufen. Darin fügst du am Ende einen Aufruf ein,
sozusagen als Callback, um die empfangenen Daten zu übernehmen,
zu verarbeiten.

1

static int8_t CDC_Receive_FS(uint8_t* Buf, uint32_t *Len)

2

{

3

  /* USER CODE BEGIN 6 */

4

  USBD_CDC_SetRxBuffer(&hUsbDeviceFS, &Buf[0]);

5

  USBD_CDC_ReceivePacket(&hUsbDeviceFS);

6

7

  /*  hier eigene Funktion aufrufen  */  

8

  My_USB_Receive_Handler ((char*)Buf, (uint16_t)(*Len));

9

10

  return (USBD_OK);

11

  /* USER CODE END 6 */

12

}

Ob man jetzt für die Länge den Pointer auf die Länge oder die
Länge selbst übergibt ist Geschmackssache.

Über deine eigene Header-Datei musst du noch deine Funktion
in dieser Source bekanntgeben. Also sinngemäs so etwas

1

  #include "my_usb_io.h"

Danke.

Die Funktion hatte ich schon gesehen (die TX Funktion steht ja auch 
dadrin), aber den zusammenhang wo nun die Daten sind konnte ich in dem 
erzeugtem Code nicht erkennen.

Dann bau ich mir mal einen Fifo und schau wie das so funktioniert.

Wenn alles gut arbeitet werde ich diesen erzeugten Code mit den 
Projekten hier aus den Forum vergleichen.
Und dann entweder diesen Projekten weiter helfen (was mir am liebsten 
wäre) oder wenn das nichts bringt meinen "SPL Code" in den CubeMX Code 
rein bauen.

Melde mich wieder wenn der Empfang läuft!

Dirk schrieb:
> Dann bau ich mir mal einen Fifo und schau wie das so funktioniert.

Schau doch mal in die Doku 
(https://www.st.com/resource/en/user_manual/dm00108129-stm32cube-usb-device-library-stmicroelectronics.pdf) 
Kapitel 6.5.

Da steht, dass der Treiber bereits Puffer verwendet. Du brauchst sie dir 
nicht zu "bauen".

Through the file usbd_cdc.h and usbd_cdc_interface.h, configure:
... The size of the temporary circular buffer for IN/OUT data transfer 
(define APP_RX_DATA_SIZE and APP_TX_DATA_SIZE)

Rückmeldung!

Habe die Daten aus dem Speicher in einen FIFO rein geschoben und im 
Hauptprogramm ausgewertet. Geht super!
Also senden und empfangen geht, soweit ich es testen konnte, perfekt.
Habe dazu einfach ein kleinen CRC gesichertes Protokoll laufen lassen 
und auf beiden Seiten Fehler Counter eingebaut. Alle Counter waren nach 
3 Stunden immer noch auf 0!
War ein Ping Pong Test, also PC sendet und der STM32 hat geantwortet.

Maximale Paket längen habe ich nicht getestet!


Die Daten UserRxBuffer & UserTxBuffer sind laut Information ein 
Ringspeicher.
Aber um dem Haputprogramm die Daten zu geben muss man die nochmal 
ablegen, oder man würde die hier direkt auswerten. Der Empfangsspecicher 
ist nach verlassen der Funktion wieder freigegeban für das nächste 
Datenpaket und somit nicht mehr vom Hauptprogramm auswertbar.

Jedenfalls es scheint alles zu gehen und jetzt werde ich mal sehen wie 
es weiter geht.
Die HAL muss ich jedenfalls los werden die stört nur!

Dirk schrieb:
> Die HAL muss ich jedenfalls los werden die stört nur!

Ach was!

Die HAL wird dann nützlich, wenn du Programmteile ohne großartige 
Änderung auf unterschiedlichen STM32 laufen lassen willst. Geht aber 
eben nur mit STM32 und nur solange ST die HAL pflegt (beim Vorgänger SPL 
war das ja sehr lange der Fall).

Kleiner Tipp: http://stefanfrings.de/stm32/stm32l0.html#vcpnohal

Da ich recht viel direkt mit den Resistern mache kenne ich die schon 
recht gut. Und für alles Normale nehme ich gerne noch die SPL. Wobei ich 
die auch mal gegen die LL Version tauschen könnte, ist ja fast das 
gleiche nur mit anderen Namen.
Allerdings gibt es bei USB eine vermischung zwischen LL und HAL.

Ja ich finde das die HAL blöd ist, aber da kann man Stunden lang drüber 
diskutieren und am Ende kommt nichts dabei raus. Ist wie Linux und 
Windows, diskutieren was besser ist bringt einfach nichts, beides hat 
Vor- und Nachteile.


@Stefan
Deine Code und den von W.S. kenne ich!
Ich wollte nur eine Codebasis haben mit der ich euren Code vergleichen 
kann.
Wie gesagt der erzeugte Code läuft gut und Ihr habt ja angeblich hier 
und da noch Problme, oder mindestens ein User hat Probleme.

Ein Fehler in Eurem Code ist auf jeden Fall:
0x02, // bDeviceClass
0x00, // bDeviceSubClass --_> da muss 2 Stehen!

Sorry, ist so definiert!

Dirk schrieb:
> Wie gesagt der erzeugte Code läuft gut und Ihr habt ja angeblich hier
> und da noch Problme, oder mindestens ein User hat Probleme.

Wir haben Meinungs-Verschiedenheiten zur Programm-Struktur, und genau 
ein User hat Probleme und das auch nur mit ein paar ganz bestimmten 
Boards.

Du kannst dich schon darauf verlassen, dass diese USB Implementierung 
zuverlässig läuft. Sie wurde von mehreren Leuten gesichtet und sehr 
gründlich getestet.

Eine weitere Alternative findest du im Artikel von Niklas: 
https://www.mikrocontroller.net/articles/USB-Tutorial_mit_STM32

Allerdings wird der Speicher des USB Devices bei deinem F0 etwas anders 
angesprochen (siehe Reference Manual). Den Part müsstest du anpassen.