32KB ist weniger als 16KB

Software Fragen und Probleme Fragen zu MakeCode/PXT
1

Ich habe hier ein Programm aus dem Forum schon gekürzt (die 3. Erweiterung für die Speicherkarte entfernt). Die 16KB Version läuft auf zwei Calliope (1.3 und 2.0 mit jeweils Display und GPS Modulen) längere Zeit stabil. Die angezeigten Werte sind sehr ähnlich.

Wenn ich das Programm im MakeCode auf 32KB umschalte und speichern will, kommt der Fehler Kompilierung fehlgeschlagen. Hier ist die 32KB Version:

Und hier hat @CalliTGS3 festgestellt: „Programm zu groß“.

Nun kann das Ziel ja nicht sein, alte Versionen von MakeCode zu benutzen…

Weitere Effekte mit der Kompilierung 32KB schreibe ich in einen anderen Beitrag.

Lutz

2

Ja, da stimmt was nicht mit der Umschalterei. Auch bei mir ist trotz 32kb nicht mehr Platz. Die einzige Abhilfe ist es bluetooth zu deaktivieren. Und die neue makecodeversion verbraucht mehr Platz wie die alte.

Michael

3

Der Calliope mini 2 hat zwar 32 kB RAM, aber der Flash Speicher ist mit 256 kB identisch zu dem Calliope mini 1. MakeCode prüft beim Download nicht die Nutzung des RAM, sondern ob das Programm in den Flash passt. Die Bluetooth Erweiterung (Bluetooth Stack) ist teil des Programms.

Bei den Einstellungen mit 32 kB RAM ist der Bluetooth Stack größer, da dort u.a. auch Partial Flashing und weitere Services aktiviert sind. Daher ist zwar mehr RAM verfügbar, aber das Programm selbst hat weniger Platz als mit den 16 kB Einstellungen, bei welchen der Bluetooth Stack kleiner ausfällt.

