Forum: Mikrocontroller und Digitale Elektronik STM32F103 USB CDC von W.S.


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 Thorsten S. (thorstens)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Referenz-Thread: Beitrag "USB CDC von Stefan Frings und WS"

ich bekomme den Code nicht ans Laufen. Ich verwende die aktuellste 
Version 1.4.2 der STM32 Cube IDE und habe das Projekt dort (als Ac6 
Toolchain) importiert. Das ging fehlerfrei und es kompiliert auch 
fehlerfrei. Aber wenn ich mein Blue Pill Board an USB stecke, wird es 
von Windows als "Anderes Gerät" identifiziert und es kann kein Treiber 
gefunden werden. VID und PID stimmen, also es werden Daten übertragen. 
Wenn ich HAL CDC verwende, läuft es problemlos, also liegt kein 
technischer Defekt vor.

Woanders hier im Forum (Beitrag "STM32F103-USB-CDC von W.S.") 
entdeckte jemand, dass neuere Compiler die Nop() Funktion wegoptimieren, 
was mit Abschaltung der Optimierung via "void 
__attribute__((optimize("O0"))) Nop(uint32_t count)" gelöst werden kann. 
Aber auch das hat nicht geholfen.

Hat jemand eine Idee, woran es liegen könnte, oder wie ich mich der 
Ursache des Problems nähern kann?

Grüße
Thorsten

von Stefan ⛄ F. (stefanus)


Bewertung
1 lesenswert
nicht lesenswert
Ich habe es gerade für dich mit der STM32 Cube IDE 1.4.0 und 1.4.2 unter 
Linux ausprobiert - läuft.

Dann habe ich Windows gebootet, auch da wird das Board erkannt und ich 
sehe die "Hello World!" Meldungen im Hammer Terminal.

Download: http://stefanfrings.de/stm32/STM32F103_usb_test.zip

Hast du den Widerstand R10 korrigiert? Er soll 1,5kΩ haben. Ich habe zur 
Korrektur 1,8kΩ parallel zum falschen Bauteil geschaltet.

Zur Zeit sind viele (alle?) Blue-Pill Boards mit gefälschten Chips 
bestückt. Hier im Forum hatte mal jemand ein Testprogramm 
veröffentlicht, mit dem man schlechte Fälschungen erkennen kann.

von Niklas G. (erlkoenig) Benutzerseite


Bewertung
3 lesenswert
nicht lesenswert
Thorsten S. schrieb:
> ich bekomme den Code nicht ans Laufen.

Welchen? Hast du die Fehler-korrigierte Version probiert?

https://github.com/Erlkoenig90/WSusb

Du könntest das Board an einen Linux-PC anschließen, Linux gibt im 
Kernel-Log deutlich bessere Fehlermeldungen aus wenn ein USB-Gerät nicht 
das tut was Linux erwartet.

von Thorsten S. (thorstens)


Bewertung
0 lesenswert
nicht lesenswert
@ Stefan: Ich habe einen 2K Widerstand nach 3.3V gelegt, daran liegt es 
nicht. Kannst du mir eventuell dein vollständiges CubeIDE Projekt per 
e-Mail senden? Hatte dir gestern eine e-Mail geschrieben (an die e-Mail 
Adresse von deiner Homepage).

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Thorsten S. schrieb:
> Kannst du mir eventuell dein vollständiges CubeIDE Projekt per
> e-Mail senden?

Ich habe es doch oben verlinkt!

von Thorsten S. (thorstens)


Bewertung
0 lesenswert
nicht lesenswert
Das habe ich auch verwendet. Musste ich aber in die Cube IDE 
importieren. Ich meinte das fertig importierte Projekt. Vielleicht ist 
beim Import etwas schiefgelaufen.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Beim Import kann gar nichts schief laufen. Wie gesagt habe ich es gerade 
noch ausprobiert.

: Bearbeitet durch User
von Mw E. (Firma: fritzler-avr.de) (fritzler)


Bewertung
0 lesenswert
nicht lesenswert
Niklas G. schrieb:
> Du könntest das Board an einen Linux-PC anschließen, Linux gibt im
> Kernel-Log deutlich bessere Fehlermeldungen aus wenn ein USB-Gerät nicht
> das tut was Linux erwartet.

