Hallo. Ich habe ein Projekt mit STM32CubeMX für einen STM32f072 zusammen gestrickt. Die einzige Funktion ist ein VCP. Nun habe ich einen Funktionieren VCP Port (erkannt von WIN10) und kann auch was zum PC Senden. Ist nur ein "TEST\r\n" jede Sekunde. Aber ich finde nicht heraus wie man damit Daten Empfängt. Es gibt einen Speicher wo die Daten wohl rein kommen aber mir fehlt die Info das da was drin ist, wieviel und wo. Es gibt hier im Forum zwar einige Projekte die das ganze ohne HAL machen, was mir auch lieber wäre. Nur ich wollte eine einfache wirklich funktioniernde Codebasis haben zum vergleichen. So kennt sich damit jemand aus und kann mir sagen wie ich die Empfangenden Daten bekomme?
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
Jaja, die böse HAL.... Aber kaum soll man mal in ein Register schauen hörts bei den meisten auf.
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.
Bitte 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.