Forum: Mikrocontroller und Digitale Elektronik STM32 USB Übertragungsproblem mit Code von S.F.


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Alex (Gast)


Angehängte Dateien:

Lesenswert?

Hallo Community!

Ich hab seit längerem eine Hardware mit einem kleinen STM32F042 zum 
Datenerfassen via USB (VCP) laufen.
Über den USB werden kleine Datenpakete (Messwerte, wenige Bytes) etwa im
Sekundentakt übertragen. Zu Konfigurationszwecken gibt es auch
ein paar Parameter die über Terminal eingestellt werden können. Ist aber
alles nicht Zeitkritisch.
Hab mit eurer (vor allem mit W.S. und Stefan Frings Hilfe, deren Code 
ich auch verwende (VIELEN DANK !!!!!!)) den USB hinbekommen.

Beitrag "STM32 USB init problem mit Kompaktcode von W.S."

Jetzt hab ich wieder ein Problem, bei dem ich nicht weiterkomme:

Ich hab mehrere von diesen USB-Datenerfassungsmodulen gebaut, und hab 
schon mehrmals beobachtet, dass manche Exemplare komisches Verhalten 
zeigen, wenn man vom PC Befehle zum STM schickt.

Aktuell hab ich ein Exemplar, das reagiert einfach garnicht auf Befehle.
Reproduzierbar auf verschiedenen PCs, Win7, Win10, Linux.
Die Daten vom STM kommen im Sekundentakt zum PC wie sie sollen (ist 
default).
Hab mit wireshark die Pakete von einem 'guten' (Bild links) und dem 
'schlechten' (Bild rechts) Modul aufgenommen.
Ich sende vom Host aus jeweils den Befehl 'stop<CRLF>', beim 
'schlechten' Modul wird offenbar das Paket nochmals gesendet aber nicht 
mehr bestätigt. Die Datenpakete kommen munter weiter, während beim 
'guten' das Senden gestoppt wird.

An was könnte das liegen?

Viele Grüße,
Alex

von Alex (Gast)


Lesenswert?

Ich hab mir die Pakete (und den Unterschied) mal genauer angesehen. In 
dem ACK-Paket sind bei dem nicht funktionierenden STM zwei Bytes 
verändert, die beim anderen gleich bleiben:
1
Der 'schlechte' :
2
0000   1b 00 a0 a9 44 98 0f de ff ff 00 00 00 00 09 00   ....D...........
3
0010   00 01 00 05 00 02 03 06 00 00 00 73 74 6f 70 0d   ...........stop.
4
0020   0a                                                .
5
Antwort:                             VV       VV
6
0000   1b 00 a0 a9 44 98 0f de ff ff 04 00 00 c0 09 00   ....D...........
7
0010   01 01 00 05 00 02 03 00 00 00 00                  ...........
8
9
Der 'gute' :
10
0000   1b 00 60 07 77 95 0f de ff ff 00 00 00 00 09 00   ..`.w...........
11
0010   00 01 00 06 00 02 03 06 00 00 00 73 74 6f 70 0d   ...........stop.
12
0020   0a                                         .
13
Antwort
14
0000   1b 00 60 07 77 95 0f de ff ff 00 00 00 00 09 00   ..`.w...........
15
0010   01 01 00 06 00 02 03 00 00 00 00                  ...........
Leider bin ich (mangels C-Erfahrung) offenbar nicht in der Lage, in der 
usb.c von S.F. den Codeteil zu finden, der dieses ACK erzeugt.
Hat schon mal jemand so ein Problem gehabt?

von Alex (Gast)


Lesenswert?

Was sind das für Daten in dem Paket?

Am Anfang des Pakets sollte ja das PID-Byte gesendet werden, bei dem die 
4 LSBs invers zu den 4 MSBs sind. Das ist aber bei 0x1b garnicht der 
Fall.

Auch ist am Ende kein CRC bzw. EOF angehängt.
Damit zeigt Wireshark offenbar die reinen nettoDaten.
Aber warum ist das dann in den AXK-Paketen auch drinnen?
Die sollten ja keine Daten beinhalten.

Sämtliche erklärungen in der USB-Literatur die ich bisher durchgekaut 
habe, beschäftigens sich nur mit dem Paketaufbau rund um die Daten.
Das passt für mich hinten und vorne nicht zusammen...

von Stefan ⛄ F. (stefanus)


Lesenswert?

Im Februar/März 2020 wurde hier ein Problem im Puffer diskutiert.
Beitrag "USB CDC von Stefan Frings und WS"

Ich hatte mich mangels technischem Verständnis aus der Diskussion 
weitgehend heraus gehalten, aber am Ende den Lösungsvorschlag in meinen 
Code übernommen. Allerdings hatte ich seit dem keinen konkrete 
Anwendungsfall dafür, er ist also nur sehr oberflächlich getestet.

Die Version auf meiner Homepage ist vom 12.03.2020, danach habe ich 
nichts mehr verändert. http://stefanfrings.de/stm32/stm32f1.html#usb

: Bearbeitet durch User
von Alex (Gast)


Lesenswert?

Hallo Stefan,

Den thread hab ich schon gefunden, allerdings nicht im Detail 
durchgearbeitet.
Ich hab aber im Zuge der Fehlersuche das Projekt auf deine neue Version 
umgestellt. Das hat aber am Verhalten nichts verändert.

Ich würde daher sagen, dass es unwahrscheinlich ist, dass das ein Bug in 
deiner neuen Version ist.

Danke und LG,
Alex

von Stefan ⛄ F. (stefanus)


Lesenswert?

Alex schrieb:
> Ich würde daher sagen, dass es unwahrscheinlich ist, dass das ein Bug in
> deiner neuen Version ist.

Es könnte allerdings dennoch ein alter Bug in dem Code sein. Oder ein 
Seiteneffekt von einem Fehler der ganz woanders versteckt ist.

Wenn dir da jemand helfen kann, dass wohl am ehesten Niklas G. 
Allerdings hat der wenig Freude am Code von W.S.

Vielleicht ist es besser, die Cube HAL zu benutzen oder das Ganze auf 
dem Beispiel von Niklas neu auf zu bauen. Der hilft dir dann bestimmt 
gerne weiter. 
https://www.mikrocontroller.net/articles/USB-Tutorial_mit_STM32

: Bearbeitet durch User
von Thomas Z. (usbman)


Lesenswert?

Eine Erklärung warum das Packet im Fehlerfall doppelt kommt wäre zum 
Beispiel ein falsch gesetztes ToggleBit beim Transfer. Das sollte dann 
aber immer auftreten und nicht nur bei einzelnen Devices.

Beschreibe doch Mal was du auf rs232 Ebene verschickst, bzw wie die 
Messpackete aussehen.

von Alex (Gast)


Lesenswert?

Die Pakete sind extrem simpel
Daten zum Host:
'Sensor1: 24.32°C<RCLF>'
So ein Datum kommt etwa alle Sekunden.

Daten vom Host:
'stop<CRLF>' stoppt die Messungen
'start<RCLF>' startet sie wieder

Es gibt noch einige Zusatzbefehle zu Konfiguration usw., aber das spielt 
hier eigentlich keine Rolle.

Entscheiden ist, das auf ein 'stop<CRLF>' offenbar eine fehlerhafte 
Antwort folgt, und das Paket dann nochmal gesendet wird.
Das wird dann aber vom STM ignoriert.

Wenn ich nicht aus dem Terminalprogramm (HTerm) sende, sondern z.B. aus 
Matlab (Messdatenauswertung), dann erkennt das Programm am PC das das 
Senden nicht möglich war.
Der PCseitige Treiber kriegt das also mit.

Alex

von Alex (Gast)


Lesenswert?

ersetze Tippfehler RCLF -> CRLF

von Peter Z. (hangloose)


Lesenswert?

Ich verwende den STM32CubeMX HAL USB Code.
Sehr einfach zum einbinden und funktioniert in meinem Fall
ohne Probleme.

von Alex (Gast)


Lesenswert?

Am Anfang hatte ich auch die HAL CDC in Verwendung, allerdings braucht 
die leider sehr viel Speicher, weshalb ich auf die schlankere 
Implementierung von W.S./S.F. gewechselt habe.

von Thomas Z. (usbman)


Lesenswert?

Alex schrieb:
> Entscheiden ist, das auf ein 'stop' offenbar eine fehlerhafte Antwort
> folgt, und das Paket dann nochmal gesendet wird.
> Das wird dann aber vom STM ignoriert.

nun tatsächlich ist es so, dass der Out Ep zb auf NAK stehen könnte dann 
würde der Host das einfach etwas später noch mal probieren.

Dieser 2te Transfer dürfte dann mit STALL beantwortet werden.
Begründung: Ein dauerhaftes NAK würde in einem Timeout enden, d.h. du 
würdest viel mehr Outs sehen.

Probier mal aus was danach passiert. Sende einfach deinen stop nochmal. 
Falls der EP auf STALL steht dürfte nichts mehr ankommen.

Sind  GetFeature/SetFeature und GetStatus für deine EPs korrekt 
implementiert?

von dummschwaetzer (Gast)


Lesenswert?

Taktprobleme? USB soll ja zimlich zeitkritisch sein. Wie erzeugen deine 
STM32F042 den internen USB-Takt?

von Alex (Gast)


Lesenswert?

Hallo Thomas Z.
Gute Idee, hatte ich noch nicht näher untersucht.

Wenn ich den Befehl wiederhole, wird er tatsächlich nicht mehr 
geschickt.
Wenn ich dann den VCP schließe kommt ein Bulk-Out Paket von EP2 (#2194), 
von dem ich vermute, dass es zu dem Paket #1909 gehört. Ist das 
plausibel?

Wenn ich den VCP erneut öffne, und den Befehl erneut schicke, wird er 
nur 1mal gesendet, beim Wiederholen nicht mehr. Beim Schließen kommt 
wieder ein Paket:
1
+ VPC öffnen
2
+ Befehl senden
3
#       time         src      dst     len   info
4
1907    43.156065    host     1.9.2   33    URB_BULK out 'befehl'
5
1908    43.156174    1.9.2    host    27    URB_BULK out
6
1909    43.156207    host     1.9.2   33    URB_BULK out 'befehl'
7
8
+ Befehl nochmal senden
9
<kein traffic>
10
+ VCP schließen
11
#       time         src      dst     len   info
12
2194    59.853448    1.9.2    host    27    URB_BULK out
13
14
+ VCP öffnen
15
+ Befehl senden
16
#       time         src      dst     len   info
17
2341    79.436340    host     1.9.2   33    URB_BULK out 'befehl'
18
19
+ Befehl nochmal senden
20
<kein traffic>
21
22
+ VCP schließen
23
#       time         src      dst     len   info
24
2372    87.408990    1.9.2    host    27    URB_BULK out

Was ich mit dieser Info jetzt anfange, weiß ich allerdings nicht 
wirklich.



Taktproblem würd ich ausschließen, weil
1) die Übertragung an sich ja funktioniert.
2) Takt wird mit CRS auf den USB synronisiert.

Alex

von Thomas Z. (usbman)


Lesenswert?

Da ist irgendwas im Buffer Code was blockiert. Stefan liegt da mit 
seiner Vermutung schon richtig.
Besorg dir mal UsbCV bei usb.org. Das Tool ist zwar etwas wackelig aber 
hilfreich. Zumindest die Chapter9 Tests sollten ohne Fehler oder 
Warnings durchlaufen. Ich selbst setze den Code von WS nicht ein, hab 
den deshalb nur überflogen. Ich benutze meine eigenen Implementation 
bzw. auf ARM den 3fach Code von Niklas.

von Alex (Gast)


Lesenswert?

Moin Thomas,

mit UsbCV werd ich testen (sicherheitshalber auf einem anderen Rechner, 
das Installationsprogramm warnt deutlich davor, dass man sich damit 
Keyboard/Maus vom System wegschießen kann).

Weist du, wie diese Pakete aufgebaut sind?
Bzw. wo es dazu eine überschaubare Doku gibt?
Was ist in den (ersten) 24 Bytes des Pakets drinnen?

Alex

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

Mal meine fehlergkorrigierte Version von W.S.' Code probiert?

https://github.com/Erlkoenig90/WSusb

Es ist ziemlich umständlich ASCII-Befehle in USB-Pakete einzupacken. 
Wäre es nicht einfacher, SETUP-Pakete mit den richtigen Codes über den 
Control Endpoint zu schicken? Das lässt sich auch leichter verarbeiten 
und spart das Parsen.

Ansonsten würde ich auf ein Softwareproblem tippen. Breakpoint in den 
USB-IRQ setzen und schauen was beim Empfang des Pakets passiert bzw. die 
Empfangs-Routine durchsteppen.

Sonst kann ich natürlich nur empfehlen, meinen USB-Code zu verwenden, 
der hat solche Probleme bisher nicht...

von Alex (Gast)


Lesenswert?

Hallo Niklas,

deine Version kannt ich bisher nicht, werd ich aber definitiv versuchen 
einzubauen.

Das mit den ASCII-Befehlen hat den simplen Grund, ohne irgendeine 
spezielle Software auf der PC-Seite auszukommen.

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

Alex schrieb:
> Das mit den ASCII-Befehlen hat den simplen Grund, ohne irgendeine
> spezielle Software auf der PC-Seite auszukommen.

Damit macht man es sich aber letztlich komplizierter. Mit der direkten 
Ansteuerung des USB-Protokolls z.B. per libusb erspart man sich eine 
Menge Fehlerpotential. Dass die Befehle wie 'stop<CRLF>' als ein 
USB-Paket ankommen ist ja auch keineswegs gesagt, der Host-Treiber für 
CDC-ACM kann die Texte beliebig zerstückeln oder puffern.

PS: Wieso muss man die Messung überhaupt stoppen können? Man könnte auch 
die USB-Standby-Funktionalität implementieren, sodass der Host das Gerät 
zum Energie sparen abschalten kann, es aber ansonsten einfach immer 
läuft.

: Bearbeitet durch User
von Thomas Z. (usbman)


Lesenswert?

Alex schrieb:
> das Installationsprogramm warnt deutlich davor, dass man sich damit
> Keyboard/Maus vom System wegschießen kann).

Die Warnung betrifft vor allem PCs bei denen Maus und KB über USB 
angeschlossen ist. Das Tool schaltet den Hostcontroller in einen spez. 
Test Mode weshalb danach keines der am Host angeschlossenen Geräte 
normal funktioniert. Danach werden je nach Auswahl diverse Kommandos 
abgesetzt und die Ergebnisse ausgewertet. Beim Beenden wird dann der der 
HostController wieder zurückgeschaltet. Auf einem Laptop sollte es kein 
Problem geben da Maus und KB üblicherweise nicht an USB hängen.

Ich versuche damit gerade ein MSC Device spec konform zu bekommen. Deine 
Frage zu den 24 Bytes kann ich nicht beantworten, glaube aber dass das 
irgendwelche Pointer (urb, Sequenznummern usw) sind, die nichts mit den 
Ep buffern zu tun haben.

von Thomas Z. (usbman)



Lesenswert?

hier mal 2 Beispiele für solche reports von UsbCV. Die stammen von 
meinem Compound Device was MSC und VCP können wird.

: Bearbeitet durch User
von Alex (Gast)


Lesenswert?

Hab jetzt mal schnell das usbCV auf einem 'guten' und dem 'schlechten' 
STM durchlaufenlassen. Hab zuvor die usb.c auf die Neue Version von 
Niklas umgemünzt.

Sowohl mit der alten Software (von S.F.) als auch mit der neuen von 
Niklas kommt ein Fehler beim
Halt Endpoint Test.

Für mich ergibt sich daraus die Vermutung, dass es an der Anpassung an 
meinen STM32F042-Controller liegt.



Zum ASCII:
- der USB Treiber darf die Befehle zerpflücken (tut er auch), das macht 
aber nix.
- Das device muss ohne spezielle Treiber auf verschiedenen Plattformen 
unkompliziert laufen -> VCP ist die beste Möglichkeit dafür.
- das 'stop' ist nur ein möglicher Befehl, und Befehle braucht es für 
die Funktionalität die ich benötige.

Alex

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

Alex schrieb:
> - Das device muss ohne spezielle Treiber auf verschiedenen Plattformen
> unkompliziert laufen -> VCP ist die beste Möglichkeit dafür.

Bei Verwendung von libusb braucht es keine Treiber.

von Thomas Z. (usbman)


Lesenswert?

Alex schrieb:
> Sowohl mit der alten Software (von S.F.) als auch mit der neuen von
> Niklas kommt ein Fehler beim
> Halt Endpoint Test.

Dann gibt es einen Bug beim Get/SetFeature bzw GetStatus liefert nicht 
das erwartete Ergebnis. (STALL oder 0). Das hatte ich schon weiter oben 
angesprochen.

von Stefan ⛄ F. (stefanus)


Lesenswert?

Alex schrieb:
> Für mich ergibt sich daraus die Vermutung, dass es an der Anpassung an
> meinen STM32F042-Controller liegt.

Falls du in der Nähe von Düsseldorf wohnst könnte ich dir das Nucleo 
L073 Board ausleihen, mit dem ich damals getestet hatte.

von Alex (Gast)


Lesenswert?

Danke für euren Input Leute, ich komm nicht hinterher :-)

+ Zum Thema VCP / libUsb:
So wie die Devices jetzt sind, kann ich sie ohne Beschreibung oder 
sonstiger Info jemandem (z.B. einem Studenten) in die Hand drücken, und 
der kann damit was anfangen. Alles was er dazu braucht ist ein 
Terminalprogramm. Und das kriegt erfahrungsgemäß jeder hin. Mit allen 
anderen Lösungen muss auf dem Host-System irgendetwas 
implementiert/installiert werden. Und dieses irgendwas wird sich im Lauf 
der Zeit ändern. Damit hab ich permanent Support-Aufwand, den ich nicht 
haben will. Bei einem VCP ist das nicht nötig. Daher ist das aus meiner 
Sicht die beste Lösung.


+ Halt Endpoint Test
Der sollte eigentlich mit dem Code von Niklas (und auch S.F. Version von 
W.S. code) funktionieren.
Um auszuschließen, dass das an meinen Zusatzfunktionen liegt, werd ich 
morgen mal eine Minimalversion auf dem STM32F042 laufen lassen und den 
Test damit wiederholen.

Die Anpassungen an den Controller hat sich bei mir auf UMEM_SHIFT=0 und 
die USB_IRQ_NUMBER=31 beschränkt. Hab ich da ev. was übersehen?


+ Das Übertragungsproblem
Ist möglicherweise von dem Halt Endpoint Problem unabhängig, weil der 
Halt Endpoint Test auch bei jenen Modulen fehlschlägt, die für mich 
einwandfrei funktionieren.
Das Suchen dieses Fehlers ist auch etwas knifflig, weil ich das nicht 
auf einer anderen Hardware nachstellen kann.
(Danke Stefan für das großzügige Angebot, aber ich sitz in Österreich 
;-))


> Dann gibt es einen Bug beim Get/SetFeature bzw GetStatus liefert nicht
> das erwartete Ergebnis. (STALL oder 0). Das hatte ich schon weiter oben
> angesprochen.

Ich bin nicht sicher, ob ich das richtig interpretiere, aber in

void DoGetStatus(void)

hab ich folgende Zeile gefunden:
1
if ((EP == logEpCtrl) || (EP == logEpInt) || (EP == logEpBulkIn) || (EP == logEpBulkIn))

Sollte da vielleicht einer der Bulks ein BulkOut sein?


Alex

von Stefan ⛄ F. (stefanus)


Lesenswert?

Alex schrieb:
> Die Anpassungen an den Controller hat sich bei mir auf UMEM_SHIFT=0 und
> die USB_IRQ_NUMBER=31 beschränkt. Hab ich da ev. was übersehen?

UMEM_FAKEWIDTH vielleicht? Obwohl: Wenn irgendeiner der 
Konfigurationsparameter falsch wäre, würde wahrscheinlich gar nichts 
funktionieren.

: Bearbeitet durch User
von Thomas Z. (usbman)


Lesenswert?

Alex schrieb:
> hab ich folgende Zeile gefunden:
> if ((EP == logEpCtrl) || (EP == logEpInt) || (EP == logEpBulkIn) || (EP
> == logEpBulkIn))
>
> Sollte da vielleicht einer der Bulks ein BulkOut sein?

Genau so ist es.. Macht ja nicht soviel Sinn den gleichen Ep 2 mal 
abzufragen. Die Frage ist halt auch ob in den logxxx wirklich Stall 
conditions gespeichert sind. Mein eigener Code ist an der Stelle 
wesentlich aufwändiger.

Ob das allerdings bei deinem Übertragungsproblem hilft ist fraglich.

von temp (Gast)


Lesenswert?

Alex schrieb:
> 2) Takt wird mit CRS auf den USB synronisiert.

Du hast keinen Quarz dran? Dann wäre es das erste was ich probieren 
würde dem ganzen einen Quarz zu spendieren. Noch dazu wenn manche deiner 
Module gehen und ander nicht oder nicht immer. Das schreit ja förmlich 
nach Ursachen bei denen Toleranzen(oder jitter) eine Rolle spielen. Und 
wenn es nur darum geht andere Ursachen auszuschließen.
Ich benutze den Grundcode mit vielen STM32F103, STM32F3x3, STM32L151 ...
Oft als USB-CAN Interface mit SLCAN. Das entspricht ja so in etwa dem 
was du machst, nur mit viel mehr Last.
Gut den F042 hatte ich noch nicht. Aber immer mit Quarz.
Und es kann bei Taktproblemem ja durchaus sein, dass die Richtung zum PC 
funktioniert und die ander nicht(immer).

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

Alex schrieb:
> Bei einem VCP ist das nicht nötig. Daher ist das aus meiner
> Sicht die beste Lösung.

Bei Serial-Ports kommt auch Support-Aufwand:
- Welchen Port soll ich auswählen?
- Welche Baudrate und welches Frame-Format wähle ich aus?
- Was mache ich wenn der Linux ModemManager an neu angeschlossene 
Serial-Ports automatisch Nachrichten sendet weil es sie für ein Modem 
hält?
- Wie verhindere ich dass Windows das Serial-Gerät als serielle Maus 
erkennt?
- Soll ich das Echo ein/ausschalten?
- Welchen Zeilenumbruch soll ich verwenden?

Und ja, auch Fangfragen sind Aufwand ;-)

Alex schrieb:
> Mit allen
> anderen Lösungen muss auf dem Host-System irgendetwas
> implementiert/installiert werden.

Ein Programm, welches mittels libusb und WinUSB auf Geräte zugreift, die 
als WinUSB deklariert sind, braucht keinerlei 
Installation/Konfiguration. Gerät anschließen, Programm draufkopieren & 
starten, fertig. Weniger Aufwand als ein Terminalprogramm (Port-Auswahl 
usw.). Unter Linux brauchts die WinUSB-Deklaration natürlich nicht, da 
geht es einfach so, aber sie stört auch nicht.

von temp (Gast)


Lesenswert?

Niklas G. schrieb:
> Ein Programm, welches mittels libusb und WinUSB auf Geräte zugreift, die
> als WinUSB deklariert sind, braucht keinerlei
> Installation/Konfiguration. Gerät anschließen, Programm draufkopieren &
> starten, fertig. Weniger Aufwand als ein Terminalprogramm (Port-Auswahl
> usw.). Unter Linux brauchts die WinUSB-Deklaration natürlich nicht, da
> geht es einfach so, aber sie stört auch nicht.

Da magst du zwar Recht haben, nur spielt das für die Probleme hier keine 
Rolle. Im Gegenteil, dann hätten wir gleich mehrerer Baustellen 
gleichzeitig.
Es macht sicher auch einen gewaltigen Unterschied ob das ganze in die 
Großserie geht oder eine kleine Individuallösung ist. Und nicht jeder 
dringt so tief in die USB Materie ein um eine neue Gerätekategorie auf 
der Controllerseite zu implementieren. Deshalb ist ja VCP so beliebt, 
weil man  am reinen USB-Code nichts ändern muss. Es ist schließlich auch 
immer eine Frage des Zeitaufwandes.

von temp (Gast)


Lesenswert?

Ach noch ein Nachtrag. libusb unter Windows ist in meinen Augen eine 
Seuche. Vor allem wenn die Geräte mal mit einer Software und dem 
direkten Windowstreiber spielen soll, und eine andere Software nur 
libusb kann. Dann heißt es jedes mal die Treiber umkonfigurieren. 
Schlimmer geht nimmer. Gerade erst wieder für j-link und OpenOCD 
festgestellt.

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

temp schrieb:
> Es ist schließlich auch
> immer eine Frage des Zeitaufwandes.

Richtig, der ganze Entwicklungsaufwand zur Paket-Anfang/Ende-Erkennung, 
Parsen, ASCII-Formatierung, Pufferung zwischen einzelnen USB-Paketen 
entfällt wenn man keinen VCP nutzt.

