@Juri: Vielen Dank für die Anpassung in v0.13!
Wenn jetzt auch noch ein Pfad mit mehr als 64 Zeichen möglich wäre, wäre es für mich perfekt. 
1 „Gefällt mir“
Mit v0.14 ist auch der Fehler behoben! Release 0.14.0 · calliope-edu/CalliopeMiniAutoupload · GitHub
3 „Gefällt mir“
damit der Uploader funktioniert, musst du alle hex-Dateien in in den Downloads Ordner kopieren oder aus dem Editor dort speichern
Danke für den Hinweis - ich hatte keine Anleitung gesehen (und also auch nicht gelesen). Mit dem richtigen Ordner funktioniert der Uploader tatsächlich sehr gut.
@Juri:
Danke für die neue Version des Uploaders.
Obwohl inzwischen signiert, kommt „natürlich“ immer noch - wie von dir befürchtet - das „fürsorgliche“ Warnfenster von Windows. 
Unterschiede zwischen Browsern:
Die 15 „Gedenk“-Sekunden, ehe sich das Explorerfenster nach erfolgreichem (!!!) Download (aus NEPO, aber ohne Uploader) schließt, gibt es auf meinem Rechner nur beim Firefox. Ebenso die anschließende absurde fail.txt mit time out.
Bei Chrome und Edge schließt sich das Fenster bei erfolgreicher Übertragung sofort, das Programm wird ausgeführt und es gibt keine fail.txt.
Andere Browser (Opera, Safari, …) habe ich nicht installiert und also auch nicht getestet.
(Immer noch: Calliope 1.3 und Win10)
Ich habe nicht genug Hintergrundwissen, um zu beurteilen, ob die gleichen Symptome beim Kopieren von hex-Dateien ohne gültige Dateierweiterung und beim regulären Herunterladen aus NEPO nur in Firefox auch dieselbe Ursache haben.
Hier ein verbessertes Skript. Es sind nun auch Leerzeichen im Dateipfad möglich. Außerdem wurde das Testen auf dem Mini statt mit der Datei über Volumennamen realisiert.
@echo off
setlocal enabledelayedexpansion
set "fullPath=%~1"
set "drive="
set "volumeName=Mini"
REM Test, ob der Parameter vorhanden ist, sonst Abbruch
if "%fullPath%"=="" (
exit /b
)
REM Test, ob Mini abgesteckt ist -> Laufwerksname ist MINI
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 (
if exist "%%d:\" (
for /f "usebackq tokens=6 delims= " %%i in (`vol %%d: ^| findstr /i "%volumeName%"`) do (
if not defined drive (
set "drive=%%d"
)
)
)
)
REM Abbruch, falls kein Laufwerk
if not defined drive (
exit /b
)
REM Parameter in Laufwerk, Pfad und Datei zerlegen
for /f "tokens=*" %%i in ("%fullPath%") do (
set "LAUFWERK=%%~di"
set "PFAD=%%~pi"
set "DATEI=%%~nxi"
)
REM Backslash am Pfadende löschen
if "!PFAD:~-1!"=="\" (
set PFAD=!PFAD:~0,-1!
)
REM Daten kopieren
robocopy.exe "%LAUFWERK%%PFAD%" %drive%: "%DATEI%" /z
@PAUSE
endlocal
2 „Gefällt mir“
Auch wir haben das beschriebene Problem in zwei Kursen mit (jetzt toal frustrierten Kindern).
Ich kopiere mal unseren internen Fehlerbericht hier ins Forum.
Hier nochmal die Fehlerbeschreibung:
Bei der Übertragung eines mit NEPO erzeugten Programms kommt es häufig (bei geschätzt >70% der Fälle) zu Fehlermeldungen. Das Programm wird dann nicht oder fehlerhaft übertragen und läuft nicht.
Dadurch waren Kurse beim MINT-Campus Dachau und auch der letzte Calliope-Einführungskurs für alle Beteiligten ziemlich unbefriedigend und frustrierend. Die geplante Calliope-Einführung bei der Lehrerfortbildung am letzten Dienstag musste deshalb abgesagt werden.
Bei fehlerhaften Übertragungen gab es wechselnd zwei Fehlermeldungen: „The transfer timed out.“ Oder „The hex file cannot be decoded. Checksum calculation failed.”.
Der Fehler trat bei alten Calliopes (V13) und auch bei neuen (V20) auf. Verwendet wurden HP-Laptops mit aktuellem Windows 10.
Fehlersuche:
Zunächst hatten wir die Kabel bzw. Kontakte im Verdacht. Wir haben mit sehr vielen verschiedenen Kabeln (neue und alte Calliope-USB-Kabel und andere passende Kabel) getestet: keine Änderung.
Dann haben wir die Laptops ohne und auch mit Netzteil probiert: keine Änderung.
Dann haben wir andere Laptops verwendet, einen privaten ASUS mit Windows 10, einen sehr alten Toshiba mit Windows 10: überraschenderweise hat die Übertragung mit beiden problemlos funktioniert (mit ASUS 11 Versuche, mit Toshiba 3-4 Versuche).
Beim Testen mit unseren älteren HP-Laptops trat der Fehler auf.
Im Calliope-Forum wird von diesem oder einem ähnlichen Problem unter WIN11 berichtet, insbesondere in Verbindung mit McAffee-Virenschutz.
Seit einem WIN10-Update im Mai klappt die Übertragung auch mit WIN10 teilweise nicht.
Bei uns läuft WIN10, jeweils mit neuestem Update sowohl auf den HP-Rechnern (fehlerhaft) als auch auf ASUS (allerdings mit Norton, dort fehlerfrei).
Im Forum gab es den Hinweis auf eine kleine App „CalliopeMiniAutoupload“. Damit konnten mit 2 oder 3 Versuchen Programme fehlerfrei übertragen werden. Laut Forum scheint es damit aber auch Probleme gegeben zu haben. Dort gab es aber auch ein Update. Bei uns hat das dann auch mit den HP-Laptops funktioniert.
Fazit:
Wir müssen den CalliopeMiniAutoUpload auf den Rechnern im Autostart installieren und umfangreiche Testreihen machen, ob das verlässlich funktioniert. Das wird viel Zeit kosten, aber das Desaster der letzten Kurse ist unzumutbar. Deshalb werden wir vorläufig keine Calliope-Kurse mehr anbieten. Wenn wir das Ganze mit Calliopes V13 und V20 getestet haben und es keine (=0) Übertragungsfehler mehr gibt, können wir mit Calliope weitermachen. Leider ist die aktuelle Lösung nur ein WorkAround und insofern weiterhin unbefriedigend. Wenn ein Kursteilnehmer sich einen Calliope zulegt, wird er möglichweise weiterhin frustriert. Unklar bleibt auch, warum es nur die HP-Laptops sind, die das Problem haben.
Das war ein Bedienungsfehler von mir. Da ich keine Anleitung gesehen hatte, habe ich - wie üblich - den mini als Speicherziel gewählt. Mit dem Uploader muss aber der downloads-Ordner als Speicherziel gewählt werden. Dann wird das Programm wirklich zuverlässig durch den Uploader auf den mini übertragen.
Wir müssen den CalliopeMiniAutoUpload auf den Rechnern im Autostart installieren
Das ist nicht nötig. Der Uploader ist schnell von einem USB-Stick oder - noch einfacher - aus einem Austausch-Ordner gestartet. Das sollte in Schulungen für alle Teilnehmer ohne weiteres möglich sein.
Ich fasse mal zusammen, was ich gelernt habe:
-
Ein Zusammenhang mit irgend einem Virenscanner hat sich nicht bestätigt.
-
Das Problem trat nach einem bestimmten Windows Update auf, zuerst bei Windows 11, dann bei Windows 10. Windows 8 und älter sind nicht betroffen.
-
Kopieren der .hex-Datei in das Laufwerk MINI funktioniert mit COPY und XCOPY mit dem Parameter /Z.
-
Es funktioniert auch mit dem „Uploader“. GitHub - calliope-edu/CalliopeMiniAutoupload Die .hex-Datei muss dann in den Downloads Ordner gespeichert werden. Der im Hintergrund gestartete Uploader erkennt das und kopiert die Datei gleichzeitig in alle angeschlossenen Laufwerke mit dem Name „MINI“. Es können also so viele Calliope MINI angesteckt werden wie Laufwerksbuchstaben frei sind. Die .hex-Datei landet dann auf allen gleichzeitig.
-
Uploader muss nicht installiert werden. Es ist nur die eine Datei CalliopeMiniUploader.exe zu starten. Das kann von einem Netzlaufwerk oder USB Stick erfolgen. Nur zum Herunterladen einer .exe-Datei müssen einige Sicherheitswarnungen ignoriert werden. Wenn das einmal gemacht wurde und die .exe-Datei im Netzwerk liegt, lässt sie sich in allen von mir getesteten Schulnetzwerken tatsächlich starten.
-
Mit Uploader funktioniert das Kopieren der .hex-Datei fehlerfrei (direkt aus den Web-Editoren MakeCode, NEPO, zwischen verschiedenen Netz- Laufwerken auf dem Computer oder direkter Download aus dem Internet).
-
Und es entfällt die Suche nach dem Ziel Laufwerk (Buchstabe), wohin die .hex-Datei mit Speichern unter oder durch Verbiegen des Download-Ordners gespeichert werden muss. Die Standardeinstellung (Ordner Downloads) einfach so lassen, einfach speichern und die Datei landet auf allen MINI, die an USB angesteckt sind, egal welchen Buchstabe sie erwischt haben. Voraussetzung ist nur, dass vorher die CalliopeMiniUploader.exe einmal gestartet wurde und im Hintergrund aktiv ist.
-
Mir ist nicht bekannt, dass sich jemand für die Problemlösung zuständig fühlt. Weil das Problem nach einem Windows Update auftrat, könnte man darauf warten, dass es mit einem Windows Update auch wieder verschwindet. Es ist aber auch nicht bekannt, dass Windows an irgend einer anderen Stelle ein Problem mit dem Kopieren von Dateien hätte. Es betrifft allein Calliope mini und vielleicht damit verwandte Mikrocontroller. Ob Microsoft das interessiert?
-
Und in der Mikrocontroller Familie gibt es keine Garantie, dass etwas funktioniert. Wer einen Fehler findet, kann ihn behalten. Und im Quelltext, der im Internet verfügbar ist, selber reparieren.
Ist mit einem Update der Calliope Firmware zu rechnen? Es sind ja auch noch andere Fehler drin. (Mir fällt ein, dass Motor und Servo nicht gleichzeitig funktionieren.)
Lutz
1 „Gefällt mir“
Mit dem Uploader-Tool scheint es problemlos zu funktionieren. Trotzdem bleibt das ärgerliche Ergebnis: es funktioniert nicht mit der „normalen“ Calliope-Funktion, sondern nur mit einem Workaround… Wer’s weiß, kann damit arbeiten, alle andern, die sich an den Upload-Dialog von NEPO halten, werden frustriert.
Sehr schade!
Zu deinem 8. Punkt: Zuständig sind in dem Fall ARM, ob es Fortschritte zu dem Fehler gibt, wird man wohl auch als Erstes in dem von klmi verlinkten Issue bei ARMmbed erfahren: Flashing errors with recent Windows update · Issue #1025 · ARMmbed/DAPLink · GitHub
Ob es da eine Lösung geben wird oder ARM doch versucht Microsoft zu einem Update des Kopierprozesses zu bewegen ist mir nicht bekannt, aber durchaus denkbar.
Dass alles open source ist und die Quelltexte verfügbar sind, bedeutet natürlich nicht, dass jeder Fehler selbst behoben werden muss - auch wenn man es theoretisch natürlich kann. In dem Fall liegt der Fehler in dem Repository einer großen Firma, welches aktiv gepflegt wird und das Feature „Drag-and-Drop programming“ wird in der Beschreibung gleich als erstes gelistet. Es betrifft auch nicht allein den Calliope mini, sondern alle Mikrocontroller, welche dieses Feature von ARMmbed verwenden. DAPLink/docs/USERS-GUIDE.md at main · ARMmbed/DAPLink · GitHub
1 „Gefällt mir“
hallo Jörn,
ich gehöre in meiner Schule win10 jetzt auch zu den Betroffenen, dass das Upload nicht mehr funktioniert.
The hex file cannot be decoded. Checksum calculation failure occurred.“ wie von allen bisher beschrieben wurde und hoffe auf eine Lösung, Bis Ostern hatte alles funktioniert, seitdem ist es nur nach 5 bis 7 uploadversuche möglich.
Momentan verstehe ich nur Bahnhof, denn ich halte als Lehrerin einen Calliope Kurs. Im Netzwerk meiner Schule habe ich keine Admin Rechte und weiß auch nicht wie ich das lösen soll mit dem Uploader.
Vielleicht könnte mal jemand das mit dem Uploader einfacher erklären wie es geht, der Reihe nachvollziehbar, damit man das gelöst kriegt, denn so wie es momentan aussieht kann ich meinen Calliope Kurs für’s nächst Schuljahr einmotten, wenn ich jede Woche stundenlang herumexperimentierne muss bis ich die *.hex date auf den Calliope kriege. Anleitung erbeten, bitte.
Hallo @stonym,
Ich versuche es mal mit einer Zusammenfassung. Admin-Rechte sind keine nötig.
Hier die drei Schritte:
- Das Uploader Tool von dieser Seite herunterladen: CALLIOPE | Tools
(Grauer Button „CALLIOPEMINIUPLOADER.EXE“) - Das Uploader Tool per Doppelklick auf die Datei
CalliopeMiniUploader.exestarten. - Fertig. Jetzt in MakeCode oder NEPO arbeiten und wenn der Browser beim herunterladen der HEX Datei frägt, ob und wo die Datei gespeichert werden soll einfach das Standardverzeichnis wählen (Also nur auf „Speichern“ und nicht „Speichern unter…“). Es kann aber auch sein, das der Browser so eingestellt ist, dass er gar nicht frägt. Die Datei wird dann von dem Downloads Ordner automatisch auf den mini kopiert, so lange der Uploader an ist.
Die Datei CalliopeMiniUploader.exe kann überall gespeichert sein - auf einem USB Stick, auf dem Dekstop liegen, in den „Eigenen Dateien“, auf einem Netzlaufwerk oder im „Downloads“-Ordner. Das ist für die Funktion egal.
Fallstricke können sein:
- Beim Schritt 1 kann es sein, das der Browser eine Bestätigung will, das man wirklich eine Ausführbar Datei herunterladen will
- Bei Schritt 2 kann beim ersten mal starten eine Meldung von Windows kommen, dass die Datei blockiert wurde. In dem Fall auf den kleinen Text „Weitere Informationen“ klicken und anschließend taucht unten ein Button auf, mit dem die Datei trotzdem ausgeführt werden kann.
- Bei schritt 3 kann es sein, das im Browser als Standard-Verzeichnis für Downloads ein anderer Ordner angegeben ist als der „Downloads“-Ordner. In dem fall kann in dem AutoUploader in den Einstellungen der passende Ordner eingestellt werden.
1 „Gefällt mir“
Besten Dank, werde es morgen ausprobieren im Schulnetzwerk.
Die Anleitung ist sehr ausführlich und gut zu verstehen. Melde mich, wenn es funktioniert.
Sieglinde
Hi Juri,
ich danke tausen mal, es klappt super.
Ich habe die downloader.exe als Link bei allen Schüler auf den Desktop gelegt. Jetzt müssen sie nur zu Beginn der Stunde den Link anklicken und das Fenster geöffnet lassen.
Das fertige *.hex programm herunterkaden— es überträgt siche sofort auf den Mini- superschnell- mini blinkt— alles funktioniert. Super einfach…Danke nlchmals mein Kurs ist gerettet.
Sieglinde
3 „Gefällt mir“
In dem Issue bei ARMmbed gibt es ein Update, demnach ist von Microsoft für den September ein Update geplant, mit dem der Fehler behoben wird: Flashing errors with recent Windows update · Issue #1025 · ARMmbed/DAPLink · GitHub
3 „Gefällt mir“
Hallo zusammen,
ich nutze das Upload Tool unter Windows 11. Es funktioniert zwar, allerdings vergehen zwischen Abschluss des Downloads der HEX-Datei und Start der Übertragung jedes Mal ca. 20 Sekunden, während der Uploader „Warte auf .hex Datei …“ anzeigt.
Ich habe die HEX Files aus Makecode erzeugt und sowohl in Firefox als auch in Chrome getestet. Bei beiden das gleiche. Ich sehe im Explorer, dass die HEX-Datei im Download Ordner schon lange fertig geladen ist. Aber der Uploader bekommt es erst viel später mit.
Kann man diese Wartezeit verkürzen?
Danke
Christian
Hallo,
seit Installation von KB5031445 klappt es bei mir unter Windows 10. Das Update ist m. E. die Vorschau auf November und das müsste ja offiziell morgen erscheinen.
Gruß Toni
2 „Gefällt mir“
Ich glaube, ich habe die Ursache für die 20s Wartezeit gefunden. Auf meinem Windows-Rechner sind einige Netzlaufwerke. Wenn der Rechner nicht im Netzwerk ist, kann er nicht auf die Laufwerke zugreifen. Dadurch vergehen einige Time-outs bis der Uploader das Laufwerk des MINI findet. Wenn die Netzlaufwerke verfügbar sind, habe ich auch keine Wartezeit.
Die mögliche Verbesserung des Uploader-Tools für solche Fälle wäre, dass man im Konfigurationsdialog neben dem Download-Ordner auch das Ziellaufwerk des MINI fest einstellen kann.
1 „Gefällt mir“
Moin,
ich habe ein etwas anderes Problem, darf aber wegen dieser merkwürdigen Neu-User-Regelung keinen eigenen Thread erstellen… wie dem auch sei:
Ich kann unter Windows 10 keine Programme per USB auf meinen Mini aufspielen.
Sowohl Schulrechner als auch mein eigener PC erkennen zwar den Calliope sofort und zeigen FLASH und MINI an. Auf das FLASH lassen sich zwar Dinge spielen, nicht aber aufs MINI. Der Calliope koppelt sich nach dem Kopiervorgang sofort ab und wieder an, das Programm ist dann nicht mehr drauf.
Das Problem tritt unabhängig vom Rechner, unabhängig vom USB-Kabel und unabhängig vom Calliopegerät auf. Der Auto-Uploader hilft auch nicht. Ärgerliche Geschichte, hat jeamnd Vorschläge?
Hallo,
dieses Verhalten ist normal und so gewollt. Nach dem Kopieren auf Mini wird das Programm intern verarbeitet und der Calliope neu gestartet. Damit arbeitet der Calliope das übertragene Programm ab. Du kommst an das Programm also nicht mehr ran, es erscheint nicht auf dem Laufwerk.
HG und viel Erfolg
Toni
1 „Gefällt mir“