Is there a Python packaging that is specifically for
embedded systems? ie, very small and configurable so the
user gets to select what modules to install?
For Linux-based embedded systems in particular?
I'm thinking of running it on the Linksys's Linux-based open
source router WRT54G. It has 4MB flash and 16MB RAM. I think
another model has 16MB flash. Any possibilities of running
Python on these systems?
If Python is not the best candidate for embedded systems because
of the size, what (scripting) language would you recommend?
PHP may fit but I don't quite like the language. Anything else?
Loa is small but it does not seem to be powerful enough.

Grant Edwards wrote:
2006-07-14, Jack <nospam (AT) invalid (DOT) comwrote:

>Is there a Python packaging that is specifically for
>embedded systems? ie, very small and configurable so the
>user gets to select what modules to install?
>>
>For Linux-based embedded systems in particular?
>>
>I'm thinking of running it on the Linksys's Linux-based open
>source router WRT54G. It has 4MB flash and 16MB RAM. I think
>another model has 16MB flash. Any possibilities of running
>Python on these systems?
>
>
A few years back there was a "deeply embedded python" project,
but it's been dead for quite a while:

This raises a good question. Is there a need for python to change
somewhat to work better in an embedded profile? Are there many people
in the community interested in using python for embedded projects?

2006-07-14, Jack <nospam (AT) invalid (DOT) comwrote:
Is there a Python packaging that is specifically for
embedded systems? ie, very small and configurable so the
user gets to select what modules to install?

For Linux-based embedded systems in particular?

I'm thinking of running it on the Linksys's Linux-based open
source router WRT54G. It has 4MB flash and 16MB RAM. I think
another model has 16MB flash. Any possibilities of running
Python on these systems?

A few years back there was a "deeply embedded python" project,
but it's been dead for quite a while:

Jack wrote:
snip
If Python is not the best candidate for embedded systems because
of the size, what (scripting) language would you recommend?
TCL is fairly popular in the embedded space. Fairly small footprint.
The syntax is not to everyone's taste.

Here's an URL to a project that appears to be dated from 2004

Jack wrote:
Is there a Python packaging that is specifically for
embedded systems? ie, very small and configurable so the
user gets to select what modules to install?

For Linux-based embedded systems in particular?

I'm thinking of running it on the Linksys's Linux-based open
source router WRT54G. It has 4MB flash and 16MB RAM. I think
another model has 16MB flash. Any possibilities of running
Python on these systems?

If Python is not the best candidate for embedded systems because
of the size, what (scripting) language would you recommend?

PHP may fit but I don't quite like the language. Anything else?
Loa is small but it does not seem to be powerful enough.

Jack wrote:
Is there a Python packaging that is specifically for
embedded systems? ie, very small and configurable so the
user gets to select what modules to install?

For Linux-based embedded systems in particular?

I'm thinking of running it on the Linksys's Linux-based open
source router WRT54G. It has 4MB flash and 16MB RAM. I think
another model has 16MB flash. Any possibilities of running
Python on these systems?

If Python is not the best candidate for embedded systems because
of the size, what (scripting) language would you recommend?

PHP may fit but I don't quite like the language. Anything else?
Loa is small but it does not seem to be powerful enough.
--

python on palmos - latest version was below 1.5.2 - but is quite interesting
has small fotoprint, is fast and usefull
but isn't maintained by years

mak

Python on the Zaurus, which I used to develop a wifi CRM app on a
group of refurb Sharp Zaurus SL-5500 units. Here's a link to the Python
implementation on the Z http://starship.python.net/~hinsen/Zaurus/.

Grzegorz Makarewicz wrote:
Jack wrote:
Is there a Python packaging that is specifically for
embedded systems? ie, very small and configurable so the
user gets to select what modules to install?

For Linux-based embedded systems in particular?

I'm thinking of running it on the Linksys's Linux-based open
source router WRT54G. It has 4MB flash and 16MB RAM. I think
another model has 16MB flash. Any possibilities of running
Python on these systems?

If Python is not the best candidate for embedded systems because
of the size, what (scripting) language would you recommend?

PHP may fit but I don't quite like the language. Anything else?
Loa is small but it does not seem to be powerful enough.
>
>
>
python on palmos - latest version was below 1.5.2 - but is quite interesting
has small fotoprint, is fast and usefull
but isn't maintained by years

mak

"Carl J. Van Arsdall" <cvanarsdall (AT) mvista (DOT) comWrote:
To: <python-list (AT) python (DOT) org>
Sent: Friday, July 14, 2006 7:36 PM
Subject: Re: Python for Embedded Systems?

| Grant Edwards wrote:
| 2006-07-14, Jack <nospam (AT) invalid (DOT) comwrote:
| >
| >Is there a Python packaging that is specifically for
| >embedded systems? ie, very small and configurable so the
| >user gets to select what modules to install?
| >>
| >For Linux-based embedded systems in particular?
| >>
| >I'm thinking of running it on the Linksys's Linux-based open
| >source router WRT54G. It has 4MB flash and 16MB RAM. I think
| >another model has 16MB flash. Any possibilities of running
| >Python on these systems?
| >>
| >
| A few years back there was a "deeply embedded python" project,
| but it's been dead for quite a while:
| >
|
| >