USB direkt zu nutzen ist viel einfacher - man hat direkt das Konzept von 
Paketen und kann einfache Transaktionen simpel per SETUP-Paket auf dem 
Control-Channel abhandeln. Wenn man wenig Datenrate hat (wenige Bytes 
etwa im Sekundentakt?) würde es sogar reichen alles per Control Channel 
zu machen, wenn das Gerät nicht selbstständig senden können muss.

Bei mir im Studium hat ein Prof das übrigens genau so gemacht - einen 
PID-Regler auf einem USB-fähigen Mikrocontroller implementiert, der vom 
PC aus per USB mit einer eigenen Anwendung parametrisiert werden konnte. 
Hat super funktioniert.

temp schrieb:
> Vor allem wenn die Geräte mal mit einer Software und dem
> direkten Windowstreiber spielen soll, und eine andere Software nur
> libusb kann.

Für einen VCP hätte man auch keinen eigenen Windows-Treiber, daher keine 
vergleichbare Situation.

temp schrieb:
> Dann heißt es jedes mal die Treiber umkonfigurieren.
> Schlimmer geht nimmer.

Für die libusb+WinUSB Kombination braucht es keine Treiber-Installation 
oder Konfiguration. Windows lädt automatisch den WinUSB-Treiber und es 
funktioniert direkt.

von temp (Gast)


Lesenswert?

Niklas G. schrieb:
> Für die libusb+WinUSB Kombination braucht es keine Treiber-Installation
> oder Konfiguration. Windows lädt automatisch den WinUSB-Treiber und es
> funktioniert direkt.

Wenn ich meinen j-link in der Segger- oder Crossworks-IDE benutzen will, 
wird der normale jlink-Treiber verwendet. Will ich das Teil unter 
OpenOCD benutzen, muss ich das Gehampele mit Zadig machen damit das 
geht. Danach gehen die IDEs nicht mehr. Das ist Mist. Vor allem weil ich 
bei der Umschalterei seit sehr, sehr langer Zeit mal wieder einen 
Bluescreen gesehen habe.

Was mache ich falsch?

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

temp schrieb:
> Was mache ich falsch?

Die J-Link Firmware gibt sich nicht als WinUSB Device aus, verwendet 
einen "normalen" Windows-Treiber, und OpenOCD verwendet wohl kein 
WinUSB. Blöd, aber nicht relevant für diesen Thread, weil man für das 
eigene Gerät sowieso keinen normalen Treiber implementieren würde und 
man problemlos den WinUSB-Deskriptor einbauen kann.

Bei Verwendung eines VCP würde man auch keinen eigenen Windows-Treiber 
einbinden der auf Basis des RS232-Protokoll ein eigenes API zu Verfügung 
stellt (geht das überhaupt?) und dann abwechselnd eine Anwendung 
verwenden welche den Port direkt anspricht.

Der normale Windows-Treiber hat den Vorteil dass mehrere Anwendungen 
gleichzeitig drauf zugreifen können (das nutzen die Segger-Tools ja 
auch), aber das geht beim VCP auch nicht.

: Bearbeitet durch User
von Thomas Z. (usbman)


Lesenswert?

temp schrieb:
> Was mache ich falsch?

gar nichts.
Ich stimme mit dir überein, dass Libusb unter Win eher suboptimal ist. 
Win hatte sehr lange Zeit einfach kein Konzept für einen Usermode 
Treiber. Das würde dann durch WinUsb behoben, leider viel zu spät. 
Deshalb hat sich WinUsb bis heute nicht so richtig durchgesetzt. Ich bin 
ehrlich gesagt froh, dass es Zadig gibt.

Ich bin aber auch mit Niklas der Meinung, dass das Kombo Libusb für 
Linux, WinUsb für Win die flexiblere Lösung ist. Unter Win funktioniert 
WinUsb fast wie ein Klassentreiber. Der Anwender braucht sich nie mehr 
um Treiber Installationen kümmern. Das ist VCP ja auch noch unter W7 
immer noch ein Problem.

von temp (Gast)


Lesenswert?

Niklas G. schrieb:
> Blöd, aber nicht relevant für diesen Thread

Naja, du hattest damit angefangen libusb ins Spiel zu bringen, was für 
diesen Thread ja auch nicht relevant ist. Und ich habe dir nur darauf 
geantwortet, dass ich lieber bei VCP bleibe als mit libusb zu hantieren.

Ich denke wir belassen es dabei und warten mal ob Alex seine Probleme 
lösen kann oder nicht. Ein völlig neuer Ansatz bringt ihn da sicher 
nicht weiter.
Zumal ich bei den STM32F042 mit 32k Flash auch öfters an die Grenzen 
kommen und der verwendete Code hier kleiner ist als alle anderen Libs.

Was noch sehr klein ist ist der USB Teil vom hid-Bootloader:
https://github.com/Serasidis/STM32_HID_Bootloader

Basierend auf dem Code von W.S. habe ich hier auch schon mal ein 
Midi-Interface implementiert:
Beitrag "STM32 USB-MIDI"

Auch dabei kam es zu keinen Problemen die mit denen von Axel zu 
vergleichen waren. Ich denke so lange nicht das Gegenteil bewiesen ist, 
wird der Fehler beim Takt oder einer anderen Stelle liegen aber nicht 
beim Code von W.S., S.F. oder N.G.

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

temp schrieb:
> Naja, du hattest damit angefangen libusb ins Spiel zu bringen, was für
> diesen Thread ja auch nicht relevant ist.

Ich finde es relevant, weil die libusb+WinUSB Kombo für solche einfachen 
Selbstbau-Geräte perfekt ist.

temp schrieb:
> Und ich habe dir nur darauf
> geantwortet, dass ich lieber bei VCP bleibe als mit libusb zu hantieren.

Aber mit einem Argument welches sich auf normale Windows-Treiber bezieht 
und nicht auf die vorgeschlagene libusb+WinUSB Lösung.

temp schrieb:
> Ein völlig neuer Ansatz bringt ihn da sicher
> nicht weiter.

Ein Ansatz welcher ohne die VCP-Bastelei (insb. mit der davon benötigten 
Pufferverwaltung) und ohne W.S.' Implementation davon auskommt könnte 
ihn durchaus weiter bringen.

von Johannes S. (jojos)


Lesenswert?

der JLink bringt doch einen GDB Server mit, ist OOCD da überhaupt nötig?

von temp (Gast)


Lesenswert?

Niklas G. schrieb:
> Der normale Windows-Treiber hat den Vorteil dass mehrere Anwendungen
> gleichzeitig drauf zugreifen können (das nutzen die Segger-Tools ja
> auch), aber das geht beim VCP auch nicht.

Was soll da auch sinnvolles dabei rauskommen?

Thomas Z. schrieb:
> Ich bin aber auch mit Niklas der Meinung, dass das Kombo Libusb für
> Linux, WinUsb für Win die flexiblere Lösung ist. Unter Win funktioniert
> WinUsb fast wie ein Klassentreiber. Der Anwender braucht sich nie mehr
> um Treiber Installationen kümmern. Das ist VCP ja auch noch unter W7
> immer noch ein Problem.

Das will ich ja nicht mal in Abrede stellen. Jedenfalls nicht solange 
alle! Programme die es für das jeweilige Gerät gibt diesen Weg benutzen. 
So wie beim SDR-Stick, da stört mich das auch nicht.

Es wäre schön, wenn jemand für den Code von W.S. (oder folgende) mal ein 
Beispiel veröffentlichen würde das den von euch vorgeschlagenen Weg 
benutzt.
So wie ich mit dem MIDI-Beispiel. Danke schon im Voraus an den der es 
macht.

von temp (Gast)


Lesenswert?

Johannes S. schrieb:
> der JLink bringt doch einen GDB Server mit, ist OOCD da überhaupt nötig?

Nein, natürlich nicht. Das war nur ein Beispiel.

von temp (Gast)


Lesenswert?

Niklas G. schrieb:
> Ein Ansatz welcher ohne die VCP-Bastelei (insb. mit der davon benötigten
> Pufferverwaltung) und ohne W.S.' Implementation davon auskommt könnte
> ihn durchaus weiter bringen.

So wie der Code von W.S. jetzt bei S.F. steht ist er nicht so schlecht, 
dass man ständig davon abraten muss. Deine C++ Implementierung ist auch 
nicht der letzte Schrei und mir persönlich viel zu aufgebläht. Aber was 
soll's, jeder hat seine eigenen Vorlieben und macht seine eigenen 
Erfahrungen.

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

temp schrieb:
> Es wäre schön, wenn jemand für den Code von W.S. (oder folgende) mal ein
> Beispiel veröffentlichen würde das den von euch vorgeschlagenen Weg
> benutzt.

Also einfach nur das Einbauen des WinUSB-Deskriptors und das Entfernen 
des CDC-ACM-Deskriptors? Der PC-Seite ist es egal ob es W.S.' oder mein 
Code ist.

temp schrieb:
> Was soll da auch sinnvolles dabei rauskommen?

Genau so viel wie bei der Idee, dass OpenOCD nicht den J-Link-Treiber 
nutzt. Warum auch immer das so ist...

temp schrieb:
> Das war nur ein Beispiel.

Ein Beispiel wie man etwas auf Basis von Technologie X schlecht umsetzt 
ist kein Grund Technologie X nicht zu nutzen...

temp schrieb:
> So wie der Code von W.S. jetzt bei S.F. steht ist er nicht so schlecht,
> dass man ständig davon abraten muss.

Ich finde das Grundkonzept, mit blockierenden Funktionen 
USB-Datentransfers zu machen ziemlich fragwürdig. Wenn sich da etwas 
verheddert mit anderen Interrupts in der Anwendung ist es gut möglich, 
dass das Programm stecken bleibt. Die Originalversion hat auch einen 
fragwürdigen C-Stil und diverse Bugs; ob es davon nicht noch mehr gibt 
weiß man nicht...

temp schrieb:
> Deine C++ Implementierung ist auch
> nicht der letzte Schrei und mir persönlich viel zu aufgebläht.

Sie blockiert immerhin nicht die main()-Schleife. Was daran aufgebläht 
sein soll weiß ich nicht.

: Bearbeitet durch User
von Thomas Z. (usbman)


Lesenswert?

Ich hab mir jetzt nochmal den Code von WS in der Version von Niklas 
näher angesehen. Ich bin mir ziemlich sicher, dass zumindest OnGetStatus 
() im Falle der Enpoints (case 0x82:) keine korrekten Antworten liefert.
Der Requests sollte ja den Zustand des EPs liefern. 1 für STALL 0 für 
UNSTALL.
Der Code liefert aber für gültige Endpoints immer STALL, und wegen des 
copypaste Fehlers beim BulkoutEP immer UNSTALL.
Ich werde versuchen dafür einen Patch einzustellen auch wenn Git noch 
nicht so mein Ding ist.

Ich bin aber immer noch der Meinung, dass dieser Bug nicht ursächlich 
für die Probleme des TO ist

von temp (Gast)


Lesenswert?

Niklas G. schrieb:
> Ich finde das Grundkonzept, mit blockierenden Funktionen
> USB-Datentransfers zu machen ziemlich fragwürdig. Wenn sich da etwas
> verheddert mit anderen Interrupts in der Anwendung ist es gut möglich,
> dass das Programm stecken bleibt. Die Originalversion hat auch einen
> fragwürdigen C-Stil und diverse Bugs; ob es davon nicht noch mehr gibt
> weiß man nicht...

In ein paar Punkten muss ich dir widersprechen. Es ist nicht das 
Grundkonzept mit blockierenden Funktionen zu arbeiten. Der reine 
USB-Teil arbeitet wie bei dir auch interruptgetrieben. Anderenfalls wäre 
eine main-loop nötig, die es
aber nicht gibt. Die einzige Stelle in der das blockieren kann ist die

bool UsbCharOut(char c)

und die ist ja wohl dem User-Code zuzurechnen und hier nur ein Beispiel. 
Und dass sie blockiert ist da auch nicht nötig, das kann jeder handhaben 
wie er will.

Das mit den Bugs weiß man bei deinem Code auch nicht, und der C-Stil ist 
ja wohl Ansichtssache. Ob dein Code außer für dich für jedermann sofort 
verständlicher ist?

Niklas G. schrieb:
> Also einfach nur das Einbauen des WinUSB-Deskriptors und das Entfernen
> des CDC-ACM-Deskriptors? Der PC-Seite ist es egal ob es W.S.' oder mein
> Code ist.
Und genau das ist schon die Stelle, wo viele scheitern. Die wollen so 
eine Lib benutzen ohne die Deskriptoren jemals verstanden zu haben. Und 
weil das so ist, wird noch so oft VCP verwendet.

Jetzt ist hier aber für mich Schluss mit allen Diskussionen die sich 
nicht mehr um das eigentliche Problem drehen.

von W.S. (Gast)


Lesenswert?

Also Leute, nun habt ihr schon etwa 7 Tage lang hier herumdiskutiert und 
alles sonstige wie Libusb, Zadig, und sonstwas genannt.

Führt das zu etwas? Nö.

Und auch die Ansichten von Niklas: "USB direkt zu nutzen ist viel 
einfacher - man hat direkt das Konzept von Paketen..." sind hier 
überhaupt nicht zielführend, denn das wäre dann eben kein virtueller 
COM-Port mehr, sondern etwas ganz anderes.

Also merkt doch mal, daß der Sinn eines virtuellen COM-Portes eben genau 
darin besteht, daß man eine asynchrone Einzelzeichen-Verbindung von 
einer App auf dem PC bis hin zu einer anderen "App" (sprich Firmware) 
auf einem anderen gerät haben kann, OHNE daß sich die beiden Apps 
darum scheren müßten, wie die Daten zwischendurch transportiert werden. 
Das ist sache des OS und das OS soll das eben so tun, daß die Verbindung 
funktioniert, ohne daß die Apps sich um deren interne Details kümmern 
müssen.

So und wenn ich das hier lese:

Alex schrieb:
> Aktuell hab ich ein Exemplar, das reagiert einfach garnicht auf Befehle.
> Reproduzierbar auf verschiedenen PCs, Win7, Win10, Linux.
> Die Daten vom STM kommen im Sekundentakt zum PC wie sie sollen (ist
> default).

..dann kommt mir der Gedanke, daß die Richtung PC-->µC irgendwie gestört 
ist. Folglich würde ich an einen freien UART des µC mal etwas 
dranhängen, einen anderen Port des PC zum Beispiel, und im µC den 
Datenstrom vom USB-Treiber her auf diesen UART ausgeben, damit man mal 
sehen kann, was da denn  so ankommt. Und das ohne irgendwelche Debugger, 
Usbsniffer etc. und nur mittels der normalen Firmware, damit möglichst 
nichts an unvorhergesehenen Beeinflussungen passieren kann. Dann dürfte 
man ja wohl weiter sehen und dem Problem etwas näher kommen.

Alex schrieb:
> Ich hab mehrere von diesen USB-Datenerfassungsmodulen gebaut, und hab
> schon mehrmals beobachtet, dass manche Exemplare komisches Verhalten
> zeigen, wenn man vom PC Befehle zum STM schickt.

Gegenfrage: hast du in deine Firmware einen kleinen Kommandointerpreter 
eingebaut? Also etwas, das aus den hereinkommenden Einzelzeichen eine 
Kommandozeile aufbaut (und die Zeichen echot) und diese nach einen CR 
oder wenn der Puffer dafür voll ist dann auswertet? Und wenn da etwas 
unverständliches drin steht, einen Fehlertext zurückschickt? Wäre wohl 
hilfreich.


Nochwas:

Alex schrieb:
> hab ich folgende Zeile gefunden:...

Ja, das ist wohl dieses hier (in DoGetStatus):
1
  ...
2
    case 0x82:          /* für einen Endpoint */
3
         if ((EP==logEpCtrl)   ||
4
             (EP==logEpInt)    ||
5
             (EP==logEpBulkIn) ||
6
             (EP==logEpBulkIn))  Buf[0] = 1;
7
         break;
und das ist offensichtlich ein uralter Schreibfehler, der offenbar noch 
niemandem (mich eingeschlossen) aufgefallen ist. Ja, der steht auch 
bei Niklas drin. Ich bin mir aber nicht sicher, ob diese Sequenz 
überhaupt benötigt wird. Vielleicht sollte mal jemand anderes den 
Quelltext nach etwaigen weiteren derartigen Schusselfehlern durchsuchen.

Noch ein Wort zu Niklas' Version: Ich finde es bedenklich, unschön und 
unüberlegt, bei jeder Gelegenheit von der Anwendungsebene aus am 
Interrupt herumzuschalten. Das ist Programmieren mit dem Schmiedehammer. 
Die Cortexe sind 32 Bit Maschinen und da sind Zugriffe auf die Indizes 
allesamt atomar und eine jede Seite ändert NICHTS an dem Index, der ihr 
nicht gehört. Folglich ist all dieses DisableUsbIRQ() etc. nicht 
erforderlich. Auch mit anderen Dingen (UsbActive(), UsbTxFlush()) hat 
sich dieser Treiber vom Prinzip des COM-Ports entfernt und kann in der 
Firmware nicht mehr wirklich genau so wie ein UART benutzt werden. Mir 
wäre das wichtig, aber wer es partout anders halten will, mag es halt 
tun.

W.S.

von Stefan ⛄ F. (stefanus)


Lesenswert?

W.S. schrieb:
> Folglich ist all dieses DisableUsbIRQ() etc. nicht
> erforderlich.

Dankeschön. Ich habe das eingebaut weil einige Leute darauf bestanden 
dass es nötig sei, aber auch ich bin immer noch der Meinung, dass das 
Quatsch war. Ich nehme das wieder raus.

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

W.S. schrieb:
> Noch ein Wort zu Niklas' Version: Ich finde es bedenklich, unschön und
> unüberlegt, bei jeder Gelegenheit von der Anwendungsebene aus am
> Interrupt herumzuschalten. Das ist Programmieren mit dem Schmiedehammer.

Der eigentliche Fehler ist es, aus der main-Schleife heraus auf die 
Kommunikation zuzugreifen. Würde man das in Interrupts machen, hätte man 
das Problem nicht.

W.S. schrieb:
> Folglich ist all dieses DisableUsbIRQ() etc. nicht
> erforderlich.

In meinem Code werden unter der Interruptsperre jeweils mehrere 
Bedingungen verknüpft. z.B. bei:
1
/* liefert true, wenn noch ein Zeichen in den Tx-Buffer passt */
2
bool UsbTxReady(void)
3
{
4
    DisableUsbIRQ ();
5
    bool res = configurationSet && !suspended && ((txw + 1) & (txLen - 1)) != txr;
6
    EnableUsbIRQ ();
7
8
    return res;
9
}

Ohne die Interruptsperre könnte zwischen dem Auslesen von 
configurationSet und txw o.ä. ein Interrupt kommen.

Bei Sachen wie:
1
/* liefert true, wenn Tx-Buffer leer ist */
2
bool UsbTxEmpty(void)
3
{
4
  DisableUsbIRQ ();
5
    bool res = (txw == txr);
6
    EnableUsbIRQ ();
7
    return res;
8
}
kann es sogar sein dass die Interruptsperre unnötig ist; ich war ehrlich 
gesagt zu faul mir das ganz genau für alle Fälle zu überlegen. Wenn du 
mir genau aufschlüsseln kannst dass das wirklich in allen Funktionen 
unnötig ist, kann ich das übernehmen. Man muss ja auch beachten dass die 
Auslese-Reihenfolge der Variablen (hier: txw und txr) nicht garantiert 
ist.

Da das ganze sowieso sehr ineffizient ist (jedes Zeichen einzeln im FIFO 
verarbeiten), macht das Ein/Aus-Schalten den Braten auch nicht fetter.

W.S. schrieb:
> und kann in der
> Firmware nicht mehr wirklich genau so wie ein UART benutzt werden

Kann deiner auch nicht, wenn der Host den Port deaktivieren/aktivieren 
können ohne das Programm zu blockieren soll (wie im alten Thread 
gewünscht). Code der mit deiner Lib funktioniert müsste auch mit meiner 
korrigierten Version funktionieren.

W.S. schrieb:
> Also merkt doch mal, daß der Sinn eines virtuellen COM-Portes eben genau
> darin besteht, daß man eine asynchrone Einzelzeichen-Verbindung von
> einer App auf dem PC bis hin zu einer anderen "App" (sprich Firmware)
> auf einem anderen gerät haben kann,

Hier ist aber keine Einzelzeichen-Übertragung gewünscht, sondern mehrere 
Zeichen lange Pakete. Und die machen es wieder komplizierter, weil man 
Paket-Anfang/Ende erkennen muss usw. Und da USB rein zufällig ein Modell 
für Transaktionen und Datenpakete schon beinhaltet, macht es viel mehr 
Sinn, das einfach zu nutzen, als das in einen Einzel-Zeichen-Strom zu 
abstrahieren und da wieder Pakete hinein zu definieren.

: Bearbeitet durch User
von Stefan ⛄ F. (stefanus)


Lesenswert?

Zur Info: Die Variable "suspended" wurde erst später (nicht von W.S.) 
hinzugefügt. Dass man dort eine Interrupt-Sperre Sinn macht hatte er 
wohl deswegen nicht auf dem Schirm.

von temp (Gast)


Lesenswert?

Schön dass alle Krieger versammelt sind...

Niklas G. schrieb:
> Der eigentliche Fehler ist es, aus der main-Schleife heraus auf die
> Kommunikation zuzugreifen. Würde man das in Interrupts machen, hätte man
> das Problem nicht.

Sorry aber das tut schon weh. Wo ist denn das ein Problem? Diesen Teil 
muss doch sowieso jeder an seine Applikation anpassen und damit die 
UsbCharOut().
Und je nachdem was ich will, breche ich nach einem Timeout ab, oder 
gleich, oder oder oder. Und wenn jemanden das mit dem char zu wenig ist, 
dann muss man da ein wenig optimieren. Aber das hat rein gar nichts mit 
dem USB-Grundcode zu tun.
Ich glaube fast du bist auch so ein typischer Programmierer für den alle 
Räder eckig sind die sie nicht selbst erfunden haben.

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

temp schrieb:
> Wo ist denn das ein Problem?

(Blockierender) I/O-Code in der main()-Schleife ist nicht für 
Nebenläufigkeit skalierbar. Da gehören höchstens rechenintensive Dinge 
hin. Alles andere handelt man im jeweiligen Interrupt ab.

temp schrieb:
> Ich glaube fast du bist auch so ein typischer Programmierer für den alle
> Räder eckig sind die sie nicht selbst erfunden haben.

Rein zufällig ist sowohl die USB-Peripherie als auch ST's eigene Library 
komplett darauf ausgelegt, asynchron aus ISRs heraus benutzt zu werden.

von Stefan ⛄ F. (stefanus)


Lesenswert?

Jeder kann und darf den Code so weit aufblähen, wie er es braucht. Ich 
halte die Kritik an diesem Punkt es für unnötige Ablenkung vom Thema.

von temp (Gast)


Lesenswert?

Niklas G. schrieb:
> Rein zufällig ist sowohl die USB-Peripherie als auch ST's eigene Library
> komplett darauf ausgelegt, asynchron aus ISRs heraus benutzt zu werden.

Das ist doch hier auch der Fall. Mir scheint du hast den Code überhaupt 
nicht verstanden. Ansonsten zeig die Stellen konkret auf die du dich 
beziehst. Das wird langsam lächerlich mit dir.

Wo soll den der USB Interrupt her wissen wann es etwas zum senden gibt? 
Und wenn ich was senden will ist es mir in der Regel nicht egal ob der 
USB-Teil das annimmt oder nicht? Und wie man damit umgeht, wenn etwas 
nicht gesendet werden konnte, das kannst du ruhig dem Anwender 
überlassen.

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

temp schrieb:
> Mir scheint du hast den Code überhaupt
> nicht verstanden.

Genau, deswegen hab ich auch W.S.'s Bugs beheben können, die er seit 
Jahren nicht gefunden hat.

temp schrieb:
> Wo soll den der USB Interrupt her wissen wann es etwas zum senden gibt?

Schau einfach in meinen Code und in mein Tutorial, da ist alles genau 
erläutert.

von Jürgen S. (avus)


Lesenswert?

Nun habe ich den Code von W.S. auch mal probiert. Danke auch an Stefan 
Frings, der auf seiner Webseite nützliche Erklärungen dazu 
bereitstellt.#
Ich habe 2h investiert und beschlossen, die andere Variante vom 
MCD-Application-Team mit ca. 20 Files aus meiner Bibliothek 
rauszuschmeissen und künftig die von W.S. zu nehmen, weil sie stabiler 
läuft.
Beim Verlassen von UsbSetup() prüfe ich mit UsbActive() noch ein paar 
ms, ob das Kabel drinsteckt bzw. USB bereit ist, und ansonsten war da 
nichts mehr dran zu ändern. Wobei ich mit der SPL programmiere und die 
ganzen Linkerscripts und Assemblerfiles nicht brauchte.
Neu war mir auch, daß man die GPIOs PA11/12 für USB gar nicht mit 
Alternate Function bzw. als In/Output vorbelegen muß.

von temp (Gast)


Lesenswert?

