Lua versus C++ for embedded processor

[John Benson]

Regarding the message appended below: I was in a similar situation, only I
had 4 "small" (RAM-wise) legacy processors in a fault-tolerant Tandem K100
system. The system came with an old Borland C++ compiler but I didn't want
to become an expert in anachronistic C++ trivia, so I ported Lua
(www.lua.org) using the perfectly serviceable C compiler. Although I still
need to put in library extensions to access the Tandem's Guardian OS API,
Lua came up quick and easy, gave me object-oriented scripting and provided
access to the applicable portion of the C Standard Library.

I've programmed Z-World Z-180-based embedded microcontrollers in their
Dynamic C language, and will be using their products again but I'm seriously
considering porting Lua in via Dynamic C so I can have object-oriented
scripting to facilitate prototyping and systems integration work. Whether it
will work out in this case is not clear yet, but the Tandem port worked
fine. Maybe Lua has a place in your embedded application, if there isn't
enough infrastructure for Python.

As for C++ on microcontrollers, I have absolutely no idea what the pros and
cons are. Any ideas out there on whether C++ is a good fit there?

Message: 5
Date: Wed, 14 Jan 2004 11:16:48 -0500
From: Peter Hansen <[email protected]>
Subject: Re: I come not to bury C++, but to praise it...
To: (e-mail address removed)
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii

I was still fussing with cfront in the early '90s.
Its era *had* passed by then, though.

And I actually went looking for it again as recently as two years
ago, considering the possibility of using it to allow the use of
C++ code for a small embedded processor which did not have an
available C++ compiler. I actually don't remember precisely why
we didn't try it out, and I assume we simply got distracted by having
to make things work and forgot to continue the search.

Can it be used as a front-end for such chips, where at best there
are two or three C compilers on the market?

-Peter

 

[Peter Hansen]

(Sorry for off-topic posts...)

Maybe Lua has a place in your embedded application, if there isn't
enough infrastructure for Python.

That's something I should seriously investigate. I did consider FORTH
but encountered the usual emotional block which always shows up: the
language is just too "weird" for most people, and I can't saddle the
company with a maintenance issue like that. It just doesn't seem
feasible to expect all the developers to have to learn FORTH just to
write for our embedded products.

Lua, on the other hand, as I understand it, is much more traditional in
flavour and (therefore?) easier to read, so it feels more likely to
find a place. Thanks for the suggestion.

As for C++ on microcontrollers, I have absolutely no idea what the pros and
cons are. Any ideas out there on whether C++ is a good fit there?

I believe the same pros and cons apply there as they do anywhere. Easier
to handle complexity (e.g. encapsulating hardware with clean driver objects)
etc, but possible impact on performance.

-Peter

 

[ciw1973]

I'll be starting a new project using Rabbit modules (the new wonderfully
low cost, feature rich RCM3700) in a couple of weeks time. I'm quite happy
to code in Dynamic C and the new version is supposed to have improved a
good deal, but I do like the idea of using scripting languages where
possible for future maintainability and Lua would probably be about the
only option for a device like the Rabbit. If you port it to Dynamic C,
could you let me know? I'd be very interested.

I took a look at Lua a while ago, and even bought the Lua book to allow me
to get a good feel for the language. It is actually very good, but at the
time I was looking at it as a replacement for Python, but for my
day-to-day, non-embedded work, the lack of additional libraries (compared
to Python) was an issue.

It did strike me as being ideal for embedded work, primarily due to its
size, and deploying a product running software written in an interpreted
language allows quick and easy live remote updating of the software
itself. I've done this on devices based on embedded PC architecture
running Perl, but it always seemed too optimistic a goal on something like
the Rabbit Cores.

 

[Cameron Laird]

I'll be starting a new project using Rabbit modules (the new wonderfully
low cost, feature rich RCM3700) in a couple of weeks time. I'm quite happy
to code in Dynamic C and the new version is supposed to have improved a
good deal, but I do like the idea of using scripting languages where
possible for future maintainability and Lua would probably be about the
only option for a device like the Rabbit. If you port it to Dynamic C,
could you let me know? I'd be very interested.

I took a look at Lua a while ago, and even bought the Lua book to allow me
to get a good feel for the language. It is actually very good, but at the
time I was looking at it as a replacement for Python, but for my
day-to-day, non-embedded work, the lack of additional libraries (compared
to Python) was an issue.

It did strike me as being ideal for embedded work, primarily due to its
size, and deploying a product running software written in an interpreted
language allows quick and easy live remote updating of the software
itself. I've done this on devices based on embedded PC architecture
running Perl, but it always seemed too optimistic a goal on something like
the Rabbit Cores.

I don't know what could more encourage one to Lua's suitability
for such uses than The Book, which you appear already to have
read. Yes, Lua implementation is, from all my experience, an
order of magnitude than the corresponding Perl effort.

 

[Scott David Daniels]

.... Yes, Lua implementation is, from all my experience, an
order of magnitude than the corresponding Perl effort.

While this is a strange topic for c.l.p, I _am_ curious what this
sentence meant to say. Perhaps: "order of magnitude less work than"?

-Scott David Daniels
(e-mail address removed)

 

[Cameron Laird]

While this is a strange topic for c.l.p, I _am_ curious what this
sentence meant to say. Perhaps: "order of magnitude less work than"?

.
.
.
"... easier to embed ..."

My apologies for the confusion. I'm an occasional professional
proof-reader--and yet ...