MakeCode Betaversion (6.0.24)

Es gibt eine neue MakeCode Beta-Version.
Ihr könnt diese unter makecode.calliope.cc/beta aufrufen.
Folgende Dinge haben sich geändert:

  • Update auf Version 6.0.24
  • Die Auswahl des jeweiligen Calliope mini (1, 2 oder 3) ist nun integriert und die RAM-Größen/Bluetoothintegration dementsprechend optimiert.
  • Jacdac integriert
  • WebUSB (für Calliope mini 3) integriert
  • Erweiterungen sind nun schneller erreichbar
  • Die Suche der Erweiterungen funktioniert nun
  • Alle Strings sind wieder übersetzt
  • Bluetooth modifiziert und aktualisiert. → Die neue App erscheint in der kommenden Woche und wird dann eine einmalige Kopplung durchführen. Dies soll zu einer besseren Verbindung im Unterricht beitragen.

Bitte gern testen und Probleme bitte hier: Issues · microsoft/pxt-calliope · GitHub posten.

2 „Gefällt mir“

Ich habe versucht, meine Beispiel Projekte von GitHub zu laden. Dabei treten grundsätzlich diese Fehler auf:

Property ‚setLedColor‘ does not exist on type ‚typeof basic‘.
Property ‚turnRgbLedOff‘ does not exist on type ‚typeof basic‘.
Property ‚rgb‘ does not exist on type ‚typeof basic‘.

Diese Fehler werden aber nicht angezeigt. Stattdessen verschwinden alle Blöcke, die diese Befehle enthalten. Also es verschwinden die kompletten Ereignisse oder Funktionen. Das Bild der Blöcke ist dann sehr übersichtlich bis fast ganz leer.

Ich habe dann den JavaScript Code aus der aktuellen MakeCode Version kopiert. Dann werden oben genannte Fehler angezeigt und ich kann die rgb Blöcke löschen. Dann ist kein Fehler mehr, aber das Umschalten auf Blöcke scheitert.

Mit Importiere URL habe ich folgende Beispiele geladen:
calliope-net/i2c-test
calliope-net/i2c-uhr-stellen
calliope-net/i2c-speicherkarte-verwalten
calliope-net/i2c-keypad-gpio-7segment
Keines davon hat noch alle Blöcke angezeigt, die mal da waren. Ursache können die fehlenden RGB Befehle sein.

Hier waren keine RGB Befehle drin, es wurden alle Blöcke angezeigt:
calliope-net/uhr-speicherkarte-dipschalter-lcd
Compiler Test:
Als Datei herunterladen OK
Hardware auswähen und danach Als Datei herunterladen:
v1:program too big by 1296 bytes
v2:program too big by 1296 bytes
v3:OK
kann nicht mehr für v1 oder v2 kompiliert werden

calliope-net/i2c-test
nach Entfernen der RGB Blöcke:
Hardware auswähen und danach Als Datei herunterladen:
v1:program too big by 2020 bytes
v2:program too big by 2020 bytes
v3:OK

Ergebnis: Abgesehen von den RGB Fehlern können Projekte, die länger als eine Unterrichtsstunde dauern (oder mehr Blöcke haben als auf den Bildschirm passen) nur mit V1 programmiert werden, weil sich bei V2 der Compiler weigert: program too big.

Wenn ich allerdings unter Hardware auswählen ein altes V1 Projekt auf V1 stelle, bringt der Compiler den selben Fehler program too big wie bei V2. Es scheint auch mit neuer V1 nicht mehr möglich zu sein, den Programm Speicherplatz wie in der alten V1 zu bekommen.

Ist bei V3 eigentlich mehr als 256 kB Flash Speicher in der Hardware? Das ist ja das Problem, an dem bereits der Compiler scheitert, nicht der RAM. Die Projekte kommen ja gar nicht auf der Hardware an, wenn der Compiler keine HEX Datei macht.

Diese kleine Projekt habe ich in der MakeCode Beta mit V1 neu erstellt:

Compiler Fehler:
program too big 32 bytes!
Das funktioniert natürlich im alten MakeCode.

Das Teilen geht noch nicht:

Aber von GitHub kann man es laden:
calliope-net/beta-calli2: Ein MakeCode-Projekt (github.com)

Hier konnte zum ersten Mal der Edge ein vollständiges Repository anlegen. Das hat noch nie geklappt.

Viele neue Features, aber kein Platz mehr für das eigene Programm.
Oder spinnt hier tatsächlich nur der MakeCode Compiler?

Den Fehler »program too big x bytes!« bekommst du weg, wenn du in die Einstellungen gehst und »Partielles flashen« deaktivierst. Damit kann ich sowohl calliope-net/uhr-speicherkarte-dipschalter-lcd als auch beta-calli2 für den mini 1 und mini 2 ausspielen. Für den mini 3 geht es auch mit partiellem Flashen.

Du kannst die geteilte URL aus dem beta Editor auch über die Importfunktion „url importieren“ laden. Für Projekte, die mit einer neueren MakeCode Version als die aktuelle Version erstellt wurden, ist das auch immer nötig.

