Newbie: Python suitability question

[Chris Arai]

Hi Cameron,

Thanks for the help.

The way the embedded app is set up it won't work as a command line executable
that could be made into an extension, called once each loop.  The reason is
that the embedded app has it's own loop of data gathering from sensors and
processing that data (and previously gathered data.)  Therefore the embedded
app must some how be static and be able to be re entered at a particular
point (the beginning of the data acq loop, not "main()") in order to be an
extension.

You are right, the main form of communication from the embedded app is the
display memory bitmap.  To the embedded app would be the key strokes.  In the
deliverable form of the embedded app the display memory is piped directly out
to the display via an on board LCD controller.  The keypad is also managed by
an onboard controller.

I am thinking that if I extend python with the embedded app that I will have
to run it as a thread.  Is this possible?  I have never done threaded
programming before.  If this is an appropriate method, then how do I
communicate between the two threads?  Via files?   What is a good reference
for learning how to do this?

My original thought was that embedding python was the way to go.  Once every
data acq loop the python module is called, but the same problem arises of
being static.  It seems to me that this method also requires threads.

Another issue that I forgot to ask was how to debug this concoction.  Will
DDD which supports gcc and python (I think) allow source debugging of both
the gcc and python sides?  Is there another debugger that you would
recommend?

Thanks again for the help.

Chris

Cameron Laird wrote:

> Yes, Python is good for this role.
>
>   I have a strong bias toward extending rather than
>   embedding Python for cases such as yours.  Are you
>   saying that it's possible to identify a command-line
>   (-like) application at the heart of this, and you
>   want Python to manage screen display, configuration,
>   ...?  That's perfect for an architecture in which
>   Python manages the embedded application.  Or does the
>   deliverable embedded application really communicate
>   only through a displayable memory bitmap?
>
>   I'll say this a different way:  I don't understand
>   the deliverable's communications, in isolation.  It's
>   only prudent to tackle that first, before specifying
>   details of the connection between the application and
>   Python.
>   --
>
> In article <3921EFC8.53C372FC at araidesign.com>,
> Chris Arai  <chris at araidesign.com> wrote:
>                         .
>                         .
>                         .
> >I am contemplating using python to act as a graphical interface to an
> >embedded application that will be cross compiled for a 68K micro
> >controller.  The reasons I (think) I want to use python are:
> >
> >1. I need to create a simulator for the target embedded system for rapid
> >development.
> >2. I'm in a hurry and lazy and want to create a simple GUI quickly.
> >3. I can easily (??) port from Linux to Windows.
> >
> >The outline is that I need to simulate the graphical display that the
> >embedded app will have and to feed the app keypad inputs via mouse
> >clicks.  So the embedded app is running and creating a memory map for
> >its graphical display, which python then redraws for the desktop, while
> >mouse clicks to the buttons are passed to the embedded app.  The
> >questions I am having difficulty answering are:
> >
> >1. Do I embed python in my app? Or...
> >2. Do I extend python with my app?
> >3. Will I need to use threads to do this?
> >
> >My guess is that I will have to embed python.  Thus my app will start,
> >call python to create the GUI, and then the app continues it's
> >processing in a loop which on each cycle of the loop updates python with
> >the new display info and also grabs inputs that were made to the python
> >GUI.  Is this possible?
> >
> >
> >AND last of all, is this an appropriate use of python, or is there a
> >better way?
>                         .
>                         .
>                         .
-------------- next part --------------
A non-text attachment was scrubbed...
Name: chris.vcf
Type: text/x-vcard
Size: 224 bytes
Desc: Card for Chris Arai
URL: <http://mail.python.org/pipermail/python-list/attachments/20000517/c10d10ef/attachment.vcf>