Ja, man kann UART Serial I/O betreiben und ST-Link debuggen über den gleichen USB Connector, und das gleichzeitig! Manche von euch mögen das bereits herausgefunden haben, ich erst vor kurzem. Das spart eine Menge an zusätzlicher Verdrahtungs- arbeit bzw. Logistik. Und einen externen UART wie z.B. den FT232 braucht es auch nicht. Was mich zu der Frage an euch bringt, vielleicht weiss es jemand zu erklären. Wie schafft es der ST-Link auf dem Nucleo-Board zu unterscheiden ob ein Zeichen für der User-UART bestimmt ist oder für den Debug-Kanal? Immerhin muss der ST-Link ja die User-Daten durchleiten zum UART auf dem Nutzer-STM32. Das auch noch in beide Richtungen und mit Baudraten die der Nutzer auf seiner Anwendung eingestellt hat und abweichen können von der Baudrate die die ST-Link Debugger-Software nutzt. Am ehesten könnte ich mir eine ESC-Sequenz vorstellen die jedem Datenstrom von der Debugger-Software an die ST-Link-Firmware vorausgeht. Ob das Performance- bzw. Geschwindigkeits-relevant ist liegt jenseits meiner Vorstellungen. Hab ich was übersehen? Ich wüsste jetzt nicht welches "RTFM" ich hätte tun müssen.
Ich weiß nicht wie STM das gemacht hat, aber bei Freescale sind UART und Jtag-Debug zwei unabhängige USB-Endpunkte.
Dir ist schon klar dass das ein USB Composite Device mit UART und Debugger ist?
Wastl schrieb: > Wie schafft es der ST-Link auf dem Nucleo-Board zu > unterscheiden ob ein Zeichen für der User-UART bestimmt ist oder > für den Debug-Kanal? Weil es ein USB Composite Device ist. Im Gerätemanager erscheinen beim Anschließen zwei Geräte. Zur Unterscheidung der Kanäle dient die "Endpoint" Nummer. Siehe https://www.mikrocontroller.net/articles/USB-Tutorial_mit_STM32
:
Bearbeitet durch User
Nemopuk schrieb: > Weil es ein USB Composite Device ist. Im Gerätemanager erscheinen beim > Anschließen zwei Geräte. Zur Unterscheidung der Kanäle dient die > "Endpoint" Nummer. OK, das ist plausibel und verständlich.
Nemopuk schrieb: > Im Gerätemanager erscheinen beim Anschließen zwei Geräte. ... und hier die Bestätigung dafür. Ist mir im Eifer des Gefechts bisher nicht aufgefallen.
Wastl schrieb: > Wie schafft es der ST-Link auf dem Nucleo-Board zu > unterscheiden ob ein Zeichen für der User-UART bestimmt ist oder > für den Debug-Kanal? Immerhin muss der ST-Link ja die User-Daten > durchleiten zum UART auf dem Nutzer-STM32. Der muss da nichts schaffen, denn der UART-Anschluss des ST-LINK-2V1 ist völlig unabhängig von der Programmier- und Debugverbindung. Es gibt sogar noch eine kleine virtuelle Festplatte, sobald man ein Nucleo-Board an den PC anschließt – da sollte man aber nicht einfach so herumfummeln (ziellos irgendetwas, verändern, abspeichern oder löschen). Soweit ich mich zu meinen Tests erinnern kann, wird die UART-Schnittstelle des STM32F103CB pinmäßig erst dann aktiviert, sobald man versucht, ein Zeichen zu übertragen – vorher ist der Tx-Ausgang noch nicht aktiviert, um möglichst Pinkonflikte zu vermeiden, da hier keinerlei Schutzwiderstände zum Target-STM32 des Boards konzipiert worden sind. In meinem Pro, der als Verbesserung des ST-LINK-2V1-Konzepts fungiert, habe ich unter anderem so einen Pinschutz vorgesehen – ich biete aber nur die Leiterplatte an, die Software für den F103CB muss man sich schon auf eigene Verantwortung selbst besorgen und einspielen. Im Netz findet man dazu die nötigen Informationen – man muss nur suchen.
:
Bearbeitet durch User
Gregor J. schrieb: > Der muss da nichts schaffen, denn der UART-Anschluss des ST-LINK-2V1 ist > völlig unabhängig von der Programmier- und Debugverbindung. Es gibt > sogar noch eine kleine virtuelle Festplatte, sobald man ein Nucleo-Board > an den PC anschließt – da sollte man aber nicht einfach so herumfummeln > (ziellos irgendetwas abspeichern). Das ist kein realer Speicher, du kannst ein Binary oder Intel Hex File draufschieben und der ST-Link programmiert den Inhalt auf den Target Controller.
Wastl schrieb: > Am ehesten könnte ich mir eine ESC-Sequenz vorstellen die jedem > Datenstrom von der Debugger-Software an die ST-Link-Firmware > vorausgeht. Naja so falsch ist das nicht; jedes USB-Datenpaket hat einen Header, in dem drin steht, an welchen USB-Endpoint es gerichtet ist. Endpoints sind so eine Art virtuelle Kanäle bei USB. An der Stelle hat das noch gar nichts mit UART zu tun. Viele Arten von USB-Geräten haben mehrere Endpoints um alle möglichen Daten nebenläufig zu übertragen. Hier sind es halt Debugging-Daten und UART-Daten auf den unterschiedlichen Endpoints. Unter Linux mit "lsusb -v" kann man sich die Endpoints anzeigen lassen.
Niklas G. schrieb: > Unter Linux mit "lsusb -v" kann man sich die Endpoints > anzeigen lassen. Oder unter Windows mit dem USB Device Tree Viewer von Uwe Sieber: https://www.uwe-sieber.de/usbtreeview.html
Niklas G. schrieb: > Naja so falsch ist das nicht; > ........ Als mir nemopuk um 14:25 schrieb fiel es mir dann doch wie Schuppen von den Haaren. Klaro, die verschiedenen Endpoints machen es möglich, nur der Gesamt-Datenstrom muss zwischen den einzelnen Endpoints "ge-shared" werden. Im Prinzip könnten es noch mehr getrennte logische Datenströme sein.
Wastl schrieb: > nur der Gesamt-Datenstrom muss zwischen > den einzelnen Endpoints "ge-shared" werden. Das Aufteilen erledigt die USB-Hardware des Mikrocontrollers, plus noch mehr Funktionalität wie Flusskontrolle, Prüfsummen, Wiederholungen. Daher ist es auch so schön praktisch Geräte direkt mit nativem USB zu implementieren, anstatt mit dem UART rumzufummeln und das alles selbst zu basteln. Nemopuk schrieb: > Weil es ein USB Composite Device ist. Das ist übrigens gar nicht nötig für die Aufteilung auf Endpoints; auch nicht-composite Geräte können mehrere Endpoints haben. CDC-ACM Geräte (die Standardklasse für USB-Serial Adapter) haben 3 Endpoints pro virtueller serieller Schnittstelle. Ein CDC-ACM Gerät kann dann auch mehrere Schnittstellen zur Verfügung stellen, ohne ein Composite Device zu sein, nur Windows kommt damit nicht klar (Linux schon), weshalb man extra für Windows das Gerät noch als Composite deklarieren muss.
:
Bearbeitet durch User
> Ein CDC-ACM Gerät kann dann auch mehrere Schnittstellen zur Verfügung > stellen, ohne ein Composite Device zu sein, nur Windows kommt damit > nicht klar Windows kann das auch. Es ist aber ganz klar vorgeschrieben, dass eine Funktion die mehrere Eps bedient entsprechende IAD Deskriptoren haben soll, wenn die entsprechende Spec neuer als IAD ist. Leider hält sich auch die usb.org nicht an die eigenen Vorgaben wie man an usbmidi2 sehen kann. Vermutlich sind die diversen Kompatibilitätsschichten die Ursache für das Durcheinander. Es ist jetzt auch zu spät daran noch was zu ändern. Weshalb vieles in den usb class Specs halt nur noch Flickwerk ist.
Thomas Z. schrieb: > . Es ist aber ganz klar vorgeschrieben, dass eine Funktion die mehrere > Eps bedient entsprechende IAD Deskriptoren haben soll Wo steht das?
Niklas G. schrieb: > Thomas Z. schrieb: >> . Es ist aber ganz klar vorgeschrieben, dass eine Funktion die mehrere >> Eps bedient entsprechende IAD Deskriptoren haben soll > > Wo steht das? mm ich sollte so spät (früh) nicht mehr schreiben.... Das war natütlich Unsinn und sollte heisen: Es ist aber ganz klar vorgeschrieben, dass eine Funktion die mehrere Interfaces bedient entsprechende IAD Deskriptoren haben soll. Sorry für die Verwirrung
Thomas Z. schrieb: > Es ist aber ganz klar vorgeschrieben, dass eine Funktion die mehrere > Interfaces bedient entsprechende IAD Deskriptoren haben soll. Aber in welcher Spezifikation steht das?
hier die spec. Das wurde entworfen weil ja vorher die Regel bestand ein Interface-> ein Treiber. Usbaudio 1.0 verletzte das ja schon mit Control und Stream Interface. Ab der Verfügbarkeit von IAD sollte deshalb IAD für Multi Interface verwendet werden. CDC war die erste Class Spec wo das zur anwendung kommen sollte. vgl auch Jan Axelson Serial Complete / Usb Complete
Thomas Z. schrieb: > CDC war die erste Class Spec wo das zur anwendung kommen sollte. Tja, gilt für CDC eine völlig separate Spec die in der CDC Spec nicht erwähnt wird?
Wastl schrieb: > Als mir nemopuk um 14:25 schrieb Die "Markierten Text zitieren"-Funktion kennst du? Dann landet man sogar automatisch auf dem richtigen Tag. Nemopuk schrieb: > Weil ...
Rainer W. schrieb: > Die "Markierten Text zitieren"-Funktion kennst du? Die Suchfunktion deines Browsers kennst du? Damit kommt man automagisch zum Beitrag mit der entsprechenden Uhrzeit. Ich kann keine Verpflichtung zum Verwenden der Zitat-Funktion erkennen.
ST hat sogar gleich vier Devices implementiert: Mein ST Board kann ich auch als Datenträger mounten und dann ein Programm per Dateibrowser übertragen :) Wofür das 4. ist weiß ich gerade nicht.
1 | lsusb -v -d 0483:374b |
2 | |
3 | |
4 | Bus 001 Device 006: ID 0483:374b STMicroelectronics ST-LINK/V2.1 |
5 | Device Descriptor: |
6 | bLength 18 |
7 | bDescriptorType 1 |
8 | bcdUSB 2.00 |
9 | bDeviceClass 239 Miscellaneous Device |
10 | bDeviceSubClass 2 |
11 | bDeviceProtocol 1 Interface Association |
12 | bMaxPacketSize0 64 |
13 | idVendor 0x0483 STMicroelectronics |
14 | idProduct 0x374b ST-LINK/V2.1 |
15 | bcdDevice 1.00 |
16 | iManufacturer 1 STMicroelectronics |
17 | iProduct 2 STM32 STLink |
18 | iSerial 3 0669FF515055657867174849 |
19 | bNumConfigurations 1 |
20 | Configuration Descriptor: |
21 | bLength 9 |
22 | bDescriptorType 2 |
23 | wTotalLength 0x0080 |
24 | bNumInterfaces 4 |
25 | bConfigurationValue 1 |
26 | iConfiguration 0 |
27 | bmAttributes 0x80 |
28 | (Bus Powered) |
29 | MaxPower 300mA |
30 | Interface Descriptor: |
31 | bLength 9 |
32 | bDescriptorType 4 |
33 | bInterfaceNumber 0 |
34 | bAlternateSetting 0 |
35 | bNumEndpoints 3 |
36 | bInterfaceClass 255 Vendor Specific Class |
37 | bInterfaceSubClass 255 Vendor Specific Subclass |
38 | bInterfaceProtocol 255 Vendor Specific Protocol |
39 | iInterface 4 ST-Link Debug |
40 | Endpoint Descriptor: |
41 | bLength 7 |
42 | bDescriptorType 5 |
43 | bEndpointAddress 0x81 EP 1 IN |
44 | bmAttributes 2 |
45 | Transfer Type Bulk |
46 | Synch Type None |
47 | Usage Type Data |
48 | wMaxPacketSize 0x0040 1x 64 bytes |
49 | bInterval 0 |
50 | Endpoint Descriptor: |
51 | bLength 7 |
52 | bDescriptorType 5 |
53 | bEndpointAddress 0x01 EP 1 OUT |
54 | bmAttributes 2 |
55 | Transfer Type Bulk |
56 | Synch Type None |
57 | Usage Type Data |
58 | wMaxPacketSize 0x0040 1x 64 bytes |
59 | bInterval 0 |
60 | Endpoint Descriptor: |
61 | bLength 7 |
62 | bDescriptorType 5 |
63 | bEndpointAddress 0x82 EP 2 IN |
64 | bmAttributes 2 |
65 | Transfer Type Bulk |
66 | Synch Type None |
67 | Usage Type Data |
68 | wMaxPacketSize 0x0020 1x 32 bytes |
69 | bInterval 0 |
70 | Interface Descriptor: |
71 | bLength 9 |
72 | bDescriptorType 4 |
73 | bInterfaceNumber 1 |
74 | bAlternateSetting 0 |
75 | bNumEndpoints 2 |
76 | bInterfaceClass 8 Mass Storage |
77 | bInterfaceSubClass 6 SCSI |
78 | bInterfaceProtocol 80 Bulk-Only |
79 | iInterface 5 ST-Link mass storage |
80 | Endpoint Descriptor: |
81 | bLength 7 |
82 | bDescriptorType 5 |
83 | bEndpointAddress 0x83 EP 3 IN |
84 | bmAttributes 2 |
85 | Transfer Type Bulk |
86 | Synch Type None |
87 | Usage Type Data |
88 | wMaxPacketSize 0x0040 1x 64 bytes |
89 | bInterval 0 |
90 | Endpoint Descriptor: |
91 | bLength 7 |
92 | bDescriptorType 5 |
93 | bEndpointAddress 0x03 EP 3 OUT |
94 | bmAttributes 2 |
95 | Transfer Type Bulk |
96 | Synch Type None |
97 | Usage Type Data |
98 | wMaxPacketSize 0x0040 1x 64 bytes |
99 | bInterval 0 |
100 | Interface Association: |
101 | bLength 8 |
102 | bDescriptorType 11 |
103 | bFirstInterface 2 |
104 | bInterfaceCount 2 |
105 | bFunctionClass 2 Communications |
106 | bFunctionSubClass 2 Abstract (modem) |
107 | bFunctionProtocol 1 AT-commands (v.25ter) |
108 | iFunction 6 ST-Link VCP Ctrl |
109 | Interface Descriptor: |
110 | bLength 9 |
111 | bDescriptorType 4 |
112 | bInterfaceNumber 2 |
113 | bAlternateSetting 0 |
114 | bNumEndpoints 1 |
115 | bInterfaceClass 2 Communications |
116 | bInterfaceSubClass 2 Abstract (modem) |
117 | bInterfaceProtocol 1 AT-commands (v.25ter) |
118 | iInterface 6 ST-Link VCP Ctrl |
119 | CDC Header: |
120 | bcdCDC 1.10 |
121 | CDC Call Management: |
122 | bmCapabilities 0x00 |
123 | bDataInterface 3 |
124 | CDC ACM: |
125 | bmCapabilities 0x06 |
126 | sends break |
127 | line coding and serial state |
128 | CDC Union: |
129 | bMasterInterface 2 |
130 | bSlaveInterface 3 |
131 | Endpoint Descriptor: |
132 | bLength 7 |
133 | bDescriptorType 5 |
134 | bEndpointAddress 0x84 EP 4 IN |
135 | bmAttributes 3 |
136 | Transfer Type Interrupt |
137 | Synch Type None |
138 | Usage Type Data |
139 | wMaxPacketSize 0x0002 1x 2 bytes |
140 | bInterval 255 |
141 | Interface Descriptor: |
142 | bLength 9 |
143 | bDescriptorType 4 |
144 | bInterfaceNumber 3 |
145 | bAlternateSetting 0 |
146 | bNumEndpoints 2 |
147 | bInterfaceClass 10 CDC Data |
148 | bInterfaceSubClass 0 |
149 | bInterfaceProtocol 0 |
150 | iInterface 7 ST-Link VCP Data |
151 | Endpoint Descriptor: |
152 | bLength 7 |
153 | bDescriptorType 5 |
154 | bEndpointAddress 0x05 EP 5 OUT |
155 | bmAttributes 2 |
156 | Transfer Type Bulk |
157 | Synch Type None |
158 | Usage Type Data |
159 | wMaxPacketSize 0x0008 1x 8 bytes |
160 | bInterval 0 |
161 | Endpoint Descriptor: |
162 | bLength 7 |
163 | bDescriptorType 5 |
164 | bEndpointAddress 0x85 EP 5 IN |
165 | bmAttributes 2 |
166 | Transfer Type Bulk |
167 | Synch Type None |
168 | Usage Type Data |
169 | wMaxPacketSize 0x0010 1x 16 bytes |
170 | bInterval 0 |
171 | Device Status: 0x0000 |
172 | (Bus Powered) |
Edit: Keine Ahnung warum die Forensoftware da jetzt extra Zeilenumbrüche einbaut.
:
Bearbeitet durch User
Malte _. schrieb: > Keine Ahnung warum die Forensoftware da jetzt extra Zeilenumbrüche > einbaut. Keine Ahnung warum du es nichst schaffst, die Hinweise zum Posten von langen Codes/Texten zu lesen, zu verstehen und umzusetzen.
Wastl schrieb: > Keine Ahnung warum du es nichst schaffst, die Hinweise zum Posten > von langen Codes/Texten zu lesen, zu verstehen und umzusetzen. Wetten, der Text war im Original viel kürzer?
:
Bearbeitet durch User
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.