Wir haben gerade ein Update gemacht, mit dem die Größe des Bluetooth Stacks für den Calliope mini 2 wieder etwas reduziert wird und auch sonst einige Parameter etwas optimiert sind. Wenn das von Microsoft akzeptiert wird kann es unter der Beta URL getestet und dann kommende Woche hoffentlich auch veröffentlicht werden. ( Update default settings for mini 1 and mini 2 by Amerlander · Pull Request #222 · microsoft/pxt-calliope · GitHub )

Die Einstellungen mit 16 kB werden aufgrund der nicht aktiven Funktion „Partial Flashing“ auch weiterhin ein etwas kleineres Programm erzeugen, aber der Unterschied ist nicht mehr so groß. Das verlinkte Programm „32GPS-Tracker“ kann dann jedenfalls wieder mit beiden Einstellungen aus MakeCode geladen werden.

4

Vielen Dank für die logische Erklärung. Jetzt suche ich aber den Sinn, wofür die Vergrößerung des RAM von 16KB auf 32KB nützlich sein soll. Wenn nicht für das Programm nutzbar, dann müsste ich ja im laufenden Programm Daten erzeugen, um den RAM zu füllen. Also Variablen und Arrays?

Gibt es überhaupt ein Beispiel-Projekt, das auf die 32KB angewiesen ist und mit 16KB nicht läuft?

Ja, Partial Flashing funktioniert, aber nur wenn das zuletzt geladene Programm bereits ein 32KB Programm ist. Spielt man ein 32KB Programm über ein 16KB Programm, soll ja kein Partial Flashing funktionieren, aber die Bluetooth Übertragung bricht komplett ab. Bluetooth ist kaputt bis zum Laden des Demo-Programm 25.

Ist der Fehler auch behoben? Kann man die Versionen jetzt mischen?

Und ist irgendwo dokumentiert, wieviel Bytes welche Variablen belegen, speziell die numerischen? Wie kann ich z. B. ein Array von Bytes (mit 8 Bit) erzeugen? Und gibt es Grenzen z.B. der Elemente im Array? Oder geht es bis die 32KB voll sind?

Das oben genannte gilt für MakeCode.

Ist bei NEPO auch zwischen 16KB und 32KB zu unterscheiden oder umzuschalten?

5

Der Fehler nicht zwischen den Versionen wechseln zu können sollte dann behoben sein. Unter Android ganz, unter iOS innerhalb von MakeCode. Irgendwo ist noch ein Caching aktiv, durch den der Wechsel von NEPO auf MakeCode nur mit dem Umweg über das Demoprogramm (das aber per Bluetooth übertragen werden kann) oder Programm 25 klappt. Da hoffe ich aber, dass das noch innerhalb der iOS App behoben werden kann.

In NEPO ist immer nur die 16KB Einstellung aktiv, so wie der Editor angelegt ist wird dort nicht so viel RAM gebraucht, so dass dort trotzdem Partial flashing aktiv sein kann.

Neben Variablen und Arrays wird der RAM in MakeCode beispielsweise verwendet, wenn die Eventblöcke eingesetzt werden (Button A, B, Pin 0-3). Wird text auf dem Display durchgescrollt dauert das je nach textlänge auch mal länger. Wird in der Zeit dann über ein Eventblock auch versucht etwas auf dem Display darzustellen merkt sich der mini das so lange, bis der erste Text fertig ist und zeigt dann das nächste an.

Bei 16 KB, geladenem Bluetooth-Stack und mehreren Events kann der RAM dabei vollaufen und der mini hängt sich auf. Auch wird das Programm ja während der Ausführung im RAM gehalten, so dass mit steigender Komplexität die Wahrscheinlichkeit den RAM voll zu kriegen steigt - mit Partial flashing aktiv würde das bei 16KB RAM schon bei den einfachsten Programmen fast sofort passieren.

Wenn das Programm aber auf 16KB stabil läuft und Bluetooth gar nicht genutzt wird gibt es tatsächlich keinen wirklichen Grund auf 32KB zu wechseln. Ansonsten ist bei 32KB eben Partial Flashing aktiv, was das übertragen etwas angenehmer macht.

So weit ich weiß gibt es bei den Arrays kein Limit, außer, dass der verfügbare RAM ausreichen muss. Über die Blöcke wird nur zwischen Number und String unterschieden, aber wenn du in der JavaScript ansicht bist kannst du Buffer verwenden und dort auch die typen angeben:

  • Int8LE: one byte, signed, little endian
  • UInt8LE: one byte, unsigned, little endian
  • Int8BE: one byte, signed, big endian
  • UInt8BE: one byte, unsigned, big endian
  • Int16LE: two bytes, signed, little endian
  • UInt16LE: two bytes, unsigned, little endian
  • Int16BE: two bytes, signed, big endian
  • UInt16BE: two bytes, unsigned, big endian
  • Int32LE: four bytes, signed, little endian
  • Int32BE: four bytes, signed, big endian
let darkness = pins.createBuffer(60 * 4);
input.onButtonEvent(Button.A, input.buttonEventValue(ButtonEvent.Click), () => {
    for (let i = 0; i < 60 * 4; i++) {
        darkness.setNumber(NumberFormat.UInt8LE, i, input.lightLevel())
        basic.pause(60000)
    }
})
1 „Gefällt mir“
6

Nun habe ich viele .HEX-Dateien, die in verschiedenen Schulen auf verschiedenen Calliope 1 und 2 geladen werden sollen. Einer .HEX-Datei sehe ich aber nicht an, ob sie 16KB oder 32KB ist. Nach der Beschreibung müsste das Programm erst mal überall in den 256KB Flash passen. Und wenn es klein ist auch eine 32KB Version auf Calliope 1 laufen.

Allerdings passiert gar nichts, wenn ich eine 32KB .HEX-Datei erwischt habe und auf einen 1.3 lade. Daran werden viele Schüler scheitern. Wie können wir in Schulen damit umgehen?

Bei MakeCode muss in der .HEX-Datei der ganze Quellcode mit Kommentaren und Blöcken drin sein. Wird das alles in den 256KB Flash geladen oder vorher aussortiert? Was kein Code ist, wird ja dort nie wieder gebraucht.

Und die Firmware, die in der Hardware ist, kann ja eigentlich nichts außer eine .HEX-Datei über USB empfangen? (Und die 25 Programme rüber kopieren.) Wenn schon Bluetooth jedes Mal wieder neu mit übertragen werden muss.

Das heißt aber auch, Fehler (z.B. bei Bluetooth und iPad) behebe ich nicht durch ein Update „auf der Leiterplatte“, sondern ich muss jede .HEX-Datei in MakeCode importieren - und dann neu speichern? Und was muss ich in MakeCode damit machen?

Also: Das Bluetooth Update wird in MakeCode gemacht, aber in allen vorhandenen .HEX-Dateien bleibt der Fehler drin.

7

Bei 16KB-Calliopes klappt die Speicherzuweisung nicht, wenn die HEX für 32KB erstellt wurde und kann daher dann nicht ausgeführt werden. Wenn beide Calliope Versionen verwendet werden würde ich einheitlich die 16KB Varianten verwenden, wenn ich mit den Hex Dateien arbeite (die ja vermutlich dann per USB oder aus dem Flash-Laufwerk geladen werden).

Die erste Übertragung beim programmieren per App ist dann ohne Partial Flashing. Alle weiteren Übertragungen mit, wenn man dort das 32KB Template gewählt hat. Da in der App ja direkt übertragen wird sollte die 32KB-Hex-Datei auch nirgendwo wieder auftauchen und daher keine Kompaitibilitätsprobleme verursachen.

Die Bluetooth Einstellungen sind teil der Hex-Datei, von daher ist es grundsätzlich richtig, das man sich mit jeder alten Datei auch wieder alte Einstellungen aufspielt.
Die Änderungen in dem Update jetzt betreffen aber in erster Linie das Template für 32KB, das unter der Überschrift „Neues Projekt (iOS)“ steht. Wer das Template mit 16KB verwendet hat oder ganz regulär über „Neues Projekt“ gegangen ist hat eine Hex Datei, die die selben Einstellungen enthält wie auch die aus dem kommenden Update.

Wurde die Hex-Datei mit einer älteren MakeCode Version erstellt können die Bluetooth Einstellungen abweichend sein, z.B. war früher ja immer das drücken von A+B+Reset nötig, um den Calliope per Bluetooth sichtbar zu machen. Aber grundsätzlich sollten auch die älteren Dateien, die über „Neues Projekt“ erstellt wurden kompatibel sein.

Wenn man allerdings eine Hex-Datei hat, welche ungewünschte Einstellungen hat und man diese umwandeln möchte reicht es nicht die nur in MakeCode zu laden - dabei werden in dem Projekt auch die Einstellungen geladen, welche in der Hex Datei verwendet sind. Man muss also zusätzlich entweder in die JavaScript Ansicht wechseln und den Code in ein neues Projekt kopieren, oder in die Projekteinstellungen, auf „Einstellungen als Text bearbeiten“ und dort dann alles unter „yotta“ löschen.

Noch ist das Update aber nicht mal als Beta verfügbar, von daher heißt es vorerst ohnehin erst einmal abwarten.

Beim übertragen wird die Hex Datei ausgelesen und nur der eigentliche Programmteil in den 256KB flash Speicher geladen. Der ganze overhead von MakeCode wird verworfen und vom mini weder gelesen, noch gespeichert.

Das übertragen macht der Bootloader und dieser macht tatsächlich nicht viel mehr als das aufspielen der HEX Datei auf den Interfaceprozessor.

In der HEX Datei ist das vollständige Programm, das direkt auf dem Prozessor ausgeführt wird. Die Hex-Datei ist also nicht nur ein Programm, das auf einem Betriebsystem auf dem mini installiert wird, sondern sie ist sozusagen selbst das ganze Betriebssystem. Und neben dem von Nepo und MakeCode genutzten System (ARM mbed OS) gibt es auch alternativen, wie z.B. „Lancester Runtime“, „RIOT OS“, „Zephyr“ oder „Apache Mynewt“.

2 „Gefällt mir“