embedded python?
Alexander May
alex-news-deleteme at comcast.net
Tue Jun 29 13:58:29 EDT 2004
PS:
> I doubt you'll need to do much "porting". Unless the Linices you
> are considering are quite unusual, they ought to look a lot like any
> other Linux, and Python may well work largely unchanged.
from http://www.vanille.de/projects/python.spy (from Christopher T King's
post)
"You won't find many Python distributions for arm-linux, because Python is
pretty finnicky when it comes to cross-compiling. The build process of
Python compiles a core part of it (the parser generator pgen) and tries to
execute that later in the build process. This - of course - doesn't work for
cross compiling. My patches to the Python build scripts are available @
sourceforge and are likely to be included into the main Python tree."
-----
Thoughts?
"Peter Hansen" <peter at engcorp.com> wrote in message
news:Rv-dnT7TAcm5BHzd4p2dnA at powergate.ca...
> Alexander May wrote:
>
> > We are developing a distributed application running on approximately six
> > thousand nodes with somewhat limited hardware resources. Our hardware
> > target is 66 MHz ARM style processor with 16 Mb ram. We haven't
selected
> > specific hardware yet; the hardware target is what we are trying to fit
into
> > based on price constraints. Each device needs to be able to handle
about 2
> > kbs (yes kilo, not mega) worth of network traffic.
>
> You mention network, so presumably you have Ethernet (?) interfaces, and
> plan on TCP or UDP, in which case you probably first need to consider
> operating systems... Python does not automatically give you support for
> networking, it just uses the underlying OS support.
>
> > I intend to a least prototype the system in Python. It would be great
if we
> > could we could use Python in production by embedding it in the hardware.
My
> > question is does anyone have any real world experience using python in
an
> > embedded system?
>
> Yes, there are a few people around here who have worked on embedded
> Python systems, including me (at a past employer).
>
> > 1) Are there any embedded Pythons out there? The nodes will likely be
> > running some form of Linux, but I don't particularly feel like devoting
> > resrouces to porting python. Any embedded Linuxes supporting Python?
> > Thoughts in general?
>
> I doubt you'll need to do much "porting". Unless the Linices you
> are considering are quite unusual, they ought to look a lot like any
> other Linux, and Python may well work largely unchanged. Any required
> changes could be in areas you don't need, anyway. Again, make sure
> you consider right away exactly what OS resources, other than
> networking, that you actually need. Multitasking? Signals? Audio?
> GUI? etc...
>
> > 2) What are the resource requirements of Python? How much overhead do
the
> > network related modules add?
>
> _socket.pyd is 49212 on Win32, and 124040 (probably with debugging
> symbol table included?) on Linux, for Python 2.3.4. This includes
> lots of doc-strings, though, so you can probably shrink it pretty
> easily with a configurable setting during compilation.
>
> > In short, is embedding python realistic?
>
> Definitely. We did it first on a 33MHz 386 (or 286?) compatible
> board with only 1MB of flash and 1MB of RAM, and a tiny embedded
> OS with no networking. That took a little slashing, such as removing
> floating point support, but for the most part such things were
> supported well by #defines during compilation. I think we based
> that one on Python 1.5.2. (It was a few years ago.) Performance,
> however, turned out to be inadequate and we decided we'd get
> farther faster by keeping Python and switching to faster hardware
> (than by ditching Python and doing it all in C).
>
> The next version was a 100MHz 486 compatible with 32MB RAM and
> Compact Flash as a hard drive. We picked 32MB flash as the target,
> but used 64MB for prototyping and kept using it thereafter because
> CF cards kept getting cheaper. This version ran vanilla Linux
> with everything non-essential removed, and stock Python recompiled
> from sources with, I believe, no changes. We stripped a few library
> files from the resulting binary (e.g. unicodedata.so) to reduce the
> footprint.
>
> I know others have done similar things on hardware in this range,
> but I don't know of anything freely available yet. Not sure that
> would make sense, either, as everybody uses different hardware in
> this sort of thing...
>
> The main advice I can give you from this experience is that if
> your hardware doesn't quite cut it, considering putting the money
> into better hardware rather than immediately abandoning any thought
> of using Python. On the other hand, you have 6K nodes, and we
> had less than a few hundred, so the "economies of scale" just
> weren't there as much in our case and development costs were
> the largest consideration. In your case, saving $100 on each
> unit might be more important than saving a few thousand hours
> of development time... your call.
>
> -Peter
More information about the Python-list
mailing list