| >
| >
| This raises a good question. Is there a need for python to change
| somewhat to work better in an embedded profile? Are there many people
| in the community interested in using python for embedded projects?
|

I for one would be interested in using it - if it can be made small enough - I
do not see it helping me with the nitty gritty of getting a system running on
bare metal, as the low level stuff in a small system is still best done in
assembler - but if there is a display and some sort of keyboard and you can
stick to character based stuff it will ease the "application" part of the work a
lot - its a natural for doing things like logging and simple transactions - and
if the hardware is strong enough to get IP running - then it will open up the
systems to be web based

It will also be of use as you could prototype on a PC - emulators and simulators
of small systems are mostly a pain as it takes a lot of effort to describe the
actual hardware before these are useful

"Small" in this context is an eight bit processor (like an 80x1 | x = 3, 5 )
with some tricks done in the hardware to expand the native 16 bit address space
to address say half a Meg of battery backed up static ram as data space, with
about 62k of code space available for the interpreter and the custom S to run
in - (Harvard architecture, not von Neumann) - These processors have lately been
improved from the original about half a MIP to now give sustained performance of
better than 10 MIPS - So they may just be able to cripple along doing the
interpreting - But its *Quite a Challenge* to fit the interpreter in, though

It is easily possible to expand these processor's address space to 24 bits -
that is 16 Meg - and it may be a better approach to make a 'Virtual Processor'
to run the python stuff - is there a definition for that sort of thing, akin to
Java's Virtual Processor? - It would be a better approach, as the resultant
higher level work would be more portable - to port to another class of
processor, you need merely write the Virtual Machine - in whatever Language
takes your fancy

What is the minimum set of instructions and structure needed to make a
simplistic Python? - does anybody know?

Might just be a pipe dream
- Hendrik van Rooyen

"H J van Rooyen" <mail (AT) microcorp (DOT) co.zawrites:
What is the minimum set of instructions and structure needed to make a
simplistic Python? - does anybody know?

There have been lots of Lisps for the PDP-11 and comparable machines.
Python's runtime semantics are close enough to Lisp that you could
probably get something Python-like running in that kind of machine,
maybe not exactly Python. You would probably want to use small-Lisp
implementation techniques like BIBP ("big bag of pages", Google for
it) memory organization. But I don't think any of those Lisps were
really all that useful. They were written mostly as toys.

SID was a well known very small Scheme interpreter that you might
like to play with:

Paul Rubin <http://phr.cx (AT) NSPAM (DOT) invalidwrites:
SID was a well known very small Scheme interpreter that you might
like to play with:

Here's another one that I like. I haven't actually used it but
studied it for possible integration in an embedded project that I
worked on but that got cancelled. It seems very good for this type of
thing. The runtime system is just 20k bytes or so:

http://hedgehog.oliotalo.fi/

Picolisp is also pretty neat but maybe not aimed the same way:

Take the challenge: it is very impressive. course they tailored it
to Pico Lisp's capabilities, but you can see the challenge problem is
very sensible, and the Pico Lisp solution is much easier to get to
than a Python solution:

Jack wrote:
Is there a Python packaging that is specifically for
embedded systems? ie, very small and configurable so the
user gets to select what modules to install?

You might also look at the gumstix embedded system, Linux running on an
ARM processor in an extremely small form factor.
(http://www.gumstix.net/)

And here is a page with a link to a gumstix Python binary:
http://cs.gmu.edu/~

I'm trying this out as soon as I get home!
-- Paul

Jack wrote:
Is there a Python packaging that is specifically for
embedded systems? ie, very small and configurable so the
user gets to select what modules to install?

For Linux-based embedded systems in particular?

I'm thinking of running it on the Linksys's Linux-based open
source router WRT54G. It has 4MB flash and 16MB RAM. I think
another model has 16MB flash. Any possibilities of running
Python on these systems?

Here's another recently announced hobbyist microcontroller system:

Uses Atmel SAM7X processor, ARM7, 32-bit, 256K Flash, 64K SRAM, up to
55MHz.

Ethernet and CAN (Controller Area Network - wireless)

Various I/ blocks and on-board sensors

~US$150

Start shipping Aug 1st.

No Python binary yet, but cross-platform tools are available. The guys
at this magazine could really get a jump with a Python build. Here's a
related site for this kit: www.uCHobby.com
-- Paul

>
Ethernet and CAN (Controller Area Network - wireless)
, my bad - CAN is not wireless, it is a serial network
specifically for linking with other ucontroller boards.
I was thinking of the onboard Bluetooth of the gumstix boards.
-- Paul

Yes, I mean Lua, not Loa :-p

Lua is a nice language. Like you said, it doesn't have many libraries
as Python does. Plus, it's still evolving and the libraries are changing.
I found a few functions not working last time I tried kepler libraries.
It's good for embedded systems though because of its small footprint.
Extensions implemented in C makes it possible that the installation size
doesn't blow up when new stuff is added, like in Python.

But I still like Python better for its power and for the style of the
language
itself. And I was hoping to find a Python implementation that bears the
principles of Lua to make it suitable for embedded systems :)

