Wollte für mein Bluepill-Board ein neues Projekt anfangen, aber die Arduino-IDE behauptete steif und fest, sie könne den (passenden) Com-Port nicht öffnen. Da es vor 2 Jahren noch funktioniert hatte, habe ich einen Backup eingespielt und mit Win10 Version 1909 klappte alles wie am Schnürchen. Aber schon nach der automatisch ablaufenden Vorbereitung für das Funktionsupdate 21H2 war wieder Ende der Vorstellung. Mit etwas Umweg über Neucompilierung des Programms stm32flash.exe kam dann eine viel einfachere Lösung zustande: In die Batchdatei serial_upload.bat habe ich eine kleine Verzögerung eingebaut (ping localhost -n 2) und schwupps, alles lief wieder. Der serial sniffer zeigte es dann eindeutig: Die Arduino IDE macht irgendwo den Port kurz zum Testen der Anwesenheit auf und stm32flash.exe wird aufgerufen, bevor der Port wieder zu ist. Klarer Fall von Selbstüberlistung. Für alle Arduinohasser ein Grund mehr, Arduino zu vermeiden. Für mich ein Grund, es zu benutzen. Ich mag es, wenn meine Tools so einfach gestrickt sind, daß ich sie selbst reparieren kann. Gruß Klaus (der soundsovielte)
Klaus S. schrieb: > Die Arduino IDE macht irgendwo den Port kurz > zum Testen der Anwesenheit auf und stm32flash.exe wird aufgerufen, bevor > der Port wieder zu ist. Klarer Fall von Selbstüberlistung. Das klingt aber eher nach einen System-Timing-Problem. Was auch deine Aussage mit den Win-Update erklären würde. Einfach gesagt, windows kommt wieder mal mit den Ports/Schnittstellen nicht zeitgemäß zurecht. Das Problem ist so alt wie Windows selbst. Hatte ich schon mit X-Geräten. Besonders beliebt USB-Teile, besonders Handys. Datenzugriff via USB und du brauchst Glück das das Timing stimmt und das Handy als Laufwerk(e) auftaucht. Und bei deinen Teil da hängt ein USB-Serial-Wandler (klingt verrückt ist aber wahr) dazwischen. Das mag Windows eh nicht sonderlich.
Klaus S. schrieb: > Ich mag es, wenn meine Tools so einfach > gestrickt sind, daß ich sie selbst reparieren kann. Klingt sehr nach Indiens Autolegende Ambassador. Vorteil: Kann jeder Schmied im nächsten Dorf reparieren. Nachteil: Muß jeder Schmied im nächsten Dorf reparieren. Aber jeder, wie er will. Oliver
Klaus S. schrieb: > Ich mag es, wenn meine Tools so einfach > gestrickt sind, daß ich sie selbst reparieren kann. Und dann benutzt du Windows? Wenn du kein Arduino nutzt, wie reparierst du die (meistens proprietäre) Debugger- oder Bootloader-Software?
Niklas G. schrieb: > Und dann benutzt du Windows? Wenn du kein Arduino nutzt, wie reparierst > du die (meistens proprietäre) Debugger- oder Bootloader-Software? Die Frage verstehe ich nicht. Ich nutze auch AVR mit Arduino. Dessen Bootloader ist OpenSource: Optiboot. Zur Not hat er dann noch die Hardwareschnittstelle ISP und Ponyprog mit einem 245er am LPT-Port. Der Bootloader der Bluepill hat AN2606 und AN3155, die von stm32flash.exe benutzt werden. Das ist auch Open Source, ich habs zur eigenen Überraschung ruck-zuck fehlerfrei compiliert bekommen. Ich habe während der Fehlersuche etwa 50 Threads gelesen, die ähnliche Probleme beschrieben, aber nicht eine einzige Lösung angeboten bekommen, sondern nur Vermutungen, die ich auch selber anstellen kann. Daher dachte ich, es wäre doch nett, wenn es auch einmal eine Lösung mit passender Begründung gibt. Und meine Vermutung kann ich auch noch hinterherschieben: Da hat sich irgendein Programmierer bei Arduino einen schlanken Fuß gemacht und sich gedacht, daß Windows das Schließen der Schnittstelle auch von selber macht, wenn er sein Programm beendet. Dass er damit den Effekt von Blocking-I/O versaut und genau solche race-conditions erzeugt, das hat er in dem Moment wohl nicht bedacht. Aber das ist vorerst nur Vermutung! Spekulation! Gruß Klaus (der soundsovielte)
Klaus S. schrieb: > Da hat sich irgendein Programmierer bei Arduino einen > schlanken Fuß gemacht und sich gedacht, daß Windows das Schließen der > Schnittstelle auch von selber macht, wenn er sein Programm beendet. Dass > er damit den Effekt von Blocking-I/O versaut und genau solche > race-conditions erzeugt, das hat er in dem Moment wohl nicht bedacht. An Plan mäßig glaube ich nicht. Ehen an ein vergessenen "Close Com-port". Ist selbst mir bei einer SQL-Datenbank-Programmierung sehr oft passiert. Das merkt man erst wenn eine andere Sub eine "unerlaubte" Operation durchführen will.
Klaus S. schrieb: > Da hat sich irgendein Programmierer bei Arduino einen > schlanken Fuß gemacht und sich gedacht, daß Windows das Schließen der > Schnittstelle auch von selber macht, wenn er sein Programm beendet. Dass > er damit den Effekt von Blocking-I/O versaut und genau solche > race-conditions erzeugt, das hat er in dem Moment wohl nicht bedacht. > Aber das ist vorerst nur Vermutung! Spekulation! Hallo, zur Richtigstellung. Das kann nur Spekulation sein, weil Arduino.cc mit Bluepill gar nichts zu tun hat. Die Leute vom "Bluepill" nutzen nur die Arduino IDE, stellen ein Core Package dafür zur Verfügung, damit man das Board zusammen mit der Arduino IDE einfacher zum laufen bekommt. Eine serial_upload.bat gibt es nämlich von Arduino.cc nicht, die muss mit dem Core Package mitgekommen sein. Wird vermutlich auf Github liegen, also schreibe einen netten Hinweis an den Core Package Entwickler.
Schlaumaier schrieb: > Einfach gesagt, windows kommt wieder mal mit den Ports/Schnittstellen > nicht zeitgemäß zurecht. Nee, die Arduino-Leute sind zu blöd, die Schnittstelle richtig zu programmieren. Kein Wunder, bei dem ganzen Schichtkuchen an zig Java-Abstraktionslayern, die die "IDE" und das ganze Geraffel drumherum so gigantisch aufbläht und gleichzeitig lahm macht.
DerEinzigeBernd schrieb: > Kein Wunder, bei dem ganzen Schichtkuchen an zig > Java-Abstraktionslayern, die die "IDE" und das ganze Geraffel drumherum > so gigantisch aufbläht und gleichzeitig lahm macht. Bei der ganzen Geschichte stellt sich mir EINE Frage. Über welche IDE reden wir eigentlich und unter welchen OS. IDE 1.* = Soll problemlos unter ab Win-7 laufen IDE 2.* = Soll unter Win-10 o. höher laufen ist aber noch ziemlich "Frisch". Ps. : Ich habe die IDE-2.* unter mein Win-7-64 problemlos ans laufen bekommen. Aber ich hätte mich auch nicht beschwert, wenn es nicht geklappt hätte.
Veit D. schrieb: > Das kann nur Spekulation sein, weil Arduino.cc mit Bluepill gar nichts > zu tun hat. Die Leute vom "Bluepill" nutzen nur die Arduino IDE, stellen > ein Core Package dafür zur Verfügung, damit man das Board zusammen mit > der Arduino IDE einfacher zum laufen bekommt. Eine serial_upload.bat > gibt es nämlich von Arduino.cc nicht, die muss mit dem Core Package > mitgekommen sein. Wird vermutlich auf Github liegen, also schreibe einen > netten Hinweis an den Core Package Entwickler. Das hört sich einleuchtend und vernunftig an. Macht zwar nicht soviel Vergnügen wie wilde Spekulation, erhöht aber wohl deutlich den Wahrheitsgehalt. Deshalb 12 Punkte dafür! Leider hat der gute Dan Drown, von dem das Package stammt, zwar einen Blog mit funktionierender Webadresse, aber keine Möglichkeit vorgesehen, ihm eine Nachricht zuzusenden. Ich gehe daher davon aus, dass er auch lieber nichts hören möchte und nehme Rücksicht auf seine Entscheidung, Für Leser, die es noch etwas genauer wissen wollen: Es handelte sich um ein altes Thinkpad X200 mit SSD und 4GByte RAM, was ich wegen der 1000g Gewicht als Reiselaptop über alles schätze. Da 4GByte schon der Vollausbau ist, hat es Win10pro in der 32-bit-Version und Arduino hat die Version 1.8.15. Ich denke aber, dass die wichtigste Erkenntnis ist, dass die Blockade des Com-Ports von der eigenen Anwendung kommen kann. In den Postings, die ich gelesen habe, war immer von Blockade durch andere Teilnehmer die Rede, nie aber von der eigenen Anwendung. Ich bin selber erst darauf gekommen, als ich in Ruhe die Übergabeparameter für stm32flash.exe anschauen wollte und die Ausgabe der argv[]-Tabelle direkt nach dem Start mit Sleep(2000) verziert habe. Zack, es lief! Das Naheliegendste sieht man nicht unbedingt als Erstes. Gruß Klaus (der soundsovielte)
STM32Duino nutzt, wenn ich es recht weiß, den orginal Bootloader von STM der den STLINK V2 ansteuern kann. Je nachdem, was man machen will, reicht das Framework auch für ein BluePill Board: https://github.com/stm32duino/Arduino_Core_STM32
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.