eine sehr kleine python vm fuer microcontroller.
ist noch ne alpha version , hat aber schon ne menge funktionierender features
um die speichernutzung gering zu halten beinhaltet es keinen python script interpreter
und kann nur python compiled code ausfuehren.
es fehlen noch um die 20 opcodes die nicht unterstuetzt werden,aber die haben mit klassen zu tun.
einige typen werden noch nicht unterstuetzt sowie lambda funktionen,klassen und dictionaries.
https://github.com/pez2001/sVimPy
svimpy
-
Leonidas
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Und welche Version des Python-Bytecodes unterstützt es? Der ändert sich ja durchaus, steht nicht fest wie etwa der von Java-Bytecode.
Übrigens weiß icht nicht ob Steffi sich freut, dass du ihre Telefonnummer im Quelltext auf Github hochgeladen hast (unit_tests.c). Quelltext ist idR ein schlechter Platz für private Notizen.
Ansonsten find ich die Idee gar nicht mal schlecht. Auf welche Microcontroller zielst du denn ab?
Btw, deine Tarballs sind furchtbar. Normalerweise entpacken sinnvolle Tarballs in projektname-version und nicht in unzählige einzelne Dateien, immer wenn jemand Daten so packt dann mag ich schreien. Außerdem wirkt das Makefile sehr verbose, das könnte man mit Wildcards stark kürzen.
Um den Wert von ``return`` braucht man keine Klammern zu machen, so schaut das komisch aus. Außerdem ist auf vielen Microcontrollern ``malloc`` und ``free`` ein No-Go, was die Nützlichkeit stark einschränkt.
Übrigens weiß icht nicht ob Steffi sich freut, dass du ihre Telefonnummer im Quelltext auf Github hochgeladen hast (unit_tests.c). Quelltext ist idR ein schlechter Platz für private Notizen.
Ansonsten find ich die Idee gar nicht mal schlecht. Auf welche Microcontroller zielst du denn ab?
Btw, deine Tarballs sind furchtbar. Normalerweise entpacken sinnvolle Tarballs in projektname-version und nicht in unzählige einzelne Dateien, immer wenn jemand Daten so packt dann mag ich schreien. Außerdem wirkt das Makefile sehr verbose, das könnte man mit Wildcards stark kürzen.
Um den Wert von ``return`` braucht man keine Klammern zu machen, so schaut das komisch aus. Außerdem ist auf vielen Microcontrollern ``malloc`` und ``free`` ein No-Go, was die Nützlichkeit stark einschränkt.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
danke fuer den gitignore tipp... kannte ich noch nicht.
tele entfernt zumindest ab dem letzten commit.
python 3.2 compiled code wird unterstuetzt zumindest in teilen. ist ja noch nicht fertig.
aber ich folge hier mal der os philosophie 'release early,release often', da ich auch auf aktive mithilfe hoffe.daher auch die gpl license.
also am liebsten haette ich das ja das das ganze auf atmegas ab dem 328er funzt.
aber das sind halt nur 2kb ram. das wird verdammt schwierig alleine wegen dem speicher den der verwaltungskrims frisst.
aber da sehe ich noch optimierungsmoeglichkeiten indem man z.b. die consts nur on the fly laedt und im speicher nur den offset speichert.
das ganze ist nicht auf speed optimiert obwohl es sich wohl nicht verstecken braucht im moment.
am ende hoffe ich das mit dem arduino zu kombinieren als platform. direkt im bootloader und im flashram die pyc files als ne art jar/tar zu speichern.
on the fly flashing ohne den chip resetten zu muessen.
ich bin fuer jede anregung/hilfe dankbar.
tele entfernt zumindest ab dem letzten commit.
python 3.2 compiled code wird unterstuetzt zumindest in teilen. ist ja noch nicht fertig.
aber ich folge hier mal der os philosophie 'release early,release often', da ich auch auf aktive mithilfe hoffe.daher auch die gpl license.
also am liebsten haette ich das ja das das ganze auf atmegas ab dem 328er funzt.
aber das sind halt nur 2kb ram. das wird verdammt schwierig alleine wegen dem speicher den der verwaltungskrims frisst.
aber da sehe ich noch optimierungsmoeglichkeiten indem man z.b. die consts nur on the fly laedt und im speicher nur den offset speichert.
das ganze ist nicht auf speed optimiert obwohl es sich wohl nicht verstecken braucht im moment.
am ende hoffe ich das mit dem arduino zu kombinieren als platform. direkt im bootloader und im flashram die pyc files als ne art jar/tar zu speichern.
on the fly flashing ohne den chip resetten zu muessen.
ich bin fuer jede anregung/hilfe dankbar.
was malloc und free angeht denk ich mal ist das kein problem die controller die das nicht unterstuetzen waeren sowieso nicht in der lage dazu auch nur kleine scripts auszufuehren geschweige denn den compiled code der vm in irgendeiner form zu im seinem rom zu speichern...
-
deets
Ohne jetzt in deine Code geschaut zu haben - aber *wozu* das ganze? Was ist denn das, was du dir von Python erhoffst, das du mit dem C bzw. dessen Dialekt beim Arduino nicht erreichst?
Denn gerade die dynamischen Collections-Klassen & die Garbage-Collection machen doch das Arbeiten in Python so angenehm - aber es sieht nicht so aus, als ob du das unterstuetzen willst / kannst.
Denn gerade die dynamischen Collections-Klassen & die Garbage-Collection machen doch das Arbeiten in Python so angenehm - aber es sieht nicht so aus, als ob du das unterstuetzen willst / kannst.
gc werd ich wohl noch einbauen ... classes bin ich mir nicht sicher...
also erhoffen tue ich mir das man am ende eine komplette suite zum programmieren des arduino hat.
man koennte dank einer vm auch nicht geflashten speicher fuer programmcode nutzen wie sd karten und so den zur verfuegung stehenden speicher vervielfachen
per python scripts wird die chip app kompiliert+verkleinert und geuploadet.
also erhoffen tue ich mir das man am ende eine komplette suite zum programmieren des arduino hat.
man koennte dank einer vm auch nicht geflashten speicher fuer programmcode nutzen wie sd karten und so den zur verfuegung stehenden speicher vervielfachen
per python scripts wird die chip app kompiliert+verkleinert und geuploadet.