Jürgen S. schrieb:
> Ich habe 2h investiert und beschlossen, die andere Variante vom
> MCD-Application-Team mit ca. 20 Files aus meiner Bibliothek
> rauszuschmeissen und künftig die von W.S. zu nehmen, weil sie stabiler
> läuft.

Ja so ist es auch in der Regel. Warum das bei Axel Probleme machte weiß 
keiner, aber auch nicht ob eine andere Implementierung läuft. Der 
Verdacht liegt immer noch auf Hardware bzw. Takt.
Klar einen Schönheitspreis gewinnt der Code nicht, muss er aber auch 
nicht. Dafür ist er aber auch von keiner weiteren Lib abhängig und auch 
von keiner Headerorgie wo es je nach Umgebung an allen Ecken und Enden 
klemmen könnte.

von Bernd N. (_bn_)


Lesenswert?

Niklas G. schrieb:
> Genau, deswegen hab ich auch W.S.'s Bugs beheben können, die er seit
> Jahren nicht gefunden hat.

Wer hier den Hintergrund verstehen will sollte den folgneden Thread 
lesen:
Beitrag "USB CDC von Stefan Frings und WS"

Ich kann bestätigen das Niklas die Bugs gefixed hat und den Code nun 
auch bereitgestellt hat. Das geht immer wieder in anderen Folge Threads 
verloren.

Warum führt das eigentlich hier immer zu Streit ?

Wie dem auch sei, hat ja mit dem Thema nix zu tun. Jedenfalls verwende 
ich Niklas Version seit einem Jahr ohne irgendwelche Probleme.

von temp (Gast)


Lesenswert?

Bernd N. schrieb:
> Ich kann bestätigen das Niklas die Bugs gefixed hat und den Code nun
> auch bereitgestellt hat

Dann lest euch nochmal die Threads durch von wem die Bugs mit dem Nops 
beseitigt wurden. Da war kein Niklas im Spiel.
Niklas hat seinen Anteil insgesamt, aber nicht nur er.

von Bernd N. (_bn_)


Lesenswert?

temp schrieb:
> Niklas hat seinen Anteil insgesamt, aber nicht nur er.

Das ist mir durchaus klar.

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

temp schrieb:
> Dann lest euch nochmal die Threads durch von wem die Bugs mit dem Nops
> beseitigt wurden. Da war kein Niklas im Spiel.

Die Set-Adress-Korrektur war in der Version, die ich von W.S. übernommen 
hatte, schon drin. Ich hatte das aber viel früher genau so schon in 
meinem eigenen USB-Code gemacht.

Jürgen S. schrieb:
> Beim Verlassen von UsbSetup() prüfe ich mit UsbActive() noch ein paar
> ms, ob das Kabel drinsteckt bzw. USB bereit ist

Das stammt auch von mir...

Bernd N. schrieb:
> Warum führt das eigentlich hier immer zu Streit ?

Weil gewisse Leute hier gerne stänkern:

W.S. schrieb:
> Das ist Programmieren mit dem Schmiedehammer.

temp schrieb:
> Sorry aber das tut schon weh. Wo ist denn das ein Problem?

temp schrieb:
> Ich glaube fast du bist auch so ein typischer Programmierer für den alle
> Räder eckig sind die sie nicht selbst erfunden haben.

temp schrieb:
> Das wird langsam lächerlich mit dir.

von Jürgen S. (avus)


Lesenswert?

Niklas G. schrieb:
> Das stammt auch von mir...
Wie auch der gute USB-Artikel, bei dem man aber wirklich tief einsteigen 
muß, um es zu verstehen. Ich hab's versucht und dann beschlossen, daß 
ich USB nicht wirklich verstehen muß - es soll nur funktionieren :).
Ich nehme an, daß in den Dateien auf stefanus Seite 
(STM32F103_usb_test.zip) auch Deine Verbesserungen eingeflossen sind. 
Danke Dir deshalb nochmal extra, und W.S. natürlich ebenfalls.

von Stefan ⛄ F. (stefanus)


Lesenswert?

Jürgen S. schrieb:
> Ich nehme an, daß in den Dateien auf stefanus Seite
> (STM32F103_usb_test.zip) auch Deine Verbesserungen eingeflossen sind.

Ja sind sie. Und zum Teil wieder heraus geflossen. Die unnötigen 
Interrupt-sperren habe ich gerade wieder entfernt und der oben genannte 
Tippfehler ist jetzt auch korrigiert.

http://stefanfrings.de/stm32/index.html

: Bearbeitet durch User
von arduinohasse (Gast)


Lesenswert?

Ok, wenn wir schon mal dabei sind möchte ich den Klappstuhl begraben und 
auf etwas anderes hinweisen.

In der InitEndpoints() wird am Ende das FLAG für den 1ms Frameinterrupt 
SOFM mit gesetzt:
1
  USB_CNTR =
2
        CTRM |             /* Int bei ACKed Paketen in oder out */
3
        RESETM |            /* Int bei Reset */
4
    SUSPM | WKUPM | ESOFM | SOFM; /* Int bei 1 ms Frame */

Im Interrupthandler selbst wird aber so gut wie nichts gemacht:
1
  if (I & SOF) /* Start of Frame, alle 1 ms */
2
    {
3
    //trace("SOF\n");
4
    USB_ISTR = ~SOF; /* Int löschen */
5
    suspended = false;
6
    //  OnEpBulkIn();  /* immer mal nachschauen... */
7
    }

Das Rücksetzten des Flags "suspended" an dieser Stelle ist in meinen 
Augen nicht nötig.
Auf alle Fälle scheit mir der 1ms Interrupt nicht nötig zu sein. Bei mir 
geht das auch ohne und deshalb habe ich das SOFM flag auch nicht 
gesetzt.

Eventuell ist das ja auch die Ursache für Probleme die manche haben. Ich 
weiss ja nicht, was passiert wenn anderweitige höher priorisierte 
Interrups so blöd programmiert sind dass sie viel länger dauern.

von temp (Gast)


Lesenswert?

sorry, hatte noch was falsches im Namen stehen. Der letzte Beitrag kam 
von
"temp"

von Stefan ⛄ F. (stefanus)


Lesenswert?

Der Code ist vielfach erprobt und auch beim TO funktioniert er auf 
einigen Modulen. Das stinkt gewaltig nach einem Hardwarefehler oder 
schlechter Taktversorgung.

Man könnte zur gegenprobe einfach mal mein simples Beispielprogramm 
laufen lassen, wo der µC jede Sekunde "Hallo" an den PC sendet. Wenn das 
klappt, dann probiert man die umgekehrte Richtung.

Wenn eins davon scheitert, liegt mit Sicherheit ein Hardwarefehler vor. 
Ich schätze zu 80%, dass es ein Hardwarefehler ist und <5%, dass es ein 
Fehler in usb.c ist.

: Bearbeitet durch User
von temp (Gast)


Lesenswert?

Stefan ⛄ F. schrieb:
> Ich denke, ihr könnt aufhören, über mutmaßliche Softwarefehler in den
> beiden USB Dateien zu spekulieren. Lasst ihn zuerst mal die Hardware und
> die Taktversorgung untersuchen.

gleiche Meinung und auch schon ein paar mal kommuniziert.

Wäre trotzdem schön wenn jemand die Sache mit dem 1ms Interrupt mal 
gegenchecken kann.
Sowas muss man ja nicht unbedingt sein wenn es nicht benötigt wird. Und 
schon gar nicht mit so einer Wiederholrate.

von W.S. (Gast)


Lesenswert?

temp schrieb:
> Schön dass alle Krieger versammelt sind...

Ach nö, als Krieger empfinde ich mich nicht.

Aber mal ne Überlegung zum COM-Port als solchem, egal ob nun virtuell 
oder sonstwie:
1. Wenn nix hereinkommt, dann kommt eben nix herein und sowas wie 
CharAvail() kann nichts anderes melden als "false". Und das sowohl dann, 
wenn das Kabel ab ist als auch wenn der Sender nix sendet.
2. Wenn der Empfänger nicht eingeschaltet ist oder das Kabel ab ist oder 
sonstwo die Übertragung unterbrochen ist, dann sendet der COM-Port die 
Daten ins Nirwana. Er merkt das nicht einmal!

So - und nun sollten wir mal dran denken, ob und wie so ein virtueller 
COM-Port sich denn benehmen sollte. Ich hab damals danach getrachtet, 
daß der USB-Comport sich möglichst genau wie ein gewöhnlicher Comport 
benehmen soll, aber ich hatte mich nicht getraut, die Sendedaten einfach 
so ins Nirvana zu schicken, wenn sie partout nicht vom Host abgeholt 
werden.

Stattdessen hatte ich - obwohl das für einen richtigen Comport eher 
unüblich ist - sowas wie UsbTxReady() und UsbTxEmpty() eingebaut, damit 
sich ggf. das übergeordnete Programm erstmal davon überzeugen kann, ob 
es die Daten, die es senden will, auch loswerden kann. Und wenn nicht, 
dann kann es der Treiber auch nicht richten, dann muß eine andere Stelle 
in der Firmware entscheiden, was zu tun ist.

Vielleicht - als Anregung - könnte man das Verhalten eines echten 
Comports hier nachempfinden: wenn kein Usb-Timertick kommt oder wenn 
nach etwa 10 ms noch immer nix abgeholt worden ist, dann sollte man den 
EpBulkIn eben stallen und alle bis dato aufgelaufenen Bytes ins Nirvana 
befördern. Das würde so etwa dem Verhalten eines echten Comports 
entsprechen. Ob sich sowas gut macht, wäre auszuprobieren, ich wage da 
keine Vorhersage.

Niklas G. schrieb:
> Bei Sachen wie:/* liefert true, wenn Tx-Buffer leer ist */
> bool UsbTxEmpty(void)
> {
>   DisableUsbIRQ ();
>     bool res = (txw == txr);
>     EnableUsbIRQ ();
>     return res;
> }
> kann es sogar sein dass die Interruptsperre unnötig ist; ich war ehrlich
> gesagt zu faul mir das ganz genau für alle Fälle zu überlegen.

Letzteres hätte ich aber als selbstverständlich erachtet.
Zur Sache: Die Seite, die den Ringpuffer befüllt, besitzt den 
Füll-Index. Die seite, die den Ringpuffer entleert, besitzt den 
Entleer-Index.
Was passiert nun, wenn du in obigem Code feststellst, daß der Puffer 
nicht leer ist und der Interrupt direkt nach dem EnableUsbIRQ() den 
Puffer leert? Dann kehrt die Funktion eben mit "ist nicht leer" zurück, 
obwohl der Puffer bereits leer ist. Kurzum: das Disable/Enable nützt 
überhaupt nichts.
Bei allen anderen Tests verhält es sich genaus so: Wenn man testet, ob 
denn noch Platz für ein Byte frei ist, dann ist es unerheblich, ob ein 
mittendrin hereinrauschender Interrupt noch weitere 64 Plätze frei 
gemacht hat. Und wenn man im Inputpuffer nachfragt, ob ein Byte drin 
ist, dann ist es unerheblich, ob ein Interrupt mittendrein noch weitere 
64 Bytes dazupackt.

Nochwas zu dem elenden Streit wegen der "Nops" und der Trampelschleife: 
Das ist GCC-spezifisch (der Keil macht es richtig) und es ist eigentlich 
herzlich nebensächlich. Eigentlich geht es ja nur darum, ein paar 
Mikrosekunden zu schinden, bis daß der Host das ACK-Paket abgeholt hat, 
damit man sofort danach auf die zugeteilte Adresse umschalten kann. Ich 
wollte damals nicht eine bedingte Warteschleife schreiben, a la
 while (Paket noch nicht abgeholt) do warten;
um schlichtweg jegliches Blockieren zu vermeiden. Das ist alles. 
Natürlich kann man - aus heutiger Sicht - auch den Zustand des 
ACK-Paketes abfragen, sagen wir mal 10 mal oder 20 mal und sobald es 
abgeholt ist die Schleife vorzeitig verlassen. Das wäre wohl die 
sauberste Lösung.


temp schrieb:
> Wo soll den der USB Interrupt her wissen wann es etwas zum senden gibt?
> Und wenn ich was senden will ist es mir in der Regel nicht egal ob der
> USB-Teil das annimmt oder nicht?

Ähem.. das ist ein tieferes Problem. Es gibt immer einen 
Sammel-Interrupt und in einem Statusregister steht, welcher Teil der 
Hardware einen Service benötigt. Aber ein Service-Bit für den EpBulkIn 
gibt es nur dann, wenn der Host einen zuvor hereingereichten Datenblock 
gelesen hat. Der ganze "Interrupt" kann NICHT und NIEMALS wissen, ob 
irgendwo Daten zum senden an den Host bereitstehen. Das ist die Krux. 
Verstehe mal, daß das Int-Bit für den zuständigen Endpoint nur dafür da 
ist, daß dieser weiß, daß sein letztes Paket angekommen ist.

Das sagt NICHTS aus darüber, ob es in dem µC noch weitere Daten zum 
senden gibt. Ich hatte damals den Timer-Service Interrupt des USB dazu 
benutzt, um nachzuschauen, ob es Sendedaten gibt und ggf. deren 
Absendung zu veranlassen - vorausgesetzt, es ist nicht grad schon eine 
Übertragung angesagt. Aber diesen Mechanismus zum eigenständigen 
Wieder-in-Gang-kriegen der Transmission µC-->PC scheint man hier nicht 
verstanden zu haben. Dabei ist das essenziell! Entweder der 
USB-Interrupt regelt das selber (er wird sich garantiert NICHT selbst 
unterbrechen) - oder man muß es eben aus der mainloop heraus anstoßen.
Letzteres ist deutlich gefährlicher, weil man genau dabei damit rechnen 
muß, daß man durch einen Interrupt unterbrochen wird ODER eine grad 
laufende Hardwarefunktion unterbricht oder diese beeinflußt und dabei 
eine Fehlfunktion bei irgendwas wie z.B. Toggelbit oder bereits 
gefüllten Puffer nochma befüllen oder falsche Länge etc. auslöst. Immer 
dran denken, daß die SIE ein durchaus komplexer eigener Prozessor ist.
So etwas muß man vorher bedenken.

W.S.

von temp (Gast)


Lesenswert?

W.S. schrieb:
> Nochwas zu dem elenden Streit wegen der "Nops" und der Trampelschleife

Der Hauptgrund war ja noch nicht mal das Wegoptimieren der Nops sondern, 
dass sie im Interrupthandler überhaupt nötig waren. Das wurde damals in 
diesem Thread behandelt und gelöst und ist im aktuellen Stand auch so:

Beitrag "Re: STM32F303 CAN und USB gleichzeitig"

Trotzdem auch an dich die Frage: Wie siehts du die Notwendigkeit des 1ms 
Interrupts von dem ich ein paar Beiträge vorher gesprochen habe?

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

Stefan ⛄ F. schrieb:
> Ja sind sie. Und zum Teil wieder heraus geflossen. Die unnötigen
> Interrupt-sperren habe ich gerade wieder entfern

Die von mir ausgebauten Funktionen UsbCharOut, UsbTxFlush, UsbTxReady, 
UsbActive, UsbGetChar brauchen die Interrupt-Sperre definitiv. Die da 
auszubauen ist... nicht so clever.

arduinohasse schrieb:
> Auf alle Fälle scheit mir der 1ms Interrupt nicht nötig zu sein.

Der war bei W.S.' Code nur "nötig" weil er den SOF-Interrupt zum 
Absenden missbraucht hat. Kann man aber nach meinen bzw. temp's 
Korrekturen deaktivieren.

W.S. schrieb:
> Eigentlich geht es ja nur darum, ein paar
> Mikrosekunden zu schinden, bis daß der Host das ACK-Paket abgeholt hat,
> damit man sofort danach auf die zugeteilte Adresse umschalten kan

Das ist halt schon völlig verkehrt. Man setzt die Adresse einfach 
nachdem das ACK gesendet wurde. Dann funktioniert alles perfekt und man 
braucht das dumme NOP gar nicht erst. Auch wenn das mit dem GCC 
natürlich auch ginge. Das haben "temp" und ich unabhängig voneinander 
hinbekommen und es funktioniert sauber, ist also definitiv die bessere 
Lösung als so ein Delay.

W.S. schrieb:
> Was passiert nun, wenn du in obigem Code feststellst, daß der Puffer
> nicht leer ist und der Interrupt direkt nach dem EnableUsbIRQ() den
> Puffer leert? Dann kehrt die Funktion eben mit "ist nicht leer" zurück,
> obwohl der Puffer bereits leer ist. Kurzum: das Disable/Enable nützt
> überhaupt nichts.

Das war klar. Aber was passiert wenn der Interrupt genau in die Mitte 
der Funktion zuschlägt? Bei deinen Original-Funktionen ist die Sperre 
wohl tatsächlich nicht nötig. Wie gesagt, ich hatte keine Lust das 
auszutüfteln. Meine erweiterten Funktionen brauchen die Sperre, weil auf 
mehrere Variablen zugegriffen wird.

W.S. schrieb:
> Aber diesen Mechanismus zum eigenständigen
> Wieder-in-Gang-kriegen der Transmission µC-->PC scheint man hier nicht
> verstanden zu haben.

Das ist eine Zweckentfremdung des SOF-Pakets. Du hast es nicht 
verstanden.

W.S. schrieb:
> Letzteres ist deutlich gefährlicher,

Funktioniert bei mir aber perfekt, ohne die bis 1ms Verzögerung. Die 
Interruptsperre entfällt wie gesagt sowieso, wenn man die gesamte 
Architektur sauber asynchron in Interrupts packt. Mein eigener Code 
kommt ohne aus.

von Stefan ⛄ F. (stefanus)


Lesenswert?

Niklas G. schrieb:
> Die von mir ausgebauten Funktionen UsbCharOut, UsbTxFlush, UsbTxReady,
> UsbActive, UsbGetChar brauchen die Interrupt-Sperre definitiv. Die da
> auszubauen ist... nicht so clever.

Ich nehme mir die Freiheit, das anders zu sehen.

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

Stefan ⛄ F. schrieb:
> Ich nehme mir die Freiheit, das anders zu sehen.

Aus echtem Interesse - wie gehst du so etwas an? Gehst du jede einzelne 
Zeile der genannten Funktionen durch, überlegst wie der Compiler sie 
umordnen könnte, überlegst ganz genau was passiert wenn welcher 
Interrupt genau wo dazwischen kommt und dann was macht? Eine Zeile 
welche 3 Variablen ausliest hat ja schon 6 Möglichkeiten, wie der 
Compiler sie umsetzt. Stellst du einen Entscheidungsbaum auf, was bei 
welcher Umsetzung passiert? Wie lange hast du für die Analyse dieses 
Programms gebraucht? Was passiert z.B. wenn UsbGetChar ClearBuffer 
aufruft, und genau zwischen Lesen & Schreiben des EPnR ein Interrupt 
kommt?

Niklas G. schrieb:
> Kann man aber nach meinen bzw. temp's
> Korrekturen deaktivieren.

... ist doch Quatsch, denn:

arduinohasse schrieb:
> Das Rücksetzten des Flags "suspended" an dieser Stelle ist in meinen
> Augen nicht nötig.

Wo soll man es denn sonst zurücksetzen? Wenn der Host das Gerät aktiv 
halten bzw. reaktivieren will, aber keine Daten sendet/empfängt, kommt 
sonst kein anderer Interrupt.

von Stefan ⛄ F. (stefanus)


Lesenswert?

Niklas G. schrieb:
> Aus echtem Interesse - wie gehst du so etwas an? Gehst du jede einzelne
> Zeile der genannten Funktionen durch, überlegst wie der Compiler sie
> umordnen könnte, überlegst ganz genau was passiert wenn welcher
> Interrupt genau wo dazwischen kommt und dann was macht?

So ungefähr.

> Eine Zeile welche 3 Variablen ausliest hat ja schon
> 6 Möglichkeiten, wie der Compiler sie umsetzt.

Erstens sind es nur 2 Variablen und eine Konstante und zweitens spielt 
es für die Entscheidung keine Rolle, ob der Interrupt dazwischen funkt.

W.S. hat bereits in diesem und in früheren Threads mehrfach versucht, 
dir zu erklären, warum es da keine Probleme gibt. Ich stimme ihm voll 
zu. Wenn du das nicht verstehst, dann lass es halt. Die Welt geht nicht 
davon unter, weder durch deine noch anderer Leute Irrtümer.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Stefan ⛄ F. schrieb:
> W.S. hat bereits in diesem und in früheren Threads mehrfach versucht,
> dir zu erklären, warum es da keine Probleme gibt.

W.S. hat erklärt, warum es in seinem Code keine Probleme gibt. Niklas' 
Code sieht an den genannten Stellen anders aus. Wenn mehrere Variablen 
hintereinander atomar geändert werden müssen, ist eine Sperre 
unausweichlich.

: Bearbeitet durch Moderator
von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

Frank M. schrieb:
> W.S. hat erklärt, warum es in seinem Code keine Probleme gibt. Niklas'
> Code sieht an den genannten Stellen anders aus. Wenn mehrere Variablen
> hintereinander atomar geändert werden müssen, ist eine Sperre
> unausweichlich.

Danke, der Erste der es versteht. In UsbTxReady sind es sogar 4 
Variablen, d.h. 24 Möglichkeiten es zu kompilieren.

von Stefan ⛄ F. (stefanus)


Lesenswert?

Frank M. schrieb:
> W.S. hat erklärt, warum es in seinem Code keine Probleme gibt. Niklas'
> Code sieht an den genannten Stellen anders aus. Wenn mehrere Variablen
> hintereinander atomar geändert werden müssen, ist eine Sperre
> unausweichlich.

Ja das sehe ich ein. Bei seinen hinzugefügten Code.

Aber bei den Teilen, die von W.S. kommen werden keine Interruptsperren 
gebraucht.

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

Stefan ⛄ F. schrieb:
> Aber bei den Teilen, die von W.S. kommen werden keine Interruptsperren
> gebraucht.

Das habe ich vorhin auch schon geschrieben.

Niklas G. schrieb:
> kann es sogar sein dass die Interruptsperre unnötig ist; ich war ehrlich
> gesagt zu faul mir das ganz genau für alle Fälle zu überlegen.

Du hast die Sperren aber auch in meinen erweiterten Funktionen entfernt.

von Stefan ⛄ F. (stefanus)


Lesenswert?

Niklas G. schrieb:
> Du hast die Sperren aber auch in meinen erweiterten Funktionen entfernt.

Korrekt erkannt, ich habe es auch schon wieder bereut. Während wir hier 
diskutierten hatte ich das bereits in Arbeit. Wenn du magst kannst du 
nochmal kontrollieren, ich habe die ZIP Files gerade nochmal 
aktualisiert.

Die Interrupt-Sperren um deine Codeabschnitte sind wieder drin.

: Bearbeitet durch User
von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

Stefan ⛄ F. schrieb:
> Wenn du magst kannst du
> nochmal kontrollieren

In UsbCharOut, UsbTxReady, UsbActive, UsbGetChar fehlt es vermutlich 
weiterhin an Sperren. Habe keine Lust das wie beschrieben detailliert 
aufzudröseln ob man die irgendwo einsparen kann; ist schließlich eine 
Mikrooptimierung, wenn man wirklich Rechenleistung einsparen wollte 
sollte man nicht jedes Zeicheln einzeln verarbeiten sondern ganze 
Pakete.

von Stefan ⛄ F. (stefanus)


Lesenswert?

Niklas G. schrieb:
> In UsbCharOut, UsbTxReady, UsbActive, UsbGetChar fehlt es vermutlich
> weiterhin an Sperren.

Das musste ja kommen. Niklas, ich weiß deine Hilfe zu schätzen. Du hast 
hier von dem ganzen ganzen USB Kram von uns allen am meisten Ahnung.

Aber bitte akzeptiere, dass man sich auch mal irren kann. Ich weis auch 
nicht, wie es dir erklären soll. Letztendlich müsste ich dazu erneut die 
Erklärungen von W.S. wiederholen, die er schon mehrfach wiederholt hat. 
Das führt zu nichts.

> wenn man wirklich Rechenleistung einsparen wollte
> sollte man nicht jedes Zeicheln einzeln verarbeiten sondern ganze
> Pakete.

Irgendwas ist immer. In diesem Fall ist der Code halt doof designt (wie 
du meinst). Immerhin funktioniert er für andere gut genug. Du musst ihn 
nicht mögen, du kannst dir ja was anderes programmieren. Es bringt 
nichts, immer wieder auf diesem Punkt herum zu reiten.

Können wir jetzt bitte Ruhe geben und dem TO weiter helfen, falls er 
sich noch traut, sich wieder zu melden?

: Bearbeitet durch User
von Stefan ⛄ F. (stefanus)


Lesenswert?

An Alex,
du hast wahrscheinlich gemerkt, dass hier wieder eine hitzige Diskussion 
um alte Wunden ausgebrochen ist. Das war vielleicht mal wieder nötig, 
hat jedoch mit deinem konkreten Problem sehr wahrscheinlich nichts zu 
tun. Schau du erst einmal, ob die Hardware und Taktversorgung OK ist.

