PyMite (Python subset interpreter/VM) for Teensy3

S

stevech

Well-known member
+1 ???

There is/was a port of the Python small memory VM for Teensy2++/AVR - one of the pyMite ports. Maybe it could be adapted without huge effort - it's likely 99% vanilla C.
https://wiki.python.org/moin/PyMite

It would be more than GREAT if a pyMite adaptation was done for the more-resource-capable Teensy3. Just a simple subset. Don't need all the esoteric features in even pyMite.
Besides being appealing to the student world, this would also allow for portable code among PCs and various mid-high end embedded processors, that are not up in the Linux class.
 
Last edited:
I sent emails to a couple people who've previously contacted me regarding Python on Teensy. I believe there were a couple more, but sadly I could not find their messages.

Let's use this forum topic to discuss possibly bringing Phython in some form to Teensy3, so the discussion doesn't get lost (like old emails in my inbox).

I'd really like to help make this happen. I personally have only used Phython a couple times, and only just quick changes to existing code where I struggled through not knowing the language by reading examples and online docs. But I can help if anything is needed on the Teensy side....
 
I'll help! I'm C/C++ literate.

I've used Python a lot in my job... I had to use it for a real time embedded job - old Python version. 115200 baud very high sustained data rate. Multiple threads. Really complex. I thought it just can't work, being a bytecode interpreter and this high I/O rate, threading, etc. I needed no GUI - used a syslog client instead. But it worked fine. Handled the same workload as my C code on an ARM7, faster CPU and FreeRTOS for threading (python's threading is built-in). I used the OS serial direct because my load was high and the python serial library is kinda bloated for my case. That was simply a dozen lines of code that decides which OS calls for serial I/O to make, at RUN TIME, not compile time. Code moves between platforms without change.

So I'm not as snarky about Python for embedded as I was. I thought of it as an IT admin's scripting tool. Not so.

The nicest thing about Python is that if you use care in coding to the least common denominator Python version (I had to use 2.6), it'll run on any Python platform: T3, PC/Windows, PC/Linux, Raspberry PI/LInux, and so on. Kind of like sticking to the ANSI standard for C99 or whatever, and avoiding proprietary. Or in the case of Arduino, having to all on your own, recode lots of libraries for each new platform rather than pulling from public domain for most.
 
Last edited:
So now there's Micro Python in the mix too:
http://www.kickstarter.com/projects/214379695/micro-python-python-for-microcontrollers
The author says he'll be open-sourcing under the MIT license, so there's hope there, but my guess is that it may take a backseat to filling Kickstarter orders. I, too, really would like to see this happen. My ideal would be a Teensy 3.0/3.1 that I could push Python bytecode to via Bluetooth. I've got the Teensy/BT part working great, just missing that last little bit...
 
Damien George decided to focus on core software and documentation of MicroPython when KickStarter funding crossed a stretch goal boundary recently. I am a funder of his project and when the software becomes available, may try to do a port to the Teensy 3.1 (thanks, Paul; two are on order as I write this). MicroPython may fit into Teensy 3.0. The company I work for is a strong Python shop, so this could be a great match for us.

FYI (is this a first?) , the MicroPython author considers the software to be essentially finished modulo additional libraries, and not a project risk. This could be an interesting project all around.
 
very interested in T3.1 adaptation. Choosing which Libraries to bring up must be a challenge.
 
Last edited:
I looked at the python-on-a-chip code (a.k.a. Pymite and P14p). After a little fiddling, I got it to at least compile and run a Python hello world script on Ubuntu.

I looked at the platform stuff. Seems fairly simple to get a basic platform defined, but of course the devil will be in the details.

The platform alone only gives you the ability to run Python code and print. To actually DO anything, libraries with native code need to be made. There seems to be some extremely basic ones for AVR and other chips, but they provide only the most basic features like accessing a few of the commonly used registers.

Building up a set of libraries to turn this into a genuinely useful system looks like quite a lot of work. I can help, especially with any really low-level details, but I just can't take time away from the audio library and other stuff PJRC has planned for next year. If this is going to happen, it really needs at least one determined and Python-experienced person to really take it on.
 
It's hard to rationalize a lot of work to get Python on sub $40 microprocessors since there are several Linux based micros in that price target.
It would be very clever to have a $25 micro running a decent Python and some set of libraries.

ZBasic is sort of similar.. structured Basic on a really low cost micro without an OS, but with a thread scheduler. But it isn't promoted much to the user community. Great work - language parser emitting C++ to GCC then to .hex for AVR.
 
You must log in or register to reply here.
Back
Top