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

Tim Wescott wrote:

> The title says most of it.
> 
> I'm working on a project for which the customer wants a lot of flexibility
> to customize a product.  The existing "macro language" is ancient (ca
> 1985), cryptic (it looks like machine language), limited, clunky, etc.
> The customer is willing to change.
> 
> I'm planning on having a chunk of serial flash (or an SD card) with a file
> system on it (maybe FAT, maybe something home-rolled and primitive).
> Scripts will be stored as text files, and read in as appropriate.
> 
> Rather than just use some clunky cryptic and limited language that's
> unique to the problem and to me (and charging my customer up the wazoo for
> it), I'd like to use something that's open-source and available.
> Something that uses modest resources is to be preferred -- my
> understanding is that I can expect Lua to use about 100k of flash, which
> is a bit much for me but bearable.  I don't know how Tcl compares -- I
> just know that it's an alternative.
> 
> So -- anyone have any direct experience with either of these, or with
> something else?  We briefly considered Java, but it just looks entirely
> too big -- it would basically drive us to use Linux or some other "real"
> OS (even the little linuxes are too big for my tastes) -- I'd really
> rather just have a scripting engine that gets called whenever a script
> needs to run, and otherwise doesn't need much hand-holding from the
> application code.
> 
> I'm looking for opinions, so fire away!
> 


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 <http://www.mpeforth.com/> or <http://www.forth.com/> for further 
information. There are also some free to download books to help.

-- 
********************************************************************
Paul E. Bennett IEng MIET.....<email://Paul_E.Bennett@topmail.co.uk>
Forth based HIDECS Consultancy.............<http://www.hidecs.co.uk>
Mob: +44 (0)7811-639972
Tel: +44 (0)1392-426688
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

Tim Wescott wrote:
> On Fri, 13 Mar 2015 20:16:32 -0700, Paul Rubin wrote:
>>7. If you're -really- resource constrained or your scripts need realtime
>>guarantees, there is Forth, but I'd stay away from it if you have enough
>>cpu and memory to run something like Lua.
>>
>>Of all the above, based on the limited info you've given, the quick
>>answer is probably "Lua unless you can afford Javascript or you're a
>>language geek and like Lisp".

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

> I'm trying to stick with an ARM M4 cored processor that has 256kB to 
> 512kB of flash, and maybe 64kB of RAM, and a 72MHz CPU speed.  Everything 
> can run at "human time", so delays of no less than 50ms are OK.  There is 
> an issue that a really hot operator shouldn't be able to overrun the 
> machine, but the buttons are actuated by a wand (it's complicated -- they 
> just are), which should slow things down.

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


  Stefan

On Fri, 13 Mar 2015 16:27:12 -0500, Tim Wescott wrote:

> The title says most of it.
> 
> I'm working on a project for which the customer wants a lot of
> flexibility to customize a product.  The existing "macro language" is
> ancient (ca 1985), cryptic (it looks like machine language), limited,
> clunky, etc. The customer is willing to change.
> 
> I'm planning on having a chunk of serial flash (or an SD card) with a
> file system on it (maybe FAT, maybe something home-rolled and
> primitive). Scripts will be stored as text files, and read in as
> appropriate.
> 
> Rather than just use some clunky cryptic and limited language that's
> unique to the problem and to me (and charging my customer up the wazoo
> for it), I'd like to use something that's open-source and available.
> Something that uses modest resources is to be preferred -- my
> understanding is that I can expect Lua to use about 100k of flash, which
> is a bit much for me but bearable.  I don't know how Tcl compares -- I
> just know that it's an alternative.
> 
> So -- anyone have any direct experience with either of these, or with
> something else?  We briefly considered Java, but it just looks entirely
> too big -- it would basically drive us to use Linux or some other "real"
> OS (even the little linuxes are too big for my tastes) -- I'd really
> rather just have a scripting engine that gets called whenever a script
> needs to run, and otherwise doesn't need much hand-holding from the
> application code.
> 
> I'm looking for opinions, so fire away!

We had a related discussion in this thread from the middle of last
year:
https://groups.google.com/d/msg/comp.arch.embedded/geUFbpOZ2J4/eY4zcBLWsJYJ

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

Regards,
Allan