Du hast geschrieben, dass du den HSI48 Oszillator verwendest und das 
Clock Recovery System (CRS) aktiviert hast. Vielleicht ist da etwas 
schief gelaufen. Falls du von meinem Beispiel für STM32 L0 abgeguckt 
hast: Bei dem geht das vielleicht anders, als bei deinem F0.

von Alex (Gast)


Lesenswert?

Hallo Leute,

ich sehe ihr habt euch ja prächtig amüsiert!
Danke für deine Achtsamkeit Stefan, sie gereicht dir zu Ehre!

Ohne alle Beiträge voll gelesen und verstanden zu haben, ich sehe das 
Thema USB ist relativ komplex und es gibt nicht 'die eine richtige' 
Lösung. Die Diskussion find ich aber sehr wichtig, so kommt immer mal 
wieder Bewegung in die Sachen. Ich bin ein Freund hitziger Debatten und 
daher nicht abgeschreckt und ich würde jedem von euch sofort ein Bier 
ausgeben!

Ich hab gestern leider überhaupt keine Zeit gefunden um an meinem 
Problem weiter zu tüfteln. Einzig die Zeile mit dem BulkIn -> BulkOut 
hab ich eben noch ausprobiert und wie erwartet hat das aber keinen 
Effekt.


Zu möglichen Taktproblemen / Hardware-Ursache:

Einer meiner ersten Ansätze war es (nach der Suche nach Lötfehlern) den 
Takt zu prüfen.
Der STM läuft auf dem RC-Oszillator, was ja für USB eigentlich ein 
KO-Kriterium ist.
ST hat dem Chip aber dieses Clock-Recovery-System verpasst, das den 
Oszillator nachjustiert, so dass er mit den SOF-Paketen synchronisiert 
wird. Das funktioniert auch, jittert allerdings ein wenig rum. Wurde 
aber von ST genau für solche Anwendungsfälle gemacht und ich gehe davon 
aus, dass es die Anforderungen von USB erfüllt.
Initialisiert hab ich das wie in den Manuals (oder einer Appnote, 
erinnere mich nicht genau, ist zu lange her) von ST beschrieben. Der 
Jitter kommt in erster Linie daher, dass die Anpassungsschritte wohl 
etwas grob sind, und nur alle Millisekunden nachretunt wird.

Ich hab auf einem Pin mal einen Takt von ca. 600kHz erzeugt und mit dem 
Oszi 4 der Module verglichen.
Eine Auffälligkeit des 'schlechen' Moduls hab ich so nicht gefunden, 
intensivere Tests mit Counter hab ich aber nicht gemacht. Grund war 
folgende Überlegung:

Wenn es wirklich der Takt ist, müsste dann nicht die Übertragung in 
beide Richtungen Probleme bereiten? Immerhin läuft der Transfer von 
Daten zum PC auch *wochenlang !!* problemlos, und das braucht ja auch 
die ACK-Pakete in die andere Richtung.
Das die Probleme völlig reproduzierbar immer nur beim BULK-OUT auftreten 
macht die CLK-These für mich unplausibel.

Andererseits verhält sich ein Programm nun mal streng deterministisch, 
d.h. es MUSS eine Hardware-Ursache geben, sonst würde das Problem nicht 
bei einem bestimmten Modul auftreten.

Es ist wohl irgendwas ziemlich knapp an der Grenze betrieben 
(höchstwahrscheinlich ist das ein Timing), die Software müsste damit 
zurechtkommen und tut es in bestimmten Fällen (BulkOut) nicht.

Nachdem ich mich mit der USB-Programmierung einfach viel zu wenig 
auskenne, um sinnvolles Debugging betreiben zu können, ist eine genauere 
Untersuchung der CRS-Clock-Geschichte wohl der Hebel, an dem ich 
ansetzen sollte.

Ich schau mir mal an, weche Möglichkeiten ich habe um rauszufinden, was 
die tatsächlichen Unterschiede zwischen den Modulen sind, und vor allem 
wie ich das 'ordentlich' quantifizieren kann.

Updates folgen, ihr dürft derweil gerne weiterdiskutieren :-).

mit Respekt, Alex

von temp (Gast)


Lesenswert?

Niklas G. schrieb:
> In UsbCharOut, UsbTxReady, UsbActive, UsbGetChar fehlt es vermutlich
> weiterhin an Sperren. Habe keine Lust das wie beschrieben detailliert
> aufzudröseln ob man die irgendwo einsparen kann; ist schließlich eine
> Mikrooptimierung, wenn man wirklich Rechenleistung einsparen wollte
> sollte man nicht jedes Zeicheln einzeln verarbeiten sondern ganze
> Pakete.

Keine Lust ist ein blödes Argument. Betrachten wir nur mal
1
bool UsbTxReady(void)
2
{
3
  DisableUsbIRQ ();
4
  bool res = configurationSet && !suspended && ((txw + 1) & (txLen - 1)) != txr;
5
  EnableUsbIRQ ();
6
  return res;
7
}
txLen ist eine Konstante, txw kann nur im main Programm verändert werden 
und txr kann im Interrupt nur so verändert werden, dass das Ergebnis des 
Vergleiches von false auf true springt, aber nicht von true auf false. 
Damit ist das komplett threadsave und benötigt keine Sperren.
Die Funktion selbst verändert ja noch nicht mal irgendeine Variable.
configurationSet und suspended können zu jeder Zeit im Interrupt 
verändert werden. Also auch direkt nach EnableUsbIRQ(). Damit ist die 
Sperre nutzlos.
Sinn würde das z.B. nur so ergeben:
1
  ....
2
  DisableUsbIRQ ();
3
  if (UsbTxReady())
4
   {
5
   UsbSendString(...);
6
   } 
7
  EnableUsbIRQ ();
8
  ....
Man muss also eine Sequenz von Aufrufen Sperren, damit das überhaupt nur 
einen Anflug von Sinn ergibt.
Auf der anderen Seite kann der User zu beliebigen Zeiten den VPC 
schließen oder das Kabel ziehen. Da kannst man die Flags 
configurationSet und suspended auswerten wie man will, das kann immer 
und zu jeder Zeit passieren. Auch das ist nicht weiter schlimm, wenn man 
in der UsbCharOut(char c) statt der Endlosschleife eine Timeout einbaut.
Ein anderer könnte auf die Idee kommen, einfach den Watchdog zu benutzen 
um solche Fälle abzudecken. Das kommt immer auf die Anwendung an, und 
keiner hat das Recht zu schimpfen: "sowas ist verpöhnt".

Jetzt mal zur UsbCharOut()
1
/* sendet ein Zeichen (d.h. schreibt es in den Tx-Buffer) */
2
bool UsbCharOut(char c)
3
{
4
  while (true) 
5
    {
6
    DisableUsbIRQ ();
7
8
    if (!configurationSet || suspended) 
9
      {
10
      EnableUsbIRQ ();
11
      return false;
12
      }
13
14
    // diesen Teil zu Sperren ist genau wie UsbTxReady komplett überflüssig   
15
    if (((txw + 1) & (txLen - 1)) != txr) 
16
      break;
17
18
    EnableUsbIRQ ();
19
20
    // das kann man so machen oder eine einen Timeout einbauen
21
    // Egal was passiert, im Fehlerfall läuft der Ringbuffer voll und das
22
    // ist eigentlich das einzige auf was ich als User reagieren muss.
23
    __asm__ volatile ("wfi"); /* trampeln auf der Stelle!! */
24
    }
25
    
26
  // das ist wieder komplett theradsave, 
27
  // da txw ausschließlich hier verändert wird.
28
  // die Abholroutine im Irq zieht txr nach, aber Daten gehen dabei 
29
  // nie verloren. Das verändern von txr kann nur zusätzlichen Platz
30
  // im Buffer schaffen, ihn aber nicht nehmen
31
  int i = (txw + 1) & (txLen - 1);
32
  UsbTxBuf[txw] = c;
33
  txw = i;
34
35
  // das will ich nicht kommentieren, da soll jeder selbst 
36
  // entscheiden wie er was will. Auf alle Fälle gilt hier das
37
  // gleiche wie oben, eine Interruptsperre ist nicht nötig
38
39
  /* Diese Bedingung einkommentieren, um nur dann automatisch abzusenden, wenn Sendepuffer voll. In diesem Fall kann über UsbTxFlush abgeschickt werden. */
40
  //    if (((txw + 1) & (txLen - 1)) == txr) {
41
    if (!transmitting) {
42
      EpBulkBeginTransmit ();
43
    }
44
  //    }
45
  EnableUsbIRQ ();
46
  return true;
47
}

Die anderen Funktionen sind alle ähnlich.

Niklas G. schrieb:
> wenn man wirklich Rechenleistung einsparen wollte
> sollte man nicht jedes Zeicheln einzeln verarbeiten sondern ganze
> Pakete

Es geht ja nicht darum Rechenzeit einzusparen, sondern darum lieber auf 
Verdacht Interruptsperren einzubauen nur weil man zu faul ist darüeber 
nachzudenken.

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

temp schrieb:
> Es geht ja nicht darum Rechenzeit einzusparen, sondern darum lieber auf
> Verdacht Interruptsperren einzubauen nur weil man zu faul ist darüeber
> nachzudenken.

Naja, es ist legitim innerhalb eines begrenzten Kontext defensiv zu 
programmieren und einen Schutz "zur Sicherheit" einzubauen, statt viel 
Zeit darauf zu verwenden, zu überlegen, ob man ihn wirklich braucht. Vor 
allem wenn die Kosten minimal sind und man nicht für die Zeit bezahlt 
wird. Aber schön, dass erst die Beleidigungen kommen und dann die 
technische Erläuterung. Da ist man richtig motiviert darüber detailliert 
nachzudenken!

: Bearbeitet durch User
von temp (Gast)


Lesenswert?

Alex schrieb:
> Wenn es wirklich der Takt ist, müsste dann nicht die Übertragung in
> beide Richtungen Probleme bereiten? Immerhin läuft der Transfer von
> Daten zum PC auch *wochenlang !!* problemlos, und das braucht ja auch
> die ACK-Pakete in die andere Richtung.
> Das die Probleme völlig reproduzierbar immer nur beim BULK-OUT auftreten
> macht die CLK-These für mich unplausibel.

Die Signale müssen ja auf der einen Seite vom PC und auf der anderen 
Seite vom µC gesampelt werden. Das macht die Hardware, aber es ist nicht 
die gleiche. Von daher können schon richtungsabhängige Unterschiede 
auftreten. Die Länge der Pakete dürfte dabei auch eine Rolle spielen. 
Auch wenn es dir nicht plausibel erscheint, was hast du jetzt noch für 
Möglichkeiten? Eine andere Softwareimplementierung oder eine andere 
Hardware. Kannst du nicht mal an das schlechteste Modul einen Quarz dran 
fummeln und mal testen? Oder einen externen Taktgenerator, da brauchst 
du nur einen Pin.
Die Diskussionen hier werden dich mit deinem Problem nicht weiter 
bringen.

von W.S. (Gast)


Lesenswert?

temp schrieb:
> Der Hauptgrund war ja noch nicht mal das Wegoptimieren der Nops sondern,
> dass sie im Interrupthandler überhaupt nötig waren.

Erkenne doch bitte das Ziel der Übung: zuerst das Kommando vom Host mit 
der zugewiesenen Adresse mit ACK bestätigen und dann wenn der Host das 
ACK erhalten hat, auf die zugewiesene Adresse umschalten. Und das 
möglichst umgehend, weil zumindest mir nicht klar ist, ob man damit ewig 
warten darf. Und sofort die Adresse umzuschalten hatte ich nicht 
probiert, weil ich annahm, daß der Host das ACK noch von Adresse 0 
erwartet. Ich habe dazu keine Festlegung in den mir zugänglichen 
Unterlagen gefunden. Und nein, ich habe keine kostenpflichtigen 
Dokumente eingekauft, sondern mußte mich auf das beschränken, was man im 
Inet eben so findet.

> Trotzdem auch an dich die Frage: Wie siehts du die Notwendigkeit des 1ms
> Interrupts von dem ich ein paar Beiträge vorher gesprochen habe?

Dieser Interrupt kommt immer und muß behandelt werden, sonst denkt der 
Host, daß man gestorben ist - und dann klemmt er einen einfach ab.

Und da man diesen Interrupt eben immer behandeln muß und man ja dabei 
bereits im Interupt-Modus ist, ist es auch keine schlechte Idee, mal 
nachzuschauen, ob der EpBulkIn grad NICHT am Transferieren ist und vor 
sich hin faulenzt, während die SIE alle Anfragen des Host nach Daten mit 
NAK abweist und im Ringpuffer des Treibers Daten vor sich hin schmoren.

W.S.

von W.S. (Gast)


Lesenswert?

Frank M. schrieb:
> W.S. hat erklärt, warum es in seinem Code keine Probleme gibt. Niklas'
> Code sieht an den genannten Stellen anders aus. Wenn mehrere Variablen
> hintereinander atomar geändert werden müssen, ist eine Sperre
> unausweichlich.

Frank, das sihst du falsch. Sperren sind nur dort nötig, wo zwei 
unabhängige Instanzen DIESELBE Variable zu ändern versuchen.

Das Lesen derselben Variablen ist hingegen für alle Instanzen erlaubt.

Und wenn man sauber programmieren will, dann macht man das so, daß nur 
die Instanz eine Variable verändert, die in ihrem Besitz ist. Und wer 
welche Variable besitzt und das Recht auf Ändern hat, muß man als 
Programmierer sorgfältig planen UND DANN AUCH EINHALTEN.

W.S.

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

W.S. schrieb:
> Und sofort die Adresse umzuschalten hatte ich nicht
> probiert, weil ich annahm, daß der Host das ACK noch von Adresse 0
> erwartet.

Richtig. Daher schaltet man die Adresse einfach im Interrupt um, wenn 
das ACK gesendet wurde. Ein fixes Delay mit NOP ist sehr fehleranfällig, 
weil die Zeit nicht vorhersehbar ist.

W.S. schrieb:
> Dieser Interrupt kommt immer und muß behandelt werden, sonst denkt der
> Host, daß man gestorben ist - und dann klemmt er einen einfach ab.

Das stimmt nicht. Den SOF-Interrupt kann man abschalten, die Hardware 
behandelt das Paket automatisch. Der USB-Peripherie ist es egal, ob die 
Software den Interrupt abfragt oder nicht. Schließlich setzt die 
Software ja auch keine Register im SOF-Handler. Auch ohne Interrupt 
bleibt das Gerät "online". Ich verwende den Interrupt lediglich um 
resume zu erkennen. Man könnte den SOF-Interrupt abschalten wenn er das 
erste Mal auftrat, und reaktivieren wenn man im suspend gelandet ist.

W.S. schrieb:
> Das Lesen derselben Variablen ist hingegen für alle Instanzen erlaubt.

"Erlaubt" ist beides. Das Lesen mehrerer Variablen kann aber 
inkonsistente Zustände zurückliefern, wenn zwischendurch die Variablen 
geändert werden. Es ist nur in diesem konkreten Fall eben so, dass die 
Interrupts die Variablen nicht zwischendurch in inkonsistente Zustände 
bringen (vermutlich). Man könnte sogar gemeinsam genutzte Variablen ohne 
Interrupt-Sperre beschreiben indem man STREX / LDREX benutzt, aber der 
Aufwand lohnt sich hier kaum.

: Bearbeitet durch User
von W.S. (Gast)


Lesenswert?

temp schrieb:
> txLen ist eine Konstante, txw kann nur im main Programm verändert werden
> und txr kann im Interrupt nur so verändert werden

temp schrieb:
> Die Diskussionen hier werden dich mit deinem Problem nicht weiter
> bringen.

Ja, das sehe ich genau so.

Ich sehe aber auch Probleme der allgemeineren Art:

1. Zur Hardware: ich habe schon eine Menge an USB-Kabeln gesehen, die 
zwar sehr schön als ordentlich abgeschirmt und auch sonst hochqualitativ 
angepriesen wurden, aber bei genauerem Hinsehen sich als miese 
Billigware erwiesen haben: keine Abschirmung, sondern nur ne blanke 
Litze beigelegt anstelle Schirm. Insbesondere sind das solche dünnen 
Typen vom Typ A nach Mini-USB und Mikro-USB. Diese Kabel machen Probleme 
ohne Ende. Manchmal geht's, manchmal nicht. Häufig bleibt bei sowas das 
Enumerieren mittendrin stecken.

2. Software, speziell gültige Dokumentationen: schwer oder nur gegen 
Geld zu kriegen. Wer da als privater Programmierer nicht im Konsortium 
ist, muß zusehen, wo und was er an Unterlagen kriegt. Und da tun sich 
Lücken auf, weil man eben hie und da nichts hat, um nachlesen zu können, 
was da korrekt ist und was nicht.

3. Rechtliches: Als Privater kann man keine pid und vid kriegen, denn 
das kostet was. Ergo kann man nur mit geklauten ID's arbeiten. Ist 
ziemlich unschön, aber nicht zu ändern.

Dem TO würde ich nach all der Diskussion hier empfehlen, sich über einen 
UART seines Chips einen zweiten Kanal zur Kontrolle mal einzurichten. 
Eben um zu kontrollieren, ob und was denn nun in seinem µC am Ende so 
herein kommt. Und das unter Ausprobieren verschiedener Kabel.

W.S.

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

Niklas G. schrieb:
> Man könnte den SOF-Interrupt abschalten wenn er das
> erste Mal auftrat, und reaktivieren wenn man im suspend gelandet ist.

Das ist eigentlich eine super Idee... Ich habe das mal testweise im 
Branch disable-sof-irq umgesetzt. Dadurch spart man sich eine Menge 
Interrupts und möglicherweise Energie. Das geht mit dem Ansatz, im 
SOF-Interrupt das Senden abzuhandeln, nicht. Möchte jemand den Branch 
mal ausprobieren?

Um das eigentliche Problem hier anzugehen, würde ich mal einen 
Breakpoint in ClearBuffer und in den Interrupt an die Zeile mit 
'trace("out\n");' setzen, Daten vom PC senden und in den Breakpoints die 
USB-Register ansehen.

: Bearbeitet durch User
von Stefan ⛄ F. (stefanus)


Lesenswert?

Ein kleiner Hinweis zum Tracen.

In "meiner" usb.c befindet sich ziemlich weit oben ein 
Konfigurations-parameter mit dem man das Tracing aktiviert. Darunter 
habe ich als Kommentar den Output von einer erfolgreichen Enumerierung 
eingefügt.

Leider hat der F0 keinen TraceSWO Ausgang, also muss man die trace() 
Funktion so umschreiben, dass sie auf eine andere Schnittstelle 
schreibt. UART wurde ja schon empfohlen.

Ich hatte mir die Mühe damals nicht gemacht, weil der Code auf meinem 
STM32L0 direkt auf Anhieb lief. Aber beim STM32F303RE war das für mich 
hilfreich - und vor allem die Erklärungen der zahlreichen Helfer, 
insbesondere W.S. und Niklas.

: Bearbeitet durch User
von Thomas Z. (usbman)


Lesenswert?

Niklas G. schrieb:
>> Man könnte den SOF-Interrupt abschalten wenn er das
>> erste Mal auftrat, und reaktivieren wenn man im suspend gelandet ist.
>
> Das ist eigentlich eine super Idee...

der SOF kommt eigendlich immer am Ende eines ms Frame. Der Host wird das 
Device auch nie in den Suspend schicken, solange das nicht im Deskriptor 
explizit eingeschaltet ist. Die Spec schreibt allerdings vor, dass ein 
Device beim ausbleiben des SOF innerhalb von 5ms?? In den powerdown 
gehen muss. Das ist sehr oft nicht richtig implementiert.
Allerdings kommen während der Enumerierung sehr oft Suspend Events 
genauso wie reset Events vor.

Suspend ist kein Paket sondern ein spezieller Zustand auf D+ und D- der 
dann als Suspend interpretiert wird

Da der SOF auch die PLL zum nachsteuern des USB Clocks beim TO steuert, 
bin ich mir nicht so sicher ob es eine gute Idee ist da rumzuspielen.

: Bearbeitet durch User
von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

Thomas Z. schrieb:
> Die Spec schreibt allerdings vor, dass ein
> Device beim ausbleiben des SOF innerhalb von 5ms?? In den powerdown
> gehen muss. Das ist sehr oft nicht richtig implementiert.

Das sollte durch den Suspend Interrupt abgehandelt werden. Habe es aber 
nicht ausführlich getestet.

Thomas Z. schrieb:
> Allerdings kommen während der Enumerierung sehr oft Suspend Events
> genauso wie reset Events vor.

Sollte nicht schlimm sein, weil während der Enumerierung ja auch noch 
keine Configuration gesetzt ist und der VCP daher durchgängig "tot" ist.

Thomas Z. schrieb:
> Da der SOF auch die PLL zum nachsteuern des USB Clocks beim TO steuert,
> bin ich mir nicht so sicher ob es eine gute Idee ist da rumzuspielen.

Es wird ja lediglich der Software-Interrupt abgeschaltet. Der USB-Kern 
sollte das SOF ganz normal verarbeiten. Die Hardware sollte überhaupt 
nichts davon mitbekommen ob man auf den Interrupt reagiert oder nicht.

von Bernd N. (_bn_)


Lesenswert?

>> Möchte jemand den Branch mal ausprobieren?
gerne doch.

von Thomas Z. (usbman)


Lesenswert?

Niklas G. schrieb:
> Das sollte durch den Suspend Interrupt abgehandelt werden. Habe es aber
> nicht ausführlich getestet.

Das ist was anderes. Eigentlich muss ein Device fehlende  SOFs 
detektieren und dann selbstständig in den Powerdown gehen. Das ist 
übrigens ganz unabhängig davon ob das Device schon konfiguriert ist. 
(selfsuspend).
An genau dieser Stelle verhalten sich auch kommerzielle Geräte oft nicht 
Spec Konform.
Sowas würde übrigens bei den Plug Fests zumindest früher überprüft.

von temp (Gast)


Lesenswert?

Ich habe hier ein nucleo32 stm32f042 gefunden, mit dem habe ich mal 
experimentiert. Sowohl mit HSI als auch mit ext. Clock. Es geht beides. 
Beim HSI ergab ein 1ms Systick eine gemessene Frequenz von 9956 Hz. Nur 
so zur Info. Ich habe nicht versucht die Clockrestauration zu machen.
Deshalb schließe ich die Clockvariante als Fehler mittlerweile aus.

Allerdings bin ich bei den Versuchen über etwas gestolpert, was mit dem 
Problem von Axel zu tun haben könnte.
Ich hatte den rx-Ringbuffer auf 64byte eingestellt, und prompt kam genau 
1 beliebiges Commando vom hterm an, danach war Ende im Gelände beim 
Empfang.

Die Ursache ist einfach:
1
void OnEpBulkOut(void) /* EP2 = Bulk-EP OUT */
2
{
3
  int i, n, hdroom, avail;
4
  UMEM_FAKEWIDTH D;
5
  char c;
6
  UMEM_FAKEWIDTH* P;
7
8
  /* Bulk EP anwählen und Anzahl der Bytes ermittlen */
9
  avail = EpTable[2].RxCount & 0x3FF;
10
11
  i = rxw - rxr;
12
  if (i < 0)
13
    i += rxLen;
14
  hdroom = rxLen - i;
15
  if (hdroom <= avail) {
16
    receiving = false;
17
    return;
18
    }
19
20
  P = (UMEM_FAKEWIDTH*) EP2RxBBuffer;
21
  n = 2;
22
  i = avail;
23
  D = *P++; /* 2 Byte laden */
24
  while (i > 0)
25
    {
26
    c = D & 0xFF; /* LSB zuerst   */
27
    UsbRxBuf[rxw] = c;
28
    rxw = (rxw + 1) & (rxLen - 1);
29
    D = D >> 8;
30
    --n;
31
    if (!n)
32
      {
33
      D = *P++;
34
      n = 2;
35
      }
36
    --i;
37
    }
38
39
  if (hdroom - avail >= EpBulkMaxLen)
40
    ClearBuffer(logEpBulkOut); /* wir haben's gelesen */
41
  else
42
    receiving = false;
43
}

Hier gibt es 2 Stellen, wo aus dem Interrupt gesprungen wird ohne das 
ClearBuffer(logEpBulkOut); zu rufen. Wenn das ausbleibt, steht die 
Kiste. Wiederholt wird der Interrupt nicht. Bei meinem 64byte Ringbuffer 
schlägt dieser Vergleich aber immer fehl. Irgendwo im UsbGetChar steht 
dieses  ClearBuffer(logEpBulkOut); nochmal um den Knoten zu lösen. Das 
halte ich an dieser Stelle aber für nicht klug. Die UsbGetChar() sollte 
nur Daten aus dem Ringbuffer lesen, und nicht noch solche Hampeleien 
machen.

