Hatte gestern versucht, eines der USB-UART Tutorials (YT) für bluepill durchzuführen. Irgendwie habe ich mir to SW4STM32 Toolchain zerschossen und kriege sie nicht mehr installiert. An einem Punkt hatte ich in den Projekt Settings to Toolchain installiert bekommen, will sagen, als ich SW4STM32 ausgewählt hatte, wurde sie automatisch nachgeladen und installiert. Dann hatte ich festgestellt, daß immer (aus STM32CubeMX heraus)STM32Cube (oder ..IDE) aufgerufen wurde, weil da offenbar eine Dateiendungs-Verknüpfung existierte. Also hatte ich alles außer STM32CubeMX deinstalliert. Jetzt kriege ich aber trotzdem die Toolchain nicht mehr installiert. Ich hatte die von OpenSTM32.org runtergeladen (64bit, war das ok?). Allerdings passiert nichts nachdem ich die Installationsexe (install_sw4stm32_win_64bits-v2.9.exe) aufgerufen habe. Jemand eine Idee?
Beim Abarbeiten von irgendeinem Tutorial hast du eine Software irgendwie so zerschossen, dass am Ende bei der Neuinstallation "nichts" passiert. Sorry, aber damit kann ich "nichts" anfangen. Dieses Problem musst du wohl mit jemandem vor Ort lösen, der sich gut mit Troubleshooting unter Windows auskennt. Ich würde einfach Windows neu installieren (ist billiger).
Deinstalliere doch erstmal alles und installiere dann mal die aktuelle STM32CubeIDE statt dem veralteten SW4STM32: https://www.st.com/en/development-tools/stm32cubeide.html Weil das die ganze Funktionalität von STM32CubeMX enthält kannst du letzteres auch deinstallieren weil es nicht mehr gebraucht wird. Mit der STM32CubeIDE gibt es endlich eine brauchbare funktionierende Freeware-IDE direkt von ST, die sogar einen aktuellen GCC mitliefert.
:
Bearbeitet durch User
Niklas G. schrieb: > Deinstalliere doch erstmal alles und installiere dann mal die aktuelle > STM32CubeIDE statt dem veralteten SW4STM32: > > https://www.st.com/en/development-tools/stm32cubeide.html > > Weil das die ganze Funktionalität von STM32CubeMX enthält kannst du > letzteres auch deinstallieren weil es nicht mehr gebraucht wird. Mit der > STM32CubeIDE gibt es endlich eine brauchbare funktionierende > Freeware-IDE direkt von ST, die sogar einen aktuellen GCC mitliefert. Ich habe ja STM32CubeIDE auf der MacOS-Seite. In der Parallels Windows 10 VM hatte ich das STM32CubeMX installiert, allerdings die Version 6.1.2. Wenn man Tuturials folgt, ist es immer gut, wenn der Ablauf beim Nachspielen genauso ist wie im Tutorial, weshalb ich dann zurückggegangen bin auf eine alte CubeMX-Version. @Stefanus: Windows neuinstallieren sollte ein Witz sein, nicht wahr? Das STM32-Zeugs total zu deinstallieren ist sicher eine Option, aber trotzdem hätte ich dann gerne das Tutorial nachgespielt mit den verwendeten Komponenten. Immerhin habe ich ja einen .ioc-File. Vielleicht kann ich den in meine macOS Version des STM32CubeIDE einlesen.
:
Bearbeitet durch User
Christoph K. schrieb: > Windows neuinstallieren sollte ein Witz sein, nicht wahr? Nein. Wenn man sich nicht gut auskennt und Geld sparen will/muss ist das oft besser, als Monatelang herum zu doktorn oder einen halb kaputten PC vor sich zu haben. Windows neu zu installieren ist einfach, wenn man seine persönlichen Dateien einigermaßen zusammen gehalten hat. Manche Leute sind darauf vorbereitet, indem sie Backups (auch von Installationsdateien) machen, sowie eine Step-By-Step Liste der Arbeitsschritte. Christoph K. schrieb: > Wenn man Tuturials folgt, ist es immer gut, wenn der Ablauf beim > Nachspielen genauso ist wie im Tutorial Nur leider sind die allermeisten Tutorials zum Zeitpunkt der Veröffentlichung schon in Details veraltet. Meine sind da keine Ausnahme.
Wenn es ein reines STM32CubeMX ist, lässt sich im Projekt Manager die gewünschte Ziel IDE auswählen, bzw. sogar ein universelles makefile Projekt.
pegel schrieb: > Wenn es ein reines STM32CubeMX ist, lässt sich im Projekt Manager die > gewünschte Ziel IDE auswählen, bzw. sogar ein universelles makefile > Projekt. Ja. Und soweit mir bekannt ist, funktioniert das unabhängig davon, ob diese Ziel-IDE installiert und funktionsfähig ist.
Stefan ⛄ F. schrieb: > Christoph K. schrieb: >> Windows neuinstallieren sollte ein Witz sein, nicht wahr? > > Nein. Wenn man sich nicht gut auskennt und Geld sparen will/muss ist das > oft besser, als Monatelang herum zu doktorn oder einen halb kaputten PC > vor sich zu haben. Windows neu zu installieren ist einfach, wenn man > seine persönlichen Dateien einigermaßen zusammen gehalten hat. > Hast Du schon mal eine Windows-Neuinstallation gemacht unter Beibehaltung all Deiner installierten Programmpakete? Bei mir sind hunderte von Paketen auf der Windows 10 VM installiert. Eher wäre es eine Option, auf einen VM Snapshot zurückzugehen. Aber ich will jetzt schnell zum Ziel kommen und nicht auf Nebenschauplätzen noch Diskussionen führen. Habe jetzt erst mal den IOC File ins STM32CubeIDE eingelesen bekommen. Das Projekt compiliert jetzt mit der arm-none-eabi-gcc toolchain. Leider kann er im Moment nicht zum Debugger verbinden. Habe das bluepill-Board mit SWCLK,SWDIO, GND,3.3V mit dem DISCO SWD Interface/Supply verbunden. Komme jetzt weiter. Das USB Programm aus dem Tutorial läuft im Debugger, zumindest ist es schon mal geflasht.
Christoph K. schrieb: > Hast Du schon mal eine Windows-Neuinstallation gemacht unter > Beibehaltung all Deiner installierten Programmpakete? Funktioniert das überhaupt? Ich hab's nur zweimal versucht, was der totale Reinfall.
Christoph K. schrieb: > Leider kann er im Moment nicht zum Debugger verbinden. Warum? SWD Pins nicht aktiviert?
Stefan ⛄ F. schrieb: > Christoph K. schrieb: >> Hast Du schon mal eine Windows-Neuinstallation gemacht unter >> Beibehaltung all Deiner installierten Programmpakete? > > Funktioniert das überhaupt? Ich hab's nur zweimal versucht, was der > totale Reinfall. Eben.
pegel schrieb: > Christoph K. schrieb: >> Leider kann er im Moment nicht zum Debugger verbinden. > > Warum? > SWD Pins nicht aktiviert? Hatte den Post aus Versehen losgeschickt, ohne vorher das Problem mit dem Nichtverbindenkönnen zum Debugger herausgenommen zu haben. Der Satz :Leider… war stehen geblieben. Zwei Sätze später schreibe ich ja:komme jetzt weiter… Da hatte ich vergessen, den BOOT0 zu setzen. Also setupseitig alles i. O.. Komme erst heute abend dazu, weiterzumachen. Danke erst mal für die Unterstützung.
:
Bearbeitet durch User
Zurück zum Projekt "BluePill USB Uart" Ich hatte mir ja dieses https://youtu.be/YZjnCOun1wU Tutorial/Projekt ausgesucht und bin damit auf STM32CubeIDE umgezogen. Zunächst mal: ich konnte das Programm mit STM32CubeIDE flashen und wenn ich dann das BluePill Board vom SWD abklemme, direkt an USB anschließe (BOOT0 Jumper wieder auf 0) und der Windows 10 VM zuweise, bekomme ich ein COM5 Device. Soweit schon mal Erfolg. Nur klappt die Kommunikation noch nicht. Der Autor baut in seinem Tutorial für den Fall, daß vom Computer eine '1' kommt, eine LED-Ausgabe ein (LED ON), für eine '0' entsprechend aus. Ich wundere mich, warum gar kein UART konfiguriert ist. Ich füge mal den IOC-File bei.
Christoph K. schrieb: > Ich wundere mich, warum gar kein UART konfiguriert ist. Ich füge mal den > IOC-File bei. USB ist kein UART.
Christoph K. schrieb: > warum gar kein UART konfiguriert ist. weil es ein virtueller COM Port über USB ist?
J. S. schrieb: > Christoph K. schrieb: >> warum gar kein UART konfiguriert ist. > > weil es ein virtueller COM Port über USB ist? Ziel ist aber doch, mit der Außenwelt zu kommunizieren. Ich will ja meinen (vermeintlich kaputten) FTDI->Serial USB Dongle ersetzen. Also muß der STM32F103 doch letztlich auch Aus- und Eingabe mit angeschlossenen TTL-UARTS ermöglichen. Die Kontrollausgabe LEDON/OFF erscheint. Funktion scheint weitgehend vorhanden zu sein. Wie gesagt, muß noch herausfinden, welcher UART des F103 nun benutzt wird.
:
Bearbeitet durch User
Christoph K. schrieb: > Wie gesagt, muß noch herausfinden, welcher UART des > F103 nun benutzt wird. Keiner. Wurde schon geschrieben. Hier ist ein Projekt, dass einen Umsetzer USB<>TTL für alle 3 UART realisiert. Kannst Du selbst übersetzen, oder "ausleihen".
pegel schrieb: > Christoph K. schrieb: >> Wie gesagt, muß noch herausfinden, welcher UART des >> F103 nun benutzt wird. > > Keiner. Wurde schon geschrieben. Wieso? > > Hier ist ein Projekt, dass einen Umsetzer USB<>TTL für alle 3 UART > realisiert. D.h. der bedient alle 3 UARTs gleichzeitig? > > Kannst Du selbst übersetzen, oder "ausleihen". Link vergessen. Achso, wollte schon fragen ".bin selbst Übersetzen?" Schön und gut. Aber meine Frage, nach der Funktion dessen, was ich da bis jetzt geflasht habe, bleibt unbeantwortet.
Christoph K. schrieb: > Schön und gut. Aber meine Frage, nach der Funktion dessen, was ich da > bis jetzt geflasht habe, bleibt unbeantwortet. ab 5:50 das Video noch mal genau ansehen
pegel schrieb: > Christoph K. schrieb: >> Wieso? > > Virtuell. Nicht wirklich! Ist mir schon klar, virtuelles serielles Device, virtueller COM-Port. Meine Frage ist: welches sind die PINs zur Außenwelt (Tx, Rx)?
Christoph K. schrieb: > Ist mir schon klar, Anscheinend nicht. Es gibt keine. Spielt sich alles nur intern ab. Ist kein Umsetzer!
pegel schrieb: > Christoph K. schrieb: >> Ist mir schon klar, > > Anscheinend nicht. Es gibt keine. > Spielt sich alles nur intern ab. > Ist kein Umsetzer! Dann habe ich offenbar das falsche Projekt für meine Anwendung ausgewählt. Was soll denn das Projekt dann überhaupt für einen Sinn haben?
pegel schrieb: > CDC Test ;) Auch schön, aber Thema verfehlt. So, dank Deines Links (https://github.com/satoshinm/pill_serial) bin ich jetzt in wenigen Minuten zum Erfolg gelangt durch einfaches st-flash des .bin Files. Habe auch das Projekt ausgecheckt and fand endlich mal ein vernünftiges README.MD, was einem sofort sagt, welche Pins benutzt werden. Was in der Doku vielleicht noch fehlt, ist, welches Device zu welchen Pinpaaren gehört. Das mußte ich durch Experimentieren rauskriegen.
1 | TX pin RX pin |
2 | PB10 PB11 /dev/cu.usbmodemE1CBBADB3 |
3 | PA2 PA3 /dev/cu.usbmodemE1CBBADB1 |
4 | PA9 PA10 /dev/cu.usbmodemE1CBBADB5 |
(Devicebezeichnungen für macOS) wobei PA9/PA10 nicht zu funktionieren scheint. Getestet mit: picocom -b 115200 /dev/cu.usbmodemE1CBBADB5 --imap lfcrlf --omap delbs --send-cmd "ascii-xfr -s -l 80 -n" Loopback Verdrahtung zeigt nur Fragezeichen an, während für die ersten beiden Pinpaare das loopback funktioniert. Hatte es mit 38400 und 115200 probiert. Hat bei der Applikation das schwache Glimmen der grünen LED eine bestimmte Bewandnis? Wenn es im Takt der Datenübertragung flackern würde, könnte man einen Sinn darin erkennen.
:
Bearbeitet durch User
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.