Best Scripting Language For Embedded Work?

We develop embedded software for 32-bit micros using Windows as the development platform.

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.)

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.)

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

d)Graphical capability would be nice.

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

Thanks, Dave Ashley

Reply to
David T. Ashley
Loading thread data ...

What are you doing that is beyond the capabilities of make?

--
Tim Wescott 
Wescott Design Services 
 Click to see the full signature
Reply to
Tim Wescott

I would recommend Lua also. It easy to embed, easy to extend with your own commands, has an active support community, etc. Size may be a problem for some embedded systems though. Last time I used it this way (Lua 5.0 or 5.1, WINCE 5.0) the compiler/interpreter DLL was about 260 Kbyte. (Remember Turbo Pascal at 30K?)

Other options with a smaller footprint: Pawn, Pico-C. (And if nobody is looking, Forth.)

--
Roberto Waltman 

[ Please reply to the group, 
 Click to see the full signature
Reply to
Roberto Waltman

Lua is much smaller than Python and easier to embed in C programs. The language itself isn't as nice though.

Reply to
Paul Rubin

Actually, re-reading your post, it sounds like you want this script interpreter to run under Windows rather than in an embedded program. It's still not really clear. If Windows is the target, file size and memory aren't really issues, so Python may indeed be a good choice. It has pretty good tools for Windows packaging if that matters.

Reply to
Paul Rubin

Python is almost certainly the easiest language to work with for that kind of thing - it is excellent at working with text (such as to generate your source files), handles files well, and has libraries for almost everything - including for working with zip files.

Is this really an issue? Can't you just say "the host computer needs Python 2.6", like the rest of the world does? If the exact version of your interpreter is an issue, you've got big problems before you start.

It is possible to combine your python code, the python interpreter, and required DLL's into a single exe file if you need it.

If you are doing your job properly, you add commands and library functions to the scripting language in the scripting language for efficiency, not C - because development efficiency is going to be much more important than run-time efficiency in such a system. The whole point of languages like Python is that it is easier and faster to develop your code with high-level languages with lots of features and libraries, than it is to use a low-level language like C.

Having said that, it's not hard to get Python code to call external DLL's (or Linux SO's), so you can do it that way. It's a lot more awkward to write proper C extensions for Python if you are not used to it.

No problem.

There are many gui toolkits, such as Tkinter, wxWidgets, etc.

Others have mentioned lua. If it really is an issue that you want a small, self-contained interpreter, then lua is a good choice. And if you really need to integrate C code directly with the interpreter, then again lua is ideal. But I don't think either of these conditions make sense as you describe them, so Python is a better match (because it is higher level, more powerful, easier to use, and has more libraries than lua).

Reply to
David Brown

Does he want to run the scripts on the development host or on the target?

--
Grant Edwards               grant.b.edwards        Yow! Can you MAIL a BEAN 
                                  at               CAKE? 
 Click to see the full signature
Reply to
Grant Edwards

While I'm a big Python fan and have written a lot of applications in Python, it's not always a great solution for manipulating files. In cases where what you're doing is primarily file manipulation, bash usually turns out to be simpler and easier.

--
Grant Edwards               grant.b.edwards        Yow! Hello...  IRON 
                                  at               CURTAIN?  Send over a 
 Click to see the full signature
Reply to
Grant Edwards

The OP is working with windows - bash is not simpler or easier there. Possible, yes, but not simpler and easier. (How people can use Windows for work without installing msys is beyond my comprehension...)

I agree that on *nix, bash is good for that sort of thing. However, once things get a little bit complicated, I tend to turn to Python anyway. Given the choice of "advanced" bash (loops, conditions, etc.) or file manipulation with Python, I usually go for Python due to familiarity. So if you first need Python (and "generating certain source files automatically" sounds to me like text file generation, for which Python is a much better choice than bash), why not stick to it for your file handling too?

The *nix way is perhaps to use bash where bash is strongest, and Python where Python is strongest - both interpreters are already on the system. But the OP is using Windows - Python alone is therefore easier than Python /and/ bash.

Reply to
David Brown

They use Cygwin. :)

Initially, using Python is definitely going to be easier. In the long run, I still think using Cygwin or MSYS and a real shell and real development tools is less work that writing your own Python versions of bash, find, grep, make, xargs and so.

--
Grant Edwards               grant.b.edwards        Yow! We just joined the 
                                  at               civil hair patrol! 
 Click to see the full signature
Reply to
Grant Edwards

I read his original post as meaning that he wants it on the host side. Certainly if he wants it on the target side then it's a different story (although for some things it may still make sense -- "embedded" processors can get pretty desktop-like these days).

--
Tim Wescott 
Wescott Design Services 
 Click to see the full signature
Reply to
Tim Wescott

I honestly find Tcl to be better for this sort of thing; but I am quite sure I am biased.

Strings are not only first class objects in Tcl, they are very nearly the *only* first class object.

With Python, it's a little less straightforward.

This being said, Python probably has more "market share"; you cna do Python on platforms that Tcl has not made it to yet.

--
Les Cargill
Reply to
Les Cargill

But still a rather good bang-for-the-buck, compared with the other scripting languages.

A usable Lisp interpreter can be done in under 5k object code. But it quickly gets bigger when you start adding useful commands to it. The OP talks about traversing directories, zipping them up, generating code, etc. Some people spend 5k object code on the CRC-32 required for zipping alone :-)

