Ich werd seit Wochen eine Idee nicht los, die nicht spezifisch für den Propeller ist, aber sich leicht erstmal mit diesem unter Linux und realisieren läßt. Mit ein paar kleinen Änderungen würde dies auch mit anderen Coprozessoren und Betriebssystemen klappen.
Was mir vorschwebt, ist Code für andere Prozessoren von der Shell aus zu benutzen wie native Programme.
Man könnte dazu beispielsweise einem Propeller-Binary eine Shebang-Zeile voranstellen, die den Download-Prozeß anstößt und das im Propeller laufende Programm mit der Standard-IO des Linuxsystemes verbindet.
Propeller-Binaries im ELF-Format, könnte man sogar ohne Änderungen benutzen. Binfmt_misc kann die Propeller-ELF-Daten am Dateianfang erkennen und dann Ähnliches anstoßen.
Alternativ könnte man vermutlich auch mit einem nahezu trivialen Programm Propeller-Binaries in ELF-Umschläge verpacken.
Das Alles ist soweit keine Hexerei.
Propeller-Loader, die nach Download die typischen Propeller-StdIO-Pins aufs Terminal leiten gibt es fast schon zuhauf. Einen solchen Lader entgräten und minimalisieren (keine unnötigen Ausgaben etc) ist vermutlich nur lamweilige Fleißarbeit.
Interessant wird die Frage, wie das Propeller-Programm dem Lader mitteilt, daß es terminiert und an der Frage eventueller Parameterübergaben gilt es auch noch zu feilen.
Denkbar wäre auch nach dem Download auf SLIP zu schalten und so den Propellerbeiwagen im Netzwerk zu haben.
Ich sehe also bislang 3 Fälle:
- Normale Propeller-Binaries, die über die Serielle kommunizieren sollen, aber unverändert auch alleine oder mit anderem Terminal laufen sollen.
Dies schließt Spielereien mit Sonderzeichen oder Wedeln mit Pins zum Signalisieren des Programmendes aus.
Man wird um das Beenden der Terminalverbindung durch einen Tastendruck nicht umhinkommen. - Propeller-Binaries, die explizit für das Coprozessordasein und serieller Verbindung zu StdIO geschrieben wurden.
Kein Problem: Eine magische Zeichensequenz kann das Ende signalisieren und eine andere als Ersatz für das so mißbrauchte Zeichen dienen. Das verbindende Programm kann diese Umdeutung rückgängig machen, aufdaß StdIO davon keinen Wind bekommt. - Propeller-Binaries, die nach Start via z.B. SLIP/COBS/PPP ins Netzwerk abgebildet werden.
Ich hab mehr als 1 Jahrzehnt nimmer geSLIPt, COBS noch nicht genug beäugt und ob PPP zu fett für den Propeller ist, schüttle ich auch nicht mal eben so ausm Ärmel. Bibliotheken für SLIP/COBS habe ich im Arduino-Umfeld schon gesichtet.
I2C-Booatloader (z.B. für ATtiny/ATmega) existieren und so könnte man sich leicht umprogrammierbare Interfaces zur Außenwelt schaffen, deren Inhalt nach Reboot lediglich nur mal gegen die gewünschte Firmware verglichen werden müsste, um sie nur bei Bedarf neu zu flashen.
Und der Co-Prozessor könnt auch gleich ein FPGA sein. RISCV-Core? ZPU? BorgCPU?
Es ist also eine riesige Spielwiese, die sich da auftut!
Nichts ist unmöööööchlisch...
Mit mehr Windowskenntnissen als ich zu bieten habe läßt sich Gleiches vermutlich auch dort hinkriegen.
Riecht das nach einem lohnenden Projekt?
——————————
Dabei fällt mir auch noch InetD ein: Dieser Dämon startet Programme und verbindet deren StdIO mit Ports. Die SLIP-Gedanken kann man also erstmal wieder schlafen schicken.
——————————
Mehrere seriell angedrahtete Co-Prozessoren möchte man natürlich irgendwie unterscheiden können.
——————————
Verwandt: Fremdbinaries per Qemu und Bnfmt_misc laufen lassen.
——————————
Ente! Maus! Aus!