Unter Windoof gibts das hier:
https://www.uwe-sieber.de/usbtreeview.html
Hat mir bei vielen USB Dingen auch schon gut weitergeholfen.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Thorsten S. schrieb:
> Wenn ich HAL CDC verwende, läuft es problemlos, also liegt kein
> technischer Defekt vor.

Stimmt, dann können wir falsche Widerstände und schlecht gefälschten 
Chip ausschließen.

von Thorsten S. (thorstens)


Bewertung
0 lesenswert
nicht lesenswert
USB-Treeview ist ein interessantes Tool. Bevor ich hier den ganzen 
Output poste, fällt mir diese Fehlermeldung auf:

String descriptors are not available  (because the device has problem 
code CM_PROB_FAILED_INSTALL)

Eine Idee dazu?

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Thorsten S. schrieb:
> Eine Idee dazu?

Laut Microsoft Knowledgebase bedeutet das, dass der Treiber nicht 
geladen wurde. Nicht sehr hilfreich.

von Thorsten S. (thorstens)


Bewertung
0 lesenswert
nicht lesenswert
Es ist verrückt. Wenn die Hardware läuft, kann es ja nur ein Problem mit 
der Softwareseite sein. Da die Software aber prinzipiell funktioniert, 
muss es irgendeine Compiler-Option oder sowas sein. Vielleicht ging beim 
Import des Projekts doch etwas schief.

@Stefan: Können wir die Größen der Ausgabedatei im Release-Build 
vergleichen?

text     data     bss     dec     hex   filename
3884       12    1636     5532   159c   STM32F103_usb_test.elf

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Thorsten S. schrieb:
> Können wir die Größen der Ausgabedatei im Release-Build
> vergleichen?

> text     data     bss     dec     hex   filename
> 3884       12    1636     5532   159c   STM32F103_usb_test.elf

Interessant, ich habe etwas andere Zahlen:

   text     data      bss      dec      hex  filename
   3856       12     1636     5504     1580  STM32F103_usb_test.elf

Aber ob das jetzt irgend etwas zu bedeuten hat, und wenn ja, was ...?

Ich habe dir mein Projekt inzwischen samt Binaries per mail geschickt.

> Da die Software aber prinzipiell funktioniert,
> muss es irgendeine Compiler-Option oder sowas sein.

Ich habe nichts verändert.

Die Assembler Optionen sind: -mcpu=cortex-m3 -c -x assembler-with-cpp 
--specs=nano.specs -mfloat-abi=soft -mthumb

Die Compiler Optionen sind: -mcpu=cortex-m3 -std=gnu11 -DSTM32 -DSTM32F1 
-DSTM32F103C8Tx -c 
-I"/home/stefan/Programmierung/STM32/STM32F103_usb_test/CMSIS/core" 
-I"/home/stefan/Programmierung/STM32/STM32F103_usb_test

Die Linker Optionen sind: -mcpu=cortex-m3 
-T"/home/stefan/Programmierung/STM32/STM32F103_usb_test/LinkerScript.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

: Bearbeitet durch User
von Thorsten S. (thorstens)


Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank für eure Unterstützung!

Ich werde dein Projekt heute Abend ausprobieren und berichte dann. 
(Übrigens waren beide deiner Mails im Spam, habe deine erste Antwort 
erst gerade gelesen.)

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Thorsten S. schrieb:
> Übrigens waren beide deiner Mails im Spam

Und? Was kann ich dafür?

Besorge dir lieber einen ordentlichen SPAM Filter, oder stelle ihn ab.

von Thorsten S. (thorstens)


Bewertung
0 lesenswert
nicht lesenswert
Stefan ⛄ F. schrieb:
> Und? Was kann ich dafür?

Das war nicht als Angriff oder Kritik gemeint, sondern als Information, 
warum ich auf deine erste Mail gar nichts erwidert hatte.

Danke nochmal für eure Unterstützung.

