Kurze frage zu eurem vorgehen:
Speichert ihr die Hex Dateien auf dem PC und kopiert sie anschließend auf den mini, oder wählt ihr bei dem Download-Dialog im Browser „Speichern unter…“ und wählt direkt das mini Laufwerk als Speicherort aus?
1 „Gefällt mir“
Wir haben alles 
probiert: Kopieren im Windows Explorer, herunterladen aus Makecode und Open Roberta.
1 „Gefällt mir“
Die Frage kam bei mir nur auf, weil es bei dem Weg über den Explorer ja nicht mehr vom Browser abhängen sollte.
Bei einem Download im Browser direkt auf das mini Laufwerk passiert in der Regel bei Chromium basierten Browsern (Edge, Chrome, Opera, Vivaldi,…) folgendes (wenn nicht das automatische Speichern im Standard-Ordner aktiv ist):
- Es wird gefragt ob man die Datei herunterladen möchte
- So bald auf „Speichern unter“ geklickt wird beginnt der Download im Hintergrund, es wird im „Downloads“ Ordner eine
.tmpDatei erstellt, noch während man den Speicherort wählt… - Hat man einen Ort zum Speichen ausgewählt wird die
.tmpDatei an den neuen Ort als.crdownloadkopiert. - Ist der Download abgeschlossen wird die Datei in den eigentlichen Dateinamen umbenannt.
Bei jedem Schritt springt potenziell der Live-Scanner eines Virenprogramms dazwischen und kann den nächsten Schritt bis zum Abschluss des Scans blockieren. Bei Windows ist der „Defender“ immer installiert, wird ein anderes Virenprogramm installiert deaktiviert er sich, aktiviert sich aber ggf. auch wieder, so bald das andere Virenprogramm deaktiviert wird.
Bei dem direkten Speichern aus dem Browser heraus gibt es also deutlich mehr Faktoren und Fehlerquellen.
1 „Gefällt mir“
Als Downloadordner ist MINI: ausgewählt. Wird also ohne Nachfrage auf dem mini gespeichert.
1 „Gefällt mir“
Hallo, wir haben diesen Fehler jetzt auch, allerdings mit Windows 10 (McAfee). Nachdem wir im März erst von dem OpenRoberta Bluetooth-Bug betroffen waren, können wir nun nur noch bei einem kleinen Teil unserer Calliopes Dateien per USB übertragen. Evtl. sind das jene Calliopes, die wir NICHT zuletzt mit dem Bluetooth Bug überspielt hatten oder gerade jene welche, die nach dem Bluetooth-Bugfix einmal neu bespielt wurden? Wir haben völlig den Überblick verloren und nun ein Sammelsurium von Calliopes, die entweder mit Bluetooth oder mit USB nicht mehr funktionieren.
Kann es übrigens sein, dass nach dem OpenRoberta Bluetooth-Bugfix das Pairing nun etwas anders funktioniert? Vorher hat man den Affengriff getätigt und Tasten A+B solange gedrückt gehalten, bis die LED-Anzeige einmal durch gelaufen war, dann erschien das Pairing-Muster. Nun bekommt man irgendwann „Pairing Mode“ angezeigt, dann das Pairing-Muster?
Und mit dem Affengriff plus Reset für 6sec. drücken kommen wir rein gar nicht mehr an die 25 Programme im Flash ran. Meistens konnten wir uns ja mit dem Programm 25 „retten“.
Es ist eine einzige Katastrophe geworden, wir haben völlig den Überblick verloren.
Bringt es was, wenn wir im MAINENNACE Mode den Bootloader neu übertragen? Dann die 25 Programme neu auf das Flash? Aber wie kommt man an die ran, wenn der Affengriff nicht mehr geht?
Oder wie bekommen wir einen offensichtlich „zerschossenen“ Calliope wieder in den Urzustand zurück versetzt?
1 „Gefällt mir“
Also ich habe die oben beschriebenen Tests immer ohne Browser und direkt mit einer HEX-Datei von der (lokalen) Festplatte gemacht.
Bei direkten Speichern unter auf MINI mit Edge und MakeCode hatte es auf Windows 11 immer noch am Besten funktioniert (1. Beitrag ganz oben).
Als Erste Hilfe empfehle ich COPY mit Parameter /Z. Auch XCOPY hat ein /Z, aber an einer anderen Stelle in der Kommandozeile. Dazu muss man die Datei natürlich vorher speichern. Vielleicht könnt ihr mal mitteilen, wo das auch nicht funktioniert.
Lutz
Ich habe das Projekt GitHub - calliope-edu/CalliopeMiniAutoupload mit Download ZIP herunter geladen und in Visual Studio Community 2022 auf Windows 11 erfolgreich starten und bearbeiten können.
Es treten die selben Fehler auf, die hier diskutiert wurden. Das Problem ist die Zeile
File.Copy(file, trg, true);
Ich habe in MainForm.cs ab Zeile 184 (copyFirmware) folgendes geändert:
static void copyFirmware(string file, List<string> drives)
{
var waitHandles = new List<WaitHandle>();
foreach (var drive in drives)
{
var ev = new AutoResetEvent(false);
waitHandles.Add(ev);
ThreadPool.QueueUserWorkItem((state) =>
{
//try
{
var trg = System.IO.Path.Combine(drive, "firmware.hex");
//File.Copy(file, trg, true);
var fs1 = new FileStream(file, FileMode.Open, FileAccess.Read);
var fs2 = new FileStream(trg, FileMode.Create);
//var fs2 = new FileStream(trg, FileMode.OpenOrCreate, FileAccess.ReadWrite, FileShare.ReadWrite);
fs1.CopyTo(fs2);
//fs2.Close(); fs1.Close();
fs2.Dispose(); fs1.Dispose();
}
//catch (IOException) { }
//catch (NotSupportedException) { }
//catch (UnauthorizedAccessException) { }
//catch (ArgumentException) { }
ev.Set();
}, ev);
}
//waits for all the threads (waitHandles) to call the .Set() method
//and inform that the execution has finished.
WaitHandle.WaitAll(waitHandles.ToArray());
}
Und mit FileStream kommt überhaupt kein Fehler mehr.
Ich habe versucht mit Parametern, Close und Dispose den Fehler nach zu vollziehen - es kommt kein Fehler mehr.
Ich habe zuletzt zwei Calliope 2.0 und ein Calliope 1.3 gleichzeitig an den USB Hub angeschlossen. Das Programm kopiert ja auf alle MINI Laufwerke gleichzeitig asynchron. Funktioniert (mit meiner Änderung) immer bei allen dreien. Nur der 1.3 blinkt schneller und dauert länger.
Ich verstehe es nicht.
Aber noch mal zum Fehler im Originalprogramm mit File.Copy und 3 angeschlossenen Calliope:
Ganz selten kommt das Programm auf allen dreien an. Die beiden 2.0 verhalten sich unterschiedlich. Bei 2.0 kann die IOException kommen: „Ein nicht vorhandenes Gerät wurde angegeben.“ Bei 1.3 kommt nie eine Exception. Es funktioniert einfach nicht ohne Grund.
Wenn die Datei-Endung nicht .hex ist:
Calliope 1.3 verarbeitet jede Datei, die Endung interessiert nicht.
Calliope 2.0 speichert eine oder mehrere Dateien in MINI. Die Dateien können geöffnet, zurück kopiert oder umbenannt werden.
Das Laufwerk MINI wird erst beim Trennen der USB Verbindung wieder geleert.
Die Dateien, auch die HEX Dateien, kommen nach meiner Beobachtung bei allen Kopier- Versuchen immer vollständig in MINI an. Erst der Neustart nach dem Laden löscht sie wieder.
Das Problem ist, dass der Neustart viel zu zeitig kommt. Vermutlich stürzt Calliope einfach ab und startet neu. Manchmal gibt es ja auch eine FAIL.TXT Datei.
Die Frage ist jetzt, was macht Calliope wenn eine Datei ankommt? Bei welchem Ereignis bzw. welchem Zeitpunkt während oder nach dem Kopiervorgang fängt er an die HEX Datei auszuwerten und in den internen Prozessor zu laden?
Wahrscheinlich streiten sich zwei Prozesse um dieselbe Datei und Microsoft behandelt das seit dem Update jetzt etwas strenger. Bestimmt wurde beim Kopieren eine Sicherheitslücke geschlossen…
Interessant ist auch, dass 1.3 mit 64 MB angezeigt wird und 2.0 mit 11 MB.
Hypothese:
Ist der absurde Neustart nach der Übertragung der HEX Datei schon immer ein Absturz aller Calliope’s und Microbit’s gewesen? Und weil der immer erst kam nachdem das Programm fertig gespeichert war, ist es nicht aufgefallen. Über den Abbruch und Wiederherstellung der USB Verbindung haben sich schon immer alle Betriebssysteme beschwert. Dafür gibt es keinen sinnvollen Grund. Die HEX Datei wird sowieso in MINI gespeichert und würde dort nicht stören während ihr Inhalt gleichzeitig im Prozessor ist. In das Laufwerk MINI kann auch eine zweite HEX Datei kopiert werden, wenn schon eine drin ist (die im Laufwerk in HEX umbenannt wurde).
Wenn Calliope am USB Kabel steckt und ich habe eine Datei vom iPad per Bluetooth übertragen, startet die auch ohne dass die USB Verbindung abstürzt. Wenn das zum Programmstart notwendig wäre, müsste das auch bei Bluetooth passieren.
Ich behaupte: Der Abbruch der USB Verbindung ist ein unnötiger Absturz. Und weil Microsoft jetzt die Qualität beim Datei kopieren verbessert hat, fällt das erst auf…
3 „Gefällt mir“
Hallo,
wir haben an unserer Schule auch das Problem, sowohl mit Win 10 oder Windows 11.
Ich habe mir daher heute einen Chromebook-Wagen geschnappt und mit den SchülerInnen mit Chromebooks und ChromeOS und dann mit Browser gearbeitet.
Ergebnis: Fehlermeldungen, Übertragungsfehler - keine!
Ich habe auch ein altes Laptop mit einem random Linux (hier Mint) getestet, auch hier Fehlermeldungen - keine!
Robert
1 „Gefällt mir“
@Holgi01, das sind mehrere Faktoren, die da zusammenkommen. Am besten wäre es vermutlich, wenn wir das gesondert (per Mail oder Video) klären. Das hat aber alles nichts miteinander zu tun, soviel dazu. 
Pairing Modus und das Bluetooth Icon zeigt einfach nur unterschiedliche Versionen der DAL an (also quasi dem System des minis, innerhalb der Hex-Dateien). Alte Versionen haben den Text, neue das Bluetooth-Icon.
Beim MAC kommt die HEX Datei zwar auf dem Calliope an und funktioniert, aber der MAC beschwert sich laut über das Verhalten von hier: Calliope 2.1
Das ist kein Fehlverhalten!
@Juri hat den alten Uploader mit den Hinweisen von @asp.net aktualisiert. Sollte es damit gehen, gibt es ja erstmal eine gute Zwischenlösung.
Source und .exe finden sich hier: Release v0.12.0 · calliope-edu/CalliopeMiniAutoupload · GitHub
Bei uns geht es ja, deshalb fällt es uns schwer das auszuprobieren.
Danke vielmals, bei mir hat es jetzt 5-mal nacheinander funktioniert mit der Übertragung auf Calliope mini v1.3.
Das Ändern des Pfads aber klappt nicht, es werden momentan nur Dateien aus dem Download-Ordner kopiert.
Und es wäre aus meiner Sicht praktisch, wenn sich das geöffnete Programm auch in der Taskleiste zeigen würde.
1 „Gefällt mir“
Super, danke für den Hinweis. @Juri kann da vermutlich noch etwas optimieren. 
Es hängt anscheinend mit dem Fehler beim Kopieren großer Dateien zusammen. Da gibt es aktuell ja auch mit Windows Probleme. Das soll mit einem der nächsten Updates gelöst werden…
Ich habe jetzt auch einen Computer organisiert bekommen, der den Fehler produziert.
Was bisher jedes mal klappt:
- Autoupload tool in der aktuellen Version
- Im Terminal
xcopy Quelle Ziel /z - Im Terminal
xcopy Quelle Ziel /z /j -
copy /zkann ich nur in der Eingabeaufforderung ausführen, klappt aber auch bisher jedes mal.
Bei allen anderen Wegen klappt es gelegentlich, aber eben nicht zuverlässig. Auch ist kein Muster erkennbar, mal klappt es oft hintereinander und dann gibt es mehrfach hintereinander den Fehler und ein Andermal wechselt es sich ab:
- Per GUI (Drag&Drop oder Kopieren): ca 50% Fehler.
-
copy Quelle Ziel: Klappt fast nie, aber gelegentlich dann eben doch -
xcopy Quelle Ziel: Klappt meist, ca 20% Fehler - Im Terminal
xcopy Quelle Ziel /j: ca 80% Fehler
Mit /j bei xcopy kann ich den Fehler am zuverlässigsten provozieren, sogar auf dem Windows Rechner, der von dem Fehler gar nicht betroffen ist.
Das von Jörn angesprochene Problem beim kopieren von Großen Dateien ist z.B. hier genannt: 14. März 2023 – KB5023706 (Betriebssystembuild 22621.1413) - Microsoft-Support
Dort wird xcopy mit /j als Workaround genannt, weshalb ich vermute, dass eventuell hier eine versuchte Fehlerbehebung durch Microsoft zu diesem neuen Fehler führt. Der Fehler gilt zwar noch nicht als behoben, aber Microsoft Tüftelt da schon länger mit verschiedenen Updates dran.
4 „Gefällt mir“
Für uns Lehrer oder Erwachsene sind die diversen Varianten mit copy/xcopy natürlich schon mal eine erträgliche Zwischenlösung.
Aber: Die Verwendung des Calliope soll ja für Kinder/Schüler unkompliziert sein. Und dazu darf man erwarten, dass das direkte Herunterladen eines Programms aus dem Editor auf den Calliope (ohne Zwischenspeichern der hex-Datei an einem anderen Ort und anschließender Arbeit mit Batch-Dateien oder Konsole), zuverlässig funktioniert. Sonst wird der Calliope vom kindergeeigneten Mikrocontroller zum Spielzeug von Spezialisten.
Hast du dir das Programm (https://github.com/calliope-edu/CalliopeMiniAutoupload/releases/download/v0.12.0/CalliopeMiniUploader.exe) denn angeschaut? Das macht es ja einfacher als alle anderen Möglichkeiten (die Kinder müssen ja gar nichts machen). Deshalb hatten wir das damals auch für den mini angepasst.
Die App wird natürlich als direkter Download noch von unserer Seite aus verlinkt, sobald wir noch etwas mehr Feedback haben.
Ja, ich habe die App probiert und sie funktioniert auch.
Aber bevor ich sie nutzen kann, bekomme ich folgendes Fenster:
Erst durch Anklicken von „Weitere Informationen“ kann ich die App tatsächlich starten.
Und das, obwohl auf meinem PC die Benutzerkontensteuerung auf der (nicht empfohlenen) niedrigsten Stufe steht, so dass ich diese Art von Warnungen fast niemals bekomme.
Daher erscheint mir nicht mal diese App wirklich als kindgerecht.
P.S. Ich bekomme das identische Warnfenster bei Win 10 und Win 11 (beide PCs mit allen aktuellen Windows-Updates und beide mit - anders als vermutlich den meisten - Benutzerkontensteuerung auf der niedrigsten Stufe).
Die App ist noch nicht final! Ich gehe davon aus, dass man bei Microsoft auch signierte Apps erstellen kann, die dann ohne Hinweis funktionieren.