Python for embedded systems (was Re: What does Python do)

[Peter Hansen]

Grant Edwards wrote:
> 
> In article <3A6D1E04.AABCC7DE at engcorp.com>, Peter Hansen wrote:
> >Actually, Python can be suitable for real-time embedded
> >software, as well.
> 
> I suppose it depends on the system resources and requirements.
> The vast majority of embedded systems don't have the resources
> required to run Python -- even the deeply embedded version
> without the compiler.

Quite true.  That's why I said "can" be suitable, not "is".

We have Python running on a 1MB Flash/1MB RAM PC/104 module.
With the compiler.  Quite cool.  I know from posts here that
at least one other company has achieved something similar.
I'm still pleased to find how well many of Python's advantages
translate through into the embedded world.  This is, of course,
an extremely long way from a 16-bit chip with a 64K address
space, but for that there's always FORTH. :-)

> >(I suppose I could even stretch things a little and say it's
> >potentially suitable for device drivers, but not in the way
> >most people would define them.)
> 
> You can't write a device driver in Python for any of the common
> desktop or server OSes: Linux, BSD, Solaris, MacOS, Win*, etc.
> It's entirely possible to design an OS such that kernel/driver
> code can be in Python, but I'm not aware of such a thing.

Well, I obviously wasn't referring to mainstream systems.  I
was thinking of specialized embedded systems such as ours, where
in effect the "device driver" in Python rides on top of an 
extremely thin layer of C code (my brain still calls these
"native methods", from Java).  The C code is too thin to be
called a driver, but of course the Python code is *not* able
to interface directly to the hardware, which is usually part
of the definition of device driver.  (I use the term "driver"
more as a package of lower-level functionality, not 
necessarily as a trivial interface to some hardware.)

> >Python is actually *more* suitable for real-time work, in
> >certain circumstances, than Java.
> 
> A lot of real-time system designers cringe at _any_ use of
> dynamic memory allocation (other than a frame stack).  Dynamic
> _anything_ is the bane of an embedded system.  Although Java
> was supposed to be useful for embedded systems, it's been a
> tough sell.

Dynamic memory allocation is not inherently contrary to the 
requirements of real-time, although many people still think
"speed" instead of "deterministic" when the word real-time
comes into the conversation.  I think with a little care,
and a generous upper limit for what you consider "soon enough",
dynamic memory allocation can meet real-time requirements
in certain cases.  But I was thinking more of the garbage 
collection in Java being a problem, while reference
counting makes deallocation much more predictable in Python.

> >... On the other hand the
> >threading model could mess things up for you, but if you focus
> >on a specific platform, even that is not necessarily a problem.
> 
> The current threading implementation is inappropriate for
> real-time work, but I don't know why one couldn't implement
> prioritized preemptive threading for Python.

I think the global interpreter lock would be the thing 
that would get in the way there.  I'm not sure to what 
extent this is true, but I believe a lower priority thread
can block a higher priority thread for a possibly 
very large time.  It's possibly still deterministic, and
therefore still "real-time", but not necessarily high
performance.  I wouldn't bet my life on it yet, since I
still need to study the core more.