Best Scripting Language for Embedded Work?

Christian Gollwitzer auriocus at gmx.de
Wed Jul 10 03:03:54 EDT 2013


Hi David,

you have multi-posted this to comp.lang.tcl. Please don't do that - use 
crossposting and a proper follow-up (as I did now)

Am 10.07.13 03:29, schrieb David T. Ashley:
> We develop embedded software for 32-bit micros using Windows as the
> development platform.

Robert's answer made me hesitate - what exactly is your platform? Are 
you writing the scripts for the embedded platform, or for Windows, or 
does the embedded controller run Windows RT or something like this?

> We are seeking a general purpose scripting language to automate
> certain tasks, like cleaning out certain directories of certain types
> of files in preparation for ZIP'ing, generating certain source files
> automatically, etc.
>
> Selection criteria:
>
> a)Should be able to compile the script interpreter as a monolithic
> executable (no .DLL dependencies, etc.) for easy versioning and
> distribution of the script interpreter.  (Note that I'm not asking
> that the script be a single executable, just the interpreter.  To run
> a script you'd need both the script and the interpreter.  The script
> would be a text file, and the interpreter would be a single .EXE.)

You are referring to tclkits. Yes, it's indeed possible to compile Tcl 
into a statically linked binary, and C extension packages can be 
statically linked, too. But tclkits are cheating: There are some files 
like the standard library (i.e. init.tcl, the clock command etc., 
unicode encondings...) which are packed into a database and attached to 
the tclkit. The tclkit then opens itself via the file system to read 
these files. I don't know if this is possible in a typical embedded 
system. If you are really talking about Windows, no issue.

Python has similar capabilities, look for pyinstaller or py2exe.

> b)Should be extensible, in that one could add commands or library
> functions to the script interpreter in C (for efficiency), and the
> whole script interpreter could again consist of a single executable
> with no other dependencies.  (Note that I'm not asking that the script
> be a single executable, just the interpreter.  To run a script you'd
> need both the script and the interpreter.  The script would be a text
> file, and the interpreter would be a single .EXE.)

That is possible in Tcl using static packages. In Python I don't know, 
but I think it should be possible.

> c)Should be able to spawn compilers and capture the output, do file
> I/O, and all the other minor expected stuff.

no real issue
> d)Graphical capability would be nice.

For GUI Python relies on either Tcl/Tk, wxwidgets, QT, GTK... I think it 
is possible to assemble these into a packaged binary, too. However it 
will be a rather large thing in the end.

> I know that Tcl/Tk would do all of the above, but what about Python?
> Any other alternatives?

I think Tcl/Tk is a really good match, especially if you are trying to 
do GUI, which is very easy there. Also most scripting stuff is available 
out of the box. Another option might be Lua

http://www.lua.org/

Very compact (a static binary is about ~200K), clean synatx, relatively 
fast. OTOH, the standard library is of course not so extensive as for 
Tcl or Python.

Bash is also an option, because it is some kind of standard for 
scripting. But on Windows it seems alien and you'd need something like 
MobaXTerm to get it into a single file.

	Christian




More information about the Python-list mailing list