Kannst du noch eine kurze Bedienungsanleitung dazu schreiben? Am Besten in GitHub in die README.md.
Callibot_V1/README.md at master · spsprofi/Callibot_V1 (github.com)
Ich habe ein Calli:bot2 von der Schule und suche ein irgendwie sinnvolles Anwendungsbeispiel.
(Für mich hat ein Auto 4 Räder und einen Motor. Und einen Servo zum Lenken.)
Servo plus Motor: Weiterhin kein Erfolg - Nicht kategorisiert - Calliope
Da bin ich jetzt gespannt, ob Calliope 3.0 Motor und Servo gleichzeitig verträgt???
Hier findest Du schonmal meine Callibot Codekarten. (etwas runterscrollen)
Das mit einer kurzen Beschreibung steht noch auf meiner Liste…
Programm 3 und 4 muss ich noch testen und bugfixen, hoffe, dass ich das die nächsten Tage hinbekomme.
Kurzanleitung:
Calliope Taster rot: Start / Stop
Calliope Taster Balu: Auswahl Programm 1-4 (man sieht es an den Punkten oben bei den LEDs), beim Umschalten auch Stopp
1: Stosstange
2: Ultraschallsensor (je nach Entfernung (von nah nach fern): Rückwärts Stop, langsamer, Geschwindigkeit halten, schneller, suchen wohin)
3: Liniensensoren, fahren bis Linie erkannt(ähnliches Verhalten wie Stoßstange)
4: Liniensensoren. fahren auf Linie
Mit den P0 und P3 Sensoren kann man die Geschwindigkeit für 1,3 und 4 einstellen (in 4er Schritten, signalisiert über die LEDs)
Bei Fragen gerne melden!
Wow, ich brauch noch einen zweiten…
spsprofi.github.io/CalliDispV1/
Ich versuch grad ein ssd1306 zusätzlich am Calli:bot zum Laufen zu bringen.
Sobald ich aber das Display anspreche bekomme ich einen Fehler beim Kompilieren, den ich nicht lokalisieren kann. Ich habe bereits versucht das Ganze in V3 zu probieren. Dort habe ich allerdings Schwierigkeiten die Kalli:bot Erweiterung von oben einzubinden. Sie taucht in der Explorer-Ansicht auf aber nicht als Blöcke zum auswählen/in Python.
Gibt es noch etwas was ich vergessen habe?
Würde mich über Tips freuen! Vielen Dank!
Die schnelle Lösung ist: Schreibe in den Projekteinstellungen in pxt.json bei bluetooth überall Nullen rein. Dann kommt kein Fehler beim Kompilieren. Ob es dann funktioniert, wäre interessant…
Erklären kann ich das, wenn ich mehr Zeit habe.
"yotta": {
"config": {
"microbit-dal": {
"bluetooth": {
"pairing_mode": 0,
"partial_flashing": 0,
"dfu_service": 0,
"event_service": 0,
"device_info_service": 0
},
"stack_size": 1280,
"gatt_table_size": "0x300",
"sram_end": "0x20004000",
"RAM_SIZE": "\"16K\""
}
}
}
Super. Vielen Dank für die schnelle Hilfe!
So, das war eine große Hilfe. Ich hab einen ganzen Abend versucht das hinzubekommen. Zig mal neue Projekte angelegt, in unterschiedlichen Reihenfolgen meine zwei lauffähigen Projekte vereinigt…war schon kurz davor den Calliope an den Nagel zu hängen.
Jetzt läuft mal das Display mit und zeigt ein paar sinnvolle Dinge an, wie die Programm-Nummer, Geschwindigkeit, Schritt-Nummer und Entfernung. Das erleichtert die Diagnose etwas…
Also nochmal vielen Dank!
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
Hallo Lutz,
Ich habe eher beim Kompiler als bei den GitHub Repositories angesetzt und mich auf die Suche nach einer Alternative gemacht. Das einzige was ich noch gefunden hab war TigerJython. Aber da bin ich dann mit den Erweiterungen auch nicht so einfach vorwärts gekommen und die Auwahl der mitgelieferten ist doch eher begrenzt. Da bin ich doch lieber bei MakeCode geblieben.
Ich hatte auch nicht das Gefühl, dass mir TigrJython beim Kompilieren viel mehr Informationen liefert.
Bei MakeCode war das große Problem für mich, die unspezifische Angabe, dass beim Kompilieren etwas schief gelaufen ist, ich jedoch nicht herausfinden konnte, was das genau war, keine Logs o.Ä.
Die neue Calli:bot2 Erweiterung habe ich mir angeschaut. Denkst Du, dass es Sinn macht, diese in meinem Projekt zu integrieren? Und bei der Ansteuerung des OLEDs versuche ich auch mal die verlinkte Erweiterung zu nutzen, so dass I2C Traffic minimiert wird.
Die Datenblätter der Displays hab ich auch schon studiert. Ich hab noch ein 1315er Display rumliegen. Dafür wollte ich noch etwas machen, das den gelben und den blauen Bereich gesondert anspricht. Eventuell mit Grafiken im gelben Bereich für die Betriebszustände. Außerdem reizt mich das Scrollen noch…vielleicht etwas für lange kalte Winterabende…
Aber vorher hab ich noch ein anderes Projekt:
Ich hab meinen alten Fischertechnik Roboter (30572) wieder ausgegraben. Mit Lichtschranken für die Positionierung der Achsen. Bin gerade dabei die Hardware für die Ansteuerung zu machen…
Und für mich als Anwender ist es toll, dass es doch recht viele und auch recht ausgereifte Erweiterungen gibt. Dafür auch Dir vielen Dank! Ich sehe auch die Arbeit, die dahinter steckt!
Viele Grüße, Ronald
Hallo Ronald,
du programmierst Python, daraus entsteht automatsch JavaScript und daraus die Blöcke? Brauchst du die Blöcke überhaupt? Ich denke, die kann man auch abschalten.
Bei den Ereignissen fällt mir auf, dass du Touch-Pins verwendest. Es ist auch möglich mit den Tasten ein zweites Ereignis auszulösen: lange geklickt oder halten. Das geht dann zusätzlich zu geklickt. Du musst von Eingabe - mehr den untersten Block drüber schieben.
Das Yellow&Blue Display SSD1315 kannst du einfach anstecken. Das ist kompatibel mit dem SSD1306.
Ich bin natürlich daran interessiert, dass jemand meine Erweiterungen nutzt. Für das Display brauchst du aber auch den EEPROM.
UPDATE:
Ich habe die Erweiterung calliope-net/oled-16x8 jetzt mit Objektvariablen programmiert und außerdem kann das Display auch ohne EEPROM benutzt werden. Dazu muss die Erweiterung calliope-net/oled-eeprom zusätzlich geladen werden und die 6 Arrays müssen direkt übergeben werden (anstatt sie auf den EEPROM zu programmieren). Die 6 Arrays haben je 16 Elemente für je 16 Zeichen aus 8x8 Pixeln. Das sind ASCII Zeichen von 0x20 bis 0x7F.
6 Arrays je 16 Elemente kommen mit keiner Bluetooth Einstellung in Konflikt und funktionieren auf jeder Version von Calliope. Bei Problemen bitte melden!
Die I2C-Adressen werden beim Calliope mini 3 übrigens getrennt behandelt, interne Komponenten haben dann keinen Einfluss mehr auf die Adressen von externen Geräten!
Stimmt. Das einzige I²C Modul, das ich nicht zum laufen bekommen habe, funktioniert jetzt am Calliope mini V3.
Diese wichtige Änderung (getrennter I²C Bus) sollte auch in der Hardware-Beschreibung stehen.
Wenn du dieses Paket abänderst kannst Du auch noch Jacdac zu deinem Paket hinzufügen
Idealerweise in einem Unterverzeichnis wie hier beschrieben
https://microsoft.github.io/jacdac-docs/ddk/microbit/software-only-accessory/
(Dann ist dein Wochenende mal wieder voll 
)
Komm grad zu nichts. Aber V3 kommt heute. Meine Fischertechnik Erstazteile liegen bereit…hoffe auf die Weihnachtsferien…