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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
Eine eigene Frage?
Dieser Thread ist über ein Jahr alt.
Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.
