Demonstrator GUI von ST verhält sich unzuverlässig. Im Moment bekomme ich nichts heraus aus dem Demonstrator GUI (unter einer Parallels Windows 10 VM). Man könnte sagen "laß die Finger davon, sowie veraltet usw.", aber es ärgert mich, wenn ein Aufbau nicht so funktioniert, wie man es erwarten sollte. Kurz und gut: ich habe einen Aufbau wie in der beigefügten Skizze. Ich habe mit meiner DLA-Probe (Pulseview) die UART-Leitungen angezapft. Wenn ich sie statt an das DI-Board anzuschließen, gegeneinander kurzschließe und auf der Windows Seite OC-Console (COM1) mit 115200 Bd (8N1) aufrufe und etwas in die Tastatur tippe, so kommt es an. Starte ich das Demonstrator GUI mit 115200, COM1, 8E1 (default), so kommt kein Zeichen auf die Leitung. Unabhängig davon, ob auf dem Target der BOOT-Mode richtig eingestellt ist, sollte das GUI doch erst mal ein Zeichen schicken (0x7f), oder? Was für einen seriellen Programmer gibt es noch, den man probieren könnte?
Angehängte Dateien:
-
IMG_3271.jpg
1,1 MB
:
Bearbeitet durch User
Christoph K. schrieb: > Demonstrator GUI von ST verhält sich unzuverlässig. Das ist seit Jahren bekannt. Dieses Programm von ST kaut eine Weile auf der Hardware herum und dann heißt es "geht nicht". Keine weitere Erläuterung dazu. Ich hatte vor Jahren schon mal ein Programm zum Programmieren der STM32 per Bootlader geschrieben und hier gepostet. Das hat wenigstens noch ein paar Testmöglichkeiten dabei, also ob Reset und Boot richtig am µC ankommen. W.S.
W.S. schrieb: > Christoph K. schrieb: >> Demonstrator GUI von ST verhält sich unzuverlässig. > > Das ist seit Jahren bekannt. Dieses Programm von ST kaut eine Weile auf > der Hardware herum und dann heißt es "geht nicht". Keine weitere > Erläuterung dazu. > > Ich hatte vor Jahren schon mal ein Programm zum Programmieren der STM32 > per Bootlader geschrieben und hier gepostet. Das hat wenigstens noch ein > paar Testmöglichkeiten dabei, also ob Reset und Boot richtig am µC > ankommen. > > W.S. Stimmt, war es STM32Prog.exe? Habe es gerade mal hervorgeholt.
Stm32CubeProgrammer funktioniert bestens, der bringt auch eine Kommandozeilenversion mit. Ich würde aber das Bluepill zur BMP umflashen und dann über SWD programmieren. Aber an der Baustelle warst du doch auch schon. Und wenn es bei STM32 bleibt, dann ist der STLink V3 mittlerweile die beste Wahl. 15€ bei Reichelt.
:
Bearbeitet durch User
J. S. schrieb: ... > Und wenn es bei STM32 bleibt, dann ist der STLink V3 mittlerweile die > beste Wahl. 15€ bei Reichelt. Leider nicht mehr verfügbar bei Reichelt. Andere Quellen mehr als das doppelte.
ich meinte diesen hier: https://secure.reichelt.de/in-circuit-debugger-programmierer-fuer-stm32-stlink-v3mini-p274817.html Das SET ist bequemer weil es mehr Anschlussmöglichkeiten hat, da ist aber der gleiche Mini drin. Für den Mini braucht man dann Adapter für den 50 mil Stecker, oder solche Breakout Boards: https://github.com/tw1chao/STLinkV3_Adapter https://github.com/TMSL/STLINK-V3MINI-Cable-Adapter-Board
J. S. schrieb: > Und wenn es bei STM32 bleibt, dann ist der STLink V3 mittlerweile die > beste Wahl. Ich frage mich seit langem, warum die Leute hier mit Fleiß immerzu einen großen Bogen um den eingebauten Bootlader machen wollen. Der kommt mit dem Chip daher, kostet nix und sollte eigentlich die genau für den Chip passenden Programmiermethoden haben. Und die Ansteuerung ist leicht, man braucht keine zusätzlichen JTAG/SWD Adapter usw. W.S.
W.S. schrieb: > J. S. schrieb: >> Und wenn es bei STM32 bleibt, dann ist der STLink V3 mittlerweile die >> beste Wahl. > > Ich frage mich seit langem, warum die Leute hier mit Fleiß immerzu einen > großen Bogen um den eingebauten Bootlader machen wollen. Der kommt mit > dem Chip daher, kostet nix und sollte eigentlich die genau für den Chip > passenden Programmiermethoden haben. Und die Ansteuerung ist leicht, man > braucht keine zusätzlichen JTAG/SWD Adapter usw. > > W.S. Ich betreibe ja das Target normalerweise über die SWD Schnittstelle, STM32CubeIDE samt umfangreicher Debugtracemeldungen über die SWV/ITM Schnittstelle. Wollte jetzt nur mal speziell den seriellen über UART testen (Demonstrator GUI). Was meinst Du jetzt mit "eingebautem Bootloader"? Auf welchen Satz bezieht sich Deine Kritik? Auf: "dann ist der STLink V3 mittlerweile die beste Wahl." ? Der STM32 hat ja viele Bootloader, seriell über UART, I2C, SPI, Can, was nicht alles noch. Aber damit kann man ja nur up/download. Richtig Debuggen doch eher nicht?
:
Bearbeitet durch User
Christoph K. schrieb: > Der STM32 hat ja viele Bootloader, seriell über UART, I2C, SPI, Can, was > nicht alles noch. Aber damit kann man ja nur up/download. Richtig > Debuggen doch eher nicht? richtig. Wenn man ein Gerät hat auf dem eine der genannten Schnittstellen herausgeführt ist, dann kann es Sinn machen die auch für ein Firmware Update zu verwenden. Der STLinkV3 + STM32CubeProgrammer unterstützen alle diese Schnittstellen, hat Fullspeed USB und ist damit sehr schnell, was sich durchaus positiv beim Debuggen bemerkbar macht. Der F407 hat 512/1024 kB Flash, auch große Programme sind damit blitzschnell geflasht. Vor der großen Krise hat der V3 Mini <8€ netto bei den Distris gekostet. Und um den noch universeller zu machen hat STM eine Bridge Library kostenlos im Angebot, damit lassen sich die Schnittstellen von PC Software aus nutzen. Und auf Github gibt es weitere Unterstützung für verschiedene Programmiersprachen. Für mich sind das genug Gründe das Teil zu 'meinem Lieblingswerkzeug' werden zu lassen. Den Test mit DIY Board und seriellem Bootloader kann ich morgen auch machen, habe diverse F407 Boards. Aber nur mit der STM32CubeProgrammer Software, das W.S. Zeug kommt mir nicht auf den Rechner.
W.S. schrieb: > Ich frage mich seit langem, warum die Leute hier mit Fleiß immerzu einen > großen Bogen um den eingebauten Bootlader machen wollen. Der kommt mit > dem Chip daher, kostet nix und sollte eigentlich die genau für den Chip > passenden Programmiermethoden haben. Und die Ansteuerung ist leicht, man > braucht keine zusätzlichen JTAG/SWD Adapter usw. Dafür gibt es (ernsthafte) technische und (vergnügliche) psychologische Gründe. 1.Technische In der Großserie wird Hardware und Software parallel entwickelt. Der Programmierer bekommt also sehr spät erst die richtige Hardware zum Test. Da ist dann das Debugging mit Breakpoints oder Einzelschritt die schnellste (dem begrenzten Hirn des Menschen) mögliche Fehlersuchmethode und da braucht man den JTag-Link ohnehin. Wer schon zur Programmierzeit die echte Hardware zur Verfügung hat, kann inkrementell programmieren. Die interpretierenden Sprachen (egal ob die Neueren wie Python und Lua oder die Alten wie Forth und Basic) sind genau dafür gut und die Programmierschnittstelle ist gleichzeitig Debugschnittstelle. Dafür reicht dann der eingebaute Bootloader. Aber nur, wenn man fit ist, kann man damit C-Progamme debuggen, aber wer ist schon fit? 2.Psychologische Minimalismus macht einfach wenig her. Wenn man den Aufwand ordentlich aufbläst, sieht alles gleich viel eindrucksvoller und professioneller aus! Gruß Klaus (der soundsovielte)
Thread beobachten
Seitenaufteilung abschaltenBitte 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.