Ich bin aber noch nicht am Ende mit Nachdenken. Ich glaube ich baue das 
für mich so um, dass die Daten lieber verworfen werden und ein Errorflag 
gesetzt wird. Dann kann in diesem Interruptteilstück immer! das 
ClearBuffer(logEpBulkOut); gerufen werden. Das passt dann auch wieder 
zum UART. Da gehen die Daten auch verloren, wenn sie keiner abholt und 
die Buffer überlaufen.

von temp (Gast)


Lesenswert?

Hallo Axel versuch mal diese beiden Funktionen in deinem Code 
auszutauschen:
1
volatile uint32_t rxOverRun;
2
void OnEpBulkOut(void) /* EP2 = Bulk-EP OUT */
3
{
4
  EpCnt++;
5
  int i, n, hdroom, avail;
6
  UMEM_FAKEWIDTH D;
7
  char c;
8
  UMEM_FAKEWIDTH* P;
9
10
  /* Bulk EP anwählen und Anzahl der Bytes ermittlen */
11
  avail = EpTable[2].RxCount & 0x3FF;
12
13
  P = (UMEM_FAKEWIDTH*) EP2RxBBuffer;
14
  n = 2;
15
  i = avail;
16
  D = *P++; /* 2 Byte laden */
17
  while (i > 0)
18
    {
19
    c = D & 0xFF; /* LSB zuerst   */
20
    if (((rxw + 1) & (rxLen - 1)) == rxr)
21
      {
22
      rxOverRun++; 
23
      }
24
    else
25
      { 
26
      UsbRxBuf[rxw] = c;
27
      rxw = (rxw + 1) & (rxLen - 1);
28
      }
29
    
30
    D = D >> 8;
31
    --n;
32
    if (!n)
33
      {
34
      D = *P++;
35
      n = 2;
36
      }
37
    --i;
38
    }
39
  ClearBuffer(logEpBulkOut); /* wir haben's gelesen */
40
}

und
1
char UsbGetChar(void)
2
{
3
  char c=0;
4
  if (rxr != rxw)
5
    {
6
    c = UsbRxBuf[rxr];
7
    rxr = (rxr + 1) & (rxLen - 1);
8
    }
9
  return c;
10
}

Sollten damit deine Probleme nicht mehr auftreten, dann weißt du 
wenigstens aus welcher Ecke sie kommen.

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

temp schrieb:
> Bei meinem 64byte Ringbuffer
> schlägt dieser Vergleich aber immer fehl.

Hehe, W.S.' Ringpuffer-Implementation mit 2 Zeigern kann nur N-1 
Elemente speichern, wenn N die Größe ist. Dann klappt das nie. Wenn die 
Paketgröße 64 ist, muss der Puffer also 65 groß sein, oder man fügt noch 
einen Füllstand-Merker hinzu.

temp schrieb:
> Das
> halte ich an dieser Stelle aber für nicht klug.

Ich schon.

temp schrieb:
> Die UsbGetChar() sollte
> nur Daten aus dem Ringbuffer lesen, und nicht noch solche Hampeleien
> machen.

Ich finde es sinnvoll, den OUT-EP genau dann zu aktivieren, wenn man 
bereit ist Daten zu empfangen. Und das ist dann der Fall, wenn man mit 
UsbGetChar() den Puffer entsprechend geleert hat.

W.S. Original-Implementation macht es so wie du vorschlägst.

temp schrieb:
> Das passt dann auch wieder
> zum UART. Da gehen die Daten auch verloren, wenn sie keiner abholt und
> die Buffer überlaufen.

Finde ich nicht gut. Beim UART ist das auch nur so, wenn man keine 
Flusskontrolle nutzt. Der VCP ist praktisch UART mit Flusskontrolle. 
Wenn man die Daten nicht abholt, sollte man vom PC auch keine schicken 
können.

von Stefan ⛄ F. (stefanus)


Lesenswert?

Niklas G. schrieb:
> Wenn die
> Paketgröße 64 ist, muss der Puffer also 65 groß sein, oder man fügt noch
> einen Füllstand-Merker hinzu.

Guter Punkt, das werde ich mal Quelltext entsprechend kommentieren.

von Stefan ⛄ F. (stefanus)


Lesenswert?

Mal was anderes: Ich könnte schwören, dass ich auf dem PC einfach

> cat /dev/ttyACM0

benutzen konnte, um Text-Meldungen vom µC --> PC anzuzeigen. Neuerdings 
geht das nicht mehr, weiß der Teufel warum (auch nicht als root). Aber 
mit jedem beliebigen Terminalprogramm kann ich den Port wie gewohnt 
öffnen und nutzen.

Hat da zufällig jemand einen Tipp für mich, was der Knackpunkt sein 
könnte?

: Bearbeitet durch User
von temp (Gast)


Lesenswert?

Niklas G. schrieb:
> Hehe, W.S.' Ringpuffer-Implementation mit 2 Zeigern kann nur N-1
> Elemente speichern, wenn N die Größe ist. Dann klappt das nie. Wenn die
> Paketgröße 64 ist, muss der Puffer also 65 groß sein, oder man fügt noch
> einen Füllstand-Merker hinzu.

Das ist mir selbst klar und es war ein Fehler von mir. Ich will auch 
nicht mit 64Byte Buffern arbeiten. Mir ist nur aufgefallen, dass sich 
das System dann genauso verhielt wie Alex es beschreiben hat.

Niklas G. schrieb:
> Ich finde es sinnvoll, den OUT-EP genau dann zu aktivieren, wenn man
> bereit ist Daten zu empfangen. Und das ist dann der Fall, wenn man mit
> UsbGetChar() den Puffer entsprechend geleert hat.
>
Das ist Ansichtssache

> W.S. Original-Implementation macht es so wie du vorschlägst.
Aber eben nicht ganz. Es gibt halt da die Stellen wo er einfach aus dem 
Interrupt rausspringt, und als Notanker ist die Hampelei im UsbGetChar 
verbaut. Und irgendjemand hat da drin auch noch den Aussprung 
programmiert wenn suspend gesetzt ist oder !configurationSet. Warum um 
Gottes Willen soll man in dem Zustand keine Daten mehr aus dem 
Ringbuffer holen?

Niklas G. schrieb:
> Finde ich nicht gut. Beim UART ist das auch nur so, wenn man keine
> Flusskontrolle nutzt. Der VCP ist praktisch UART mit Flusskontrolle.
> Wenn man die Daten nicht abholt, sollte man vom PC auch keine schicken
> können.

UART mit Flusskontrolle ist mir das letzte mal untergekommen als es noch 
kein Internet gab und Daten per Modem übertragen wurden.
Wenn eine 100% UART das Ziel ist hast du recht, aber heute sind 99,xx% 
der Anwendungen ohne Flußkontrolle. Und jede Wette auch Alex sein 
Projekt. Das ist ja eine Kette die sich von der Anwendung auf dem PC bis 
zum µC durchzieht. Wer von den Beteiligten benutzt denn regelmäßig 
Flußkontrolle?

von temp (Gast)


Lesenswert?

Stefan ⛄ F. schrieb:
>> Wenn die
>> Paketgröße 64 ist, muss der Puffer also 65 groß sein, oder man fügt noch
>> einen Füllstand-Merker hinzu.
>
> Guter Punkt, das werde ich mal Quelltext entsprechend kommentieren.

Mach es lieber nicht (oder richtig), denn es wird dann noch schlimmer. 
Wenn du in den Code schaust, wird häufig eine Maske gebaut aus buflen-1. 
Da kommt bei 256 eben 0xff raus. Versuch das mal mit 65...
Also immer schön bei den 2er Potenzen bleiben.

von Stefan ⛄ F. (stefanus)


Lesenswert?

temp schrieb:
> Wer von den Beteiligten benutzt denn regelmäßig Flußkontrolle?

Wir hatten die Diskussion schon weiter oben.

Diese Funktionen UsbGetChar/UsbPutChar darf sich jeder gerne so 
umschreiben, wie er sie braucht. Das ist ja durchaus überschaubar - auch 
für Leute wie mich, die von USB keine Ahnung haben.

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

temp schrieb:
> Es gibt halt da die Stellen wo er einfach aus dem
> Interrupt rausspringt, und als Notanker ist die Hampelei im UsbGetChar
> verbaut.

Das ist kein Notanker, das ist der ganz normale Ablauf.

temp schrieb:
> Und irgendjemand hat da drin auch noch den Aussprung
> programmiert wenn suspend gesetzt ist oder !configurationSet.

Ich war das. Siehe git-History.

temp schrieb:
> Warum um
> Gottes Willen soll man in dem Zustand keine Daten mehr aus dem
> Ringbuffer holen?

Weil der PC das Gerät offenbar still legen will. Das Abholen der schon 
angekommenen Daten könnte man noch erlauben, ja.

temp schrieb:
> Wer von den Beteiligten benutzt denn regelmäßig
> Flußkontrolle?

Ich habe das vor 2 Jahren noch benutzt in einem Projekt, wo per UART 
Datenpakete von einem Sensor abgeschickt werden. Sehr praktisch zur 
Vermeidung von Overflows. Das Ganze wurde in dem alten Thread übrigens 
schon durchgekaut. Das sind übrigens alles Überlegungen, die man sich 
bei der direkten Verwendung von USB ohne VCP sparen kann. Aber wir 
wollten es ja "einfach" haben!

von Stefan ⛄ F. (stefanus)


Lesenswert?

Braucht sonst noch jemand einen Eimer um sich auszukotzen?

Komisch das der TO hier von allen am wenigstens Meckert, dabei ist er 
doch derjenige, der hier gerade wirklich ein akutes Problem hat.

von Stefan ⛄ F. (stefanus)


Lesenswert?

Ich habe nochmal getestet. Sowohl in meiner aktuellen Fassung als auch 
der von Niklas sehe ich keine Fehlfunktionen, wenn man mehr Daten sendet 
oder empfängt, als in den Puffer passen.

Meine Hauptschleife:
1
    while (1)
2
    {
3
        // LED On
4
        WRITE_REG(GPIOC->BSRR,GPIO_BSRR_BR13);
5
        delay_ms(100);
6
7
        UsbStrOut("Hello World!\n");
8
9
        // Send echo of received characters back
10
        while (UsbRxAvail())
11
        {
12
            char c=UsbGetChar();
13
            UsbCharOut(c);
14
        }
15
16
        // LED Off
17
        WRITE_REG(GPIOC->BSRR,GPIO_BSRR_BS13);
18
        delay_ms(1000);
19
    }

Ich kann mit dem Terminalprogramm wenige Zeichen bis einige hundert 
Zeichen am Stück senden (der USB Treiber teilt das natürlich auf), das 
Echo kommt vollständig zurück. Und es blockiert nichts.

: Bearbeitet durch User
von Stefan ⛄ F. (stefanus)


Lesenswert?

temp schrieb:
> Mach es lieber nicht (oder richtig), denn es wird dann noch schlimmer.
> Wenn du in den Code schaust, wird häufig eine Maske gebaut aus buflen-1.
> Da kommt bei 256 eben 0xff raus. Versuch das mal mit 65...
> Also immer schön bei den 2er Potenzen bleiben.

Verstehe, danke für den Hinweis.

von temp (Gast)


Lesenswert?

Stefan ⛄ F. schrieb:
> Ich habe nochmal getestet. Sowohl in meiner aktuellen Fassung als auch
> der von Niklas sehe ich keine Fehlfunktionen, wenn man mehr Daten sendet
> oder empfängt, als in den Puffer passen.

Was du jetzt genau meinst weiss ich nicht, aber wenn du dich auf meinen 
Testvorschlag von oben beziehst hast du was falsch verstanden.
Ich unterstelle keinen eine Fehlfunktion, bei mir geht es ja auch schon 
lange.

Nur, als ich heute mit dem 64byte Buffer gespielt habe, was sowieso nie 
gehen konnte, ist mir ein ähnliches Verhalten wie bei Alex aufgefallen. 
Ich habe nur das erste Packet vom PC bekommen. Was Alex wie macht wissen 
wir alle nicht. Deshalb war mein Code-Vorschlag nur für ihn, mit dem 
Ziel ohne wenn und aber das ClearBuffer(logEpBulkOut); bei jedem Packet 
was reinkommt auszuführen. Wenn das funktioniert, braucht er nur noch 
diese beiden Funktionen bei sich zu analysieren. Wenn nicht hilft eine 
größere Glaskugel.

von Stefan ⛄ F. (stefanus)


Lesenswert?

temp schrieb:
> Ich unterstelle keinen eine Fehlfunktion,
> bei mir geht es ja auch schon lange.

Das wollte ich damit auch nicht sagen.

Ich wollte dem TO nur eine Bestätigung geben, dass die USB Software 
prinzipiell in Ordnung ist. Wenn er einen Softwarefehler hat, dann 
vermutlich in seinem eigenen Code den er drumherum gebaut hat.

: Bearbeitet durch User
von Thomas Z. (usbman)


Lesenswert?

Ich hatte ja versprochen einen Patch für DoGetStatus() einzustellen...
Der Patch ist fertig allerdings hab ich beim Testen festgestellt, das 
der Request nicht antwortet.

Ich habe festgestellt, dass GetFeature, SetFeature und GetStatus alle in 
einen Timeout reinlaufen. Da scheint noch ein prinzipielles Problem zu 
existieren.

Der VCP Comport selbst funktioniert problemlos. Es ist also eher ein 
formales Problem. Geprüft hab ich dieses mal mit den Sourcen von Stefan.
Mal schauen ob ich den Fehler finde.

von Alex (Gast)


Lesenswert?

Hallo Leute,

kurzer Zischenbericht zu meinen Versuchen:

Ich hab an das 'schlechte' Modul einen 24MHz TCXO drangebaut, mit 
PLL->48MHz.
Das Problem mit dem Senden von Kommandos bleibt aber bestehen.

Das hab ich definitiv nicht erwartet !!


@Stefan: Die Annahme, dass der Fehler in meinem Code liegt, teile ich 
:-)
Nächster Test: Neues Projekt, und mal nur den USB-Teil von euch + die 
Anpassungen an den Chip auf der 'schlechten' Hardware.

Alex

von Stefan ⛄ F. (stefanus)


Lesenswert?

Alex schrieb:
> Das hab ich definitiv nicht erwartet !!

Offenbar sind Taktprobleme damit ausgeschlossen.

Alex schrieb:
> Nächster Test: Neues Projekt, und mal nur den USB-Teil von euch + die
> Anpassungen an den Chip auf der 'schlechten' Hardware.

Klingt nach einem guten Plan

von Thomas Z. (usbman)


Lesenswert?

So die Ursache für die Timeouts habe ich gefunden..
Es ist das Stall(1); was natürlich falsch für Protokoll Stalls ist. 
Trotzdem muss da noch was anders sein.

von temp (Gast)


Lesenswert?

Was ich mir noch wünschen würde, ist eine Möglichkeit festzustellen, ob 
der PC den Port geöffnet oder geschlossen hat. Wenn man danach bei 
Google sucht, kommt man zu der Erkenntnis, dass das irgendwie nicht 
zuverlässig geht.
Hat hierzu jemand eine Idee?

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

temp schrieb:
> Was ich mir noch wünschen würde, ist eine Möglichkeit festzustellen, ob
> der PC den Port geöffnet oder geschlossen hat. Wenn man danach bei
> Google sucht, kommt man zu der Erkenntnis, dass das irgendwie nicht
> zuverlässig geht.

Das haben wir doch alles schon durchgekaut:

Beitrag "Re: USB CDC von Stefan Frings und WS"

Das Gerät bekommt nichts davon mit, wenn ein Programm :COM1 o.ä. öffnet. 
So ist das halt beim VCP.

von temp (Gast)


Angehängte Dateien:

Lesenswert?

Niklas G. schrieb:
> Das haben wir doch alles schon durchgekaut:

Mag sein, ich habe auch nicht alle Forenbeiträge im Kopf.
Allerdings habt ihr folgendes doch nicht durchgekaut:

Man kann sehr gut das DTR Flag für diese Aufgabe benutzen. Ich habe das 
jetzt mal mit dem hterm probiert, mit canhacker und lt. Internet soll 
das steinalte Hyperterminal das auch beim Öffnen setzen und beim 
Schließen wieder resetten. Sicher viele andere Software auch und bei 
eigener kann man das selber einbauen. Beim hterm muss man einmalig DTR 
bei geöffnetem Port drücken. Danach setzt er das beim Öffnen und 
Schließen alleine.

Die Stelle im Code von WS würde dann so aussehen:
1
volatile bool bIsComPortOpen=false;
2
3
/* Zustand von DTR und RTS vom Host zum Gerät merken */
4
void VCOM_Read_DTR_RTS(void)
5
{
6
  if ((CMD.SetupPacket.wValue & 0x01)!=0)
7
    bIsComPortOpen=true;
8
  else
9
    bIsComPortOpen=false;
10
  Dtr_Rts = CMD.SetupPacket.wValue >> 8;
11
  ACK();
12
}

Ich werde das jedenfalls so benutzen, dass ich die Buffer leer mache
wenn der Port zu ist. Aber das kommt wie immer auch auf die Anwendung 
an. Ich nutze nur das hterm oft zum loggen, und da nervt es, wenn beim 
Öffnen und Schließen noch Daten aus den Buffern kommen.

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

temp schrieb:
> Man kann sehr gut das DTR Flag für diese Aufgabe benutzen.

Und ich dachte Flusskontrolle nutzt man nicht mehr... Das verlässt sich 
auch darauf dass das Programm das setzt. Ein eigenes Programm macht das 
eventuell nicht.

von temp (Gast)


Lesenswert?

Niklas, ich denke du hast ganz schön einen an der Waffel.
Unterlass doch einfach deine Beiträge, wenn sie so sind wie deine 
letzten beiden.

Niklas G. schrieb:
> Und ich dachte Flusskontrolle nutzt man nicht mehr... Das verlässt sich
> auch darauf dass das Programm das setzt. Ein eigenes Programm macht das
> eventuell nicht.

Was soll das? Unter Flusskontrolle verstehe ich was anders. Und ja, mag 
sein dass man das so nennen kann wenn man es wörtlich nimmt. Und ich 
will in meinem User-Code auch nichts mit Flusskontrolle zu tun haben. 
Punkt. Und was du machst und für richtig hältst ist mir sowas von 
Wumpe...

Aber was soll's, ich diskutiere mit dir nicht mehr. Die die es 
interessiert können und werden es benutzen wie sie wollen und die 
anderen lassen es bleiben.

Niklas G. schrieb:
> Ein eigenes Programm macht das
> eventuell nicht.

Ein eigenes Programm macht das was ich will. Mag sein dass das bei 
deinen anders ist.

von Alex (Gast)


Lesenswert?

Guten Morgen!
Update:

Das Hello World von S.F. Webseite läuft auf meiner 'schlechten' Hardware 
mit dem externen TCXO,
die runtergeschickten Zeichen kommen als Echo zurück.

Damit ist bewiesen, dass der Fehler an meinem Code liegt.

Weiter Updates folgen...

Alex

von temp (Gast)


Lesenswert?

Alex schrieb:
> Das Hello World von S.F. Webseite läuft auf meiner 'schlechten' Hardware
> mit dem externen TCXO,
> die runtergeschickten Zeichen kommen als Echo zurück.

Dann ist es so wie ich vermutet habe, die Daten werden irgendwann und 
irgendwie nicht mehr abgeholt und dann steht die Kiste. Ich hatte dir 
hier mal einen Test vorgeschlagen:
Beitrag "Re: STM32 USB Übertragungsproblem mit Code von S.F."
hast du das mal probiert?

von Alex (Gast)


Lesenswert?

Hallo temp,

ich hatte deinen Beitrag übersehen (bin bei eurer Diskussion leicht 
'ausgestiegen'), vielen Dank für die Erinnerung !!

Ich werds heute Abend ausprobieren und umgehend reporten!

DANKE!!

von Thomas Z. (usbman)


Lesenswert?

Hallo zusammen,
ich habs jetzt im wesentlichen zusammen:

1. der Configdescriptor ist ein byte zu lang (unkritisch)
2. OnGetStatus, OnGetSetFeature laufen wegen Sall(1) in einen Timeout
3. Stall() und UnStall() sind fehlerhaft

Überprüft habe ich das ganze mit Thesycons UsbIo Treiber, weil man damit 
jeden Chapter 9 Request einzeln absetzen kann. Da ich nur die V2.5 
besitze hab ich das ganze in einer VM unter W7 und XP getestetet, das 
aber nur am Rande.
1
void DoGetStatus(void)
2
{
3
   ...
4
    case 0x82: /* für einen Endpoint */
5
        trace("forEndpoint\n");
6
        switch (EP)
7
        {  
8
           /* nur für bulk + int eps notwendig
9
           case 0x80: //ctrl in
10
           case 0x00: //ctrl out  */
11
           case 0x02: //bulk out stall condition
12
                if (((USB_EP2R >> 12) & 0x03) ==1) Buf[0] = 1;
13
                break;
14
           case 0x81: //bulk in stall condition
15
                if (((USB_EP1R >>  4) & 0x03) ==1) Buf[0] = 1;
16
                break;
17
           case 0x83: //interrupt in stall condition
18
                if (((USB_EP3R >>  4) & 0x03) ==1) Buf[0] = 1;
19
                break;
20
           default:
21
                StallLogEP(logEpCtrl); 
22
                return;
23
         }
24
    ...
25
}

Stall bzw UnSTall ist kritischer, da ist STAT_RX bzw STAT_TX verdreht. 
Das hat mich etwas Zeit gekostet wegen der Magic Numbers.
Der Einfachheit halber hab ich einfach die Abfrage von != auf == 
geändert,
was bei STall() funktioniert bei Unstall aber nicht. Da muss ich die XOR 
Bedingungen noch anpassen. Generell bin ich mir beim XOR unsicher ob das 
die Togglebedingungen immer richtig abbildet, da muss ich noch etwas 
nachdenken.

Ich hab mir allerdings noch nicht überlegt ob das alles auch richtig 
wäre wenn man zB beide BulkEps auf einen bidirektionalen Endpoint legen 
würde.

von Stefan ⛄ F. (stefanus)


Lesenswert?

Thomas, kann ich das so 1:1 in die usb.c rein kopieren oder hängen damit 
noch andere notwendige Anpassungen zusammen?

von Thomas Z. (usbman)


Lesenswert?

Der gezeigte Code ist zwar korrekt und getestet. Das ist aber noch nicht 
alles. Ich würde warten, bis ich usb.c hochlade. Dann ist auch alles 
drin. Meine Änderungen beziehen sich ja nur auf USB Funktionen. Am VCP 
hab ich nichts gemacht.
Wie gesagt noch gibt's ein Problem beim UnStall().

von Stefan ⛄ F. (stefanus)


Lesenswert?

Thomas Z. schrieb:
> Ich würde warten, bis ich usb.c hochlade.

Ok, dann warte ich ab und hoffe dass es dann korrekt funktioniert. Weil: 
Fachlich kann ich euch da nicht folgen, dazu habe ich zu wenig (fast gar 
keine) Ahnung von USB.

: Bearbeitet durch User
von Alex (Gast)


Lesenswert?

Ich hab die beiden Funktionen, die temp mir oben (24.02.2021 15:41) 
vorgeschlagen hat mal reinkopiert, und es hat funktioniert !!!!

Nur um zu verifizieren, dass das die Ursache wirklich adressiert, hab 
ich wieder auf die beiden vorigen Funktionen zurückgestellt, und es hat 
auch funktioniert kopfkratz.

Ich glaub ich hab mittlerweile so heftig in dem Code rumgepfuscht, dass 
ich nicht mehr sauber nachvollziehen kann, wann ich was ausprobiert 
habe. Ein log hab ich nicht gemacht (schäm).

Ich schließ micht jetzt mal dem Stefan beim Warten an, und verwende die 
Version die Thomas dann hochlädt. Sonst wird der Saustall in meinem Code 
noch schlimmer..

von Johannes S. (jojos)


Lesenswert?

Da macht es Sinn sich mal mit git zu beschäftigen.

von Stefan ⛄ F. (stefanus)


Lesenswert?

Alex schrieb:
> hab ich wieder auf die beiden vorigen Funktionen zurückgestellt,
> und es hat auch funktioniert kopfkratz.

Hast du vielleicht ganz knapp zu wenig RAM (Stack versus Heap Überlauf)?

Das müsste sofort eindeutig werden, wenn du den Sende-Puffer (txLen) mal 
deutlich größer oder kleiner machst. Zum Beispiel 16 Bytes versus 1024 
Bytes.