Stefan

Reply to
Stefan Reuther

It depends on what he really needs here - Python code for simple file manipulation is easy, but I agree that replacing make, grep, find or xargs would be a bad idea. But if he is from a pure Windows background, he has probably never heard of these tools anyway - and if he has *nix experience and needed them, surely he'd be trying to use Linux rather than Windows with cygwin (shudder!) or msys.

We'll just have to wait for some more posts from the OP.

Reply to
David Brown

It depends on what you want to script. Replacing grep, with all of it's command line options, would be hard. But replacing any single invocation of grep, with the options hardcoded, is pretty trivial. If your wheel reinvention takes a whopping 3 lines of code it's just not the end of the world to keep reinventing it over and over again.

--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com 
Email address domain is currently out of order.  See above to fix.
Reply to
Rob Gaddi

That isn't actually a plus, IMHO, as it makes it too easy to write code which "mostly works".

E.g. "$x $y" is almost equivalent to [list $x $y], but not quite. [expr $x == $y] is almost equivalent to [expr $x eq $y], but not quite. And so on.

At least it's an improvement over bash. Both make it easy to write half-baked code, but bash makes it almost inevitable.

Nowadays, Python is my preferred "scripting" language, although I don't use it for anything which is likely to have a long lifetime over which it will grow, mostly due to the lack of static typing.

Unfortunately, Python 3.x blew it by forcing everything into Unicode (I mostly use Linux, where all of the system interfaces use byte strings).

Reply to
Nobody

Yes, languages with that sort of pervasive conversion are sometimes snidely called "stringly typed".

Python 3 has separate string (=unicode) and bytes (=byte string) types. Haskell has something similar.

Reply to
Paul Rubin

I know what you mean. You do have to defend yourself from that.

So what's wrong with that? That's actually a source of power in some cases. That is, IMO, useful.

Oh, sure. I won't disagree about those at all. Never mind what happens when you have curly braces in a file you're parsing. A text file is a list of (lists of words) delimited by newlines , right? Nope - here comes a { without a matching } on the same line....

bash scripts can only support so much weight. True also of Tcl; but for some reason Tcl is closer to a sweet spot.

bash is quite a bit harder to debug, IMO.

Right. I just find Python a bit more tedious.

many of the things I have to write are doing someting in a communications domain. Event driven sockets and serial ports are just easy in Tcl.

FSM are also easy:

namespace eval myFSM { array set vee {

0 { ... set state 1 } 1 { ... } ...

set trigger 0

proc startFSM { variable state variable vee set state 0 set something 1 while {$something) { vwait trigger eval $vee($state)

} } } # namespace myFSM

...

after 1000 " ::myFSM::startFSM "

Now it is as if you had a thread but more minimal.

I find that things constructed in this manner are pretty robust and can live a long time. As with anything, you'll have to reorient yourself after you've been away from it for a while, but that generally doesn't happen often.

You can also set up trace operators on variables, so queues, callbacks and timers are pretty easy.

I think Python is a little better for larger things, where multiple people are involved. However, I write a lot of "single serving" programs ( in the Fight Club sense of "single serving" ) - stuff that only I use. They're usually test rigs, not production.

--
Les Cargill
Reply to
Les Cargill

You are not doing a good job of tempting me away from Python!

I sometimes use Python for large programs too - the text manipulation, lists, dictionaries, and libraries make it easy to work with. I too miss static typing and declaration-before-use, which would catch more errors at "compile" time rather than run-time. No language is perfect.

With C++11 and "auto" (and a few other features), C++ has gone up a notch in my opinion, and I might consider it for PC applications. Now the syntax for things like dictionaries/hashes and lists is merely absolutely hideous. The compile-time warning and error checking beats Python, of course.

But for scripting and utilities, Python is normally my first choice.

Serial ports are easy in Python too.

I don't see a problem with that (though my use of Python 3 has been minimal so far). I have often had problems with Python 2 with mixups between Unicode strings and data in other encodings (some of us have to live with non-ASCII strings in daily life) - I like the new separation between strings and byte arrays.

Reply to
David Brown

It's not *that bad - you do have to watch quotes, parens and braces though.

I'll usually spend five minutes cursing and using regsub to fix this...

--
Les Cargill
Reply to
Les Cargill

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.