Hallo @Juri ,
ich habe jetzt alle 3 Versionen von Calliope zum Testen 1.3, 2.0, 2.1 und Windows 11.
Das Kopieren funktioniert bei Calliope 2.0 und 2.1 immer, wenn die Datei nicht die Endung .hex hat. Ich habe es mit .tex und .txt probiert.
Calliope 1.3 interessiert die Endung nicht, der verarbeitet alles auch ohne Punkt und Endung. Dabei funktioniert es manchmal und manchmal nicht. Bei einer .hex-Datei stürzt er immer nach der Übertragung ab. Bei einer nicht-.hex-Datei, wenn das Kopieren erfolgreich war, läuft das Programm auf Calliope schon mindestens 15 Sekunden und die USB Verbindung stürzt erst dann ab, ohne dass das Programm auf Calliope gestört wird. Wenn das Laufwerk MINI dann wieder auftaucht, steht in FAIL.TXT: „The transfer timed out.“
Bei 2.0 und 2.1 können auch mehrere nicht-.hex-Dateien in MINI kopiert werden, die dort bleiben bis er aus geschaltet wird (oder bei einer .hex-Datei abstürzt). Die Dateien sind auch vollständig, man kann sie zurück kopieren, umbenennen. Das Programm auf Calliope interessiert das nicht, es funktioniert.
Das sollte doch beweisen, dass es nicht am Kopieren liegt.
Das Problem ist, dass Calliope bei .hex-Dateien schon während der Übertragung anfängt diese abzuarbeiten und dann immer abstürzt. Früher war die Datei schon vollständig im Prozessor und so konnte das Programm nach dem Absturz starten. Nur die am USB angeschlossenen Computer aller Betriebssysteme haben das gemerkt und laut geschrien. Wir Menschen haben und angewöhnt das zu ignorieren.
Ich würde danach suchen, warum die USB Verbindung immer abstürzt und das abstellen. Das passiert übrigens auch nach einer Übertragung aus dem FLASH, nicht aber bei Bluetooth.
Ich habe den Uploader heute morgen auf Win 10 und Win 11 ausführlich getestet, um eine aussagekräftige Testreihe zu haben. Und dabei hat sich leider gezeigt, dass meine letzten erfolgreichen Versuche bloßer Zufall waren.
Kopieren im Explorer:
Besser als ohne den Uploader. Schien zunächst zuverlässig zu funktionieren, aber nach vielen Versuchen traten dann doch zu häufig dieselben Probleme auf wie beim Kopieren ohne aktiven Uploader.
Herunterladen aus NEPO und Makecode:
In Makecode schien es zuerst ganz gut zu funktionieren (mehrere erfolgreiche Übertragungen gleich beim ersten Versuch), dann musste ich aber auch wiederholt 3 bis 6 Anläufe nehmen, ehe es geklappt hat.
In NEPO war es von Anfang an genauso schlecht wie ohne den Uploader.
Ob sich NEPO und Makecode da aber wirklich unterscheiden, kann ich nicht sicher sagen, dazu hätte ich noch viel viel mehr Tests machen müssen.
Anders als beim Kopieren im Explorer erscheint selbst nach erfolgreichem Herunterladen aus dem Editor auch mit dem Uploader nachträglich die fail.txt mit der time out-Meldung.
Weitere Beobachtung (mit und ohne Uploader):
Bei Win 11 verhält sich das Explorer-Fenster wie immer (schließt sich kurz und öffnet sich wieder), bei Win 10 bleibt es geschlossen (egal ob die Übertragung erfolgreich war oder nicht).
Guten Morgen, gibt es Updates hierzu? Mit dem Calliope 2 haben wir nach wie vor das Copy-Problem. Ich bin mir rel. sicher, dass es eine Synchronierungs-/Timing-Sache ist. Der Calli schreibt das Programm schon ins Ram aber der Kopiervorgang ist noch nicht abgeschlossen, Datei noch nicht geschlossen, Datei-Buffer nicht geflushed oder sowas. Das Verhalten ist typisch für ein Timing, das grenzwertig ausgelegt ist… mit dem Win-Update hat sich das Timing evtl. minimal geändert und daher jetzt die Probleme. Nur Spekulation von mir… ich entwickele seit 1988 Software und im Laufe der Jahre entwickelt man „so ein Gefühl“…
Ja, habe ich. Das hat auch funktioniert, habe das aber nur 2…3x probiert und es funktioniert auch mit normalem Kopieren manchmal 2…3x hintereinander ohne Probleme (und dann wieder nicht). Von daher hat mein Versuch mit dem Uploader keine „statistische Aussagekraft“. Naila hat ja 3 Beiträge weiter oben geschrieben, dass es mit dem Uploader genauso Probleme zu geben scheint - oder habe ich den Thread falsch interpretiert?
Da hast du recht, bei unseren Testrechnern gab es bislang aber keine Probleme mit dem Uploader (einer hat aber auch so keine Probleme mit dem Kopieren), deshalb ist es gut, da mehr Informationen zu erhalten.
Ich denke, dass wir wirklich viel häufiger am Stück testen müssen, um ein aussagekräftiges Gesamtbild zu bekommen.
Heute morgen hatte ich bei der Vorbereitung meiner AG nämlich das Glück, dass 10 mal hintereinander der Download direkt aus NEPO (ganz einfach wie vorgesehen, also auch ohne Uploader) auf Anhieb geklappt hat. Der 11. Versuch brauchte dann wieder 4 Anläufe.
Wahrscheinlich nehme ich mir am Wochenende etwas Zeit dafür. Aber es wäre sicher gut, noch mehr geduldige Langzeittester zu haben.
Die Anwendung ist jetzt signiert. Ob Windows das Fenster anzeigt oder nicht, liegt allerdings im Ermessen von Microsoft. Das Fenster wird allerdings nur nach dem Download einmalig angezeigt und nicht bei jedem öffnen.
Welche Warnungen beim Herunterladen von für Microsoft noch nicht ausreichend vertrauenswürdigen Anwendungen so auftauchen können, hat Louis Kessler hier in seinem Blog schön ausgeführt (englisch): https://www.beholdgenealogy.com/blog/?p=3823
Ich habe jetzt mit dem Autouploader in Version 0.12 noch einige male getestet und bisher damit noch keinen Fehlschlag gehabt - außer ich habe so schnell hintereinander gedownloadet, dass der Flashprozess einfach noch nicht abgeschlossen war. Wir bleiben aber dran und versuchen auch noch alternative Workarounds zu finden, bis das ‚normale‘ kopieren wieder klappt.
Ich habe gestern viele Tests gemacht: Kopieren im Explorer (einmal ein kleines Programm: Lärmampel mit und ohne Uploader, einmal ein komplexes Programm: tictactoe ohne Uploader) , jeweils 50 Mal. Einfaches Programm mit 29 Fehlversuchen ohne Uploader, 20 Fehlversuche mit Uploader. Das komplexe Programm hatte ohne Uploader 26 Fehlversuche, das habe ich dann nicht weiter getestet, weil die Komplexität keine Rolle zu spielen scheint.
Nächste Runde: dasselbe Programm aus NEPO 50 mal mit und 50 mal ohne Uploader übertragen. Ohne Uploader 38 Fehlversuche, mit Uploader nur, aber immerhin 16.
Eigentlich wollte ich dasselbe auch noch mit makecode testen, dazu bin ich aber noch nicht gekommen.
Bei beiden Verfahren (kopieren im Explorer bzw. herunterladen aus dem Editor) schneidet der Uploader besser ab, beim Kopieren im Explorer aber nicht wirklich signifikant (da bräuchte es wohl eher 1000 statt 50 Versuche).
Bei Fehlversuchen im Explorer war der Inhalt der fail.txt immer „The hex file cannot be decoded. Checksum calculation failure occurred.“ Bei erfolgreicher Übertragung gab es anschließend keine fail.txt. Schließen und wieder öffnen des Explorer-Fensters erfolgte mit und ohne Uploader gleich schnell.
Beim Herunterladen aus NEPO schloss sich das Explorer-Fenster bei Fehlversuchen schnell, bei erfolgreicher Übertragung aber erst nach ca. 15 Sekunden (dann verschwand auch erst die hex-Datei) und öffnete sich danach in beiden Fällen sofort wieder. Nach erfolgreicher Übertragung aber dennoch mit einer fail.txt „The transfer timed out.“ Kein Unterschied mit oder ohne aktiven Uploader.
Trotzdem schön, dass der Uploader jetzt zertifiziert ist. Danke.
Ich vergaß: alle Tests mit Calliope 1.3, Windows 10 Pro mit allen Updates.
Ich vergaß außerdem: Browser für die Tests aus NEPO war Firefox.
In der Schule auf den Thin Clients (verbunden mit Windows Server 2012) konnte ich die exe Datei ohne Fragen zu beantworten herunter laden und im Download Ordner ausführen, wieder ohne Rückfrage. Allerdings ist an den Thin Clients die USB Funktion gesperrt, so dass es nichts nutzt.
damit der Uploader funktioniert, musst du alle hex-Dateien in in den Downloads Ordner kopieren oder aus dem Editor dort speichern. Also nichts im Laufwerk MINI speichern.
Was du zu NEPO schreibst, passt zu meinen Beobachtungen, wenn die Datei nicht die Endung HEX hat:
Calliope 1.3 interessiert die Endung nicht, der verarbeitet alles auch ohne Punkt und Endung. Dabei funktioniert es manchmal und manchmal nicht. Bei einer .hex-Datei stürzt er immer nach der Übertragung ab. Bei einer nicht-.hex-Datei, wenn das Kopieren erfolgreich war, läuft das Programm auf Calliope schon mindestens 15 Sekunden und die USB Verbindung stürzt erst dann ab, ohne dass das Programm auf Calliope gestört wird. Wenn das Laufwerk MINI dann wieder auftaucht, steht in FAIL.TXT: „The transfer timed out.“
Hier sieht man den total spannenden Effekt, dass das übertragene Programm auf Calliope schon läuft und erst 15 Sekunden später bricht die USB Verbindung ab, ohne das laufende Programm zu beeindrucken. Und außerdem bleibt die HEX Datei in MINI in den 15 Sekunden lesbar.
Jetzt ist die Frage, wie speichert NEPO eine HEX Datei ab? Wird die erst mit einer anderen Endung gespeichert und hinterher umbenannt? Möglicherweise macht das auch jeder Browser anders. Und was ist im Browser der Download Ordner? Direkt das Laufwerk MINI?
Mein Testergebnis war jedenfalls, dass es mit dem aktualisierten Uploader immer funktioniert, wenn man ihn richtig anwendet - die HEX Dateien müssen in Downloads gespeichert werden, nicht in MINI.
Das kann uns aber nicht zufrieden stellen. Der Fehler muss in der Calliope Software gefunden und behoben werden. Die USB Verbindung darf nicht mehr zusammen brechen.
Warum soll es bei Windows nicht das selbe Problem sein wie bei Mac. Dass es dort wieder funktioniert ist ja Glück oder Zufall, aber nicht gelöst:
Das MINI Laufwerk ist kein richtiges Laufwerk, etwas darauf persistent zu speichern ist nicht möglich. Es ist nur ein virtuelles Laufwerk, das als Vereinfachung zum Flashen genutzt wird - ansonsten wäre dafür ein extra Programm nötig, wie z.B. beim Arduino die Arduino IDE.
Das Neustarten ist nötig, damit der mini mehr als 1x Programmierbar ist - bei dem 1.3 mini kann man die Datei zwar umbenennen, aber dann ist nach dem ersten programmieren Schluss und der mini muss von Hand neugestartet werden. Irgendwo gab es auch mal eine Firmware, bei der der Neustart deaktiviert war, technisch ist das möglich, aber hilft uns hier nicht weiter und führt zu anderen Problemen.
Da das virtuelle Laufwerk keinen richtigen Speicher hat kann dort auch nichts dauerhaft gespeichert werden. Alles, was dort rauf kopiert wird wird direkt an den Prozessor gestreamt. DAPLink and the USB Interface
Der Fehler bei Windows ist wohl, dass Dateien seit dem Update nicht mehr chronologisch kopiert werden - so erhält der mini die Info, dass das ende der Datei geschrieben wurde, während weiter vorne noch Infos fehlen. In dem von @klmi verlinkten Beitrag ist das ausführlicher beschrieben.
Hier ist es also der Microcontroller, der nicht mehr richtig erkennen kann, dass die Datei noch nicht zu ende geschrieben ist, beim Mac war es das Betriebssystem, das den Vorgang abgebrochen hat, weil es nicht die passenden Rückmeldungen erhalten hat.
Bei mir funktioniert es mit dem Uploader zuverlässig, vielen Dank!
Die SmartScreen-Warnung kommt beim ersten Start, aber das ist dann halt mal so (Microsoft …).
Ist weiterhin geplant, auch noch andere Pfade als den Downloads-Ordner zu ermöglichen, wie unter CALLIOPE | Tools vermerkt? Das klappt bei mir nämlich weiterhin nicht.
Die Mitteilung von MacOS, dass ein Laufwerk nicht korrekt ausgeworfen wurde, ist KEIN Fehler.
Wie schon von mir geschrieben, ist dies vorgesehen, damit man direkt die neue Datei ausgeführt sieht. Aus Sicht der NutzerInnen ist es sonst schwer zu wissen ob und wann schon ein Programm auf den Microcontroller kopiert worden ist. Das ist der Grund, weshalb das Gerät neugestartet wird. Das hat nichts mit dem Kopiervorgang oder dem System zu tun. Das taucht nicht bei Bluetooth auf, weil da der Interfaceprozessor gar nicht angesprochen wird. Bluetooth läuft direkt auf dem Anwendungsprozessor.
Ich nutze von Haus aus Ordnerumleitungen (auch in der Schule). Beim ersten Start des CalliopeUploaders erscheint folgende Fehlermeldung:
Der Pfad darf nicht nach C:\Users.… gehen, sondern muss der Umleitung folgen, die in der Registry unter HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders steht.
Für den Microbit wird als Workaround der Befehl robocopy /z . E:\ file.hex empfohlen. Kann das bitte jemand testen?
So, ich habe mit dem ROBOCOPY-Befehl gespielt und das läuft bislang perfekt.
Folgendes Batch-Skript habe ich mithilfe verschiedener Forenideen zusammengebaut. Es greift die obige Idee wieder auf, die Hex-Datei einfach auf das Icon des Skipts zu ziehen oder das Skipt per „Senden an“ zu verknüpfen.
@echo off
for %%D in (D E F G H I J K L M N O P Q R S T U V W X Y Z) do (
dir %%D:\Mini.htm > nul 2>&1 && (call set ZIEL=%%D)
)
if not defined ZIEL EXIT
for /f "tokens=1,2 delims=" %%i in ("%1") do (
set "LAUFWERK=%%~di"
set "PFAD=%%~pi"
set "DATEI=%%~ni"
)
robocopy.exe %LAUFWERK%%PFAD% %ZIEL%: %DATEI%.HEX /z
@PAUSE
Das Skript leistet folgendes:
USB-Laufwerksbuchstabe des Calliope wird gesucht (kann ja immer mal ein anderer sein), indem er auf allen Laufwerken prüft, ob die mini.html-Datei vorhanden ist und speichert das Ergebnis in der Variablen ZIEL. Sollte kein Calliope angeschlossen sein, endet das Skript.
Die als Parameter übergebende Datei wird in die Bestandteile Laufwerk, Pfad und Dateiname zerlegt. Dies ist für den Robocopy-Befehl notwendig.
Nun folgt der Robocopy-Befehl mit den Angaben Laufwerk und Pfad der zu kopierenden Datei, Ziellaufwerk, Quelldateiname und die Option z.
@Toeoe Der eigene Pfad war tatsächlich so programmiert, dass damit nicht ein Ordner überwacht wurde, sondern ein zusätzlicher Ort angegeben werden konnte, wohin die Hex Datei kopiert werden soll. Ich habe jetzt eine neue Version (v0.13) erstellt in welcher darüber der zu Überwachende Ordner angegeben werden kann.
@ToniTaste Wie hast du denn die Ordnerumleitung eingerichtet?
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\User wurde nur zur Abwärtskompatibilität in Windows 95 eingerichtet und sollte nicht genutzt werden.
@Juri Die Ordnerumleitung funktioniert in der Schule hervorragend. Hier auf meinem Endgerät ist wohl ein Konfigurationsfehler in meinem Profil, der das Programm zum Absturz brachte.