On 14.3.15 10:43, Paul E Bennett wrote:
> Tim Wescott wrote:
>
>> The title says most of it.
>>
>> I'm working on a project for which the customer wants a lot of flexibility
>> to customize a product.  The existing "macro language" is ancient (ca
>> 1985), cryptic (it looks like machine language), limited, clunky, etc.
>> The customer is willing to change.
>>
>> I'm planning on having a chunk of serial flash (or an SD card) with a file
>> system on it (maybe FAT, maybe something home-rolled and primitive).
>> Scripts will be stored as text files, and read in as appropriate.
>>
>> Rather than just use some clunky cryptic and limited language that's
>> unique to the problem and to me (and charging my customer up the wazoo for
>> it), I'd like to use something that's open-source and available.
>> Something that uses modest resources is to be preferred -- my
>> understanding is that I can expect Lua to use about 100k of flash, which
>> is a bit much for me but bearable.  I don't know how Tcl compares -- I
>> just know that it's an alternative.
>>
>> So -- anyone have any direct experience with either of these, or with
>> something else?  We briefly considered Java, but it just looks entirely
>> too big -- it would basically drive us to use Linux or some other "real"
>> OS (even the little linuxes are too big for my tastes) -- I'd really
>> rather just have a scripting engine that gets called whenever a script
>> needs to run, and otherwise doesn't need much hand-holding from the
>> application code.
>>
>> I'm looking for opinions, so fire away!
>>
>
>
> 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 <http://www.mpeforth.com/> or <http://www.forth.com/> for further
> information. There are also some free to download books to help.


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

Tauno Voipio wrote:

>> 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 <http://www.mpeforth.com/> or <http://www.forth.com/> for further
>> information. There are also some free to download books to help.
> 
> 
> 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.

It still is and there is also a version called FICL which most BSD users 
might recognise.
 
> Forth is a fascinating language for old HP calculator users, but in my
> classification, it belongs to the group of write-only languages.
 
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.....<email://Paul_E.Bennett@topmail.co.uk>
Forth based HIDECS Consultancy.............<http://www.hidecs.co.uk>
Mob: +44 (0)7811-639972
Tel: +44 (0)1392-426688
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

On Sat, 14 Mar 2015 07:50:15 +0000, mroberds wrote:

> Now that I think about it, all the GUI stuff seemed to be a combination:
> Tcl/tk.  I guess you can use Tcl on its own without tk.

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

On Sat, 14 Mar 2015 13:55:08 +0200, Tauno Voipio
<tauno.voipio@notused.fi.invalid> wrote:

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

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
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

Hi Matt,

On 3/14/2015 12:50 AM, mroberds@att.net wrote:
> Don Y <this@is.not.me.com> wrote:
>> On 3/13/2015 5:28 PM, mroberds@att.net wrote:
>>
>>> For a while, sometimes Tcl was used as sort of the Linux equivalent
>>> of Visual Basic - for when you wanted a simple GUI but didn't want to
>>> spend weeks screwing around with X/(GTK|Qt)/C++.
>>
>> Are you sure you're not thinking of tk?
>
> Now that I think about it, all the GUI stuff seemed to be a
> combination: Tcl/tk.  I guess you can use Tcl on its own without tk.

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

>>> The thing I found odd about the choice of Lua for this application
>>> was that *it didn't have any bitwise operators*.
>>
>> I didn't like the fact that you could mix and match types without
>> anything alerting you to the fact that you're trying to do something
>> "wrong".  E.g., if (5 == "5")...
>
> I don't remember ever crashing Wireshark by screwing up my Lua scripts.

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

> Things just wouldn't decode / display on the Wireshark GUI correctly.
> If that happened, I could always save the captured packets to a file,
> fix my Lua script, reload the file in Wireshark, and have the script
> run again.
>
> The Lua interpreter also supported a simple printf-like function that
> would just display on the Wireshark console and not in the GUI.

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.

> Wireshark would open a separate 80x25 text window when you used the
> console.  I found this useful for answering "am I pulling the right
> bytes out of the packet or not", and *then* I could work on pushing
> those bytes to the GUI in a useful way.

On 14.3.15 20:04, Stephen Pelc wrote:
> On Sat, 14 Mar 2015 13:55:08 +0200, Tauno Voipio
> <tauno.voipio@notused.fi.invalid> wrote:
>
>> 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.
>
> 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.


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

-- 

-TV

On Sat, 14 Mar 2015 11:46:56 -0700, Don Y <this@is.not.me.com> wrote:

>On 3/14/2015 12:50 AM, mroberds@att.net wrote:
>> Don Y <this@is.not.me.com> wrote:
>
>>> I didn't like the fact that you could mix and match types without
>>> anything alerting you to the fact that you're trying to do something
>>> "wrong".  E.g., if (5 == "5")...
>>
>> I don't remember ever crashing Wireshark by screwing up my Lua scripts.
>
>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".

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