(txLen muss nicht >64 sein, aber eine Zweierpotenz (4,8,16,32,...)

von temp (Gast)


Lesenswert?

Alex schrieb:
> Ich hab die beiden Funktionen, die temp mir oben (24.02.2021 15:41)
> vorgeschlagen hat mal reinkopiert, und es hat funktioniert !!!!
>
> Nur um zu verifizieren, dass das die Ursache wirklich adressiert, hab
> ich wieder auf die beiden vorigen Funktionen zurückgestellt, und es hat
> auch funktioniert kopfkratz.

Das war jetzt auch mit dem exterenen Takt oder mit dem HSI48?

von temp (Gast)


Lesenswert?

Ich hatte bei meinem STM32F042 auch mal am Takt gespiel mit einem LED 
Tooglen in einem 1ms Systick-Handler:

HSE:           499.9 Hz

HSI:           497.6 Hz

HSI48:         505.0 Hz

HSI48 mit CRS: 499.9 Hz

nur um mal eine Hausnummer zu haben wieweit der Takt bei mir abweicht.
Zuerst hatte ich in geistiger Umnachtung versucht den HSI mit CRS gerade 
zu rücken. Natürlich ohne Erfolg. Dafür aber wieder was gelernt.

Wenn dich der Teil interessiert:
1
void SetSysClockHsi48()
2
{
3
  RCC->CR2 |= RCC_CR2_HSI48ON;
4
 
5
  // Wait till HSI48 is ready
6
  while ((RCC->CR2 & RCC_CR2_HSI48RDY) == 0)
7
    ;
8
  
9
  // Enable Prefetch Buffer and set Flash Latency 
10
  FLASH->ACR = FLASH_ACR_PRFTBE | FLASH_ACR_LATENCY;
11
 
12
  // HCLK = SYSCLK 
13
  RCC->CFGR |= (uint32_t)RCC_CFGR_HPRE_DIV1;
14
      
15
  // PCLK = HCLK 
16
  RCC->CFGR |= (uint32_t)RCC_CFGR_PPRE_DIV1;
17
18
  // Select PLL as system clock source 
19
  RCC->CFGR &= (uint32_t)((uint32_t)~(RCC_CFGR_SW));
20
  RCC->CFGR |= (uint32_t)RCC_CFGR_SW_HSI48;    
21
22
  while ((RCC->CFGR & (uint32_t)RCC_CFGR_SWS) != (uint32_t)RCC_CFGR_SWS_HSI48)
23
    ;  
24
25
  // CRS einschalten
26
  RCC->APB1ENR|=RCC_APB1ENR_CRSEN;
27
  CRS->CR|=CRS_CR_AUTOTRIMEN | CRS_CR_CEN;
28
}

von temp (Gast)


Lesenswert?

der Kommentar:
1
// Select PLL as system clock source
ist natürlich Blödsinn...

von Jürgen S. (avus)


Lesenswert?

Thomas Z. schrieb:
> Wie gesagt noch gibt's ein Problem beim UnStall().
Gut, daß Du das testen kannst.

Inzwischen habe ich den Code auch auf einer Bluepill mit 
Original-STM32F103C8T6 getestet (zuvor auf einem F103RCT6), und er läuft 
ebenfalls gut. Wobei mir die Stalls bzw. Bugs vielleicht bei meinen 
Anwendungen gar nicht auffallen.
Ich steuere über die Bluepill einen RFM69, der an andere RFM69 Daten und 
auch ganze AVR-Programme überträgt. da flutschen also schon auch 
'größere' Datenmengen von bis zu 16kB hin und her, abwechselnd mit 
Mini-Paketchen von 1-7 bytes als Statusbericht. Kein Problem bisher.
Aus Begeisterung habe ich sogar der Bluepill einen Erkennungsstring 
verpaßt. Das PC-Programm klappert alle Comports durch, ob sie einen 
bekannten string senden, um die Bluepill auch auf verschiedenen PCs 
anschließen zu können. Hat sofort funktioniert - mit den alten 
usb-Dateien war das ein Gekrampfe mit Timing, Aufhängern etc..

von Alex (Gast)


Lesenswert?

Ging sowohl mit HSI48 als auch mit dem HSE.

Ganz ausschließen kann ich die Takt-Geschichte glaub ich nicht, weil die 
CRS mittelt ja die Taktabweichung immer über 1ms, wenn die Schwankungen 
innerhalb dieser ms aber sehr groß sind, könnte das durchaus ein Problem 
für den USB sein.
Meine Chips sind im TSOP20-Package, die haben leider keinen MCO (main 
clock out) als Alternate Function.
Sonst hätte ich mit einem Frequenzzähler mal bei kürzerer gatetime den 
jitter verglichen...

von Alex (Gast)


Lesenswert?

> Hast du vielleicht ganz knapp zu wenig RAM (Stack versus Heap Überlauf)?
Ram hab ich jede Menge, der Flash ist mir ziemlich knapp...

von Thomas Z. (usbman)


Angehängte Dateien:

Lesenswert?

in folgenden Funktionen hab ich was verändert:

Stall();
UnStall;
DoGetSetFeature();
DoGetStatus();
und bei SetInterface.

Ein paar Kleinigkeiten bei den Deskriptoren sind unwesendlich ich hab da 
nur ein paar Dinge geändert um in Zukunft flexibler zu sein.

Bei SetInterface lösche ich die ToggleBits, wie von der Spec verlangt. 
Da ich nicht genau weis wann usbserial.sys SetInterface absetzt kann 
dies sich auch auf den VCP auswirken. Meine Tests waren zwar erfolgreich 
aber der Teufel steckt ja bekanntlich im Detail.

Alle anderen Änderungen sollten sich nicht auf den VCP auswirken, Sie 
betreffen lediglich die Kompatibilität mit der Spec. Die VCP 
ClassRequests habe ich noch nicht geprüft, Ich gehe aber davon aus, dass 
die ok sind.

Eine Änderung hätte ich noch für die Zukunft:
Im Moment melden sich ja alle Devices mit der gleichen Seriennumer.
Besser wäre es die Serien Nummer aus dem Chip zu lesen oder abschaltbar 
zu machen.

Viel Spass beim Ausprobieren.

von Jürgen S. (avus)


Lesenswert?

Thomas Z. schrieb:
> Im Moment melden sich ja alle Devices mit der gleichen Seriennumer.
> Besser wäre es die Serien Nummer aus dem Chip zu lesen oder abschaltbar
> zu machen.
gute Idee

Ich habe gerade Dein usb.c mit der Bluepill verwendet (schreibe bewußt 
nicht getestet, weil ich das gar nicht kann), und es geht nach wie vor, 
also bleibt das neue usb.c drin ;-). Danke dafür.

2 Sachen noch:
1.)
Nop habe ich wieder durch
1
void Nop(volatile uint32_t count)
2
{
3
  while(count--);
4
}
ersetzt, damit es nicht wegoptimiert werden kann.

2.)
Woran ich beim letzten Mal geknobelt habe:
Oben in der usb.c steht
#define NAME_OF_USB_IRQ_HANDLER USB_LP_CAN_RX0_IRQHandler
und der Hinweis, daß der Name des Handlers mit startup_stm32.s matchen 
muß.
Coocox- bzw. SPL-User rennen vielleicht auch in die Falle; es gibt keine 
Fehlermeldung, aber der Handler USB_LP_CAN_RX0_IRQHandler wird nicht 
angesprungen.
Es sollte in diesem Fall USB_LP_CAN1_RX0_IRQHandler heißen.

von Thomas Z. (usbman)


Lesenswert?

Jürgen S. schrieb:
> Ich habe gerade Dein usb.c

na ja meine usb.c ist sehr übertrieben wenn schon ist das von W.S. mit 
Änderungen von einigen Forenmitgliedern.
Ich hab das bewusst im Original Stil belassen, und auch deshalb deutsche 
Kommentare verwendet.

Ich persönlich würde sowas genau wie W.S. machen auch wenn mein Code Sil 
natürlich ein etwas anderer wäre. Bare Metal Rules.
Ich lege allerdings sehr viel Wert auf Kompatibilität zur Spec. Viele 
meiner Devices laufen unabhängig vom OS seit XP, oder Linux ohne dass 
eine Zeile verändert wurde.
Da wäre z.B. zu sagen, dass VCP eigendlich IAD Deskriptoren vorschreibt. 
Das habe ich bewusst weggelassen, weil's bisher noch nicht notwendig 
ist, und noch funktioniert. Ich habe allerdings VCPs mit IAD am laufen.

Die zwei Dinge die du anmerkst sind genauso in der Version von Stefan 
drin. Mit den zig IDEs stehe ich etwas auf Kriegsfuss.

von Stefan ⛄ F. (stefanus)


Lesenswert?

Danke Thomas, ich habe deine Änderungen auf meine Homepage übernommen 
und noch ein bisschen aufgeräumt (Formatierung und Reihenfolge der 
Abschnitte).

Auch Danke an Dich Jürgen. Ich habe das volatile hinzugefügt aber das 
NOP stehen gelassen weil ich unsicher bin, ob das wirklich
bei jedem Compiler weg gelassen werden darf.

von Stefan ⛄ F. (stefanus)


Lesenswert?

Ich habe die API zum Anwendungsprogramm hin erweitert.

Es gibt dort jetzt eine neue Funktionen mit der man testen kann, ob ein 
bestimmtes Zeichen im Empfangspuffer liegt (zum Beispiel '\n').

Ich habe Funktionen zum Senden und Empfangen von Zeichenketten sowie 
Datenpaketen mit fester Länge hinzugefügt.

Bei den Funktionen zum Senden/Empfangen kann man jetzt einen Timeout 
angeben.

Wer daran Interesse hat, kann sich das von meiner Homepage downloaden:
http://stefanfrings.de/stm32/index.html

von Stefan ⛄ F. (stefanus)


Lesenswert?

Thomas Z, ich habe noch eine kleine Bitte an dich. Der Code enthält 
vermutlich noch einen alten Bug. Mit "alt" meine ich, das ich den Effekt 
schon vor unseren Änderungen bemerkt hatte.

Wenn ich den Port /dev/ACM0 mit Cutecom öffne sehe ich jede Sekunde die 
erwartete Meldung "Hello World!".

Wenn ich nun etwas zum Senden eintippe, dann sendet der µC diesen String 
als Echo zurück. Manchmal beginnt das Echo aber mit einem Fragment von 
"Hello World!", zum Beispiel:

Ich Sende:  bla
Ich empfange: Helbla

Wenn ich main.c auf dem Mikrocontroller so ändere, dass das Echo doppelt 
zurück gesendet wird, dann passiert dies:

Ich Sende:  bla
Ich empfange: Helbla
Ich empfange: Helbla

Ich Sende:  gaga
Ich empfange: Hellgaga
Ich empfange: Hellgaga

Da scheint ein Zusammenhang bezüglich der Anzahl der Zeichen zu 
bestehen.

Der Effekt tritt nur bei ersten gesendeten String auf. Danach nicht 
mehr. Und es passiert auch nicht immer.

Es wäre super, wenn du mal danach schauen könntest. Vielleicht hast du 
eine Idee, woran das liegen könnte.

: Bearbeitet durch User
von Stefan ⛄ F. (stefanus)


Lesenswert?

Thomas, ich habe noch eine Info dazu: Diese Problem aus meinem 
vorherigen Beitrag tritt unter Windows 10 nicht auf.

Unter Linux aber häufig. Es ist Debian Testing mit Kernel 5.10.13-1.

von Thomas Z. (usbman)


Lesenswert?

Ich schau mir das mal an, wird allerdings etwas dauern. Vielleicht hab 
ich dann auch schon die Sache mit der SN eingebaut.
Ich hab die Conig Params  zusammengefasst beim Keil bekommt man dann ein 
Einstellmenu. In anderen IDEs sind es weiterhin nur defines.

von Stefan ⛄ F. (stefanus)


Angehängte Dateien:

Lesenswert?

In Ubuntu 20.04 (Live Stick) mit Kernel 5.8.0-43-generic tritt der 
Fehler auch auf.

Ich habe inzwischen eine Methode gefunden, den Fehler schneller 
auszulösen. Und zwar Klicke ich links oben wiederholt auf den Open/Close 
Button. Manchmal erscheinen dann falsche Zeichen. Der Fehler tritt sogar 
im read-only Modus auf.

Was mir dabei sehr auffällt ist: Die falschen Zeichen sind immer 
Buchstaben aus "Hello World!" oder LF oder CR. Niemals andere 
Buchstaben.

: Bearbeitet durch User
von Thomas Z. (usbman)


Angehängte Dateien:

Lesenswert?

Stefan, kannst du mal tracen was unter linux bei open/close für Requests 
kommen? Ich erwarte da ein paar ClassRequests, die hab ich bisher noch 
garnicht getestet.


Anbei ein Bild meines ConfigMenus und hier der source dafür:
Die core Einstellungen laufen schon die VCP Einträge machen noch nichts
1
/* USB als virtuellen COM Port betreiben */
2
#include "usb.h"
3
4
// <<< Use Configuration Wizard in Context Menu >>>
5
// <h> Configuration for STM bare metal VCP
6
// <h> CORE params
7
8
// <o> UMEMSHIFT      <0=> off
9
//                    <1=> on
10
// <i> Off for devicec like STM32L0x2, STM32L0x3, STM32F0x2, STM32F303xD and xE
11
// <i> On  for devicec like STM32F103, STM32F302, STM32F303xB and xC                
12
#define UMEM_SHIFT     1
13
14
// <o> USB_IRQ_NUMBER <0-31>
15
// <i> Take the number from the reference manual for ypor controller
16
#define USB_IRQ_NUMBER 20
17
18
// <o>  ENABLE_TRACING <0=> false
19
//                     <0=> true
20
// <i>  Enable trace messages via SWO
21
#define ENABLE_TRACING 0
22
23
// </h>
24
// <h> VCP params
25
26
// <o> USB_VID         <0-0xFFFF>
27
// <i> USB Vendor ID
28
#define USB_VID        0x0416
29
30
// <o> USB_PID         <0-0xFFFF>
31
// <i> USB Prodct ID
32
#define USB_PID        0x5011
33
34
// <o> USB_SERIAL      <0=> none>
35
//                     <1=> fixed>
36
//                     <2=> from chip
37
// <i> Select what kind of USB Serial Number is used
38
#define USB_SERIAL     0 
39
40
// <o> IAD_SUPPORT     <0=> false
41
//                     <1=> true
42
// <i> Enable extra IAD conform descriptors
43
// <i> Spec requires IAD for devices using which use 2 or more interfaces for one function
44
// <i> although neither WIN nor Linux requires that up to now
45
#define IAD_SUPPORT    0  
46
47
// <o> VCP_IN_EP       <0x81=> EP1 In
48
//                     <0x82=> EP2 In
49
//                     <0x83=> EP3 In
50
//                     <0x84=> EP4 In
51
//                     <0x85=> EP5 In
52
//                     <0x86=> EP6 In
53
//                     <0x87=> EP7 In
54
#define VCP_IN_EP      0x81
55
56
// <o> VCP_OUT_EP      <0x01=> EP1 Out
57
//                     <0x02=> EP2 Out
58
//                     <0x03=> EP3 Out
59
//                     <0x04=> EP4 Out
60
//                     <0x05=> EP5 Out
61
//                     <0x06=> EP6 Out
62
//                     <0x07=> EP7 Out
63
#define VCP_OUT_EP     0x02 
64
65
// <o> VCP_STAT_EP     <0x81=> EP1 In
66
//                     <0x82=> EP2 In
67
//                     <0x83=> EP3 In
68
//                     <0x84=> EP4 In
69
//                     <0x85=> EP5 In
70
//                     <0x86=> EP6 In
71
//                     <0x87=> EP7 In
72
#define VCP_OUT_EP     0x83
73
74
// <<< end of configuration section >>>
75
....

: Bearbeitet durch User
von Stefan ⛄ F. (stefanus)


Lesenswert?

Beim Einstecken bekomme ich:
1
RESET
2
InitEndpoints
3
setAddr adr=0
4
CTR out
5
logEpCtrl
6
SETUP
7
rdCtrlBlock maxlen=8, count=8
8
clrBuf logEpNum=0
9
isStandardRequest
10
GET_DESCRIPTOR
11
doGetDescr type 0001
12
descDevice
13
wrCtrlBlock count=18
14
validateBufvalidateBuf logEpNum=1

Beim Öffnen des COM Portes:
1
CTR in
2
logEpBulkIn
3
validateBuf logEpNum=1
4
CTR out
5
logEpCtrl
6
SETUP
7
rdCtrlBlock maxlen=8, count=8
8
clrBuf logEpNum=0
9
IsClassRequest
10
SET_CONTROL_LINE_STATE
11
wrCtrlBlock count=0
12
validateBuf logEpNum=0
13
CTR in
14
logEpBulkIn
15
validateBuf logEpNum=1
16
CTR out
17
logEpCtrl
18
SETUP
19
rdCtrlBlock maxlen=8, count=8
20
clrBuf logEpNum=0
21
IsClassRequest
22
SET_LINE_CODE
23
wrCtrlBlock count=0
24
validateBuf logEpNum=0
25
CTR out
26
logEpCtrl
27
EpCtrlOut
28
IsClassRequest
29
SET_LINE_CODE
30
rdCtrlBlock maxlen=7, count=7
31
clrBuf logEpNum=0
32
wrCtrlBlock count=0
33
validateBuf logEpNum=0
34
wrCtrlBlock count=0
35
validateBuf logEpNum=0
36
CTR in
37
logEpCtrl
38
CTR in
39
logEpBulkIn
40
validateBuf logEpNum=1
41
CTR out
42
logEpBulkOut
43
clrBuf logEpNum=2
44
CTR in
45
logEpBulkIn
46
validateBuf logEpNum=1
47
CTR in
48
logEpBulkIn
49
validateBuf logEpNum=1
50
CTR in
51
logEpBulkIn
52
validateBuf logEpNum=1
53
CTR in
54
logEpBulkIn
55
validateBuf logEpNum=1validateBuf logEpNum=1
56
CTR in
57
logEpBulkIn
58
validateBuf logEpNum=1
59
CTR in
60
logEpBulkIn
61
validateBuf logEpNum=1
62
CTR in
63
logEpBulkIn
64
validateBuf logEpNum=1
65
CTR in
66
logEpBulkIn
67
validateBuf logEpNum=1
68
CTR in
69
logEpBulkIn
70
validateBuf logEpNum=1
71
CTR in
72
logEpBulkIn
73
validateBuf logEpNum=1
74
CTR in
75
logEpBulkIn

Beim Schließen des COM Portes:
1
validateBuf logEpNum=1
2
CTR in
3
logEpBulkIn
4
validateBuf logEpNum=1
5
CTR in
6
logEpBulkIn
7
validateBuf logEpNum=1
8
CTR in
9
logEpBulkIn
10
validateBuf logEpNum=1
11
CTR in
12
logEpBulkIn
13
validateBuf logEpNum=1
14
CTR in
15
logEpBulkIn
16
validateBuf logEpNum=1
17
CTR in
18
logEpBulkIn
19
CTR out
20
logEpCtrl
21
SETUP
22
rdCtrlBlock maxlen=8, count=8
23
clrBuf logEpNum=0
24
IsClassRequest
25
SET_LINE_CODE
26
wrCtrlBlock count=0
27
validateBuf logEpNum=0
28
CTR out
29
logEpCtrl
30
EpCtrlOut
31
IsClassRequest
32
SET_LINE_CODE
33
rdCtrlBlock maxlen=7, count=8
34
clrBuf logEpNum=0
35
wrCtrlBlock count=0
36
validateBuf logEpNum=0
37
wrCtrlBlock count=0
38
validateBuf logEpNum=0
39
CTR out
40
logEpCtrl
41
SETUP
42
rdCtrlBlock maxlen=8, count=8
43
clrBuf logEpNum=0
44
IsClassRequest
45
SET_CONTROL_LINE_STATE
46
wrCtrlBlock count=0
47
validateBuf logEpNum=0
48
CTR in
49
logEpCtrl
50
validateBuf logEpNum=1

Ich habe keine Ahnung, was das alles bedeutet. Hoffentlich hilft es dir.

von Stefan ⛄ F. (stefanus)


Lesenswert?

Ich finde das sehr auffällig:
1
validateBuf logEpvalidateBuf logEpNum=1

Allerdings kann ich da keinen 1:1 Zusammenhang zu den unerwarteten 
Zeichen an COM Port finden. Beides tritt unabhängig voneinander auf.

In den allermeisten Fällen sehen die Trace Meldungen so aus, während der 
Fehler auftritt:
1
validateBuf logEpNum=1    --> Hello World!
2
CTR in
3
logEpBulkIn
4
validateBuf logEpNum=1    --> Hello World!
5
CTR in
6
logEpBulkIn
7
validateBuf logEpNum=1    --> Hello World!
8
CTR in
9
logEpBulkIn
10
CTR out                   <-- qqq
11
logEpBulkOut
12
clrBuf logEpNum=2
13
validateBuf logEpNum=1    --> Hqqq   (das H ist hier falsch)
14
CTR in
15
logEpBulkIn
16
validateBuf logEpNum=1    --> Hello World!
17
CTR in
18
logEpBulkIn
19
validateBuf logEpNum=1    --> Hello World!
20
CTR in
21
logEpBulkIn

: Bearbeitet durch User
von Stefan ⛄ F. (stefanus)


Angehängte Dateien:

Lesenswert?

Ich bin ein Stück weiter. Die folgende main() Funktion zeigt mir, dass 
der Fehler in dem Moment des Öffnens vom COM-Port auftritt.

Dass ich den Fehler vorher erst nach Eingabe einer Zeichenkette (im 
CuteCom) gesehen habe lag daran, dass das Programm vorher alle 
hereinkommenden Zeichen bis zum ersten LF sammelte.
1
int main(void)
2
{
3
    // Initialize system timer
4
    SysTick_Config(SystemCoreClock/1000);
5
6
    init_io();
7
    UsbSetup();
8
9
    while (1)
10
    {
11
        // LED On
12
        WRITE_REG(GPIOA->BSRR, GPIO_BSRR_BS5);
13
        WRITE_REG(GPIOC->BSRR, GPIO_BSRR_BR13);
14
        delay_ms(100);
15
16
        UsbSendStr("Hello World!\n",10);
17
        // Alternative: puts("Hello World!");
18
19
        // Echo received characters
20
        while (UsbRxAvail())
21
        {
22
          UsbSendStr("rx:",10);
23
          char c;
24
          UsbGetChar_noWait(&c);
25
          UsbSendChar(c, 10);
26
                UsbSendChar('\n', 10);
27
        }
28
29
        /*
30
        // If a line has been received, then send an echo back
31
        if (UsbRxBufferContains('\n'))
32
        {
33
            char buf[256];
34
            UsbGetStr(buf,sizeof(buf),'\n',0);
35
            UsbSendStr(buf,10);
36
        }
37
        */
38
39
        // LED Off
40
        WRITE_REG(GPIOA->BSRR, GPIO_BSRR_BR5);
41
        WRITE_REG(GPIOC->BSRR, GPIO_BSRR_BS13);
42
        delay_ms(900);
43
    }
44
45
}

Die Ausgabe zeigt ganz deutlich dass der µC seine "Hello World!" 
Meldungen einwandfrei sendet. Aber kurz nach dem Öffnen des COM Portes 
empfängt er fälschlicherweise ein unerwartetes Fragment, scheinbar aus 
dem Sende-Puffer.

von W.S. (Gast)


Lesenswert?

Jürgen S. schrieb:
> Woran ich beim letzten Mal geknobelt habe:
> Oben in der usb.c steht
> #define NAME_OF_USB_IRQ_HANDLER USB_LP_CAN_RX0_IRQHandler
> und der Hinweis, daß der Name des Handlers mit startup_stm32.s matchen
> muß.
> Coocox- bzw. SPL-User rennen vielleicht auch in die Falle; es gibt keine
> Fehlermeldung, aber der Handler USB_LP_CAN_RX0_IRQHandler wird nicht
> angesprungen.
> Es sollte in diesem Fall USB_LP_CAN1_RX0_IRQHandler heißen.

Das hat Stefan eingeführt und ich bin mit so etwas nicht glücklich. 
Ich war ganz früher auch mal auf diesem Trip, aber mittlerweile stehe 
ich auf dem Standpunkt, daß ein usb.c eben nur genau für den Chip sein 
soll, für den er geschrieben ist.
Und wenn der gleiche Quellcode zu 99.9% auch für einen anderen Chip 
brauchbar sein sollte, dann ändert man die restlichen 0.1% und speichert 
ihn unter anderem Namen oder woanders ab, so daß eben immer gilt:
  1 Plattform = 1 Handler.
Soviel Platz haben wir mittlerweile auf unseren Festplatten. Wenn man 
das so tut, dann braucht man auch keine Flags in der Quelle, keine 
unnötigen externen Referenzen, keine #ifdef und so weiter.
Vielleicht sollte man sich mal auf irgend eine Förmlichkeit einigen, 
z.B.:
usb_stf103.c
usb_lpc4088.c
usb_nuc120.c
und so ähnlich.

W.S.

von W.S. (Gast)


Lesenswert?

Thomas Z. schrieb:
> Ich lege allerdings sehr viel Wert auf Kompatibilität zur Spec.

Und hast du selbige da und darfst du sie auch mal posten?
Originalunterlagen würde ich mir gern mal ansehen.

W.S.

von W.S. (Gast)


Angehängte Dateien:

Lesenswert?

