Script interpreter

Chris Johns chrisj at
Tue Jun 6 06:50:40 UTC 2006

Waschk,Kolja wrote:
> I'm currently working on a measurement device where data from sensors is
> processed in a FPGA with "hardwired" logic and with code in a softcore CPU
> (NIOS2). The CPU is responsible for communication as well, and it seems
> there will be some spare time, during which it could perform yet unknown
> tasks. It could, for example, utilize the measurement results to control a
> motor or special display or ...
> Ideally it would be up to the user to decide what the CPU shall do with its
> spare time. There could be a robust environment that allows the user to
> upload code have it executed by the device.

Python allows code to be uploaded and then run. You can use the Python 
command line it you want to. Try Python on your host machine for an 
example, it is just the same.

> Results from the user code could
> be sent out via RS232 or other interfaces.

This will depend on the type of comms operating over the RS232 link. You 
can bind C or C++ functions to Python and make them available to the 
user. This includes any data collecting devices. The Wiki has links to a 
C++ package I used. It worked well.

> Assuming that software on the device is generally based on RTEMS, are there
> any known methods to achieve this kind of functionality? I have read posts
> about using Java KVM with RTEMS... Others embed Python interpreters, even
> mobile phones run Python... hm.. there are some goals to aim for, and
> I don't know whether using any of those "cool" approaches is appropriate.
> - A clean separation of base software (RTEMS, with data processing and
> communication) and user code should allow to make the device robust and
> avoid things like "freezes" due to errors in user code. For example, the
> device, when connected to a host PC, should never become unresponsive to
> host commands just because the user code entered a tight endless loop.

Which ever solution you arrive at I suspect a user app could cause 
problems. Both Java and Python supports dynamic memory allocation and a 
poor user app could consume all the available memory. A user could fill 
the disk which would cause problems. Clear documentation should help the 
user keep clear of these problems. With Python you do not have pointer 
type problems and a failure will just stop the Python interpreter which 
you can start again.

> - Ideally, the user should be able to debug her or his code from a connected
> PC, single-stepping the code (and ideally, this development environment for
> the PC side already exists, or debug feature can be provided online,
> text-based, to be accessed using telnet or serial console).

I think Python has a debugger but I have not tried using it on RTEMS. It 
should work.

> Anyone here who already embedded a Python interpreter in a RTEMS
> environment?

Yes I have and found it fun. About an hour after getting Python running 
I was reading my mailbox with an RTEMS target using the IMAP4 protocol 
and sending Joel an email using SMTP.

> Is it resource-intensive? Even a BASIC interpreter would be a
> reasonable idea if it only allowed some kind of online debugging.

It does have a large memory foot print but I suspect not much more than 
any language with similar features. The cost of the memory was well 
worth it due to the number internet protocols I could support quickly. I 
found unicode support had a large foot print and building Python without 
unicode can be done but a number of library packages expect unicode 
support (well at least the email parts I tried).

I run-time performance for my applications was fine. I compiled the 
Python source code and uploaded it which made start up much quicker and 
consumed less memory. My application was network based and so most of 
the time was spent waiting for comms. If you have a performance issue 
write it in C and bind it to Python.

You set the priority the Python main thread runs at so make it lower 
than your application. I bound RTEMS calls to Python and so was able to 
wait on events and play with mutexes.

If you have further questions or need some help let me know.


More information about the users mailing list