Ich war auch kurz davor… Dann wurde mir bewusst, von dem was jemand bei GitHub veröffentlicht darf ich nicht erwarten, dass es meinen Vorstellungen entspricht. Die Repositories sind meistens beim ersten Versuch stehen geblieben, der vor 4 oder 5 Jahren war. Forken bedeutet, die Fehler der anderen zu übernehmen und eigene dazu zu machen. Das ist bei einigen Erweiterungen, die in MakeCode verlinkt sind, leider passiert. Da funktionierte die alte Version noch und die Neue nicht länger als ein paar Minuten.
Ich habe hier versucht die Geschichte zu dokumentieren, damit ich vergleichen kann:
CALLIOPE für Programmierer
Das Problem ist genau das, was du auch hattest: Der I²C Bus wird aus verschiedenen Threads aufgerufen (RTC Uhr, LCD 16x2).
Das OLED 16x8 (SSD1306 und andere) kann nur Pixel und man muss die Zeichen im Code erzeugen. Bei der Erweiterung steht der Zeichengenerator in einem großen Array.
Die Menge der Daten (der Speicherplatz) ist aber gar nicht das Problem. Ein Array mit mehr als 32 Elementen ist das Problem. Mehrere Arrays mit je 32 Elementen funktionieren nämlich:
Warum größere Arrays funktionieren, wenn Bluetooth deaktiviert ist, lässt sich also nicht mit vollem Speicher begründen. Ich schätze, beim Calliope3 besteht das Problem weiter, weil es in der Software liegt.
In der Erweiterung für das Display gibt es auch eine pxt.json Datei und dort drin ist Bluetooth deaktiviert. Sonst würde die immer an dem großen Array scheitern. Egal welche Calliope Version. Bei 2.1 gehen auch nicht mehr als Elemente in ein Array, jedoch viele Arrays mit bis zu 32 Elementen.
Wenn jetzt das Projekt eigene Bluetooth Einstellungen in pxt.json hat, die mit denen in der Erweiterung im Konflikt stehen, kann der Compiler Fehler kommen. Das weiß ich aber nicht.
Ich bin also I²C auf den Grund gegangen und habe nichts geglaubt, was andere programmiert hatten.
An dem OLED 16x8 (SSD1306 und andere) bin ich beim ersten Versuch gescheitert, weil ich nicht verstanden habe warum der Code überhaupt funktioniert. Es wird jedes Byte einzeln in einen Buffer gepackt und über den I²C Bus ans Display geschickt. Eine Zeile sind 128 Datenpakete (mit Adresse, Steuerzeichen, …) über den Bus.
Als ich dann das Datenblatt verstanden hatte, konnte ich die ganze Zeile und davor die Cursor Positionierung in einem einzigen Buffer übertragen. Datenverkehr auf vielleicht 20% reduziert.
OLED neu erfunden, 2 Displays, 1 EEPROM, 1 Stecker, i2c
Und weil die EEPROM Erweiterung schon fertig war, habe ich den Zeichengenerator aus dem Code in den EEPROM verlegt. Funktioniert ohne Array, aber nicht ohne EEPROM mit programmiertem Zeichengenerator. Mit 2 Displays und Hochformat.
Um auf den CalliBot zurück zu kommen. Auch die Erweiterung ist alt. Ich habe von Knotech eine Liste mit neuen I²C Registern bekommen, die ab V 2 gelten. Die Hardware entwickelt sich, die Software wird der Community überlassen?
Ich habe es als Herausforderung gesehen:
Komplett neue I²C Erweiterung für CalliBot ab Version 2.
FG Lutz