Re: [python-on-a-chip] Micro Python - Python for microcontrollers

[Dean Hall]

Interesting, I hadn't heard of it until just now.
The FAQ at the bottom of the page does a comparison to the PyMite VM.
The comparison is mostly fair, though I think the heap allocator is pretty fast in most cases except when a GC is needed.
I'm most interested to see this "complete compiler" and what kind of RAM is required for it.

From the description, I don't think Micro Python will be stackless and have cheap coroutines; but that's just an estimate based on early information.
The project is already fully funded, so it looks like we have a new contender in the Python on a microcontroller space!

!!Dean


On Nov 15, 2013, at 5:38 PM, JAY FREE wrote:

> Hello All,
> Thought you might be interesred in a kickstarter project which I saw recently
> http://www.kickstarter.com/projects/214379695/micro-python-python-for-microcontrollers
>
> Regards,
> Jeffrey
>
> --
> --
> You are subscribed to the "python-on-a-chip" (or p14p for short) Google Group.
> Site: http://groups.google.com/group/python-on-a-chip
>
> ---
> You received this message because you are subscribed to the Google Groups "python-on-a-chip" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to python-on-a-ch...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

[pir...@gmail.com]

> The project is already fully funded, so it looks like we have a new contender in the Python on a microcontroller space!
>

It's the third one that I get news is being currently developed, the
other one is PyCorn (http://www.pycorn.org/). It uses the raw CPython
with some glue code to run on bare naked Beagle board and Raspberry Pi
:-) I think I should re-take seriously my idea to develop a
pure-Python operating system now that there're so much virtual
machines... :-D

--
"Si quieres viajar alrededor del mundo y ser invitado a hablar en un
monton de sitios diferentes, simplemente escribe un sistema operativo
Unix."
– Linus Tordvals, creador del sistema operativo Linux

[John Griessen]

On 11/15/2013 06:34 PM, Dean Hall wrote:
> I don't think Micro Python will be stackless

In the first Q&A in his FAQ section, he makes that out to be a liability.

Is there some way P14P can handle interrupt driven code and not trigger garbage
collection cycles like he suggests?

[pir...@gmail.com]

It will be free software, so some ideas would be taken...

Send from my Samsung Galaxy Note II

--
--
You are subscribed to the "python-on-a-chip"  (or p14p for short) Google Group.
Site: http://groups.google.com/group/python-on-a-chip

--- You received this message because you are subscribed to the Google Groups "python-on-a-chip" group.

To unsubscribe from this group and stop receiving emails from it, send an email to python-on-a-chip+unsubscribe@googlegroups.com.

[Dean Hall]

Going stackless is a tradeoff. First, lets be precise about what stackless means here: Normally, one designates a contiguous chunk of memory (the stack) for the execution frames. This allows one dimensional operation (push, pop); a typical function call pushes an execution frame and uses it for execution.
When the function is done, it pops the frame.

If you want coroutines or threads in this scenario, you would need to declare a stack for each thread. If your application's functions use lots of variables or the calls nest deeply, these stacks might have to be pretty big. So multiple stacks would consume a lot of RAM.

Stackless on the other hand, allocates an execution frame from the heap when needed and returns it to the heap when done. This allows a thread or coroutine to allocate the frame as needed (without having to declare the big stack). Allocating a frame from the heap is pretty quick. The heap allocator is pretty efficient.
The only slowdown comes if a GC needs to take place.

[ Aside: The Speed Discussion
If you're running Python on a microcontroller, you've already decided that speed is not the most important factor.
Accepting Python means accepting automatic memory and garbage collection.]

Yes there is a way for p14p to "handle interrupt driven code". But you have to write it yourself in C and you definitely don't want to run it within the interrupt context. Instead, here's what you'd probably want to do:

1) Declare an enumeration for each interrupt of interest.
2) Create a global var to hold the value of the triggered interrupt.
3) In the ISR, set the global var with the enum value of that interrupt.
4) In the big while() loop of interp.c near the top (where it checks the reschedule flag) insert new code that checks your global var. If non-zero, launch the thread to handle the ISR.

(There are some details I'm leaving out, but that's the gist)

The way to not trigger a GC is to have more RAM than you need.

!!Dean

[pir...@gmail.com]

> Yes there is a way for p14p to "handle interrupt driven code".  But you have to write it yourself in C and you definitely don't want to run it within the interrupt context.  Instead, here's what you'd probably want to do:
>
> 1) Declare an enumeration for each interrupt of interest.
> 2) Create a global var to hold the value of the triggered interrupt.
> 3) In the ISR, set the global var with the enum value of that interrupt.
> 4) In the big while() loop of interp.c near the top (where it checks the reschedule flag) insert new code that checks your global var.  If non-zero, launch the thread to handle the ISR.
>
> (There are some details I'm leaving out, but that's the gist)
>

The way I did it in my x86 port was filling a list with a PyObject that represented the interruption and if other thread was processing that list exit, but if not, this thread started to dispatch this objects from inside Python as events on an event-loop. This way, interruptions were really easy to manage while still very performant reliable...