TCL for embedded microcontroller applications
Stefan Franke
on a 16 bit microcontroller? The size of the interpreter kernel is
definitely an issue - since I need only the core language, can all
the OS specific stuff (file handling etc) be stripped off to reduce
the interpreter size?
# ---------------------------------------------------------------
# stefan franke email fra...@iti.informatik.tu-darmstadt.de
# please remove the phrase "antispam." from my reply address
# bitte den text "antispam." aus der antwortadresse entfernen
# ---------------------------------------------------------------
Cameron Laird
Stefan Franke <antispa...@iti.informatik.tu-darmstadt.de> wrote:
>Can TCL be used as a scripting language for an embedded application
>on a 16 bit microcontroller? The size of the interpreter kernel is
>definitely an issue - since I need only the core language, can all
>the OS specific stuff (file handling etc) be stripped off to reduce
>the interpreter size?
.
.
Yes, and yes and no.
Tcl *is* used for many embedded applications on 16-bit
microcontrollers. I expect some of the references will
come through soon.
There's a real question about how to do it, though.
Tcl originated as an embeddable language, and it was
very easy to do what you describe with early versions
(which were quite small). Now Tcl is a full-blown
general-purpose language, and it simply doesn't fit in
applications like yours.
What to do? Long-term, many of us hope and argue that
the core Tcl team will rework the basic distribution
to facilitate the kind of segmentation you need; that
is, make a Tcl that's just the command-processor, with
I/O, higher arithmetic, networking, ... as loadable
and/or linkable modules. That doesn't seem imminent,
though, and, in any case, doesn't answer your immediate
need.
If I were doing it, right now, I'd start with a base of
7.6, and strip out stuff I don't need. I'd choose 7.6
because I've worked with it in this regard, and I know
I'd be successful quickly.
There's nothing wrong with 8.0; maybe it's even easier
than 7.6. I simply do not have experience enough to
say whether the new Object-handling complicates or
simplifies this use of Tcl.
I might advise someone new to Tcl to go back as far as
possible to look for a particularly tiny release. I
feel comfortable recommending 7.3, for example; although
I have no definite notion about how big it was, I know
that its incidence of faults is low enough to make it
reliable in an application such as yours.
--
Cameron Laird http://starbase.neosoft.com/~claird/home.html
cla...@NeoSoft.com +1 713 996 8546 FAX
Philippe Le Foll
>In article <35e4365...@129.188.137.102>,
>Stefan Franke <antispa...@iti.informatik.tu-darmstadt.de> wrote:
>>Can TCL be used as a scripting language for an embedded application
>>on a 16 bit microcontroller? The size of the interpreter kernel is
>>definitely an issue - since I need only the core language, can all
>>the OS specific stuff (file handling etc) be stripped off to reduce
>>the interpreter size?
> .
>
>7.6, and strip out stuff I don't need. I'd choose 7.6
>because I've worked with it in this regard, and I know
>I'd be successful quickly.
>
>There's nothing wrong with 8.0; maybe it's even easier
>than 7.6. I simply do not have experience enough to
>say whether the new Object-handling complicates or
>simplifies this use of Tcl.
>
I used TCL-8 in conjuction with VxWorks and the object approach
really help me in order representing complex structures, the dual
representation even if it has many limits is very helpfull and final
product if much more faster than previous interface I made with 7.X.
Nevertheless If we think of a small code, then 7.x is surelly better
because currentelly internal compiler can not be removed from
make configure tool.
Tcl 7.x and 8.0 as been interface with VxWorks looking for both
implementations is probabelly a good start for any embedded applications.
My personnal job target was to test VxWorks applications, which is not
exactelly what you are looking for. My tool for Tcl/VxWorks is named
jWrap and can be download from www.fridu.com.
Philippe
lvi...@cas.org
I was just looking at my tcl 8.0p2 executable. I start it up, and then
I do a ps -elfy . The size reported is 3,880 kilobytes, without any
additional variables created or packages loaded. This despite the fact
that the disk image is 6k (plus the size of all the dynamic libraries)...
Commercial users of Tcl who need the runtime image to be very small should
be sure to contact Scriptics about the needs you have and the amount
you are willing to pay for a solution.
--
<URL:mailto:lvi...@cas.org> Quote: In heaven, there is no panic,
<*> O- <URL:http://www.teraform.com/%7Elvirden/> only planning.
Unless explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
Cameron Laird
.
.
.
>Commercial users of Tcl who need the runtime image to be very small should
>be sure to contact Scriptics about the needs you have and the amount
>you are willing to pay for a solution.
.
.
I want to clarify this. That is, I'm going to make a few ex-
tra points, all of which I believe have Larry's agreement. In
any case, things look this way to *me*.
Scriptics is not the only solution provider in this domain
(the thread began with consideration of Tcl for an embedded
processor). It's natural to look to Scriptics and no farther,
and this might well be my advice for some requirements. Still,
readers should be aware that several other consultancies have
experience and ability in embedding Tcl in specialty hardware.
Larry traditionally remarks at about this place in a thread
that developers who succeed with an interesting product or pro-
ject should send notice of it to him so he can include it in
his FAQs (or, on occasion, pass it on to me or others, who
also maintain pages for such sorts of information).
Also, the Tcl Conference, Usenix sessions, academic engineering
conventions and a wealth of other outlets are available for
anyone inclined to share his or her outcomes, techniques, false
starts, comparisons, ... Note in particular that the first of
these, whose next instance is just a couple of weeks away, has
a strong tradition of Work-in-Progress (WIP) presentations.
lvi...@cas.org
According to Cameron Laird <cla...@Starbase.NeoSoft.COM>:
:In article <6s9fph$e81$1...@srv38s4u.cas.org>, <lvi...@cas.org> wrote:
:>Commercial users of Tcl who need the runtime image to be very small should
:>be sure to contact Scriptics about the needs you have and the amount
:>you are willing to pay for a solution.
: .
:tra points, all of which I believe have Larry's agreement. In
:any case, things look this way to *me*.
:
:Scriptics is not the only solution provider in this domain
followed by lots of good stuff...
<BLUSH>
I really apologize to all of you about that. I don't know _where_ my
brain was. Of course, Neosoft, CPU, and so many others out there are
supporting Tcl, and I didn't intentional mean to imply that companies
should run to Scriptics for all your work.
For that matter, this shouldn't be a big deal for a company to take on
as their own project.
However, once you've worked through the process, if you would like to
not have to reimplement (or repurchase) the efforts of doing this to
whatever becomes a new release of Tcl, please do share the results with
Scriptics (and the rest of us <grin>). With so many people dealing
with small systems these days (MIT and their wearable CPUs, 3com and PalmOS,
various and sundry companies and Windows CE, Apple and their upcoming
MacOS X small boxes, etc.) I think this is a great opportunity.
Also, I know that there was an announcement for some discussions about
"PalmScript" for a port of Tcl to the PalmOS environment - perhaps something
will fall out of that work that would be appropriate.
....
Wow - what a way to start out a Monday. My foot squarely in my mouth.
Thanks Cameron for being so diplomatic about this . I am mortified!
Cameron Laird
>
>According to Cameron Laird <cla...@Starbase.NeoSoft.COM>:
>:In article <6s9fph$e81$1...@srv38s4u.cas.org>, <lvi...@cas.org> wrote:
>:>Commercial users of Tcl who need the runtime image to be very small should
>:>be sure to contact Scriptics about the needs you have and the amount
>:>you are willing to pay for a solution.
>: .
>:I want to clarify this. That is, I'm going to make a few ex-
>:tra points, all of which I believe have Larry's agreement. In
>:any case, things look this way to *me*.
.
.
>Wow - what a way to start out a Monday. My foot squarely in my mouth.
.
.
NOW I've found something on which Larry and I disagree.
His feet are squarely planted on the ground, and nowhere
near his mouth.
What he wrote was entirely accurate. I just know from
my own experience how often outsiders to the Tcl world
don't "get" many of our habits and assumptions; I only
intended to honor Larry by using somewhat different
words for the ideas he so often volunteers for the bene-
fit of the Tcl community.
Larry's follow-up is right: these are exciting times for
Tcl. There are great opportunities for Tcl to make big
contributions on rendering such hot technologies as XML,
CORBA, LDAP, Unicode, Java, palmtop computing, component-
based development, ... safe for human consumption. One
of the reasons to seek out his posts, of course, is his
success at linking a particular answer to a particular
question, with the larger themes and issues active in Tcl
work.
Ilya Zakharevich
<lvi...@cas.org>],
who wrote in article <6s9fph$e81$1...@srv38s4u.cas.org>:
>
> I was just looking at my tcl 8.0p2 executable. I start it up, and then
> I do a ps -elfy . The size reported is 3,880 kilobytes, without any
> additional variables created or packages loaded. This despite the fact
> that the disk image is 6k (plus the size of all the dynamic libraries)...
Assuming Solaris, can you do
/usr/proc/bin/pmap pid
(on Linux it is may be
more /proc/12605/maps
).
Ilya
Robert Heller
In a message on 31 Aug 1998 23:20:43 GMT, wrote :
IZ> [A complimentary Cc of this posting was sent to
IZ> <lvi...@cas.org>],
IZ> who wrote in article <6s9fph$e81$1...@srv38s4u.cas.org>:
IZ> >
IZ> > I was just looking at my tcl 8.0p2 executable. I start it up, and then
IZ> > I do a ps -elfy . The size reported is 3,880 kilobytes, without any
IZ> > additional variables created or packages loaded. This despite the fact
IZ> > that the disk image is 6k (plus the size of all the dynamic libraries)...
IZ>
IZ> Assuming Solaris, can you do
IZ> /usr/proc/bin/pmap pid
IZ> (on Linux it is may be
IZ> more /proc/12605/maps
IZ> ).
IZ>
IZ> Ilya
IZ>
Most likely the extra 2+ Ks in the executable is debug and symbol info, which
does not get loaded into memory for normal execution. Since
the shared libraries are "shared" their memory (code) usage is not counted
against any one process -- it is probably counted as some kind of recoverable
system space -- memory allocated to the "system" with a ref-count (number of
processes referencing the shared libraries), which is freed when the ref-count
goes to 0 (it might not be freed right away, but at the next time the system
needs the space).
--
\/
Robert Heller ||InterNet: Hel...@CS.UMass.EDU
http://vis-www.cs.umass.edu/~heller ||FidoNet: 1:321/153
http://netmar.com/mall/shops/heller /\