Stefan ⛄ F. schrieb:
> Es gibt dort jetzt eine neue Funktionen mit der man testen kann, ob ein
> bestimmtes Zeichen im Empfangspuffer liegt (zum Beispiel '\n').
>
> Ich habe Funktionen zum Senden und Empfangen von Zeichenketten sowie
> Datenpaketen mit fester Länge hinzugefügt.

Also Stefan, da knurrt aber der Blindenhund ganz gewaltig!

Also: der USB-Treiber ist der Lowlevel-Treiber, was du hingegen machst, 
ist etwas, das 1..2 Ebenen höher angesiedelt ist. Also soll das auch in 
eine andere Quelle, die sich nur um das von dir Angesprochene kümmert 
und die je nach Bedarf auch andere LL-Treiber benutzt, z.B. einen für 
einen UART.

Ich häng dir mal so etwas ähnliches zur Ansicht dran, damit du siehst, 
wie z.B. ich da etwas Ordnung in die Datenströme kriege. Die Datei ist 
eine Vorlage, die an die konkrete Plattform angepaßt wird. Manche haben 
keinen UART0, andere keine UART6..7..sonstwas. Obendrein gibt es bei den 
meisten µC-Anwendungen bei mir auch kein Kommandofenster und kein 
Filesystem und deshalb auch keine Textfiles, dennoch ist sowas wie 
CharToFileStream(..) oder CharToCommandWindow(..) formal vorgesehen. Die 
Anwendungseben spricht bei mir NIEMALS den usb.c oder serial.c oder so 
an, sondern macht das grundsätzlich nur über gio.c.

Und weil es bei mir häufig vorkommt, daß einige Programmstücke nicht 
wissen (sollen), was der aktuelle I/O-Kanal ist, gibt es in Analogie zum 
PC sowas wie stdout und stdin als generalisierten Kanal.

Und jetzt kommst du und wirfst das Zusammensetzen von Kommandozeilen und 
Datenpaketen in den LL-Treiber, wo sowas definitiv nicht hin gehört.

Und mal abgesehen davon, erzeugst du damit firmwareinterne Probleme: Was 
ist, wenn eine gewünschte Pufferlänge größer ist als der FIFO des 
LL-Treibers? Ich denke da grad an eine meiner Anwendungen zum 
Programmieren von µC, wo ich einen Programmierpuffer habe, der 2..8K 
oder so groß ist.

Nein, der Ringpuffer im LL-Treiber dient NUR zur Entkopplung und nicht 
als Puffer für eine Kommandozeile oder eines sonstigen 
anwendungsspezifischen Blockpuffers. Sowas muß separat gemacht werden 
und es gehört auch logisch auf eine höhere Ebene.

W.S.

von Alex (Gast)


Lesenswert?

Zu dem Thema mit der Seriennummer kann ich vielleicht etwas beitragen.
Ich nutze dazu die Unique ID vom STM. Die StringSerial ist bei mir keine 
Konstante, sondern eine Variable, die in der UsbSetup() gesetzt wird.
1
// Device ID vom chip zum Erzeugen einer USB-Seriennummer
2
// STM32F042: Device ID:   @ 0x1FFF F7AC +0 +4 +8 (3x32bit)
3
#define DEVICE_ID_ADDRESS         (0x1FFFF7AC)  
4
#define DEVICE_ID_SIZE          (12)//in bytes

Folgenden Block hab ich in die UsbSetup() eingefügt:
1
    // read Unique ID and generate serial number for the USB
2
    char c;
3
    int j;
4
    uint8_t* idB;
5
    uint8_t x;
6
  StringSerial[0] = DEVICE_ID_SIZE*2 + 2; //
7
  StringSerial[1] = DESC_STRING;
8
9
  for (j = DEVICE_ID_SIZE*2*2 + 2, idB = (uint8_t*)(DEVICE_ID_ADDRESS + DEVICE_ID_SIZE-1); j>2; idB--)
10
  {
11
    x = *idB;
12
    c = (char)(x & 0x0F);
13
    if (c < 10)
14
      c += 0x30;
15
    else
16
      c += 0x37;
17
    StringSerial[--j] = 0;
18
    StringSerial[--j] = c;
19
    x >>= 4;
20
    c = (char)(x & 0x0F);
21
    if (c < 10)
22
      c += 0x30;
23
    else
24
      c += 0x37;
25
    StringSerial[--j] = 0;
26
    StringSerial[--j] = c;
27
  }
28
  // serial number finished

Ich bin mir aber nicht sicher, ob die Seriennummer dann nicht zu lang 
ist.
Im Gerätemanager werden nur 12 von den 24 hex digits angezeigt.

Ist sicher noch verbesserungswürdig, aber funktioniert bei mir.

von Alex (Gast)


Lesenswert?

@ Stefan und W.S.

Ich denke W.S. hat mir seiner Kritik einen wichtigen Punkt getroffen.

Ich hatte bei mir im Code auch eine Zusatzfunktion eingefügt, mit der im 
Empfangsbuffer auf ein CR oder LF geprüft wurde.
Erst dann wurden die Daten weiterverarbeitet.

Ich glaube, dass das mit ein Grund war, warum der Code bei mir solche 
Schwierigkeiten gemacht hat.

von Stefan ⛄ F. (stefanus)


Lesenswert?

Ob man die Funktionen des Application Layers in der gleichen Datei hat, 
oder nicht, ist Geschmackssache. Ich möchte darüber nicht streiten. 
Jeder kann sich seine Variante des Codes so gestalten, wie er es haben 
möchte.

Ich möchte viel lieber den Fehler lösen. Aus irgend eine Grund empfängt 
der µC nur unter Linux beim Öffnen des COM Port falsche Bulk Out 
Interrupts in denen sich Fragmente zuvor gesendeter Daten befinden.

: Bearbeitet durch User
von Stefan ⛄ F. (stefanus)



Lesenswert?

Ich habe sicherheitshalber nochmal den Gegentest gemacht. Der Fehler 
tritt wirklich auch mit dem Original-Code von W.S. aus dem Jahr 2015 
auf. Ich habe ihn angehängt.

Wenn ich den COM Port öffne, empfängt der µC häufig (aber nicht immer) 
unerwünschte Zeichen. Im Screenshot sind das die Zeilen mit dem Präfix 
"rx:".

Im Hammer Terminal sieht es genau so aus. Wie gesagt passiert das aber 
nur unter Linux.

: Bearbeitet durch User
von Jürgen S. (avus)


Lesenswert?

W.S. schrieb:
> Das hat Stefan eingeführt und ich bin mit so etwas nicht glücklich.
> Ich war ganz früher auch mal auf diesem Trip, aber mittlerweile stehe
> ich auf dem Standpunkt, daß ein usb.c eben nur genau für den Chip sein
> soll, für den er geschrieben ist.
Ohoh, da bin ich ganz anders veranlagt. Ich habe im Gegensatz sogar 
meine 407/429/103-Bibliotheken mit #ifdefs ausgestattet, um ja nicht für 
jeden Chip wieder eine separate Datei zu haben. Hab tatsächlich nur noch 
eine spi.h/c, usb.h/c, diskio.h/c etc. für diese 3 Prozessoren, und für 
manche Projekte auch ein CPU-übergreifendes H-File für STM32 und AVR.
Ich komme einfach nicht mehr hinterher, in einem Projekt eine Datei zu 
ändern und dann daran zu denken, diese Änderung auch für die anderen 
Prozessoren/Projekte einzuflechten. Irgendwann hat man dann wieder 
drölfzig Versionen, von denen die eine die x-Verbesserung hat, aber 
dafür nicht die y-Verbesserung, und vice versa.
Das war also meinerseits keine Kritik, den IRQ-Handler oben wählbar 
auszuführen, sondern eher Kritik an Coocox bzw. eher SPL oder gar CMSIS, 
daß der IRQ-Handler nicht semantisch geprüft wird.


@Alex, vielleicht verwende ich Dein Seriennummerprogramm mit dem 
nichtkonstanten SerialString. Ich hatte selbst auch dran gesetzt (die 12 
Byte der CPU_UNIQUE_ADDRESS passen einfach zu gut in den Descriptorstr, 
als daß man die Gelegenheit versäumen sollte :). Ich hatte dann nur den 
*P pointer für diesen String mit einem nichtkonstanten ersetzt - aber 
irgendwas lief nicht richtig. Egal.
Für die 103er User und die anderen STMs hier die entsprechenden 
Startadressen der CPU_UNIQUE_ADDRESS bzw. bei Dir DEVICE_ID_ADDRESS
1
// Unique device ID register (96 bits), Base address:
2
//#define DEVICE_ID_ADDRESS  0x1FFFF7E8    // STM32F1
3
#define DEVICE_ID_ADDRESS  0x1FFF7A10    // STM32F4,STM32F2
4
//#define DEVICE_ID_ADDRESS   0x1FFFF7AC    // STM32F0,STM32F3
5
//#define DEVICE_ID_ADDRESS  0x1FF0F420    // STM32F7
6
//#define DEVICE_ID_ADDRESS  0x1FF80050    // STM32L0
7
//#define DEVICE_ID_ADDRESS  0x1FF80050    // STM32L0, L1 Cat.1,Cat.2
8
//#define CPU_UNIQUE_ADDRESS  0x1FF800D0    // STM32L1 Cat.3,Cat.4,Cat.5,Cat.6

von Thomas Z. (usbman)


Lesenswert?

W.S. schrieb:
>> Ich lege allerdings sehr viel Wert auf Kompatibilität zur Spec.
>
> Und hast du selbige da und darfst du sie auch mal posten?
> Originalunterlagen würde ich mir gern mal ansehen.

Na ja die Specs hab ich von der usb.org. Ich nehme mir allerdings die 
Freiheit raus üblicherweise die v1.1 Spec ranzuziehen, wenn ich sowieso 
nur ein FS Device habe.

Die zweite Informationsquelle sind dann noch die Testbeschreibungen die 
mit UsbCv kommen.

Zum testen nehme ich usbio.sys in einer älteren Demo Version. Die 
aktuelle Version (mit W10 Support) ist ja nicht mehr frei verfügbar und 
zu stark eingeschränkt.

Es gibt natürlich auch ein paar Dokumente die nicht öffentlich sind, 
aber wirklich relevantes steht da auch nicht drin. Das sind mehr so 
Hands On Dokumente.

Ich kann aber bestätigen,  das die Dokumente von der usb.org teilweise 
unter aller Sau sind. Typisch halt für Gremien. So haben Sie 
beispielsweise bei der Midi2.0 Spec. einfach vergessen, dass da IAD rein 
muss.

von Stefan ⛄ F. (stefanus)


Lesenswert?

Ich bin überrascht dass W.S. für seinen obigen Einwurf

W.S. schrieb:
> Also Stefan, da knurrt aber der Blindenhund ganz gewaltig!

ein -1 bekommen hat. Ich finde seine Ansicht durchaus legitim, den USB 
Treiber und den Applikations-Layer nicht zu vermischen. Auf der Arbeit 
in meinen Java Projekten trenne ich die Layer schließlich auch streng.

Dennoch mache ich es hier absichtlich anders, weil ich dieses 
Testprojekt einfach halten will. In einer ernsthaften Anwendung wird 
man sich das sowieso passend umschreiben.

Ich habe ihm jetzt ein +1 gegeben, um das auszugleichen :-)

Wie dem auch sei, entweder ist in dem Code mindestens seit 2015 ein Bug 
drin, oder in Linux.

: Bearbeitet durch User
von Thomas Z. (usbman)


Lesenswert?

@Alex
Das ist so ziemlich genau das was ich in usb.c einbauen werde. 
Allerdings möchte sich es konfigurierbar machen. So in der Art off | 
fixed | chipid.
UsbStrings können bis zu 63 Zeichen lang werden. Lediglich die MSC Spec 
schreibt dass Sie genau 12 Zeichen lang sein müssen, wenn das Device 
bootbar sein muss.

von Stefan ⛄ F. (stefanus)


Angehängte Dateien:

Lesenswert?

Irgendwie riecht das stark nach einem Linux Bug. Das Programm usbmon 
erzeugt mir folgende Ausgabe:
1
ffff9ea3abec8000 3590089985 S Bo:1:025:2 -115 1 = 65  "e"
2
ffff9ea3abec8480 3590089988 S Bo:1:025:2 -115 1 = 6c  "l"
3
ffff9ea3abec8600 3590089990 S Bo:1:025:2 -115 1 = 6c  "l"
4
ffff9ea3abec8780 3590089991 S Bo:1:025:2 -115 1 = 6f  "o"
5
ffff9ea3abec8a80 3590089993 S Bo:1:025:2 -115 1 = 20  " "
6
ffff9ea3abec86c0 3590089995 S Bo:1:025:2 -115 1 = 57  "W"
7
ffff9ea340ba0480 3590089996 S Bo:1:025:2 -115 1 = 6f  "o"
8
ffff9ea340ba0c00 3590089998 S Bo:1:025:2 -115 1 = 72  "r"
9
ffff9ea340ba0180 3590090000 S Bo:1:025:2 -115 1 = 6c  "l"
10
ffff9ea340ba03c0 3590090002 S Bo:1:025:2 -115 1 = 64  "d"
11
ffff9ea340ba0300 3590090003 S Bo:1:025:2 -115 1 = 21  "!"
12
ffff9ea340ba0900 3590090006 S Bo:1:025:2 -115 2 = 0d0a

Bo heisst nach meinem Verständnis, dass dies Daten sind, die der PC an 
den µC gesendet hat. Dann kann der µC wohl gar nichts dafür.

Ich bin aber unsicher, ob ich das so korrekt interpretiere, denn ich 
habe dieses Tool noch nie benutzt und von USB eigentlich keine Ahnung.

Kann jemand meine Schlussfolgerung bestätigen oder mich korrigieren?

Ich habe einen etwas längeren Abschnitt angehängt. In dieser Zeit habe 
ich den COM Port dreimal geöffnet:

1) Beim ersten mal trat kein Fehler auf

2) beim zweiten mal habe ich nur ein falsches Zeichen 48 "H" gesehen

3) beim Dritten mal fast die gesamte "Hello World!" Meldung gefolgt von 
einem 0d (CR) dessen Herkunft mir völlig suspekt ist. In meinen 
Quelltexten habe ich nämlich konsequent nur 0a (LF) als Zeilenumbruch 
verwendet.

: Bearbeitet durch User
von Thomas Z. (usbman)


Lesenswert?

Jürgen S. schrieb:
> (die 12 Byte der CPU_UNIQUE_ADDRESS passen einfach zu gut in den
> Descriptorstr, als daß man die Gelegenheit versäumen sollte :)

Du täuschst dich.. der String ist 12*4 + 2 Bytes lang.
24 Digits in Unicode + 2

von Stefan ⛄ F. (stefanus)


Lesenswert?

Ich werde irre, ich habe die Erklärung gefunden: 
https://stackoverflow.com/questions/14866899/linux-cdc-acm-device-unexpected-characters-sent-to-device

Also es ist wohl so, dass der Linux Kernel diese CDC Geräte als serielle 
Konsole behandelt. Auf diesen Konsolen sendet er alle Zeichen als Echo 
zurück, und zwar in dieser charakteristischen Sequenz von Einzel-Bytes.

So ein Scheiß!

Ich habe nicht herausgefunden, wie man dem Kernel sagen kann dass er von 
meinem µC die Finger lassen soll. Aber immerhin kann man dieses echo su 
deaktivieren:
1
sudo stty -F /dev/ttyACM0 -echo

Danach funktioniert auch wieder mein von früher gewohnter cat Befehl zum 
Anzeigen der Ausgaben:
1
cat /dev/ttyACM0

Ich danke für eure Aufmerksamkeit :-)

Thomas, meine Bitte an dich (zu helfen), hat sich damit erledigt.

: Bearbeitet durch User
von Thomas Z. (usbman)


Lesenswert?

Stefan ⛄ F. schrieb:
> So ein Scheiß. Jetzt müsste man das nur irgendwie deaktivieren können
> ...

Willkommen in der Welt der OS unabhängigen USB Devices. Da gibt's sicher 
einen workaround. Ich kann mir nicht vorstellen dass kommerzielle CDC 
Devices auch das Problem haben. Das sollte man mit den Silabs Dingern 
doch gegentesten können.
Die Kunst beim USB Firmware Design ist auch, dass es überall gleich 
funktioniert. Wenn ein Mac im Spiel ist wird das noch viel lustiger.

Ich hab schon Usbfunktionen gebaut, die aufgrund der Requests beim 
Enumerieren erkennen konnten ob das Device am Mac oder unter Win 
arbeitet. Der Grund dafür war das beide OS eine unterschiedliche 
Teilmenge der Spec gut unterstützten. Ich hatte also für jedes OS einen 
eigenen Satz Deskriptoren und Firmware Abschnitte.

von Stefan ⛄ F. (stefanus)


Lesenswert?

Thomas Z. schrieb:
> Das sollte man mit den Silabs Dingern doch gegen testen können.

Ich habe ein ESP8266 Modul mit Silabs CP2102, aber die melden sich nicht 
als /dev/ttyACM* Gerät, sondern als /dev/ttyUSB*

Thomas Z. schrieb:
> Die Kunst beim USB Firmware Design ist auch, dass es überall gleich
> funktioniert.

Du bist lustig, genau deswegen wollte ich CDC benutzen.

: Bearbeitet durch User
von Thomas Z. (usbman)


Lesenswert?

Stefan ⛄ F. schrieb:
> Ich habe ein ESP8266 Modul mit Silabs CP2102, aber die melden sich nicht
> als /dev/ttyACM* Gerät, sondern als /dev/ttyUSB*

Nun das könnte ja schon der Workaround sein.
Poste mal die Deskriptoren...
Win ist es vermutlich egal. Wie ich MS kenne, machen die aus allem einen 
VCP solange da nichts grob falsch ist.

von Stefan ⛄ F. (stefanus)


Lesenswert?

Thomas Z. schrieb:
> Nun das könnte ja schon der Workaround sein.

Sag bloß ich kann theoretisch einfach die Deskriptoren ändern und dann 
wird aus /dev/ttyACM0 ein /dev/ttyUSB0. Sonst ist keine Änderung an dem 
komplexen Quelltext nötig?

: Bearbeitet durch User
von Thomas Z. (usbman)


Lesenswert?


von W.S. (Gast)


Lesenswert?

Jürgen S. schrieb:
> Ohoh, da bin ich ganz anders veranlagt. Ich habe im Gegensatz sogar
> meine 407/429/103-Bibliotheken mit #ifdefs ausgestattet, um ja nicht für
> jeden Chip wieder eine separate Datei zu haben...

Das finde ich schlimm. Schließlich hast du zwar nur eine Datei, dafür 
aber für jede elende Plattform dort drin irgendwelche #ifdef's, die du 
dann jedesmal neu einstellen mußt, entweder durch Editieren der Quelle 
oder durch eine Abhängigkeit von einem Projektfile, einer weiteren .h 
oder einem Makefile.
Wohlgemerkt: die Datei usb.h sollte für alle Plattformen gleich sein, 
damit eben die höheren Schichten problemlos portierbar sind, aber die 
usb.c sollte wirklich auf "ihre" Plattform passen und möglichst 
keinerlei Anpassungen nötig haben. In dieser Hinsicht begrüße ich, daß 
Thomas die Definition der HW-Register in die usb.c transferiert hat, 
damit ist dann auch die Abhängigkeit von einer 'prozessorname'.h 
beseitigt.


> Irgendwann hat man dann wieder
> drölfzig Versionen, von denen die eine die x-Verbesserung hat, aber
> dafür nicht die y-Verbesserung, und vice versa.

Das muß doch nur einmal (und hoffentlich richtig) für eine Plattform 
gemacht sein und fertig ist die Laube, solange es diesen Chip zu kaufen 
gibt.

> Das war also meinerseits keine Kritik, den IRQ-Handler oben wählbar
> auszuführen, sondern eher Kritik an Coocox bzw. eher SPL oder gar CMSIS,
> daß der IRQ-Handler nicht semantisch geprüft wird.

Du meinst wohl nicht den Handler, sondern dessen Namen. Der wiederum ist 
eigentlich überhaupt nicht von einer IDE prüfbar, weil er ja nur genau 
mit dem Namen im Startupcode übereinstimmen muß - und der sollte zwar 
zum RefManual passen, muß das aber nicht. Prinzipiell könnte man den 
USB-Interrupt auch 'Ottokar' nennen, wenn man sich in allen beteiligten 
Quellen daran hält. Aber wie soll eine IDE das alles prüfen? Da sind wir 
wieder bei den Versionen für mehrere Chips, wo es dann eben verschiedene 
Namen gibt. Auch deshalb bin ich gar sehr dafür, so einen Treiber NUR 
für eine einzige Plattform zu machen. Das eliminiert dann auch solche 
Namensprobleme.

W.S.

von Stefan ⛄ F. (stefanus)


Lesenswert?

W.S. schrieb:
> Das muß doch nur einmal (und hoffentlich richtig) für eine Plattform
> gemacht sein und fertig ist die Laube, solange es diesen Chip zu kaufen
> gibt.

Alleine schon an den Beiträgen in diesem Forum siehst du, wie oft die 
usb.c in den vergangenen 5 Jahren aufgrund akuter Fehlfunktionen 
verändert wurde. dazu kommen Verbesserungen die von konkreten Projekten 
getrieben werden, die man sich aber auch für künftige Projekte (auch auf 
anderen µC) konservieren möchte.

Mit "einmal richtig machen" ist es hier (und in vielen anderen 
Projekten) nicht getan.

von W.S. (Gast)


Lesenswert?

Thomas Z. schrieb:
> Win ist es vermutlich egal. Wie ich MS kenne, machen die aus allem einen
> VCP solange da nichts grob falsch ist.

Das ist ja auch völlig korrekt aus meiner Sicht. Immerhin ist sowas ja 
erstmal nichts anderes als ein bidirektionaler serieller Kanal. Also 
sollte der Treiber im OS diesen zwar bereitstellen, damit Applikationen 
darauf zugreifen können, aber nicht mehr.

Da ist es ja doch wohl eher die Aufgabe einer Shell oder einer anderen 
Anwendung, gegebenenfalls anzunehmen, daß dieser Kanal zu einer 
Fern-Konsole führt und dann ggf. die Zeichen als Echo zurückzusenden. So 
einen Kurzschluß im OS-Kernel zu haben, verstehe ich wirklich nicht.

W.S.

von Thomas Z. (usbman)


Lesenswert?

W.S. schrieb:
> In dieser Hinsicht begrüße ich, daß Thomas die Definition der
> HW-Register in die usb.c transferiert hat, damit ist dann auch die
> Abhängigkeit von einer 'prozessorname'.h beseitigt.

Du irrst dich, die Definitionen waren schon drin als ich das angeschaut 
habe. Ich hab da nichts geändert, nur mal mit dem Datenblatt 
gegengecheckt.

Was ich gemacht habe ist EPs mit 0x07 zu maskieren, da es nur 8 EPs 
gibt. Ich bin mir aber nicht sicher ob ich alle Stellen erwischt habe.

von W.S. (Gast)


Lesenswert?

Thomas Z. schrieb:
> Du irrst dich

Macht nix, es ist eine Abhängigkeit weniger und das ist gut.

Andererseits bin ich ziemlich unzufrieden mit sowas wie UsbTxFlush und 
der Aufblähung von UsbCharOut. Mein eigentliches Ziel war und ist es, 
die beiden Ringpuffer als einzige Schnittstelle zwischen der allgemeinen 
Firmware und dem zum USB gehörigen Treiberzeugs zu haben.

Und jetzt wird von dort, also quasi von außen aus massiv dem USB in die 
Gedärme gegriffen. Muß das sein? Bei meinen anderen (älteren) 
Implementationen (LPC, NUC) und auch meiner zugrundeliegenden 
Treiberversion war das nicht nötig, bzw. war mir nichts negatives 
aufgefallen. Da wird alles direkt im Interrupt erledigt, teilweise eben 
durch den Timertick am USB. Für die übrige Firmware sollte es doch 
ausreichend sein, festzustellen, ob es Bytes abzuholen gibt oder ob man 
Bytes senden kann oder nicht. Warten muß man ja auch bei einem realen 
COM-Port, bis die Zeichen im Puffer endlich nach draußen geschaufelt 
sind.

Ich hatte das bei anderen Plattformen so gelöst, daß ich im Timertick 
einfach den Int auf NAK-BulkIn eingeschaltet hatte. Damit gibt es dann 
alsbaldig einen Int, sobald der Host die SIE vergeblich nach Daten 
abfragt und dieser Int konnte dann feststellen, ob etwas im Ringpuffer 
steht. Und wenn ja, wurde ein Paket fertiggemacht und aktiviert und 
voila, der Datenfluß war wieder angelaufen - alles ohne Eingriffe von 
außen.

Im EpBulkIn-Handler hatte ich da jeweils den Int auf NAK-BulkIn wieder 
ausgeschaltet, damit der µC nicht alle paar µS einen Interupt abkriegt. 
Bloß bei dem Core in dem STM32 habe ich eine derartige Möglichkeit zur 
Kommunikation mit der SIE nicht gefunden. Vielleicht hast du ja eine 
Idee, wie man das hier sauber wieder hinkriegt, dann wäre das ganze 
Gehampel mit Int verbieten und von außen dem Treiber in die Gedärme zu 
greifen überflüssig.