Die verschwindenden Blöcke schaue ich mir gerade noch an, das soll so natürlich nicht.

Das Problem mit den Grenzen: Array 32 Elemente und Buffer.length 240 Byte besteht weiterhin. Aber es lässt sich bei V2 mit

Bluetooth nur laden, wenn der Pairing-Modus aktiviert ist (A+B und kurz die Reset-Taste gedrückt halten)

was

„enabled“: 0

hinzu fügt, nicht mehr abstellen.

let list = [0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]
basic.showNumber(list.length)

mit 33 Elementen, V2 und enabled:0 stürzt auf dem Calliope 2.1 jetzt auch ab. Mit dem alten MakeCode hat das mit enabled:0 funktioniert.

{
    "name": "array-grenzen",
    "description": "",
    "dependencies": {
        "core": "*",
        "v2": "*"
    },
    "files": [
        "main.blocks",
        "main.ts",
        "README.md"
    ],
    "preferredEditor": "tsprj",
    "yotta": {
        "config": {
            "microbit-dal": {
                "bluetooth": {
                    "enabled": 0
                }
            }
        }
    }
}

Nur mit V1 können Arrays mehr als 32 Elemente haben.

V2 per Konfiguration „enabled“:0 ebenfalls mehr als 32 Elemente zu erlauben, funktioniert nicht mehr.

Hier stürzt es übrigens nicht im Compiler, sondern erst nach der Übertragung auf Calliope 2.1 ab, 3 ist noch nicht vorhanden…

Beim Calliope mini 3 (nur Hardwareauswahl, keine Änderung an den Einstellungen) habe ich bei einer Arraygröße von 1364 Elementen aufgehört zu testen! :wink:
Allerdings nutzt der Calliope mini 3 auch die neuere CoDAL und nicht mehr die DAL…

Im beta Editor unterscheiden sich mini 1 und mini 2 nur in den Einstellungen zum RAM und ob Bluetooth enabled auf 0 oder 1 steht.

Mein Eindruck ist aber, dass das Umschalten noch immer nicht zuverlässig angewendet wird. Erst nachdem ich zusätzlich in den Textmodus der Einstellungen gewechselt bin, wurde die Hex Datei auch mit der gewählten Einstellung ausgespielt.
Wenn die Einstellung mit dem Teilen Link auch noch aktiv ist, kannst du hier 33 Array-Elemente mit dem mini 2 Template testen: Ohne Titel

Die beiden Vorlagen unterscheiden sich nur in den drei Einstellungen:

"sram_end": "0x20008000", // 0x20004000
"RAM_SIZE": "\"32K\"", // 16K
"bluetooth": {
    "enabled": 1 // 0
}

Die Beta ist jetzt auf 6.0.26 geupdated.
Die Einstellungen scheinen zu haken, ich habe dazu hier ein Issue aufgemacht: Settings not applied in GUI · Issue #264 · microsoft/pxt-calliope · GitHub
In dem Video in dem Issue sieht man, dass die Einstellung erst angewendet wurde, nachdem im Textmodus ein Absatz eingefügt wurde. Manchmal klappt es auch so, aber manchmal scheint das zu hängen.

Importieren, auf mini 2 stellen und direkt herunterladen konnte ich:
calliope-net/i2c-uhr-stellen
calliope-net/i2c-keypad-gpio-7segment

Zusätzlich in den Einstellungen musste ich "partial_flashing": 0 setzen, um die Hex auch herunterladen zu können:
calliope-net/i2c-speicherkarte-verwalten
calliope-net/uhr-speicherkarte-dipschalter-lcd

Hier musste ich zusätzlich die Storage Erweiterung laden, da die Blöcke nicht mehr in den Standard blocken sind. Außerdem sowohl partial flashing als auch bluetooth deaktiviert, das Programm ist dann aber noch immer 52 byte zu groß (davor 2100). In mini 1 und mini 2:
calliope-net/i2c-test

Die Storage Blöcke sind jetzt in die Erweiterungen gerutscht. In dem i2c Paket könnte die Erweiterung als abhängigkeit hinzugefügt werden - ich hab dazu einen PR erstellt: Storage Erweiterung als Abhängigkeit hinzufügen by Amerlander · Pull Request #1 · calliope-net/i2c · GitHub

Das Problem mit den Arrays, die bei aktiviertem Bluetooth nicht größer als 32 Elemente sein können, scheint ein Bug zu sein. Allerdings habe ich noch nicht versucht ihn in den microbit samples zu reproduzieren und kann daher nicht sagen, ob das in MakeCode oder in der DAL entsteht.

Hallo @Juri ,
vielen Dank für die Reparaturen und Tests. Die Storage wird gar nicht gebraucht. Es musste nur die Erweiterung i2c aktualisiert werden, dort ist der Code nicht mehr drin. Ich habe calliope-net/i2c-test aktualisiert. Damit habe ich folgendes getestet:

