Hallo zusammen, für eine Debug- (oder eher Prototyping-) Anwendung würde ich gerne zum ersten Mal den virtuellen COM-Port meines Nucleo-64-Boards nutzen. Leider finde ich nirgends, wo ich suche, eine Angabe der maximalen vom ST-Link V2-1 unterstützten Baudrate. Hat jemand eine Quelle parat?
Gast
#5845449
hi, so was findest du im Datenblatt TN1235 von ST. SWIM programming speed rates: 9.7 kbyte/s in low-speed, 12.8 kbyte/s in high-speed
Gast
#5845465
ah sorry, blöd. einfach 115200 Baut, schon versucht? sonst standard baudrate schnell durch probieren...
Gast
#5845497
Walter T. schrieb: > Leider finde ich nirgends, wo ich suche, eine Angabe der maximalen vom > ST-Link V2-1 unterstützten Baudrate. Hat jemand eine Quelle parat? Jedenfalls lässt sich der Port auf 4 Mbit setzen.
stty schrieb: > Jedenfalls lässt sich der Port auf 4 Mbit setzen. Bei mir in Windows 10 nur auf 128000 Baud. ventu schrieb: > einfach 115200 Baut, schon versucht Da ist auch der Wert, der in allen "Tutorials" verwendet wird. Mir sind die allerdings zu knapp. Ich will im 10-kHz-Takt 4*16 Bit übertragen. Am liebsten als HEX-Textstring, weil es sich dann einfach in eine CSV-Datei speichern läßt, ohne auf dem PC eine Software zu schreiben. Ansonsten eben binär. Wenn das nicht funktioniert, brauche ich mir die Arbeit, die Nutzung des UART zu implemtieren, erst gar nicht zu machen. Naja, fast. Notfalls kann ich ja immer noch einen FTDI-Wander dazusetzen.
Da sollten ein oder zwei MBit/s eigentlich schon drin sein. Die eingestellte Baudrate ist dabei völlig egal, da die Daten bei einem Virtuellen COM-Port an keiner Stelle als echte UART-Daten vorliegen, sondern immer in USB-Frames mit maximaler Geschwindigkeit ankommen. Die Baudraten-Einstellung wäre z.B. bei einem FTDI-Wandler interessant, damit der weiß, auf welche Geschwindigkeit er seinen UART setzen muss. Da es bei einem VCP direkt vom Controller aber nur USB-Frames und kein "Modem" gibt, welches auf eine Geschwindigkeit eingestellt werden muss, ist die Wahl der Baudrate ziemlich egal und hat keine Auswirkungen. Der einzig begrenzende Faktor ist die Geschwindigkeit der USB-Kommunikation. Und der ST-Link hat damit eigentlich auch nichts zu tun. Zum Debugging mit dem ST-Link kann man allerdings die SWO-Leitung nehmen, aber auch da muss man eigentlich keine Baudrate einstellen und hat mit einem Virtual COM nichts zu tun.
Jein. Es gibt eine echte UART-Leitung zwischen ST-Link V2-1 und dem Target mit einer echten Baudrate. Der COM-Port-Treiber des ST-Links heißt nur "virtual". Ich nehme an, weil sie so eine ID weiterverwenden konnten. Insofern ist die Bezeichnung irreführend.
Walter T. schrieb: > Insofern ist die Bezeichnung irreführend. Ahhh. Ja. Stimmt. Ich erinnere mich. Ich war gedanklich bei einem STM32, der Hardware-USB mit an Board hat. Mea Culpa.
Aber wo wir beim Thema sind: Hat jemand die maximale Baudrate von SWO griffbereit? Ich suche auch gerade. Ich bin nicht fix bei der Methode, wie ich die paar Sekunden Sensordaten auf den PC bekomme, ich habe nur ein wenig Pinmangel, und die USB-Pins sind belegt.
Gast
#5845812
SWO != virtueller Comport
Gast
#5845970
Walter T. schrieb: > Hat jemand die maximale Baudrate von SWO griffbereit? Die Bitrate von SWO ist immer 1/4 vom Systemtakt.
Walter T. schrieb: > Jein. Es gibt eine echte UART-Leitung zwischen ST-Link V2-1 und dem > Target mit einer echten Baudrate. Das ist ungünstig, denn IIRC läuft der COM Port im ST-Link hart auf 115200 Baud. Falls der µC auf dem Nucleo64 selbst USB kann sollte man eher darüber gehen. Dann ist man nicht an die 115200 gebunden und kann eine viel schnellere UART Baudrate einstellen. Ich würde das auch eher fest verdrahten und die Einstellungen vom CDC einfach ignorieren.
Jim M. schrieb: > Walter T. schrieb: >> Jein. Es gibt eine echte UART-Leitung zwischen ST-Link V2-1 und dem >> Target mit einer echten Baudrate. > > Das ist ungünstig, denn IIRC läuft der COM Port im ST-Link hart auf > 115200 Baud. Ich habe mit dem VirtualComPort vom ST-Link V2-1 schon Baudraten von 9,6k bis 250k eingestellt (ich glaube sogar bis 500k). Funktionierte alles einwandfrei wie es sollte. Macht mich das jetzt zu einem Zauberer oder dich zu einem Lügner? mfg
Gast
#5846006
Ich bin auch ziemlich sicher, dass zumindest niedrigere baudraten (als 115200) funktionieren. Aber bevor ich dummschwätze, wollte ich das heute Abend nochmal checken. Ich melde mich wieder.
Felix F. schrieb: > Macht mich das jetzt zu einem Zauberer oder dich zu einem Lügner? Ups. ST-Link mit JLink verwechselt.. :-/
Gast
#5846032
Walter T. schrieb: > Ich will im 10-kHz-Takt 4*16 Bit übertragen. Am > liebsten als HEX-Textstring, Walter T. schrieb: > ich habe nur ein wenig Pinmangel, und die USB-Pins > sind belegt. Ganz schön blöd, wenn man die entscheidenden Pins vergeigt hat - und warum hast du dein Projekt nicht zuvor ausreichend gut geplant? Ich red mir hier seit ewig den Mund zum Fransenteppich, um den Leuten zu predigen, vor Beginn der Arbeiten ihre Projekte erstmal wirklich zu planen, aber offensichtlich nützt das garnix. Und wenn man im 10 kHz Takt jeweils 64 Bits über ne echte Serielle übertragen will, dann macht man das besser 7 bit weise: 1. Byte : Bits 0..6, MSB im Byte=0 2. bis 10. Byte: Bits 7..63, MSB im Byte=1 Auf die Weise hat man die Synchronisierung, da das 1. Byte wegen des nicht gesetzten MSB von allen anderen Bytes unterschieden werden kann. Aber da du ja sowieso so ein Nucleo-Board verwenden willst, kannst du ja auch die USB-Leitungen deines µC freimachen und stattdessen die UART-Leitungen verwenden. Dann geht VCP eben ohne dein ST-Link und ohne den seriellen Flaschenhals. W.S.
Gast
#5846037
W.S. schrieb: > Ganz schön blöd...vergeigt > Ich red mir hier seit ewig den Mund zum Fransenteppich, Das Nachtreten finde ich jetzt nicht gerade hilfreich.
W.S. schrieb: > warum hast du dein Projekt nicht zuvor ausreichend gut geplant? Sobald ich ein Projekt habe, das unambitioniert genug ist, daß ich schon im Vorherein alle Eventualitäten abschätzen kann, mache ich das. Leider läßt mein Hobbybudget es nicht zu, ein eigenes Produktmanagement zu installieren, das mir schon die fertigen Lastenhefte liefert. Naja. Irgendwas ist halt immer. Bis dahin muß halt notfalls ein 5 Euro teurer USB-Seriell-Wandler aushelfen, falls das über ST-Links nicht klappen sollte. Hätte ich auch schon lange so gemacht, wenn ich das blöde Ding nicht verlegt hätte.
Ich verwende den st Link vom Nucleo board. Dort lässt sich die Baudrate des VCM bis ca 1 Mbit richtig einstellen. Darüber hinaus war es unzuverlässig bzw. die baudrate stimmte nicht. Dein Terminalprogramm muss das allerdings einstellen können und das Betriebssystem muss das durchlassen. Wie das bei Win10 ist weiss ich nicht, bei Ubuntu klappt alles. Am besten checkst Du die baudrate mit dem Oszi. Baudrate kannst Du beliebig einstellen, auch "krumme" Werte gehen, da der stm103 im stlink einen fractional Baudrate Generator hat. Der Baudratenfehler ist aber nicht einfach abzuschätzen (->dabla)
Falls es hilft: Meine VCP-Implementation auf STM32F103-Basis kann auch alle Baudraten, die der UART unterstützt. Es wird jeweils geprüft ob die vom PC geforderte Baudrate im Toleranzbereich liegt. Alle drei USART-Schnittstellen können gleichzeitig via USB-CDC genutzt werden; USART1 geht dabei bis 4.5MBit/s, USART2-3 bis 2.25 MBit/s. Wenn du also noch einen STM32F103 rumliegen hast... https://github.com/Erlkoenig90/f1usb/tree/vcp https://github.com/Erlkoenig90/f1usb/blob/vcp/src/vcp.cc#L83
Gast
#5846279
Die im uC eingebaute USB Schnittstelle auch für printf debugging zu nutzen wurde ich eh nicht forcieren. Gerade dann nicht, wenn der uC auch noch über STLink o.Ä. immer mal wieder neu programmiert wird und dadurch durch einen Reset geht. Ein seperater Wandler (FTDI), der im STLink eingebaute virtuelle Com Port oder auch SWO falls das geht würde ich immer vorziehen. Zweig (kein AST)
Der ST-Link V2-1 auf dem Nucleo-Board läuft wirklich problemlos mit 921600 Baud - was für meinen Anwendungsfall ausreicht, deswegen habe ich noch keine höhere Geschwindigkeit getestet. Getestet wurde mit Putty unter Windows 10. Und wer das auch testen will: An Pin 35 der Steckerleiste CN10 ist PA2 mit den Default-Lötjumper-Einstellungen gar nicht verbunden. Was die Ursache dafür war, daß das jetzt heute nachmittag so lange gedauert hat, bis überhaupt ein Signal aus dem USART2 überhaupt zu sehen bekommen habe. Am Pin .RX auf dem ST-Link-Teil der Leiterplatte bekommt man allerdings das Signal. Danke für die hilfreiche Diskussion! Niklas G. schrieb: > Alle drei > USART-Schnittstellen können gleichzeitig via USB-CDC genutzt werden; Auf Deine Implementierung war ich auch schon gestoßen auf der Suche nach einem kurzfristigen Ersatz für meinen FTDI-Adapter. Diesmal brauche ich sie wohl nicht - aber ich habe mir den Link schon in meiner Problemlösungssammlung gesichert.
Gast
#5846416
Ich habe es mit einem Nucleo-64 STM32F303RBT6 getestet: Mit 8 MHz R/C Oszillator: 300 Baud geht nicht 600, 1200, 2400, 4800, 9600, 19200, 115200, 230400, 460800 Baud gehen 921600 Baud geht nicht 1000000 Baud geht nicht Mit 8 MHz aus Quarz: 460800 Baud geht 921600 Baud geht nicht 1000000 Baud geht nicht Mit 72 MHz CPU Takt und 36 MHz I/O Takt aus Quarz: 300, 600 Baud gehen nicht 1200 Baud geht 921600, 1000000, 2000000 Baud gehen 4000000 Baud geht nicht
Walter T. schrieb: > Ich bin nicht fix bei der Methode, wie ich die paar Sekunden Sensordaten > auf den PC bekomme, ich habe nur ein wenig Pinmangel, und die USB-Pins > sind belegt. SWO ist dafür hervorragend geeignet, da die Schnittstelle direkt am Cortex-Kern dran hängt. Man kann sich auf dem SWO-Pin auch ein NRZ-Signal ausgeben lassen, so dass man das mit einem gewöhnlichen USB-UART Adapter auslesen kann.
Christopher J. schrieb: > [...] Danke für die Anmerkung. Aber die obige Aussage hat sich erledigt. Ich bin ja jetzt einen Schritt weiter und habe einen schnellen UART, mit dem ich meine Sensordaten direkt in eine CSV-Datei "pipen" kann. Ich bin mit dem Thema also glücklich fertig.
Falls du mal etwas mehr Durchsatz haben solltest: Mit einem J-Link gehen mit SWO bis zu 6MHz, bei einem ST-Link V2 bis zu 4MHz (wimre) und bei einem ST-Link V3 bis zu 24MHz. Es besteht aber auch die Möglichkeit mit Sigrok und einem Logic-Analyzer den SWO-Pin zu samplen. Da kommt man mit einem billigen 24MHz Saleae-Clon auch leicht auf effektive 12MHz.
Gast
#5846802
Weiß jemand, ob die Bitraten jenseits von 1000000 beim USB CDC Device überhaupt effektiv erreicht werden?
Stefanus F. schrieb: > Weiß jemand, ob die Bitraten jenseits von 1000000 beim USB CDC Device > überhaupt effektiv erreicht werden? Ja, das geht. Habe bei mir bis 6 Mbit/s im Dauerstreaming (echtzeitdaten timergesteuert) erreicht. Im freerun Mode geht noch mehr. Du musst auf dem PC aber immer dafür sorgen, dass die Daten schnell genug abgenommen werden. Die internen buffer der CDC sind begrenzt. Wenn Du vom uC immer nur 64 byte grösse Blöcke sendest, kann es auch zu Problemen kommen. Ab und zu musst Du dann einen zero length Block senden. funktioniert unter Linux und Windows. Wenn CubeMX verwendet wird gab es bei mir Probleme unter Win10. Vielleicht ist das in neueren Versionen von Cube aber behoben. file usb_cdc_if.c : im state CDC_GET_CONTROL_LINE_STATE müssen vernünftige Werte gesetzt werden. Win 10 prüft die.
>>file usb_cdc_if.c : im state CDC_GET_CONTROL_LINE_STATE müssen >>vernünftige Werte gesetzt werden. Win 10 prüft die. Sorry: meinte natürlich CDC_GET_LINE_CODING
Jetzt bin ich auch zu Geschwindigkeitstests gekommen. Bei mir (STM32F446RE @ 168 MHz, Nucleo-64-Board) ist bei 2000000 Baud definitiv Schluß. Aber generell sollte das ja reichen. Jetzt muß ich mich nur mal in den DMA einarbeiten. Sendeseitig habe ich den noch nie genutzt, aber bei normalem Senden mit "Warten auf Transmit complete" geht bei einer Senderate von 10 kHz schon bei 5 gesendeten Zeichen pro Schleifendurchlauf nichts mehr (die Interrupt-Last ist ohnehin schon recht hoch). Mit DMA sollte das ja unproblematisch werden. Ich habe nur noch keinen Schimmer, wie man den sendeseitig triggert, wenn er lediglich einen FIFO abarbeitet. Aber das Wetter ist ja perfekt für ein wenig Lesearbeit im Liegestuhl. Viele Grüße und schönes Wochenende!
Hallo Zusammen,
ich bin in diesem Thema unerfahren und nutze ein altes Thema.
Ich habe eine Betty Fernbedienung aus 2007 ersteigert , diese kann nicht mehr aktivieren und auch nicht über TAE und Scart updaten da der Service bereits 2010 eingestellt wurde.
Ich möchte diese Fernbedienung mit der Boop Firmware Flashen. Dazu habe ich folgende Voraussetzung:
WIN 11 PC, ,das Betty-Heaven Flash PRG, und einen ST-LINK V2,
leider komme ich nicht weiter weil der ST-Link nicht als COM-Port erkannt wird.
Hab ihr eine Idee wie ich das als Newbie anders erledigen kann.
Angehängte Dateien:
-
St-Link_Com_Port.jpg
(94 KB)
Hab ihr eine Idee wie ich das als Newbie anders erledigen kann.
Den STM32CubeProgrammer statt des Betty Tools nutzen zum flashen. Und einen neuen Thread eröffnen.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.