ChriD
RiotOS kenn ich. Gibt noch andere Möglichkeiten. Problem dabei ist, dass wir ja nur einen Kern haben. Echte Nebenläufigkeit gibt es also nicht. Läuft der eine Thread, kann der andere nicht laufen. Die Threads teilen sich zwar die Zeit, aber wenn es um Microsekunden geht, kann Threading hier schon wieder Probleme bereiten.
In der Tat. Ich wünsche mit den 48h Tag. Aber selbst dann wäre es zu wenig Zeit :-(
@STSC
CircuitPython setzt doch als "alternative Basis" auf die Arduino-HW auf und ersetzt den klassischen C++ Arduino setup()/loop() Ansatz. Oder kann ich Circuit-Python auch als Library in meinem Arduino Sketch nutzen? Habe dazu noch nichts gefunden.
Danke für die Blumen. Wir un unser besten.
Natürlich. Feedback jedweder Art ist immer gerne willkommen. Manchmal müssen wir der Begeisterung für Neues aber einen kleinen Dämpfer verpassen. Ich hoffe das kommt nicht negativ rüber.
Beim atmega bin ich mir nicht sicher, aber für den SAMD haben wir die Möglichkeit vom Sketch aus in den Flash zu schreiben und wir könnten auch den Ausführungspointer in diesen Teil des Flashs verschieben. Was anderes wie der Flash geht hier nicht, da ich keinen Code von einem externen Speicher ausführen kann. Es muss der Flash des SAMD sein.
Das schwierige ist hierbei, das mit dem Sketch in Einklang zu bringen. Man muss ja nach der Ausführung wieder zurück zum Sketch und da weiter machen wo man aufgehört hat. Und es kommt noch hinzu, dass der separate Code auch auf die KNX Funktionen zugreifen kann.
Und dann muss man den Code, dem man mit der Suite so separat einspielt auch entsprechend compiliert bekommen.
Das ist alles durchaus machbar, reduziert aber nicht die Komplexität des Ganzen.
Das einfachste für den Anwender, und auch für uns wäre wie gesagt: Eine Arduino Lib die man im Sketch verwendet um ein Script das man aus dem EEPROM, einem externen Flash oder einer SD Karte lädt ausführen.
Aber auch hierbei ist ein wenig die Schwierigkeit das Script mit dem Sketch zu kombinieren was Aufrufe in Richtung KONNEKTING und dergleichen betrifft.
Sollte aber wenn man eine Schnittstelle definiert durchaus machbar sein.
Aber wie gesagt: Komplett auf Python umstellen ist erstmal keine Option. LUA klingt noch vielversprechend. Aber hier habe ich noch nicht ausreichend geschaut ob es vernünftige Libs gibt.
RiotOS kenn ich. Gibt noch andere Möglichkeiten. Problem dabei ist, dass wir ja nur einen Kern haben. Echte Nebenläufigkeit gibt es also nicht. Läuft der eine Thread, kann der andere nicht laufen. Die Threads teilen sich zwar die Zeit, aber wenn es um Microsekunden geht, kann Threading hier schon wieder Probleme bereiten.
Ahhh es gäbe so viel schönes Zeugs und so wenig Zeit :-)
@STSC
Das wäre ja auch bei CircuitPython so, dass KONNEKTING in C bleibt, aber man es trotzdem in Python z.B. für eine Logik verwenden kann.
Hochachtung was ihr da auf die Beine stellt.
Trotzdem kann man ja ein paar mögliche zukünftige Ideen diskutieren.
Könnte man nicht fix 8KB oder 16KB vom EEPROM/FLASH für ein C-Objekt reservieren. Dieser Code müsste dann zur Laufzeit ausgeführt ausgeführt und ggf. davor vielleicht noch ins RAM kopiert werden. 8KB oder 16KB sollten sich relativ schnell mit der Suite hochladen lassen und man müsste nicht die komplette Firmware übertragen.
Das schwierige ist hierbei, das mit dem Sketch in Einklang zu bringen. Man muss ja nach der Ausführung wieder zurück zum Sketch und da weiter machen wo man aufgehört hat. Und es kommt noch hinzu, dass der separate Code auch auf die KNX Funktionen zugreifen kann.
Und dann muss man den Code, dem man mit der Suite so separat einspielt auch entsprechend compiliert bekommen.
Das ist alles durchaus machbar, reduziert aber nicht die Komplexität des Ganzen.
Das einfachste für den Anwender, und auch für uns wäre wie gesagt: Eine Arduino Lib die man im Sketch verwendet um ein Script das man aus dem EEPROM, einem externen Flash oder einer SD Karte lädt ausführen.
Aber auch hierbei ist ein wenig die Schwierigkeit das Script mit dem Sketch zu kombinieren was Aufrufe in Richtung KONNEKTING und dergleichen betrifft.
Sollte aber wenn man eine Schnittstelle definiert durchaus machbar sein.
Aber wie gesagt: Komplett auf Python umstellen ist erstmal keine Option. LUA klingt noch vielversprechend. Aber hier habe ich noch nicht ausreichend geschaut ob es vernünftige Libs gibt.
Kommentar