Was du in dem Video zeigst, tritt bei mir auch auf. Die in pxt.json angezeigten Einstellungen sind nicht immer wirksam. Zuerst ist oben „v2“ nicht erschienen, obwohl ich zweimal die Hardware (über die 3 Punkte) auf V2 eingestellt hatte. Wenn v2 dann oben steht, kommt manchmal der Fehler 2044 Bytes fehlen. Ich habe mit dem Schalter partial_flashing deaktiviert, es steht auch in der pxt.json Ansicht drin. Dann habe ich an der Konfiguration nichts mehr geändert.

Ich habe nur noch zwischen Blöcke und Projekteinstellungen - Einstellungen als Text bearbeiten hin und her geschaltet. Beim Herunterladen, was man in beiden Ansichten klicken kann, kommt manchmal der Fehler 2044 bytes! und manchmal nicht. Das ändert sich mit nicht nachvollziehbarer Logik. Aber wenn ich pxt.json sehe, der Fehler kommt, und ich füge ein Zeichen in die Datei ein, dann kommt der Fehler nie und die HEX Datei wird angeboten. Danach auf Blöcke geht es auch und wieder zurück in die pxt.json Ansicht kommt der Fehler wieder.

In V 6.0.26 sind die RGB Blöcke wieder da, allerdings nicht in deutsch (4 Blöcke unter Grundlagen sind englisch).

Ja, die RGB Blöcke hatten wir verschoben und jetzt wieder zurückgeschoben, da das laden der Board Version mini 1 nicht als Default funktionierte (Set default board version · Issue #263 · microsoft/pxt-calliope · GitHub)

Die Übersetzung sollte dann bald wieder da sein.

Nach meinem Stand sind jetzt die Motorblöcke die einzigen, welche bei einem Import eines alten Programms nicht gefunden werden und erst keine Fehler mehr anzeigen, wenn die Board-Version manuell gewählt wurde.

1 „Gefällt mir“

Wenn ich die Hardware in der Blockansicht einstelle, klappt es bei mir immer von v1 auf v2 und v3 zu wechseln - wenn ich aber in den Einstellungen im Textmodus bin, während ich die Hardware auswähle, klappt es zuverlässig nicht.

Bei Projekten, die bei GitHub liegen, kannst du die gewünschten Einstellungen und Boardversionen auch schon in die PXT.json mit hineinschreiben.

Mit den Änderungen kann ich z.B. das Projekt Amerlander/i2c-test direkt für den mini 3 laden mit ble and partial flashing deaktiviert: default to v3 · Amerlander/i2c-test@0401ebb · GitHub

Über die Branches oder Version Releases kann man so auch verschiedene Boards abdecken (oder die alten MakeCode Versionen weiter unterstützen): Amerlander/i2c-test#v1 Amerlander/i2c-test#v2

Ja, wenn ich die Programme für den Fischertechnik Baukasten mit Motor
elssner/ft-trockner
elssner/ft-schranke
lade, fehlen Blöcke ohne Fehlermeldung. Man wird nicht gewarnt.

Ich kann dann Hardware v1 auswählen. Und dann in der GitHub Ansicht die Blöcke zurücksetzen. Dann sind sie da. Bei einem falschen Klick ist aber noch mehr weg als am Anfang.

Wenn ich nun in alte Programme v1 einfüge, was passiert dann im aktuellen MakeCode? Ich sehe erst mal einen roten Punkt und nichts drunter.
image

Was passiert eigentlich, wenn ich Erweiterungen programmiere und in pxt.json der Erweiterung v1, v2 oder v3 drin steht? Das kommt dann mit der Hardware Konfiguration des Projektes in Konflikt, das die Erweiterung lädt?

Ja, die Abhängigkeit zu den Versionspaketen in die Erweiterung zu schreiben kommt vermutlich den User-Einstellungen in die Queere. Das also nur bei Projekten, die importiert werden sollen und nicht bei Erweiterungen, die in bestehende Projekte geladen werden machen.

Wenn du über „importieren → github → neues Projekt“ gehst, sollte in der pxt.json aber auch keine Boardversion drin stehen (ob das anders wird, wenn das Default laden des v1 Boards behoben wird weiß ich allerdings nicht). Ansonsten beim committen eben darauf achten, dass die nicht mit reinkommt.

Du kannst aber Dateien nur abhängig von anderen Erweiterungen laden:

    "fileDependencies": {
        "custom-a.ts": "v2", // Lädt nur, wenn der mini 2 ausgewählt ist
        "custom-b.ts": "v1 || v2", // Lädt beim mini 1 und 2
         "custom-b.ts": "!v3" // Lädt nicht beim mini 3
    }, 

Bei pxt-jacdac wird das u.a. gemacht, um nach der Editor-Variante zu unterscheiden: https://github.com/microsoft/pxt-jacdac/blob/78e2c68b85363e580cc4c757fdce89a032e990f9/pxt.json#L73

Da die /beta nun zur aktuellen Version geworden ist, schließe ich dieses Thema.
Bei Fragen oder Anmerkungen einfach ein neues Thema eröffnen oder ein Issue bei GitHub (s.o.) anlegen.