Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #37373 > unrolled thread

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

Back to article view | Back to comp.lang.forth

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Embedded Scripting -- Tcl?  Lua?  Thoughts?  Suggestions? rickman <gnuarm@gmail.com> - 2015-03-18 02:34 -0400
    Re: Embedded Scripting -- Tcl?  Lua?  Thoughts?  Suggestions? Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2015-03-18 12:37 +0000

#37373 — Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions?

On 3/13/2015 8:04 PM, Tim Wescott wrote:
> On Fri, 13 Mar 2015 15:03:09 -0700, Don Y wrote:
>
>> Hi Tim,
>>
>> On 3/13/2015 2:27 PM, 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!
>>
>   << smart-assery snipped >>
>>
>> As to *your* question...
>>
>> What sorts of things does the customer expect to *do* with those
>> scripts?
>> And, (besides space) what other constraints are you needing to place on
>> those actions?  E.g., any timeliness constraints?  Performance?
>> Numerical precision?  etc.
>>
>> Who is the intended user:  *just* the client?  Or, will these things be
>> exposed to users?
>>
>> What sorts of things do the scripts interact with (displays, etc.)?
>> E.g., do you need to be able to manipulate a GUI without constraint?
>> Or, are you just serving up text and/or canned dialogs?
>>
>> What sort of user input device (keyboard, keypad, etc.)?  Other I/O's?
>>
>> I opted for a (bastardized) Limbo as my scripting language.  But, I use
>> it to generate "real" applications and not just automate some
>> preexisting actions.  However, it won't fit your memory requirements.
>>
>> Can you tolerate something as "crude" as a bastardized BASIC?  I.e.,
>> add "product specific" hooks to it to address some of the special needs
>> (displays, etc.) at a "native" level.  A BASIC interpreter/compiler can
>> be really small.
>>
>> The same can be said of C interpreters, mini-compilers (JIT).  But,
>> you'd be targeting a different class of "developer" (user).
>
> The product will have a character display, and it'll store text files for
> later retrieval.  It has a measurement thingie (I don't want to get too
> specific -- but it makes measurements) that'll cough up a number when it's
> actuated, and it has a sea of (well, around 100) buttons that the user can
> press.
>
> My intention at the moment is to make the box this big dumb thing with
> some system code that knows to call a function for each measurement and
> button press (i.e., when the user presses button 1, the function named
> "button_1" will get called if it exists).  Then I'll encode the actual
> functionality as a bunch of functions in the language-o-choice.
>
> The nice thing about this is that if a user comes up with some desired
> customization (which we expect, as we're replacing an existing product for
> which this was common), we can either tell them to start coding and have
> fun, or we can charge them $$ to code the thing up to their specifications.
>
> The real driver for wanting to do this as a scripting language is to make
> it easy for the user to customize.  I'm imagining that some users won't
> want to touch the customization with a 10 foot pole, some will be happy to
> customize a button or two, some will get their feet wet and then call us,
> and some will go whole hog with the thing, and do entire systems without
> us even knowing it's going on.

I think what you are describing is Forth.  There are two commercial 
vendors, MPE and Forth Inc.  I know the MPE license allows you to embed 
the "interpreter" into your product for the customer to use.  There are 
also open source Forths around, but with varying levels of embeddability 
and support.  One is Mecrisp which is available for a few of the many 
ARM processors around and the TMS430 I believe.  There are many others.

Forth can be idiot simple to use.  The assumption is it has a serial 
terminal for I/O or something much like it.  I/O can be redirected 
from/to files or anything else by using deferred words.  It can run on 
the bare metal or under an OS.  You can give as much power to your 
customer as you think they can handle or as little as you think is wise.

I've cross posted this to the forth group to get input from some of the 
regulars there.

Oh, about the "file system".  If you are happy with no file system at 
all, Forth can treat your storage as "blocks" of 1 KB and no real files 
at all.  You can't get much simpler than that.

-- 

Rick

[toc] | [next] | [standalone]

#37391

rickman wrote:

[%X]

>> The real driver for wanting to do this as a scripting language is to make
>> it easy for the user to customize.  I'm imagining that some users won't
>> want to touch the customization with a 10 foot pole, some will be happy
>> to customize a button or two, some will get their feet wet and then call
>> us, and some will go whole hog with the thing, and do entire systems
>> without us even knowing it's going on.
> 
> I think what you are describing is Forth.  There are two commercial
> vendors, MPE and Forth Inc.  I know the MPE license allows you to embed
> the "interpreter" into your product for the customer to use.  There are
> also open source Forths around, but with varying levels of embeddability
> and support.  One is Mecrisp which is available for a few of the many
> ARM processors around and the TMS430 I believe.  There are many others.
> 
> Forth can be idiot simple to use.  The assumption is it has a serial
> terminal for I/O or something much like it.  I/O can be redirected
> from/to files or anything else by using deferred words.  It can run on
> the bare metal or under an OS.  You can give as much power to your
> customer as you think they can handle or as little as you think is wise.
> 
> I've cross posted this to the forth group to get input from some of the
> regulars there.
> 
> Oh, about the "file system".  If you are happy with no file system at
> all, Forth can treat your storage as "blocks" of 1 KB and no real files
> at all.  You can't get much simpler than that.

Sometimes don't you wish Usenet had a "Like" button?

MPE's VxfForth is probably best for most of the platforms you are likely to 
be dealing with these days. I do recall suggesting Forth earlier in this 
thread. You really can design the script language you want and make it seem 
quite natural to the user.
 
-- 
********************************************************************
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..
********************************************************************

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.forth

csiph-web