W.S.

von Stefan ⛄ F. (stefanus)


Lesenswert?

W.S. schrieb:
> Andererseits bin ich ziemlich unzufrieden mit sowas wie UsbTxFlush und
> der Aufblähung von UsbCharOut. Mein eigentliches Ziel war und ist es,
> die beiden Ringpuffer als einzige Schnittstelle zwischen der allgemeinen
> Firmware und dem zum USB gehörigen Treiberzeugs zu haben.

Du meinst wohl die (inzwischen umbenannte) Funktion:
1
// Send a character to the host (via send buffer).
2
// Returns false if the buffer is full.
3
bool UsbSendChar_noWait(char c)
4
{
5
    // check space
6
    int i = (txw + 1) & (USB_TXLEN - 1);
7
    if (i == txr)
8
    {
9
        return false;
10
    }
11
12
    // write into the buffer
13
    UsbTxBuf[txw] = c;
14
    txw = i;
15
16
    // Comment in the following condition to delay sending until the buffer is full
17
    // Then you may call UsbTxFlush() to trigger sending
18
19
    // if (((txw + 1) & (txLen - 1)) == txr)
20
    {
21
        // trigger sending
22
        if (!transmitting)
23
        {
24
            DisableUsbIRQ();
25
            EpBulkBeginTransmit();
26
            EnableUsbIRQ();
27
        }
28
    }
29
    return true;
30
}

Was ist denn da aufgebläht? Der Aufruf von EpBulkBeginTransmit() wurde 
vor einem Jahr (Beitrag "USB CDC von Stefan Frings und WS") 
hinzugefügt, weil die ganze Übertragung unter gewissen Bedingungen 
stecken bleibt.

Ich denke, dass deine Idee "die beiden Ringpuffer als einzige 
Schnittstelle" schlicht nicht funktioniert hatte.

Entweder braucht es oben den Aufruf von EpBulkBeginTransmit(), oder eben 
als separate Funktion:
1
// Trigger sending the remaining characters from the 
2
// send buffer (asynchronously, not blocking)
3
void UsbTxFlush (void)
4
{
5
    if (!transmitting)
6
    {
7
        DisableUsbIRQ();
8
        EpBulkBeginTransmit();
9
        EnableUsbIRQ();
10
    }
11
}

Wie sonst willst du dafür sorgen, dass das Senden zuverlässig getriggert 
wird?

> Ich hatte das bei anderen Plattformen so gelöst, daß ich im Timertick
> einfach den Int auf NAK-BulkIn eingeschaltet hatte.

Im oben verlinkten Thread hat Niklas begründet, warum er es anders 
gelöst hat. Ist das jetzt so schlimm? Auch andere Stream basierte 
Schnittstellen haben mehr als nur die Puffer zwischen Anwendung und 
Treiber. Daran ist nichts überraschendes.

Das eigentliche Problem ist doch vermutlich eher, dass diese Änderung 
von Niklas stammt und ihr beiden euch zerstritten habt. Immerhin 
funktioniert seine Anpassung, ist das nicht wichtiger?

: Bearbeitet durch User
von Stefan ⛄ F. (stefanus)


Lesenswert?

an W.S:
Ich möchte nochmal klarstellen, dass ich und viele andere hier für 
deinen Code sehr dankbar sind. Dank deiner Arbeit muss ich nicht diese 
scheiß HAL verwenden.

Nur sei doch bitte nicht angepisst, dass Leute deinen Code weiter 
entwickeln, so wie es ihnen beliebt. So ist das halt bei Open-Source. 
Dadurch geht dein Werk weder kaputt noch wird es herab gewürdigt. Ganz 
im Gegenteil, das ist ein Ausdruck der Wertschätzung. Meinst du ich 
hätte freiwillig die vergangenen drei Tage durchgehend daran gearbeitet, 
wenn er nicht entsprechend wertvoll wäre? Ganz sicher nicht.

Auch Niklas hat sich vor einem Jahr tagelang damit befasst, obwohl er es 
gar nicht nötig gehabt hätte (er hat ja seine eigene Implementierung). 
Auch Niklas hat dir damit großen Respekt gezollt.

Nicht zu vergessen Thomas, der sich offenbar auch mit deinem Werk 
beschäftigt. Er würde das nicht tun, wenn dein Code schlecht wäre.

Wir sind halt nur nicht in allen Punkten der gleichen Meinung. Aber wir 
sind dir dankbar. Lass uns bitte Freiheit darauf aufzubauen und es für 
uns selbst nach unserem Geschmack zu ändern. Deine Veröffentlichung 
(Beitrag "Re: STM32F4 USB CDC") betrifft das 
nicht.

: Bearbeitet durch User
von Thomas Z. (usbman)


Lesenswert?

W.S. schrieb:
> Vielleicht hast du ja eine
> Idee, wie man das hier sauber wieder hinkriegt

Mir ist bekannt, dass es cores gibt die einen Interrupt auf NAK bieten, 
z.B. FX2 Das ist vielleicht interessant zu Debugzwecken sonst fällt mir 
dazu nichts ein.
NAK steht ja nunmal dafür Ich hab nichts, musst du später noch mal 
probieren. Das weiß die FW aber auch so. Simulieren könntest du sowas 
indem ein Flag generiert wird was epnum,dir und ctr auswertet im 
InterruptStatusReg auswertet.

Angenommen machst sowas auf dem InEp:
ArmEp(EpNo, nBytes); dann weißt du wenn im FlagReg CTR für diesen EP 
gesetzt ist dass der Code nun NAKs schickt bis ein neues ArmEp kommt.

von Jürgen S. (avus)


Lesenswert?

W.S. schrieb:
> Das finde ich schlimm. Schließlich hast du zwar nur eine Datei, dafür
> aber für jede elende Plattform dort drin irgendwelche #ifdef's, die du
> dann jedesmal neu einstellen mußt, entweder durch Editieren der Quelle
> oder durch eine Abhängigkeit von einem Projektfile, einer weiteren .h
> oder einem Makefile.
Es wird schon einen guten Grund haben, wenn Du das so handhabst, wie Du 
es machst. Denn gute Treiber zeichnen sich dadurch aus, daß man sie nur 
noch wenig anfassen muß, weil sie eben ausgereift sind. Da ist schon was 
dran.
Zudem haben die #ifdef-Konstruktionen bei größeren Projekten neben der 
schlechteren Lesbarkeit den Nachteil, daß die Objektfiles nur für die 
ausgewählten Definitionen gelten, man also bei anderer Konstellation 
alles neu compilieren muß. Bei kleinen Hobbybastler-Sachen fällt das 
aber nicht ins Gewicht.
> Wohlgemerkt: die Datei usb.h sollte für alle Plattformen gleich sein,
> damit eben die höheren Schichten problemlos portierbar sind, aber die
> usb.c sollte wirklich auf "ihre" Plattform passen und möglichst
> keinerlei Anpassungen nötig haben. In dieser Hinsicht begrüße ich, daß
> Thomas die Definition der HW-Register in die usb.c transferiert hat,
> damit ist dann auch die Abhängigkeit von einer 'prozessorname'.h
> beseitigt.
Ich denke da nochmal drüber nach, wenn ich die Deine bzw. inzwischen 
eure usb.h und usb.c für den STM32F4 einge-#ifdef-t habe :). Meine Tests 
auf dem F4 stehen noch aus.
> Das muß doch nur einmal (und hoffentlich richtig) für eine Plattform
> gemacht sein und fertig ist die Laube, solange es diesen Chip zu kaufen
> gibt.
Das wäre der Idealfall. Man hat das knowhow, entsprechende 
Testmöglichkeiten, konstruiert eine gute Software und legt sie als 
'erledigt' ab. Bei den Nichtprofis wie mir gab es in den ersten Jahren 
immer wieder etwas zu ändern, teils durch Wissenszuwachs, teils, weil 
sich andere Ansätze als erfolgversprechender herausstellten, teils, weil 
beim Ändern einer Datei eine andere auch geändert werden muß.
> Du meinst wohl nicht den Handler, sondern dessen Namen. Der wiederum ist
> eigentlich überhaupt nicht von einer IDE prüfbar, weil er ja nur genau
> mit dem Namen im Startupcode übereinstimmen muß - und der sollte zwar
> zum RefManual passen, muß das aber nicht.
Das mit den IRQ-Handlernamen ist nicht einfach, wenn es ganz sicher sein 
soll, ja. Die billigste, aber für oberflächliche Fehlervermeidung 
ausreichende Variante wäre, nicht angesprungene Prozeduren als #warning 
auszugeben. So würden falsch benamte IRQ-Handler auffliegen.
Als weitere Sicherheit und Minimalkonvention könnte man IRQ-Handlernamen 
noch abverlangen, daß sie "isrvect_" oder sowas fest im Namen haben 
müssen. So daß man gleich weiß, daß es ein IRQ-Handler sein sollte, der 
da ungenutzt rumbaumelt.
Advanced wäre es, wenn der Compiler/Linker anhand der CPU-Register 
erkennt, daß ein Interrupt gesetzt ist, und untersucht, ob der 
Einsprungpunkt bzw. die Adresse, auf die der Interruptvektor zeigt, als 
Prozedur definiert ist. Aber was ist wahrscheinlich zu utopisch/komplex.

Edit:
Stefan ⛄ F. schrieb:
> Aber wir sind dir dankbar.
Definitiv. Nur zwei Dateien, plattformunabhängig, kompakt, und stabiler 
als andere Versionen, die ich probiert habe. Das ist schon sehr gut.

: Bearbeitet durch User
von Stefan ⛄ F. (stefanus)


Lesenswert?

Ich möchte darauf hinweisen, dass die usb.c auf meiner Homepage keine 
#ifdef enthält.

Da gibt es nur 4 Plattform spezifische Zeilen. Die habe ich ganz bewusst 
ganz nach oben platziert, damit man bei der spezifischen Anpassung 
nichts falsch macht:
1
// For devices with 2x16 bits/word access schema 
2
// (e.g. STM32L0x2, STM32L0x3, STM32F0x2, STM32F303xD and xE)
3
#define UMEM_SHIFT 0
4
#define UMEM_FAKEWIDTH uint16_t
5
6
// For devices with 1x16 bits/word access schema 
7
// (e.g. STM32F103, STM32F302, STM32F303xB and xC)
8
// #define UMEM_SHIFT 1
9
// #define UMEM_FAKEWIDTH uint32_t
10
11
// The name of the IRQ handler must match startup_stm32.s 
12
#define NAME_OF_USB_IRQ_HANDLER USB_IRQHandler
13
14
// Take the number from the reference manual of your µC. 
15
#define USB_IRQ_NUMBER 31

Tatsächlich habe ich diese Datei 4 mal auf meiner Festplatte in 
Plattform-Spezifischen Verzeichnissen. Für mich hat es sich als sehr 
praktisch heraus gestellt, dass alles unterhalb dieser #defines in allen 
4 Dateien identisch ist. So kann ich Korrekturen einfach herüber 
kopieren.

: Bearbeitet durch User
von W.S. (Gast)


Lesenswert?

Thomas Z. schrieb:
> NAK steht ja nunmal dafür Ich hab nichts, musst du später noch mal
> probieren. Das weiß die FW aber auch so.

Ähem... das ist so ein Problem: Wenn in Richtung µC-->PC mal eine Weile 
keine Daten vorhanden sind und nach dem letzten ACK der SIE an den Host, 
also wenn die letzten vorhandenen Daten gesendet worden sind, nix mehr 
zu senden da ist, dann kann man auch kein weiteres Paket fertig machen 
und muß den Interrupt unverrichteterdinge beenden.

Und genau DA passiert es nämlich, daß ab da die SIE dem Host nur noch 
NAK sagt, es aber keinen Interrupt mehr gibt. Wer also soll dann später, 
wenn wieder Daten im Ringpuffer aufgelaufen sind, sich darum kümmern? 
Ohne Interrupt auch keine Routine im Treiber. Das ist das Problem.

Ich hatte das so geregelt, daß sich eben der Timertick so alle 
Millisekunde mal drum kümmern soll, Niklas hingegen hat das nicht 
verstehen/akzeptieren wollen und stattdessen sich sowas wir diese Flush 
aus dem Grundprogramm heraus ausgedacht.

Natürlich ist sonnenklar, daß es irgendwen geben muß, der sich drum 
kümmert. Das eleganteste ist da natürlich, immer mal den 
NAK-BI-Interrupt einzuschalten, dann kümmert sich nämlich die SIE quasi 
darum. Dann regelt das der Treiber von selbst und das Grundprogramm muß 
sich nicht drum kümmern. Und so soll es eigentlich sein: Der Treiber 
soll die höheren Schichten nicht mit seinen internen Befindlichkeiten 
belästigen.

Alternativ kann man natürlich irgendwo im Treiber ein Flag haben, so wie 
das jetzt von euch gehandhabt wird. Aber bei so einem Flag ist wieder 
die Frage, wer es denn anschauen soll. Der UsbCharOut ist dafür kein 
guter Kandidat, denn er kriegt ja nur einzelne Zeichen ab und würde 
entweder bei jedem Zeichen den Transfer anstoßen müssen, also immerzu 
nur Pakete der Länge 1 machen oder er würde sammeln müssen, aber bis 
wohin? Der Treiber weiß ja niemals, ob das aktuelle Zeichen jetzt nun 
definitiv das Letzte ist für eine Weile.

Ich hatte mir das vor Jahren schon einmal alles überlegt und kam zu dem 
Ergebnis, daß es wohl das erträglichste ist, wenn der CharOut einfach 
nur den Ringpuffer vollstopft und ansonsten wartet - und spätestens nach 
einer Millisekunde der Timertick im Treiber sich um das Starten der 
Übertragung kümmert.

Eine Millisekunde an Verzögerung ist für einen virtellen COM-Port m.E. 
durchaus akzeptabel, immerhin geht dann ja ein Block von 255 Bytes auf 
die Reise und wenn die Firmware noch mehr Bytes hat und den Ringpuffer 
zwischendurch schnell genug wieder nachfüllt, dann geht es ab da ja 
ratzfatz, bis mal wieder eine ausreichend große Lücke kommt und die SIE 
anfängt NAK zu sagen und später aus diesem Zustand wieder herausgeholt 
werden muß.

Und noch ein Wort an Stefan: Natürlich kann das ein jeder machen wie er 
will. Ich habe dazu allerdings eine Meinung und mit der will ich nicht 
hinterm Berg halten, schließlich hatte ich mir dazu Gedanken gemacht. 
Ich möchte allerdings auch nicht ohne sachliche Argumente einfach nur so 
angeblafft werden, wie Niklas das getan hat. Verstehe das mal.

W.S.

von Alex (Gast)


Lesenswert?

Jetzt dreh ich langsam durch...

Wenn ich Stefans Hello World (usb.c. vom 27.2. um 19:05) mit Echo bei 
mir aus dem Debugger laufen lasse, dann klappt es.
Als Release compiliert und aus dem Flash kommt kein Echo.

Als Debug compiliert läuft es auch mit Echo, wenn ich es aus dem Flash 
boote.
Anpassung lediglich an meinen Chip, mit TCXO.
USB läuft, Hello World kommt immer.


Unterschied in den Einstellungen: (jeweils zuerst die debug-cfg)

GCC Assembler:

-mcpu=cortex-m0 -g3 -c -x assembler-with-cpp --specs=nano.specs 
-mfloat-abi=soft -mthumb

-mcpu=cortex-m0 -c -x assembler-with-cpp --specs=nano.specs 
-mfloat-abi=soft -mthumb

GCC Compiler:

-mcpu=cortex-m0 -std=gnu11 -g3 -DUSE_HAL_DRIVER -DSTM32F042x6 -DDEBUG -c 
-I../Core/Inc -I../Drivers/STM32F0xx_HAL_Driver/Inc 
-I../Drivers/STM32F0xx_HAL_Driver/Inc/Legacy 
-I../Drivers/CMSIS/Device/ST/STM32F0xx/Include 
-I../Drivers/CMSIS/Include -O0 -ffunction-sections -fdata-sections -Wall 
-fstack-usage --specs=nano.specs -mfloat-abi=soft -mthumb

-mcpu=cortex-m0 -std=gnu11 -DUSE_HAL_DRIVER -DSTM32F042x6 -c 
-I../Core/Inc -I../Drivers/STM32F0xx_HAL_Driver/Inc 
-I../Drivers/STM32F0xx_HAL_Driver/Inc/Legacy 
-I../Drivers/CMSIS/Device/ST/STM32F0xx/Include 
-I../Drivers/CMSIS/Include -Os -ffunction-sections -fdata-sections -Wall 
-fstack-usage --specs=nano.specs -mfloat-abi=soft -mthumb

GCC Linker:

-mcpu=cortex-m0 
-T"C:\Users\Alex\STM32CubeIDE\workspace_1.4.0\SFusbTest2\STM32F042F6PX_F 
LASH.ld"  --specs=nosys.specs -Wl,-Map="${ProjName}.map" 
-Wl,--gc-sections -static --specs=nano.specs -mfloat-abi=soft -mthumb 
-Wl,--start-group -lc -lm -Wl,--end-group

-mcpu=cortex-m0 
-T"C:\Users\Alex\STM32CubeIDE\workspace_1.4.0\SFusbTest2\STM32F042F6PX_F 
LASH.ld"  --specs=nosys.specs -Wl,-Map="${ProjName}.map" 
-Wl,--gc-sections -static --specs=nano.specs -mfloat-abi=soft -mthumb 
-Wl,--start-group -lc -lm -Wl,--end-group

Wenn ich in der Debug-CFG die Optimierungen (-Os) einschalte und die 
debuglevel (-g3) ausschalte hat das keinen Effekt.

Ich steh völlig auf der Leitung.
Was zum Kuckuck hab ich da noch übersehen?

von Stefan ⛄ F. (stefanus)


Lesenswert?

Könnte es sein dass du im Release Modus das falsche Binary in den Flash 
überträgst?
Gucke dir mal die Debug Configurations (beim grünen Käfer) an.

: Bearbeitet durch User
von Alex (Gast)


Lesenswert?

Wenn ich das .bin vom release in den Flash schreibe und von dort starte, 
dann kommt das Echo nicht.
Wenn ich mit dem Debugger das .elf vom selben compile-Vorgang laufen 
lasse, dann hab ich das Echo.

Im Debugger gehen also beide Versionen, aus dem Flash nur die als Debug 
compilierte-Version (das .elf).

Kapieren tu ich das noch nicht.

von Stefan ⛄ F. (stefanus)


Lesenswert?

Schau mal im Dateimanager auf das Datum der Dateien. Haben beide Dateien 
das aktuelle  Datum/Zeit?

von Alex (Gast)


Lesenswert?

Ja, die passen definitiv zusammen.

von Alex (Gast)


Lesenswert?

Hab grad mit dem CubeProgrammer das ELF in den Flash geschrieben, kein 
Echo.
Das SELBE ELF im Debugger gibt ein Echo.

von Stefan ⛄ F. (stefanus)


Lesenswert?

Dem Cube Programmer traue ich schon lange nicht mehr. Bei mit zickt er 
immer wieder herum (nicht nur wegen der Java Version). Versuche mal zum 
Vergleich das alte ST-Link Utility.

> Das SELBE ELF im Debugger gibt ein Echo.

Ich erinnere mich an ein Problem das ich mit der System Workbench hatte. 
Da lief eins meiner Programme mit falscher Taktfrequenz bei diese beim 
Flashen und die Taktfrequenz auf 64 MHz via HSI änderte und mein eigener 
Code danach nicht mehr imstande war, die von mit gewünschte 
Takteinstellung vorzunehmen. Da war die Lösung, dass ich zunächst die 
PLL abschalten musste, bevor ich sie um-konfiguriere.

Das ist jetzt nicht direkt dein Problem, aber könnte in eine ähnliche 
Richtung gehen. Da dein Programm im Debugger läuft, wäre jetzt mal 
interessant, ob es danach auch noch läuft, wenn du den µC Stromlos 
machst und neu startest.

: Bearbeitet durch User
von Alex (Gast)


Lesenswert?

Irgendwelche Takt-Zeug hab ich ausgeschlossen, da aber das Hello World 
brav kommt.

> Da dein Programm im Debugger läuft, wäre jetzt mal interessant, ob es
> danach auch noch läuft, wenn du den µC Stromlos machst und neu startest.

Schreibt der Debugger das Programm in den Flash?
Da hab ich noch garnicht drüber nachgedacht. Musste er ja eigentlich, 
vor allem wenn ich das SELBE elf auch flashen kann, muss es so sein.

Hab das grad versucht, und es schein so, als ob es garnichts damit zu 
tun hat, ob Debugger oder nicht. Mal gehts, mal nicht, aber eher nicht.
Bin grad immer am selben elf-file, und sehe grad kein Muster...
Die Tests gestern Abend hab ich 3mal wiederholt und es war konsistent.
Jetzt grad ist nichts konsistent.
Ich probiers später mal mit einer 'guten' Hardware, vielleicht hat der 
Chip ja wirklich einen an der Waffel (immerhin tapse ich da jetzt schon 
wochenlang dran rum, und die Luft ist zu der Jahreszeit eher etwas 
trocken...)
Bringt ja nix, Geister zu jagen.

von Stefan ⛄ F. (stefanus)


Lesenswert?

Alex schrieb:
> Irgendwelche Takt-Zeug hab ich ausgeschlossen, da aber das Hello World
> brav kommt.

Ach ja, stimmt.

> Schreibt der Debugger das Programm in den Flash?

Normalerweise schon. Jedenfalls bei den Mikrocontrollern, die ich 
verwende (F1, F3, L0).

> Mal gehts, mal nicht, aber eher nicht, sehe grad kein Muster...

Das ist bitter. Suche weiter!

Könnte es an der Verkabelung liegen?

von temp (Gast)


Lesenswert?

Alex schrieb:
> Wenn ich das .bin vom release in den Flash schreibe und von dort starte,
> dann kommt das Echo nicht.

Das kann doch nicht alles sein was du zur Fehlersuche beitragen kannst? 
Klappt die USB-Enumeration überhaupt noch oder geht das auch schon nicht 
mehr.

Wenn du komplett im Dunkeln tappst, kannst du ja mal nur bestimmte 
Dateien mit -O(x) übersetzen und den Rest mit -O0.
Und wenn das nicht hilft, kannst du immer noch bestimmte Teile gezielt 
mit #pragmas optimierenm oder auch nicht.

von Stefan ⛄ F. (stefanus)


Lesenswert?

Das rudimentäre Beispielprogramm müsste völlig unabhängig von diesen 
Compiler/Linker Einstellungen sein.

von temp (Gast)


Lesenswert?

W.S. schrieb:
> Ich hatte mir das vor Jahren schon einmal alles überlegt und kam zu dem
> Ergebnis, daß es wohl das erträglichste ist, wenn der CharOut einfach
> nur den Ringpuffer vollstopft und ansonsten wartet - und spätestens nach
> einer Millisekunde der Timertick im Treiber sich um das Starten der
> Übertragung kümmert.
>
> Eine Millisekunde an Verzögerung ist für einen virtellen COM-Port m.E.
> durchaus akzeptabel, immerhin geht dann ja ein Block von 255 Bytes auf
> die Reise und wenn die Firmware noch mehr Bytes hat und den Ringpuffer
> zwischendurch schnell genug wieder nachfüllt, dann geht es ab da ja
> ratzfatz, bis mal wieder eine ausreichend große Lücke kommt und die SIE
> anfängt NAK zu sagen und später aus diesem Zustand wieder herausgeholt
> werden muß.
>

Deine Überlegungen verstehe ich durchaus.

> Und noch ein Wort an Stefan: Natürlich kann das ein jeder machen wie er
> will. Ich habe dazu allerdings eine Meinung und mit der will ich nicht
> hinterm Berg halten, schließlich hatte ich mir dazu Gedanken gemacht.
> Ich möchte allerdings auch nicht ohne sachliche Argumente einfach nur so
> angeblafft werden, wie Niklas das getan hat. Verstehe das mal.

Und diese ganz besonders.

Aber zum Thema, mir gefällt auch absolut nicht, daß das OnEpBulkIn(); 
aus dem Usercode gerufen wird. Auf der anderen Seite möchte ich aber die 
1ms Interrupts nicht haben. Ich hab mir jetzt so geholfen.
1
// 1. SOF und ESOF Interrupt disabled. 
2
void InitEndpoints(void)
3
{
4
  ....
5
  USB_CNTR =
6
        CTRM |             /* Int bei ACKed Paketen in oder out */
7
        RESETM |           /* Int bei Reset */
8
        SUSPM | WKUPM 
9
       // | ESOFM | SOFM;       /* Int bei 1 ms Frame */
10
       ;  
11
}     
12
13
// 2. TxFlush
14
// bei TxFlush wird nur der SOF-Interrupt enabled
15
void UsbTxFlush(void) 
16
{