von W.S. (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Thorsten S. schrieb:
> Aber wenn ich mein Blue Pill Board an USB stecke, wird es
> von Windows als "Anderes Gerät" identifiziert und es kann kein Treiber
> gefunden werden. VID und PID stimmen, also es werden Daten übertragen.

Also welche vid+pid wird denn auf dem PC angezeigt? Wenn es die von 
Nuvoton ist, dann wundert es mich nicht, daß das Ding als 'anderes 
Gerät' angezeigt wird.

Nochwas zu dem ewigen Thema Warteschleife bei GCC-Benutzern: Die dient 
wirklich nur dazu, daß ein paar µs vergehen, so daß der Host das 
ACK-Paket noch auf der Adresse 0 abholen kann, bevor man die gegebene 
Adresse per USB_SetAddress setzt. Im Prinzip müßte es auch ausreichen, 
nachzuschauen, ob im zugehörigen EP Register STAT_TX noch gesetzt ist. 
Wenn nicht, dann ist das (leere) ACK-Paket über die Bühne und man kann 
problemlos die Adresse setzen. Wenn ich mal Zeit dafür haben sollte, 
teste ich das mal aus. Also so etwa maximal 20x nachschauen, ob STAT_TX 
noch 3 ist.

Ich füg dir mal einen Auszug aus meinem damaligen Projekt bei (was ich 
schon früher hier mal gepostet hatte): das ist die fertig übersetzte 
Firmware für einen STM32F103C8T6, die sich am USB als Nuvoton-Gerät 
meldet. Flashe die doch probehalber mal drauf, denn ich weiß, daß die 
bei mir so wie sie ist auch funktioniert. Und lade dir mal USBTREEVIEW 
herunter und schau damit mal, ob mit meiner Firmware die Strings 
einigermaßen vernünftig am PC aussehen. Mir kommt da nämlich der 
Verdacht hoch, daß etwas mit den EP-Puffern bei dir nicht stimmt. Die 
alten STM32F103C8T6 haben nämlich eine ausgesprochen eigenartige Art, 
wie man auf den Puffer zugreifen darf und wie nicht. Ich hatte das in 
der Quelle vermerkt, siehe:
1
/* Layout des USB RAM's (512 Bytes)
2
   ================================
3
Der RAM geht aus Sicht der CPU von 0x40006000 bis 0x400063FF,
4
also 0x400 Bytes gleich 1024 Bytes und das Layout ist krötig,
5
weil die Hälfte nicht implementiert ist und zu 0 gelesen wird!
6
Er ist NUR 16 bitweise les- und schreibbar! NICHT byteweise
7
und auch nicht wirklich 32 bitweise.
8
Beispiel:
9
Text sei "Hello-World"
10
0x40006000: 48 65 00 00 6C 6C 00 00 6F 2D 00 00 57 6F 00 00 72 6C 00 00 64 ...
11
             H  e        l  l        o  -        W  o        r  l        d ...

Und Stefan hat bemerkt, daß es bei anderen STM32 mit fast identischem 
USB_Core nicht mehr so eigenartig ist. Könnte ja sein, daß der Chip auf 
deinem Board das auch anders handhabt - ist ne Vermutung meinerseits.

W.S.

von Thorsten S. (thorstens)


Bewertung
0 lesenswert
nicht lesenswert
@W.S.: Wenn ich die Blue Pill mit deiner Firmware einstecke, wird das 
Gerät gar nicht mehr erkannt. Inzwischen habe ich aber mehr meinen PC 
oder das USB-Kabel im Verdacht und werde da morgen weiter forschen.

Die VID/PID von Stefans Treiber sind 0x0416 / 0x5011. (lt. Kommentar 
Realtek)

Zunächst habe ich versucht herauszufinden, warum die Text-Segmente des 
Binaries unterschiedlich groß sind. Schuldig ist:

void __attribute__((optimize(0))) Nop(uint32_t count)

Wenn ich das zurücksetze auf den Original-Code:
void Nop(uint32_t count)

Ist das Binary identisch groß. Damit ist schon mal eine verwunderliche 
Sache geklärt. Morgen gucke ich weiter.

von Thomas Z. (usbman)


Bewertung
2 lesenswert
nicht lesenswert
Welches OS benutzt du denn? Falls das < W8 ist gibt's keine direkte 
Unterstützung für CDC dann brauchst du eine inf Datei.

von Stefan ⛄ F. (stefanus)


Bewertung
-1 lesenswert
nicht lesenswert
Thomas Z. schrieb:
> Welches OS benutzt du denn? Falls das < W8 ist gibt's keine
> direkte
> Unterstützung für CDC dann brauchst du eine inf Datei.

Gute Frage. Ich war einfach von Windows 10 ausgegangen, weil ich mir 
nichts anderes mehr vorstellen kann.

von Thorsten S. (thorstens)


Bewertung
0 lesenswert
nicht lesenswert
Ich benutze Windows 7. Der Hal CDC ging problemlos, woher bekomme ich 
eine .inf Datei?

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Thorsten S. schrieb:
> woher bekomme ich eine .inf Datei?

Ha! Da haben wir vor lauter Bäumen den Wald nicht mehr gesehen.

W.S. hier mal vor einigen Jahren mal die inf Datei von Nuvoton (als 
Kommentar am Ende der Datei usb.h) veröffentlicht: 
Beitrag "Re: USB des STM32 F103C8T6 nutzen"

Ansonsten kannst du (falls es nicht kommerziell ist) vielleicht einfach 
die ID Nummern von ST kopieren, dann wird nämlich (hoffentlich) deren 
Treiber geladen, den die IDE freundlicherweise installiert hat. Den 
Treiber kann man auf der Webseite von ST natürlich auch einzeln 
downloaden.

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


Bewertung
0 lesenswert
nicht lesenswert
Stefan ⛄ F. schrieb:
> Thorsten S. schrieb:
>> woher bekomme ich eine .inf Datei?
>
> Ha! Da haben wir vor lauter Bäumen den Wald nicht mehr gesehen.

Thorsten S. schrieb:
> Wenn ich die Blue Pill mit deiner Firmware einstecke, wird das
> Gerät gar nicht mehr erkannt.

Also, ihr beiden, was ist denn nun? Thorsten hätte ja auch mal etwas 
genauer die Situation bei sich beschreiben können - außer nur "gar nicht 
erkannt". Das ist ja noch 'vielsagender' als die Fehlermeldungen bei 
Windows.

Was also mach denn Windows beim Reinstecken? Fängt es an zu rödeln und 
sagt dann unbekanntes Gerät? Oder tut sich rein garnix? Oder was?

Bei Stefans Beitrag kommt mir der Verdacht, daß es schlicht und einfach 
nur an der .inf liegt, die da angeblich fehlt. Aber die ist ja bei der 
Quelle dabei - und zwar in der usb.h als Kommentar drin. Es wäre ja ein 
Treppenwitz, daß unsereiner grübelt, ob da bei Thorsten das ganze 
Pinsetup nicht stimmt oder der Chip ein Fake ist oder das Kabel nix 
taugt oder der GCC mal wieder Mist baut oder sonstwas Schlimmes - und 
dann liegt's nur an der Inf-Datei.

Einen Punkt hätte ich aber noch: im Original von mir (wo Stefans Link 
hinzeigt) ist in Zeilen 291+292 die Power-Deklaration und je nachdem, 
was Thorsten bei sich ansonsten so mit dem Ding anstellt, wäre da eine 
Korrektur nötig:
1
  0xC0,                   /* bmAttributes         */
2
  0x32,                   /* MaxPower             */
Die bmAttributes sind Bit 7: 1=immer, 6: 1=selfpowered, 5: 0=kein remote 
wakeup und MaxPower 0x32=50=100mA. Wenn das nicht paßt, dann muß das 
angepaßt werden, sonst ist mitten im Enumerieren ggf. der Strom weg. Ist 
mir noch nie selber passiert, aber wie Win10 sich da benimmt weiß ich 
nicht.

W.S.

von Thomas Z. (usbman)


Bewertung
1 lesenswert
nicht lesenswert
W.S. schrieb:
> je nachdem, was Thorsten bei sich ansonsten so mit dem Ding anstellt,
> wäre da eine Korrektur nötig:   0xC0,                   /* bmAttributes
> */
>   0x32,                   /* MaxPower             */
>
> Die bmAttributes sind Bit 7: 1=immer, 6: 1=selfpowered, 5: 0=kein remote
> wakeup und MaxPower 0x32=50=100mA

Das passt schon auch wenn bei selfpowered die Maxpower auch auf 0 
gestellt werden kann. 100mA wäre lowpower das kann ein Usbanschluss 
immer. Das von dir genannte Szenario könnte nur bei einem Hipower Device 
auftreten. Dann wird aber die Enum nach dem Lesen des Devicedeskriptors 
abgebrochen und es erscheint eine Fehlermeldung in der Taskleiste.

von W.S. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Thomas Z. schrieb:
> Das passt schon

und jetzt wissen wir noch immer nicht, was denn nun genau bei dir mit 
dem Ding abgeht oder eben nicht.

W.S.

von Stefan ⛄ F. (stefanus)


Bewertung
1 lesenswert
nicht lesenswert
Zu viele Infos könnten das Volk verunsichern.

Er schrieb, dass er Windows 7 verwendet, ohne einen Treiber installiert 
zu haben. Ich denke, dann ist klar, dass genau dies der Fehler ist.

Mit dem Code und Treiber von ST läuft die gleiche Hardware ja.

Sein Dankeschön kommt sicher später, wenn er es ans Laufen gebracht hat. 
Stimmt's Thorsten?

: Bearbeitet durch User
von Thomas Z. (usbman)


Bewertung
2 lesenswert
nicht lesenswert
W.S. schrieb:
> und jetzt wissen wir noch immer nicht, was denn nun genau bei dir mit
> dem Ding abgeht oder eben nicht.

Das brauchst du auch nicht zu wissen, da ich deinen Code nicht einsetze. 
Ich benutzt schon seit geraumer Zeit den Code von Niclas

von Stefan ⛄ F. (stefanus)


Bewertung
-2 lesenswert
nicht lesenswert
Thomas Z. schrieb:
> Ich benutzt schon seit geraumer Zeit den Code von Niclas

Der kommt aber ursprünglich von W.S.. Sei mal nicht so pampig zu ihm, 
sondern freue dich, dass er als Autor hier seine Hilfe anbietet.

Von Niklas hast du zu diesem Code eher keine Hilfe zu erwarten, außer 
die alt bekannte Kritik, dass er den Coding Style von W.S. scheußlich 
findet. Niklas hat den Code im Rahmen einer Diskussion überarbeitetet, 
um zu beweisen, dass er nicht nur meckern, sondern auch Fehler 
korrigieren kann.

Pass auf, dass du da nicht zwischen die Fronten der beiden gerätst. Und 
verärgere sie nicht, denn wenn die zwei dir hier nicht helfen können, 
dann niemand.

: Bearbeitet durch User
von Johannes S. (jojos)


Bewertung
2 lesenswert
nicht lesenswert
Niclas hat den Code auf Github abgelegt, da kann man Issues erstellen 
und Fehler dann ordentlich verfolgen. Mal hier, mal da ein zip abzulegen 
ist Web 1.0 und eher verwirrend.

von Stefan ⛄ F. (stefanus)


Bewertung
-2 lesenswert
nicht lesenswert
Nicht jeder möchte seinen veröffentlichten Code zu einem Lebenswerk 
machen, was Support-Aufwände angeht.

von Thomas Z. (usbman)


Bewertung
2 lesenswert
nicht lesenswert
Stefan ⛄ F. schrieb:
> Der kommt aber ursprünglich von W.S.. Sei mal nicht so pampig sondern
> freue dich, dass der Autor hier seine Hilfe anbietet.
>
> Von Niklas hast du zu diesem Code eher keine Hilfe zu erwarten, außer
> die Kritik, dass er den schrecklichen unverkennbaren W.S. Style hat.
> Niklas hat ihn offenbar in überarbeiteter Version veröffentlicht, um zu
> beweisen, dass er nicht nur meckern kann, sondern auch Fehler
> korrigieren.

Woher weißt du was ich einsetze? Ich brauche auch keine Hilfe dazu, weil 
der 3fach Uart von Niklas macht alles was ich brauche. Funktionen die 
ich zusätzlich brauche ändere ich mir passend ab.
Falls ihr zwei das noch nicht bemerkt habt ich bin nicht der TO.

von W.S. (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Stefan ⛄ F. schrieb:
> sondern auch Fehler
> korrigieren.

Bin mir garnicht sicher, daß das ne Fehlerkorrektur war oder eher ein 
Mißverständnis. Aber jetzt habt ihr ja einen geänderten Treiber, wo man 
aus der Anwendung heraus sich um das Leeren des Ringpuffers kümmern muß 
- wenn ich das richtig verstanden habe. Also Lowlevel-Treiberinterna 
nach oben hin exportiert. Ist nicht mein Ding. Aber es kann natürlich 
ein jeder sich dranmachen und ändern wie es ihm gefällt - aber wenn es 
nicht so geht wie gedacht, dann nicht mit mir meckern.

W.S.

von Stefan ⛄ F. (stefanus)


Bewertung
-2 lesenswert
nicht lesenswert
Thomas Z. schrieb:
> Woher weißt du was ich einsetze?

Von deiner eigenen Aussage:

Thomas Z. schrieb:
> Ich benutzt schon seit geraumer Zeit den Code von Niclas

Thomas Z. schrieb:
> Ich brauche auch keine Hilfe dazu, weil
> der 3fach Uart von Niklas macht alles was ich brauche.

Junge, dann schreibe das auch! Was du hier abziehst grenzt echt an 
mutwilliger Verarschung. Die ganze Diskussion hier dreht sich um den 
Code von W.S., der sowohl von mir als auch von Niklas überarbeitet 
neu-veröffentlicht wurde.

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


Bewertung
4 lesenswert
nicht lesenswert
Stefan ⛄ F. schrieb:
> Von Niklas hast du zu diesem Code eher keine Hilfe zu erwarten

Ich habe sogar schon Hilfe geboten:

Niklas G. schrieb:
> Du könntest das Board an einen Linux-PC anschließen

Das ist eine sehr zielführende Herangehensweise. Wenn die einfach 
ignoriert wird, habe ich auch keine Lust beim Kaffeesatzlesen zu helfen.

Stefan ⛄ F. schrieb:
> Niklas hat den Code im Rahmen einer Diskussion überarbeitetet,
> um zu beweisen, dass er nicht nur meckern, sondern auch Fehler
> korrigieren kann.

Wie du sicher weißt, habe ich schon diverse Projekte und Artikel online 
gestellt, aus denen ersichtlich sein sollte, dass "Meckern" nicht meine 
Kernkompetenz ist. Das Meckern ist nur die Antwort auf das persistente 
Von-Oben-Herab-Behandeln durch W.S.

W.S. schrieb:
> Bin mir garnicht sicher, daß das ne Fehlerkorrektur war oder eher ein
> Mißverständnis.

Ich mir aber. Ich habe deine Bugs, die du selber aufgrund deiner 
Verteufelung von Debuggern nicht finden konntest, mithilfe eines solchen 
Debuggers im Handumdrehen gefunden und behoben.

W.S. schrieb:
> Aber jetzt habt ihr ja einen geänderten Treiber, wo man
> aus der Anwendung heraus sich um das Leeren des Ringpuffers kümmern muß

Muss man nicht. Das macht der Treiber intern automatisch. Nur halt nicht 
in einem völlig zweckentfremdeten SOF-Interrupt.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Niklas G. schrieb:
> Wie du sicher weißt, habe ich schon diverse Projekte und Artikel online
> gestellt, aus denen ersichtlich sein sollte, dass "Meckern" nicht meine
> Kernkompetenz ist. Das Meckern ist nur die Antwort auf das persistente
> Von-Oben-Herab-Behandeln durch W.S.

Ja ich weiß. An deiner Stelle hätte ich es auch dabei belassen. Ihr zwei 
braucht euch nicht zu einigen, habt ihr beide nicht nötig.

Ich finde eure Werke beide hilfreich bin euch dafür dankbar.

: Bearbeitet durch User
von Thomas Z. (usbman)


Bewertung
0 lesenswert
nicht lesenswert
Stefan ⛄ F. schrieb:
> Junge, dass schreibe das auch! Was du hier abziehst grenzt echt an
> mutwilliger Verarschung. Die ganze Diskussion hier dreht sich um den
> Code von W.S., der sowohl von mir als auch von Niklas überarbeitet
> neu-veröffentlicht wurde.

Komm mal runter und schalte den Denkapparat vor dem Posten ein. Ich 
hatte nur genau 2 Posts hier gemacht. Zum einen hab ich einen Hinweis 
auf die Inf gegeben. Zum 2. hab ich angemerkt dass eine mA Angabe bei 
einem selfpowered Device nicht so sinnvoll ist.

Die Angiffe kamen dann von dir. WS hat mich vermutlich einfach mit dem 
TO verwechselt. Also fass dich mal an der eigenen Nase.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Thomas Z. schrieb:
> Komm mal runter

Ist erledigt.

von guckmal (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Niklas G. schrieb:
> Das Meckern ist nur die Antwort auf das persistente
> Von-Oben-Herab-Behandeln durch W.S.

Du hast nicht gemeckert du hast ihm seine Fehler aufgezeigt.
Aber sowas verträgt W.S. nicht und wird dann pampig und noch 
unausstehlicher.
Denn da könnte sein Dogma/Weltbild zusammenbrechen!

von gnarl (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Heul, wein, wimmer.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
guckmal schrieb:
> du hast ihm seine Fehler aufgezeigt.
> Aber sowas verträgt W.S. nicht und wird dann pampig und noch
> unausstehlicher.

Wenn man das weiß, kann man die betroffene Person auch einfach mal in 
Ruhe lassen. Von solchen "Fehlern" bricht schließlich nicht die Welt 
zusammen.

Mich macht ihr ja auch nicht wegen meiner Rechtschreibschwäche fertig.

: Bearbeitet durch User
von guckmal (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Stefan ⛄ F. schrieb:
> Mich macht ihr ja auch nicht wegen meiner Rechtschreibschwäche fertig.

Du machst auch keine Leute von oben herab, sondern hilfst.
W.S. hilft nicht, er predigt nur.

Stefan ⛄ F. schrieb:
> kann man die betroffene Person auch einfach mal in
> Ruhe lassen.

Wer in Ruhe gelassen werden will, der soll auch Andere in Ruhe lassen.
Das ist eine ganz einfache Formel.

von Thorsten S. (thorstens)


Bewertung
0 lesenswert
nicht lesenswert
Ich wollte mich nur kurz melden, dass ich gestern und heute sehr viel um 
die Ohren hatte und frühestens morgen dazu komme, das Board an einen 
Windows 10 Rechner anzuschließen.

W.S. schrieb:
> Also, ihr beiden, was ist denn nun? Thorsten hätte ja auch mal etwas
> genauer die Situation bei sich beschreiben können - außer nur "gar nicht
> erkannt". Das ist ja noch 'vielsagender' als die Fehlermeldungen bei
> Windows.

Gar nicht erkannt trifft es schon auf den Punkt. Im Gerätemanager 
erscheint nichts. Aber ich teste jetzt wie gesagt erst mal an W10.

von Thorsten S. (thorstens)


Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
Läuft unter W10 anstandslos. Ich war wirklich fest davon ausgegangen, 
dass W7 einen default CDC Treiber mitbringt. Im Anhang eine INF Datei, 
um das unter W7 ans Laufen zu bekommen. Rechts-Klick auf die INF Datei 
und "Installieren" wählen. Der Treiber ist natürlich unsigniert. Dann 
Board anstecken. Bei mir kommt eine Fehlermeldung, keine Ahnung warum. 
Einfach auf "weiter, ok, jaja" klicken, dann läuft es. Im 
Terminalprogramm erscheint der "Hello World!" Text.

von Stefan ⛄ F. (stefanus)


Bewertung
2 lesenswert
nicht lesenswert
Na also, geht doch. Solche Rückmeldungen sind immer hilfreich für 
andere, die das später lesen.

: Bearbeitet durch User
von Thorsten S. (thorstens)


Bewertung
1 lesenswert
nicht lesenswert
Mir ist gerade noch ein Fehler in der INF Datei aufgefallen:

CopyINF=win7-driver.inf

"win7-driver.inf" war der ursprüngliche Dateiname. Ich hatte die Datei 
vor dem Hochladen noch für das Forum editiert. Der Dateiname muss 
angepasst werden, also:

CopyINF=win7-blue-pill-driver.inf

von nix versteh (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Thorsten S. schrieb:
> Im Anhang eine INF Datei,
> um das unter W7 ans Laufen zu bekommen.

Nochmal zum besseren Verständnis: soll das die Inf-Datei für
die USB-Implementierung von W.S. sein?

von Thorsten S. (thorstens)


Bewertung
0 lesenswert
nicht lesenswert
Ja, die INF Datei ist für den WS/Stefan Frings Treiber.

Die VID/PID lautet 0x0416 / 0x5011 und wird an mehreren Stellen in der 
INF Datei verwendet.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.