>PHP may fit but I don't quite like the language. Anything else?
>Loa is small but it does not seem to be powerful enough.

>You mean Lua ? Not powerful enough ? What do you mean by
>that ? Lua is great IMH Sure it does not come with thousands
>of libraries, but the language design is extremely clean, the
>language constructs powerful and the footprint very small.

>16kloc of C code can't hurt your embedded device can they ? ;)

>Please tell us what kind of limitation you find in Lua

>Cheers,

>SB

In article <@comcast.com>,
Jack <nospam (AT) invalid (DOT) comwrote:
>Yes, I mean Lua, not Loa :-p
>
>Lua is a nice language. Like you said, it doesn't have many libraries
>as Python does. Plus, it's still evolving and the libraries are changing.
>I found a few functions not working last time I tried kepler libraries.
>It's good for embedded systems though because of its small footprint.
>Extensions implemented in C makes it possible that the installation size
>doesn't blow up when new stuff is added, like in Python.
>
>But I still like Python better for its power and for the style of the
>language
>itself. And I was hoping to find a Python implementation that bears the
>principles of Lua to make it suitable for embedded systems :)
>
PHP may fit but I don't quite like the language. Anything else?
Loa is small but it does not seem to be powerful enough.
>
>>You mean Lua ? Not powerful enough ? What do you mean by
>>that ? Lua is great IMH Sure it does not come with thousands
>>of libraries, but the language design is extremely clean, the
>>language constructs powerful and the footprint very small.
>
>>16kloc of C code can't hurt your embedded device can they ? ;)
>
>>Please tell us what kind of limitation you find in Lua
.
.
.
PHP is about as bad a choice as there is for this domain.
Let's talk about it some other time.

The usual contestants are Forth, Lua, Tcl, and various Lisps.
Python could play quite well at least in some situations, but
entirely no one has done much since 1.5.2 times (which doesn't
seem to me like a long time).

If you're to the point of sniffing at Lua's relative poverty
of libraries, you need to detail your requirements more pre-
cisely. What's "small" and "embedded" to some people is a
full-featured host to others. Generally speaking, yes, Lua
is still advancing significantly, or, from a different per-
spective, it hasn't stabilized yet. The point is that there's
necessarily no "Pareto optimizer" which is simultaneously
smallest, fastest, newest, most mature, most Unicode-aware,
most featureful, lowest-level, highest-level, That's why
there's a point to the engineering we do here.

In article <@python.org>,
Carl J. Van Arsdall <cvanarsdall (AT) mvista (DOT) comwrote:
.
.
.
>This raises a good question. Is there a need for python to change
>somewhat to work better in an embedded profile? Are there many people
>in the community interested in using python for embedded projects?
.
.
.
Yes and no. Python could thrive for the next decade while
utterly surrendering the small-and-embedded domain to Forth,
Lua, Tcl, Scheme, and so on, so, no, there's no *need* for a
TinyPython. the other hand, yes, there are at least several
of us with an interest and occasional opportunities for Python
in such applications. While <URL:
looks dormant, it
was set up to serve just such constituencies, and we might yet
breathe life into it as any of the other several TinyPython
initiatives might, or might not, revivify.

claird (AT) lairds (DOT) us (Cameron Laird) writes:
Yes and no. Python could thrive for the next decade while
utterly surrendering the small-and-embedded domain to Forth,
Lua, Tcl, Scheme, and so on, so, no, there's no *need* for a
TinyPython. the other hand, yes, there are at least several
of us with an interest and occasional opportunities for Python
in such applications.

I think we should see what happens with PyPy, which might be easier to
target at embedded platforms than CPython is. Main thing needed would
be a static compiler haven't followed PyPy enough to know if it
relies on having Psyco at runtime.

In article <7x3bd21kry.fsf (AT) ruckus (DOT) brouhaha.com>,
Paul Rubin <http://phr.cx (AT) NSPAM (DOT) invalidwrote:
>claird (AT) lairds (DOT) us (Cameron Laird) writes:
>Yes and no. Python could thrive for the next decade while
>utterly surrendering the small-and-embedded domain to Forth,
>Lua, Tcl, Scheme, and so on, so, no, there's no *need* for a
>TinyPython. the other hand, yes, there are at least several
>of us with an interest and occasional opportunities for Python
>in such applications.
>
>I think we should see what happens with PyPy, which might be easier to
>target at embedded platforms than CPython is. Main thing needed would
>be a static compiler haven't followed PyPy enough to know if it
>relies on having Psyco at runtime.

PyPy indeed presents exciting prospects.