Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions?

Weighing in with a base-line requirement of about 8k of code-space and easily extensible I would suggest Forth could probably suit your needs very well. You add a little bit to it and design the script language environment you need. You didn't mention which processor you are using in the product but there is a Forth for most targets out there.

See or for further information. There are also some free to download books to help.

--
******************************************************************** 
Paul E. Bennett IEng MIET..... 
 Click to see the full signature
Reply to
Paul E Bennett
Loading thread data ...

+1 for that.

Lisp can be implemented in 5k flash, but still has the problem of user acceptance. So I would choose Lua; I have already used it for writing test drivers.

Another group managed to sneak a Python interpreter into their product, but that's a huge Java blob, so I cannot say how much memory the Python takes.

This should be enough for Lua. If it's not enough, I believe Lua can be off-line compiled.

Stefan

Reply to
Stefan Reuther

We had a related discussion in this thread from the middle of last year:

formatting link

Reading through it, I think Squirrel is the only language that this thread hasn't mentioned.

Regards, Allan

Reply to
Allan Herriman

AFAIK, Forth is the language of OpenBoot and its ancestors. I have last really used Forth with boot of Intergraph workstations (based on M68k) in early 1980's.

Forth is a fascinating language for old HP calculator users, but in my classification, it belongs to the group of write-only languages.

--

-TV
Reply to
Tauno Voipio

It still is and there is also a version called FICL which most BSD users might recognise.

Whilst the underlying VM model has remained the same, there have been a number of changes in the language definition. However, it still performs well as an Application Specific Language Builder allowing you to create the script language you need.

With a reasonable coding style it is far from Write-Only. As Chuck would say, Forth is an "Amplifier of Programmer ability". It has been used in some collaborative projects where reading others code was an important aspect of the project. Still, it is Tim's choice.

--
******************************************************************** 
Paul E. Bennett IEng MIET..... 
 Click to see the full signature
Reply to
Paul E Bennett

openocd has a version of Tcl built-in for scripting. It works. Can't say whether Lua would be better.

Reply to
Mel Wilson

All languages of that period suffered from such remarks. Try a modern Forth in order to make current observations.

I speak as someone who wrote their first software in 1967.

Stephen

--
Stephen Pelc, stephenXXX@mpeforth.com 
MicroProcessor Engineering Ltd - More Real, Less Time 
 Click to see the full signature
Reply to
Stephen Pelc

Yes. And you can use tk without tcl! :> (limbo uses a tk implementation for its UI builder)

The above isn't technically "wrong". If you think about it, the expression evaluates to FALSE. I'd rather the language not allow such "mistakes".

tcl/tk's big development win was wish.

IME, one of the biggest advantages to many of these languages was their interpretive/JIT-ed nature. A development cycle was just edit-test instead of edit-compile-link-test. Likewise, being able to "stop" the program and probe its contents.

Reply to
Don Y

I win by a few years, June 1964, with an IBM 1620.

--

-TV
Reply to
Tauno Voipio

The problem is that in some languages 5 == "5" is true. I've never actually used Lua, but IIRC, TCL makes that mistake, as does Javascript (both mentioned elsewhere in this thread).

George

Reply to
George Neuner

Which is crazy. Looks like a bastard cross between Pascal's assignment and Modula's constant declaration syntax.

That's more reasonable. If you using := for assignment, then = is equal and multiple value equal doesn't make a whole lot of sense unless you're talking about ordered sets (tuples). But I would assume that Limbo has a syntax for constant tuples.

But a tuple semantically is different from multiple values. A tuple is a single container with multiple content - the container must be "opened" to get at its content whereas the individual values (typically) do not.

Then there is the question of whether tuples can be frame allocated or whether they end up on the heap. And whether a tuple has O(1), O(N) or O(something else) access.

Depending on the implementation, it might actually be faster to allocate a heap tuple than to return/set multiple values. But because it usually is slower to unpack the tuple, that may eat up any saving from using it in the first place.

George

Reply to
George Neuner

No, there are other uses - the most common to return both a result and error/status from a function.

However, multiple assignment - or equivalently, multiple value return

- too often is abused by allowing some of the values to be elided. There are times when all values aren't interesting, but IMO there should be a syntactic placeholder that is not assigned to.

Remember which forum you're in 8-)

Currying creates closures and *may* additionally require GC. Many high level language features don't mix well with small devices.

George

Reply to
George Neuner

Javacard would fit depending on the libraries you include. Javacard is a Java VM, but pure interpreter and very small. It does not support dynamic load or verification of class files. Be aware though that Javacard also has no GC - applets have to request heap space at startup and manage it (if they are so inclined) themselves.

I haven't used Lua myself (dose of salt) but my understanding is that the VM is separable. If you can cross compile the bytecode, it should be workable.

TCL will look weird to many people. IME (not recent) it also has lousy feedback on script errors. I have never tried to use it in a really small space so I can't comment on it's minimum RAM needs.

Code space wise, any of these should have plenty of headroom with

100KB. The real question is how much RAM can they use?

If you have a little more [well, 3x] space I'd mention TCC.

Have you looked at PicoC ?

formatting link

George

Reply to
George Neuner

GC is present in some Javacard devices. Maybe more of a problem is that I don't think Javacard is open source.

I checked into this yesterday and tcl these days has gotten rather bloated. The "small footprint" version is 100k-200k of code:

formatting link

I used an embedded tcl several versions back and it was smaller then, but people probably expect the recent improvements.

It doesn't sound like there's much need to host the compiler on the embedded board, and using C defeats a main benefit of scripting languages, which is to supply automatic memory management and protect the user from the usual C hazards like pointer errors causing memory corruption.

I do see there are some Scheme implementations around with mighty small ram requirements, e.g.

formatting link
(scroll down the page) discusses some targets with as little as 32k of flash and 8k of ram. It is written in ARM assembler though, making me wonder if it has a reasonable C FFI.

formatting link
might also be interesting: someone just pointed it out to me and I haven't looked at it much yet.

For simple purposes like UI customization, Scheme is probably ok for non-Schemers since they can probably get their stuff working by copying and modifying existing examples. There are also lots of books on Scheme. So it seems worth looking into these if Lua turns out to be too large.

I looked at Tiny Scheme which is a well known small implementation (about 40k), but its ram footprint looks rather large, maybe since it uses a recursive S-expression evaluator instead of a VM.

I'm a fan of Hedgehog Lisp which has an offline compiler and a very compact VM (about 20k), but it's a weird dialect with almost no users. Sometimes I think of hacking it to be more compatible with Scheme, and maybe adding alternative front end to it. For a while I thought using its VM as a runtime for a Haskell dialect for microcontrollers that I wanted to call "Control-H", so that the file extension would be a backspace character. ;-)

Reply to
Paul Rubin

It's effectively, x: int; y: int; x = 3; y = 3; Or, x, y: int; x = y = 3;

':=' declares and defines; ':' declares while '=' defines So, x, y = 3;

That's not required in limbo. E.g., it is common for a function to return a tuple: one member being a flag (success/fail) with the other(s) being the expected result(s).

E.g., you could create a function that parses a (unsorted) list of values comparing each to a "given" and returns:

- the count of values below the given value

- the count of values above the given value

- the count of values *at* the given value

- a (sorted?) list of all (unique) values below the given value

- a sorted list of all the unique values above the given value

- a summary code (like an error code: LIST_EMPTY, SUCCESS, etc.) [Note that the number of entries in each of these lists may be less than the *counts* returned as duplicates will be elided]

In the following, assume the "values" are strings:

check_list( given: string, // what we seek candidates: list of string // where it is sought ) : (int, // count below int, // count at int, // count above list of string, // sorted strings below sought list of string, // sorted strings above sought int // result code )

it could then be invoked as:

(below, at, above, before, after, result) := check_list("Penny", names);

Use of the ':=' operator saves me the effort of declaring each of the types of the members of that tuple. This is sort of an "anonymous" tuple (the function could have returned it's values to a variable of the appropriate tuple type)

Then, I could say: if (below < above) { sys->print("Of the " + string (len names) + "names examined, far" + " more names preceded the name of interest than followed." + " There were %d different names preceding, lexically," + " and %d names following.", len before, len after); ...

[Highly contrived example]

Assuming these are the only return values used from that function invocation, a smarter way of invoking it would have been:

(below, nil, above, before, after, nil) := check_list("george", names);

which makes it obvious which values are not used.

Reply to
Don Y

IMO there are other use cases, like rteurning multiple values, and dissecting a tuple (you can argue that these are the same case):

status, result = some_operation() name, address = person

Wouter

Reply to
Wouter van Ooijen

Very nice!

And I see that bitwise operators are now official, rather than just a common patch.

That pretty much removes the two stumbling points Lua had as an embedded language for something like a Cortex M4.

Reply to
David Brown

Javacard does not require GC - that's an extension. The standard manager allocates but does not recycle until the applet ends.

Oracle's VM isn't *libre*, but it is an open reference platform. There are FOSS versions available.

I also like Scheme, but it is a non-starter for a lot of people. Notwithstanding that a lot of scripts could be accomplished by modifying examples, the prefix notation just seems to turn off many people.

I have, on occasion, embedded Guile and mzScheme. Bare bones, they are small enough, but useful configurations grow quickly.

George

Reply to
George Neuner

And how do you access those values in the tuple - surely it can't be the same as values not in the tuple.

Multiple-value return is more complex than single-value return. Many languages allow functions to return a container type to preserve the (relative) simplicity of the single-value return. Ansi C does this with structs.

I don't know what Limbo does, but tuple using languages typically allocate the tuple and its contents separately and then return a reference to the tuple. Which goes back to what I said about the cost of accessing the values.

George

Reply to
George Neuner

Right, fair enough, but some devices do include it.

Sort of like Microscheme :)

Oh cool, good to know.

Hmm, I had been wondering about the memory footprint of Guile. I know that it has some front ends for other language syntaxes, particularly Ecmascript a/k/a Javascript, with Lua supposedly in development.

I spent yesterday evening looking into very small ram-stingy Scheme implementations and I wonder whether the Guile Ecmascript front end could be used with them. But, it probably increases the product's support burden.

Picobit looks interesting:

formatting link

Absolutely unsuitable for non-nerd user scripting, but maybe of interest to language geeks: Purescript (purescript.org) is a Haskell dialect that compiles to Javascript, and could be probably made to generate Scheme instead. I think someone is already working on retargeting it to Lua. But I think the pure functional approach (no mutable data, lots of GC) isn't a good fit for small embedded systems.

Reply to
Paul Rubin

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.