Hier eine Library um den USB-OTG-Port am Discovery-Board im CDC-Mode zu betreiben. Damit wird beim Verbinden mit einem PC ein virtueller Comport eingerichtet über den man (wie per UART) Daten austauschen kann.
Auf der PC Seite muss der “VirtualComPort-Driver von ST” installiert sein. Den gibts auf der ST-Seite zum download (ich hab mit Version 1.3.1 getestet).
Auf der ST-Seite nach “STSW-STM32102″ suchen.
Die LIB erwartet beim empfang als Endekennung das Zeichen “0x0D” = CarriageReturn
(das muss der PC also am Stringende anhängen)
Beim Protokoll (Baudrate, Stopbits usw) muss nichts eingestellt werden, das wird vom USB-Treiber erledigt. 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)…ob das aber durchgehend eingehalten wird, kann ich nicht sagen.
(Nachtrag : im Capture-Tool-Projekt komme ich auf Datenraten von ca. 7MBit/sec, wobei USB-FullSpeed mit max 12MBit/sec spezifiziert ist)
In der Library gibt es eine Sende und eine Empfangsfunktion für Strings und eine Funktion zum testen ob die USB-Verbindung steht.
Ich hab auch ein “mini” PC-Terminal-Programm geschrieben um die Funktion zu testen.
Es wird ein USB-Kabel mit Micro-USB-Stecker benötigt. (gibts bei EBay oder Amazon)
Benutzte Pins
1 2 3 4 5 | PA8 -> USB_OTG_SOF (wird nicht benutzt) PA9 -> USB_OTG_VBUS PA10 -> USB_OTG_ID PA11 -> USB_OTG_DM PA12 -> USB_OTG_DP |
Voraussetzungen :
1 2 | Benutzte Module der CooCox-IDE : GPIO, MISC Benutzte Librarys : keine |
Enumerationen :
1 2 3 4 5 | typedef enum { USB_CDC_NO_INIT =0, // USB-Schnittstelle noch nicht initialisiert USB_CDC_DETACHED, // USB-Verbindung getrennt USB_CDC_CONNECTED // USB-Verbindung hergestellt }USB_CDC_STATUS_t; |
.
1 2 3 4 5 6 7 | typedef enum { NONE = 0, // keine Endekennung LFCR, // LineFeed + CarriageReturn (0x0A,0x0D) CRLF, // CarriageReturn + LineFeed (0x0D,0x0A) LF, // nur LineFeed (0x0A) CR // nur CarriageReturn (0x0D) }USB_CDC_LASTBYTE_t; |
.
1 2 3 4 5 | typedef enum { RX_USB_ERR =0, // keine USB Verbindung RX_EMPTY, // nichts empfangen RX_READY // es steht was im Empfangspuffer }USB_CDC_RXSTATUS_t; |
Funktionen :
1 2 3 4 | void UB_USB_CDC_Init(void); // zum init der USB-Schnittstelle USB_CDC_STATUS_t UB_USB_CDC_GetStatus(void); // USB Status abprüfen ErrorStatus UB_USB_CDC_SendString(char *ptr, USB_CDC_LASTBYTE_t end_cmd); // zum senden eines Strings per USB USB_CDC_RXSTATUS_t UB_USB_CDC_ReceiveString(char *ptr); // zum empfangen eines Strings per USB |
Beispiel :
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 | //-------------------------------------------------------------- // File : main.c // Datum : 07.04.2013 // Version : 1.0 // Autor : UB // EMail : mc-4u(@)t-online.de // Web : www.mikrocontroller-4u.de // CPU : STM32F4 // IDE : CooCox CoIDE 1.7.0 // Module : CMSIS_BOOT, M4_CMSIS_CORE // Funktion : Demo der USB-CDC-Library // Hinweis : Diese zwei Files muessen auf 8MHz stehen // "cmsis_boot/stm32f4xx.h" // "cmsis_boot/system_stm32f4xx.c" //-------------------------------------------------------------- #include "main.h" #include "stm32_ub_usb_cdc.h" int main(void) { char buf[APP_TX_BUF_SIZE]; // puffer fuer Datenempfang USB_CDC_RXSTATUS_t check; SystemInit(); // Quarz Einstellungen aktivieren // Init vom USB-OTG-Port als CDC-Device // (Virtueller-ComPort) UB_USB_CDC_Init(); while(1) { // Test ob USB-Verbindung zum PC besteht if(UB_USB_CDC_GetStatus()==USB_CDC_CONNECTED) { // Ceck ob Daten per USB empfangen wurden check=UB_USB_CDC_ReceiveString(buf); if(check==RX_READY) { // wenn Daten empfangen wurden // als Echo wieder zurücksenden // (mit LineFeed+CarriageReturn) UB_USB_CDC_SendString(buf,LFCR); } } } } |
Hier die Library zum Download :
Hier der komplette CooCox-Projektordner zum Download :
Hier der Link zu dem PC-Programm :
71 Antworten auf 31-USB_CDC-Library (STM32F4)
Wie hat Dir dieser Artikel gefallen?
(1 Bewertungen, Durchschnitt: 5,00 von 5)
Loading...
Pierre
Hi. Thanks for you tutorials.
http://mikrocontroller.bplaced.net/wordpress/?page_id=1263
i have some problems.
first problem – i can use your terminal to comunicate with device, but i cant communicante with other terminals. Nothing is returning. i used string such as TEST0x0D
Second problem. when i send string about 20 times – stm32f4 goes crasy and send some string all time. string looks like “*P[Z! F@`W:BO!(F[(y@tr@}{“BZr-9pzQ2ol”
Thanks
Hi,
your terminal must send a “CarriageReturn” at the end of the string, instead of the characters “0x0D”. So when you try to send “TEST” the terminal must send 5 Bytes : 0×54, 0×45, 0×53, 0×54, 0x0D
To verify the second problem i need your complete Projekt (main.c). please send it to me as zip-file.
I have second problem on you code as is. with absolutelly no changes. and use your terminal with word “HELP”.
send 20 times and have infine loop with strange string comes all the time.
uhh..ok, i will check this here, hang on.
ok, i have here the same problem !!
I will check this and give a feedback, thanks for comment
BUG is now fixed, Version 1.2 is online, please test it again.
Have you updated the Terminal in Version 1.2?
My download today is version 1.0
Thanks and best regards!
the actual Version of the Terminal_Program is 1.0 and the STM-Library has Version 1.4 (there was no need to update the Terminal because the BUG was in the STM-Library)
Hi there!
First of all – thanks for sharing your code with the world.
I just downloaded ub_stm32f4_usb_cdc_v102 and compiled it in Coocox 1.7.
My device uses a STM32F407VG, HSE is 8MHz. The USB-FS connection is device only, e.g. PA8-SOF and PA10-ID are not connected.
DFU with DFUSE works like a charm.
Problem with your project: My Win7 doesn’t even register a new USB device.
When crawling through the code I asked myself, if it’s correct to use PA9-VBUS as output (thus never seeing the connection status).
Looking forward to your reply, lungfish
I withdraw the part about PA9-VBUS being an output. Sorry.
Still trying to get the example running, though.
Hi,
SOF (PA8) is not used but i am not sure about the ID-Pin (PA10) …try to connect it to GND. Have you installed the right VCP-Driver from STM ?
Sooo – I should have quit earlier, yesterday.
Anyways – I took an Olimex STM32-E407, changed its HSE to 8MHz and
– your example works without any mods.
Now that I have a baseline to start from, I’ll go back to my board and we’ll see.
The ID-Pin can be left open, even the internal PullUp is OK.
Soo – for safety reasons I had a 1k resistor between PA9 and VBUS.
Change that to 22R and the show is on the road.
Now the unpowered device sucks power from the PC, though.
Nice. On the STM-Discovery-Board there isn’t a resistor anywhere. PA9 is directly routed to the USB VBUS Pin.
Without the resistor, the unpowered board sucks power through the internal PA9 protection diode.
I’ll have to think about a solution for that. Could kill the STM32 under the wrong circumstances.
Hi,
thanks for sharing your librarys.
How fast is this CDC Library? I need to transmit every 20ms a maximum of 1024 byte in approx 5 ms (something about 1.6MBit). So, no continous stream. In a short time quite a few data.
I think isochronous transfer would be the best. But i want to avoid this cause i havent found any good example for this (i think i would have to write Win and Linux driver on my own).
Or do anyone found examples USB isochronous with win+linux driver + demoapplication (never wrote a program for linux or win)
I don’t know the speed of the USB-Transfer, but i can check this. I think the bottleneck is on the PC-Side, with the “normal” Terminal settings you can get 115200 Baud wich is too slow. It is not a easy problem with no experience
Hi,
thanks for your fast reply. I found this:
http://forum.chibios.org/phpbb/viewtopic.php?f=3&t=523
But, as i understand, thats bulk mode which is for high data rates, but not for time critical processes. But i need to transfer my “process image” every 20 ms
But, maybe i give it a try.
Maybe using hterm? Or linux.
USB or writing a OS driver… till now uart was always suitable for my projects…
now i checked the speed with a terminal program (in a quick and dirty test) . For a block of 1024 Bytes (plus one end character) i measured a time between 3 and 4 ms. So this is in your limit. But i dont know what happend by repeating this every 20ms…it’s on you to test this
To do this with my Library you have to change the size of the Receive Buffer (File=usbd_cdc_vcp.h) …use this :
#define APP_TX_BUF_SIZE 2048
Thanks for you test. I will try to setup a linux OS an fire all 20ms a given load. I will read the data and compare it.
Again, thanks for the test!
Hallo,
danke für das Demo!
Ich verwende ein STM32F4-Discovery und Win7 x64 mit dem ST Treiber 1.3.1. Alles funktioniert bestens.
Wenn man allerdings bei einer geöffneten Verbindung (z.B. Open in deinem Terminal) einen Reset auf dem Discovery auslöst, ist der PC ‘beleidigt’. Der Gerätemanager zeigt zwar beim Loslassen des Resettasters wieder einen COM Port an, man bekommt aber keine Verbindung. Egal ob Close+Open oder Neustart des Terminals. Erst nach dem Schließen des Terminals, einem Reset am Discovery und einem Neustart des Terminals funktioniert der Open wieder.
Kennt jemand eine Lösung für dieses Problem?
ja, mein Terminal Programm ist “Quick&Dirty” such einfach ein anderes PC-Programm mit Fehlerbehandlung
Mit Hyperterminal und ZOC habe ich das gleiche Problem. Schaut aus als wäre es ein Treiberproblem. Eine Fehlerbehandlung auf dem PC reicht wahrscheinlich nicht aus, da man das Discaovery zusätzlich reseten muss.
Bin weiterhin für Ideen und Tips dankbar.
Hier noch ein Hinweis.
Die ST USB OTG Library hat einen bug, der bei dir evtl. noch nicht abgefangen wurde (google mal nach ep->xfer_count). Bei mir wurden Unmengen an USB Interrupts ausgelöst. Wenn du in usb_dcd_int.c nach Zeile 468 folgende vier Codezeilen einfügst sollte das Problem beseitigt sein:
if( ep->xfer_count >= ep->xfer_len) {
uint32_t fifoemptymsk = 1 < < ep->num;
USB_OTG_MODIFY_REG32(&pdev->regs.DREGS->DIEPEMPMSK, fifoemptymsk, 0);
break;
}
Für Quellcode gibts die Code-Tags, die sollten funktionieren (ich hab die anderen Posts gelöscht) und zu dem Bug-Fix : wann kommt dieser Fehler vor mit den vielen Interrupts ?
Beim Senden von Daten. Wegen der hohen MCU Leistung des STM32F4 fällt das zuerst nicht auf. Bei einer zeitkritischen Anwendung kann man dann aber lange nach dem Fehler suchen.
Im ST e2e Forum gibt es einen Beitrag dazu. Da wird auch die Lösung beschrieben. Hier ein kleiner Auszug:
When idle I get 1000 IRQs per second, as expected (the SOF IRQ).
When transmitting about 200Kbytes/second I get about 32,000 IRQs per second!
Hier der Link:
https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=https%3a%2f%2fmy%2est%2ecom%2fpublic%2fSTe2ecommunities%2fmcu%2fLists%2fcortex_mx_stm32%2fYet%20another%20STM32F1057%20USB%20OTG%20driver%20issue%20%28VCP%20device%29&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B¤tviews=1235
ok, hab es in der Version 1.4 hinzugefügt. Danke für den Hinweis.
Hi,
zunächst vielen Dank für die Veröffentlichung deiner erarbeiteten Sachen, sie haben mir schon oft geholfen. Ich arbeite mit dem STM32F4Discovery auf Grund einer Studienarbeit. Dank der STM32F4xx_DSP_StdPeriph_Lib habe ich es auch hinbekommen die ganze Beispiele selbstständig nachzuvollziehen und zum Laufen zu bringen etc. Also USART, CAN und so.
Als nächstes benötige ich USB, deine Beispiele funktionieren wunderbar, ich hab jedoch das Problem, dass ich diese nicht einfach verwenden kann, ohne den Weg dahin zu wissen, daher habe ich versucht, ähnlich wie bei USART und CAN, dies über die STM32_USB-Host-Device_Lib zu implementieren. Es hagelt aber massenweise Fehler und ich weiß nicht, wo ich anfangen soll die Lib von STM anzupassen.
Hast du irgend einen Tipp oder irgend eine Beschreibung, die die USB Lib besser erklärt, oder wie du vorgegangen bist? Ich brauch irgendwie n Anstoß.
Danke schonmal und weiter so!
Hi, bei STM gibts beim “STM32F107RB” unter “Design Resources” Links auf viele Bibliotheken u.a. bei “STSW-STM32046″ eine USB-Lib da ist ein Beipspiel für USB-VCP dabei…das habe ich als Basis benutzt.
Hey,
solangsam steig ich bei der Library halbwegs durch.
Habe aber noch eine Erklärfrage.
Weißt du, wo die Funktion “static uint16_t VCP_DataRx (uint8_t* Buf, uint32_t Len)” aufgerufen wird. Dein Kommentar im Quelltext lautet dazu “Wird beim Empfang von einem Zeichen aufgerufen”.
Im gesamten Quellcode finde ich jedoch kein Aufruf der Funktion. Ich hatte vermutet, dies geschieht per Interrupt oder ähnlichem, habe jedoch nichts gefunden.
uhh, sorry , k.A. das ganze USB-Thema ist sehr Umfangreich und ohne die fertigen Sourcen von ST wäre ich da nie auf einen grünen Zweig gekommen. Ich würde mal Braikpoints im File “usbd_cdc_core.c” setzen (da sind die DataIn/Out-Funktionen) und schauen wann die zuschlagen.
Hi,
ich nutze Ihre USB Bibliothek.
Bei der Übertragung PC -> Mikrocontroller komme ich je nach System auf Geschwindigkeiten > 200 kB/s oder gar > 300 kB/s, je nach PC System.
Ich bin jedoch überrascht, dass die umgekehrte Richtung wesentlich langsamer ist ca. 110 kB/s . Mein STM32 macht nichts anderes als in der while(1) Schleife die Funktion UB_VCP_DataTx(65); auszuführen. Ich mess das ganze mit HTerm, da dort die Anzahl der Bytes und die vergangene Zeit angezeigt werden kann.
Ich frage mich, ob und wie diese Geschwindigkeit verbessert werden könnte? Für Ideen oder Hinweise wäre ich sehr dankbar.
Beste Grüße
Sind das 110 kBit/s oder 110kByte/s ? Bei der CDC-LIB wird im Bulk-Mode gesendet und zwar immer 64 Bytes. Vielleicht ist der Puffer nicht ganz voll und es werden Datenbytes “verschenkt” … hab da aber keine große Ahnung von
Event. mal mit der Puffergröße spielen oder schauen wie weit der Puffer voll ist.
Hellow, please help me.
.\usb5.axf: Error: L6200E: Symbol USB_CDC_STATUS multiply defined (by stm32_ub_usb_cdc.o and main.o).
.\usb5.axf: Error: L6200E: Symbol USB_CDC_STATUS multiply defined (by usbd_cdc_vcp.o and main.o).
.\usb5.axf: Error: L6200E: Symbol USB_CDC_STATUS multiply defined (by usbd_usr.o and main.o).
do you have modify the “demo_31-Projekt” ? looks like you have defined a second variable with the name “USB_CDC_STATUS” in your code.
I ran your code without changes
I do not use “demo-31-project” because it’s my compiler KEIL
ok, try this :
1. move this complete line :
USB_CDC_STATUS_t USB_CDC_STATUS;from the file “stm32_ub_usb_cdc.h” to the file “stm32_ub_usb_cdc.c”
(insert it beneath the include lines)
2. open the file “usbd_usr.c” and insert this line :
extern USB_CDC_STATUS_t USB_CDC_STATUS;(insert it beneath the include lines)
and give a reply
Thank you very much for your help! The project successfully assembled! Unfortunately, my computer still does not recognize my device (STM32F4DISCOVERY), it says unknown device. And WinDriver it also does not see, that is, Virtual COM ports are not created.
Спасибо за вашу помощь, я написал правильные настройки скорости и всё теперь работает!!!
Hallo,
ich habe folgendes Problem, nutze allerdings das Projekt “Show 01″. Ich will einen Datensatz mit 4×64 byte an den STM übertragen. 64 Byte, da das ja die maximale Bytegröße für den Bulktransfer ist. Ich checke also nun in der while – schleife ob etwas im Buffer ist. Als Rückgabewert bekomme ich ja die Anzahl der Bytes.
Nun ist es so, das ich am PC immer 64 Byte kurz hintereinander verschicke, der STM aber denkt es wären z.B. 128. Wäre ja nicht schlimm, wären es eben 2 Pakete. Dumm ist aber nur, das die ersten 64 Byte richtig sind, dann kommen vielleicht 30 Byte Müll und die letzten Byte sind wieder richtig.
Ein weiteres Problem ist, das ist kein festes Endezeichen habe, sondern mir wurde ein Frame so definiert:
0×01 0×02 Daten 0×04 (Gesamtbreite 64 Byte). Jedes Datenbyte kann 0×00 oder oxFF sein, also keine Asciicodierung. Vielleicht muss ich einfach mal die USB CDC Library abspecken (Endeerkennung raus und selbst parsen). Aber ich sehe halt noch das Problem mit den “Mülldaten”. Hat hier jemand eine Idee?
ich kann mir nicht vorstellen das “müll” übertragen wird. Entweder läuft ein Puffer voll oder du hast irgendwo anders ein Problem. Ich hab die Lib eigentlich zum Übertragen von Strings geschrieben. Datenwerte kleiner 32dez werden rausgefiltert. Wenn du keine Endekennung hast und alle Bytewerte nutzen willst, musst du selber eine Empfangsfunktion schreiben.
Die Filterung “Ascii” hab ich rausgeworfen. Dann muss ich mal weiter forschen wo da der Fehler liegt. Eine einfache Vergrößerung des Eingangspuffers von 64 z.B. auf 128 geht ja nicht, weil Windows dann den STM CDC nicht mehr erkennt.
Am liebsten wäre mir quasi wie in der guten AVR Welt ein Empfangsinterrupt, wo jedes mal ein Byte raushüpft. Dann könnte ich meinen Standardparser nutzen. Alte Zeiten…
die Puffer größe wird im File “usbd_cdc_vcp.h” eingestellt mit dem Define “APP_TX_BUF_SIZE” stell den mal auf 2048 und schau was passiert.
Kann die library auch für andere controller angepasst werden?
z.b freescale kl25xx?
falls die CPU einen USB-Port hat natürlich, es ist doch der komplette Quellcode in “c” vorhanden. Allerdings muss das jemand anders machen, ich hab mich auf den STM32F4 eingeschossen.
Guten Abend,
vielen vielen Dank für die ganzen Tutorials und Codes ! Das Beispiel mit dem USB CDC hat bei mir auf Anhieb funktioniert !
mfGruß,
opcode
so soll es sein, freut mich zu hören
Hey.
Ich wollte mit deiner Funktion zum senden: UB_USB_CDC_SendString(char *ptr, USB_CDC_LASTBYTE_t end_cmd); die errechneten Werte eines ADC Senden. Habe dazu den Wert in einer U-int16 Variablen. Nur leider kommt bei mir nichts an, wenn ich den COM-Port mit Putty angucke. Code: UB_USB_CDC_SendString(adc_messwert, CRLF);
Was muss ich noch tun, damit er mir den Wert sendet.
LG Felix
du musst die Zahl zuerst in einen String wandeln !!
für sprintf wird bei CoIDE noch die “Retarget printf” benötigt
Hello,
I have tried a lot to compile your code in linux using similar make file, include and libs from your other CDC sample. But no matter whatever I do I receive this error:
~/sat/bin/arm-none-eabi-gcc -std=gnu99 -g -O2 -Wall -Tstm32_flash.ld -mlittle-endian -mthumb -mthumb-interwork -nostartfiles -mcpu=cortex-m4 -msoft-float -Iinc -Ilib/Core/cmsis -Ilib/Core/stm32 -Ilib/Conf -Iub_lib -Iub_lib/usb_cdc_lolevel -Ilib/StdPeriph/inc -Ilib/USB_OTG/inc -Ilib/USB_Device/Core/inc -Ilib/USB_Device/Class/cdc/inc src/main.c lib/startup_stm32f4xx.s -o build/ub_stm32f4_usb_cdc_v104.elf -Llib/StdPeriph -Llib/USB_Device/Core -Llib/USB_Device/Class/cdc -Llib/USB_OTG -lm -lstdperiph -lusbdevcdc -lusbcore
/tmp/ccCc7yln.o: In function `LoopFillZerobss’:
/home/mehdix/workspace/robotik/ub_stm32f4_usb_cdc_v104/lib/startup_stm32f4xx.s:97: undefined reference to `SystemInit’
/tmp/cc9pDJPB.o: In function `main’:
/home/mehdix/workspace/robotik/ub_stm32f4_usb_cdc_v104/src/main.c:27: undefined reference to `SystemInit’
/home/mehdix/workspace/robotik/ub_stm32f4_usb_cdc_v104/src/main.c:31: undefined reference to `UB_USB_CDC_Init’
/home/mehdix/workspace/robotik/ub_stm32f4_usb_cdc_v104/src/main.c:36: undefined reference to `UB_USB_CDC_GetStatus’
/home/mehdix/workspace/robotik/ub_stm32f4_usb_cdc_v104/src/main.c:38: undefined reference to `UB_USB_CDC_ReceiveString’
/home/mehdix/workspace/robotik/ub_stm32f4_usb_cdc_v104/src/main.c:43: undefined reference to `UB_USB_CDC_SendString’
collect2: error: ld returned 1 exit status
make: *** [build/ub_stm32f4_usb_cdc_v104.elf] Error 1
The appropriate files are included but I can not comple. I appreciate if you can help me to compile this code.
uhh, sorry … i dont know what to do under linux. Perhaps you should start with a smaller Projekt like the “Demo_01″ to verify your build chain and the right settings.
Gerade aufgefallen:
Die Elemente der enums USB_CDC_LASTBYTE_t und USB_CDC_RXSTATUS_t kommen sich mit der UART-Lib ins Gehege. Ein Prefix à la “CDC_” schafft Abhilfe. Ggf. könnte man das in beiden Libs übernehmen.
Die Library funktioniert am STM32F4 Discovery wunderbar. Jetzt möchte ich aber auf das Microe Mini-M4 Board wechseln und dort bekomme ich USB nicht zum Laufen.
Ich habe
* CPU auf die STM32F415RG in CooCox Target geändert
* HSE=16000000 gesetzt weil der externe Quarz dort statt 8MHz jetzt 16MHz hat
* PLL_M von 8 auf 16 geändert um obiges auszugleichen und trotzdem 48MHz an USB zu bekommen (Mit STM32 Clock Config Excel Tool kontrolliert)
* Die Software per MicroE HID Bootloader hochgeladen
Nach einem Reset meldet sich kurz der Bootloader per USB, dann springt meine Software an aber ich bekomme keinen STM32 Virtual ComPort .
Hat irgendjemand eine Idee was ich übersehen haben könnte? Memory Mapping wegen USB Bootloader? Ein De-Init am USB bevor ich obiges USB Init in main aufrufe? Code an sich läuft am Mini-M4 Board, UART macht was ich progrmmiert habe.
Danke!
Vielen Dank für diese umfassenden Werke
Bin gerade dabei zu versuchen, deine Beispiele nachzuvollziehen. Komme aus der 8Bit-Ecke (AVR). Verwende das F4-Discovery Board.
Mit compiliertem Beispiel”31″ meldet sich das Board bei mir als “Verbundgerät” unter WIN7 64Bit an.
Com9 und COM10 möchte er gern installieren (Rest ist belegt). Klappt zu Fuß mit dem 1.3.1.0 ST-vcp-Treiber für COM9. COM10 (natürlich) nicht. Wie auch… COM9 wird korrekt angezeigt, Port->open mit deinem Terminalprogramm geht auch. Es lässt sich aber nichts schreiben. (WriteFile Function failed (win error code:87))
Ich habe auch schon versucht, COM10 danach zu “deaktivieren”. ist er dann auch. COM9 lässt sich trotzdem nicht nutzen.
Ganz unten im Gerätemanager steht zusätzlich immernoch “USB-Verbundgerät”.
Ich bin etwas ratlos…
Danke! Axel
Now i ran the setup “dpinst_amd64.exe “in the drivers folder provided by ST.
Version 1.4.1. now it works. manually usb-driver installation of the recocnized board has failed.
Ich habe die Setup.exe “dpinst_amd64″ im Treiberverzeichnis ausgeführt. (Win7/64bit)
Vorher hatte ich versucht, die beiden seriellen Ports über “treiber aktualisieren” zum Leben zu erwecken, was nicht gelang.
Das zwei Geräte angezeigt werden, sei in Ordnung.
uups, formating failed
ist das Problem jetzt gelöst oder nicht ?
Hallo Uwe,
ich bin ja ein begeisterter Benutzer deiner Bibliotheken, hat mir bei den ersten Versuche beim -Umstieg von 8- auf 32-Bit sehr viel geholfen und alles erleichtert. Dafür ein riesiges Dankeschön!
Momentan arbeite ich am USB-CDC Beispiel, um mal auszutesten, welche Datenraten möglich sind. momentan habe ich ein Maximum von ca. 1,2MBit. Dazu sende ich von DiscoveryBoard aus alle 1ms dreimal hintereinander einen String mit 64 Zeichen Länge. Hier treten dann allerdings schon übertragungsfehler auf. die Strings gehen teilweise verloren. Sende ich alle 1ms nur zweimal 64 Zeichen, geht es noch glatt.
Ich habe schon sehr viel experimentiert, längere Strings, geringere Wiederholrate, kürzere Strings schnelle Wiederholung, beides mehr, beides weniger, … . Schneller als ~135000 bytes/s bekomme ichs nicht hin.
Empfang läuft über HTerm, eingestellt auf 4MBit (wenn höher, geht gar nichts mehr). Dein Terminal-Programm kommt bei mir sehr ins schwitzen, ich kann ohne Probleme verbinden und einen String senden, welcher die Übertragung startet, ab dann ist aber leider nichts mehr zu machen. Hast du vielleicht eine Idee, was da bremsen könnte? Ich habe andere Terminals schon versucht zu verwenden, allerdings ist oft die Baudrate, die Datenmenge oder ein fehlender Timestamp hinderlich.
Bei Bedarf kann ich auch mal mein Projekt per Mail schicken.
Gruß,
Domingo
Hey,
das Problem hatte ich auch. Sobald man große Datenmengen vom STM in den PC senden will, bricht die USB Verbindung zusammen und es gehen extrem viel Daten verloren.
Habe damals lang rumexperimentiert, aber auch nicht hinbekommen
Hello,
Would be so kind and give me a little advice with the CDC project. I have succesfully using your library with no problem at all. But you have mentioned at the top of your article that you have been able to achieve about 7Mbit/s in some other project. Now I am achieving only about 1Mbit/s which is too low for my project and I am wondering where is the issue. When I was trying to send data faster via your lib it start to lost bytes. Is this is a problem on the side of the PC driver and its Endpoint handling in CDC mode or?
I have also looked into the project where you have achieved about 7Mbit but I did not found any difference in the CDC lib.
Thank you very much.
Jan
7Mbit/s yes, but only in “receive” direction. In “transmit” other people have the same problems. I can try to find a solution, give me a few days.
Thank you for your time and support. I have tried to identify the problem as well. Maybe there will be problem on the computer side, but still I am testing it with no better result. It could be also problem that the COM port driver is handling endpoint IN in small size or not so frequently. Maybe there will be some way if the device will use only 2 bulk endpoints (IN and OUT) with no CDC intelligence and handle it with libusb driver or winusb driver on the computer side.
Please do you have something new in this issue? Thanks Jan
I need your help…I have a great project for you to complete. I’m looking for a way to emulate an USB keyboard on a windows machine using the STM32F4 discovery. If you could start a simple program to get me started would be great such as pushing a button on the stm32F4 discovery board when plugged into a PC causes the PC to read it as ‘a’ from a keyboard being pushed…I would really appreciate the help…thank you
there is an example from “st” to do this.
have a look at the f4 usb firmware folder from “st”
for the “USB Device HID example”
http://stm32f4-discovery.com/2014/09/library-34-stm32f4-usb-hid-device/
This would be for you I think.
Hi,
erst einmal viele dank für deine vielen tollen Libs.
Ich benutze die CDC-Lib um Messwerte vom Sensor zum PC zu übertragen. Ich habe dabei jedoch ein kleines Problem und hoffe, dass du mir helfen kannst:
Der Mikrocontroller macht erst einmal ein Datenpaket von 4096Bytes voll bis es an den Computer geht. Wie kann ich das abstellen? Ich möchte, dass die Daten asap an den Computer gesand werden, sonst kommt es dort zu unangenehmen Ruckel-Effekten bei der Darstellung.
lg,
Torben
das kann nicht sein, denn dann würde obiges Beispiel von mir gar nicht funktionieren. Was sein kann ist, das in einem zu “langsamen” Zyklus gesendet wird. So wie ich es noch in Erinnerung habe liegen zwischen den USB-Packeten 1ms. Glaube aber nicht das man das schneller einstellen kann. Was für ein Programm hast du denn auf der PC Seite ? event. hat das keine “Echtzeit” Priorität und ist aus dem Grund zu langsam.
Hallo,
erstmal Danke für Deine tolle Seite. Sie hat mir den Umstieg zum STM32 bis jetzt sehr erleichtert. Ich hänge jetzt allerdings an einem Problem fest. Gibt es eine Möglichkeit mit Deiner Lib statt einen ASCII String mit 0x0D Abschlussbyte, eine Binary-Sequenz mit fixer Länge und einer Startsequenz zu empfangen (z.B. 0xAA 0xBB 0xCC 0xDD +2048 Byte?
Wäre super wenn Du mir da helfen könntest.
Lucky1
Habe wahrscheinlich die Antwort im Capture Client gefunden.
Werde es mal ausprobieren.
Gruß
Lucky1