Re: Embedded Basic interpreter recommendations?

On Mon, 9 Mar 2009 11:04:03 -0700, "John Speth" <>
wrote:

>Hi everybody-
>
>This question comes up from time to time from various posters but it never
>gets an answer that fits my specific needs. Here goes:
>
>Would anyone be able to recommend a free embedded basic interpreter with C
>source code?
>
>My intended target is the STM32 which probably has enough RAM for small
>programs. My intent is to create an embedded controller board with a serial
>port that will expose a Basic interpreter/monitor to a terminal emulator.
>The user will be able to interactively enter numbered program lines,
>save/load the program to/from flash, execute the program, and run Basic
>commands in immediate mode (non-numbered lines). It's meant to be a tool
>for interactive experimentation of embedded concepts by non-programmer
>types. I suppose it's much like a Basic Stamp.
>
>I know "free" and all those features above is a tall order but if I can find
>an extensible package with some of those features it would be good too.
>
>Thanks, JJS

I was also similarly interested in something akin. 30 years ago I was
part of those involved in writing a commercially used interpreter --
at the time, it was over timeshared service, though. The final result
fit in 32k byte of the main cpu (which included 20k byte of swap space
that did NOT include the interpreter, so the interpreter itself took
up only 12kbyte) and used an I/O processor with 16kbyte of memory
(most for buffers, not code.) This included pretty much everything
one could want -- line number editing (just retype the linenumber with
a line and it replaces the prior line) and pre-compilation into very
fast code for interpretation. This meant all line numbers being
replaced with addresses of the lines they referred to (no lookup), all
variables being replaced with addresses into the variable table (no
lookup needed), etc. It had to be, back then, so there the
interpreter included an interpreter precompiler, an editor decompiler,
the editor features, a variety of commands, support for all
transcendentals, matrix math including inversion and determinants, and
the execution engine, of course. Chebychev was used throughout the
transcendentals, with minimax techniques to minimize accumulation of
errors by setting constants appropriately, for very fast conversion
and controlling error bounds rather than controlling average error, as
does Taylor's, for example.

I've considered the idea of doing it in a modern context for flash
systems, but it was a lot of work and time (all coded in assembly for
speed and compactness, which was vital then) and doing it all over
again would not be easily considered.

There is a definite niche for what you are talking about -- especially
in education. I don't consider the Parallax BASIC Stamp to be
anything close to as sophisticated, nor as useful for education.,
despite the fact that much better was achieved on slower processors
and with less available code memory. But it may be the simpler choice
at this time.

You might also write some of the compiler vendors. A few of them may
have developed a useful BASIC they couldn't really sell, but would be
willing to part with. You'd need to be in a position to make
modifications.

If you find a worthy team to work on it, I'd be happy to share some of
the details that turned out to work so well in the past -- I still
have all the source code for it and I remember a great deal of the
details, too. And I may be able to put in some time, as well. I
applaud the idea.

You will likely get some suggestions about Forth. I am no expert in
it, only having small experiences with it (and enjoying the learning),
but frankly I think you are on the right track for your target and I
don't think Forth would serve it well.

Jon

Jon Kirwan wrote:

> You will likely get some suggestions about Forth. I am no expert in
> it, only having small experiences with it (and enjoying the learning),
> but frankly I think you are on the right track for your target and I
> don't think Forth would serve it well.

Forth is nice for interactive development, but hard for new programmers,
because you have to think about memory handling etc., which is much easier
in Basic. But I don't see any reason why to use a dumb terminal interface.
With wxWidgets a GUI can be developed which works on Windows, Mac and
Linux, and even some portables and you need another PC or device anyway, if
you want to use it with a serial port. The GUI could provide more modern
file editing, debugger etc., instead of old-style C64 line numbers.

BTW: I'm planning to develop such a system, too. What do you think of
Modula-2? It is supposed to be more safe than Basic or C, but I don't know
if it is easy for new programmers and if C or Basic programmers would like
to use it.

--
Frank Buss,
http://www.frank-buss.de, http://www.it4-systems.de

On Mon, 9 Mar 2009 21:47:03 +0100, Frank Buss <>
wrote:

>Jon Kirwan wrote:
>
>> You will likely get some suggestions about Forth. I am no expert in
>> it, only having small experiences with it (and enjoying the learning),
>> but frankly I think you are on the right track for your target and I
>> don't think Forth would serve it well.
>
>Forth is nice for interactive development, but hard for new programmers,
>because you have to think about memory handling etc., which is much easier
>in Basic. But I don't see any reason why to use a dumb terminal interface.
>With wxWidgets a GUI can be developed which works on Windows, Mac and
>Linux, and even some portables and you need another PC or device anyway, if
>you want to use it with a serial port. The GUI could provide more modern
>file editing, debugger etc., instead of old-style C64 line numbers.

I think the OP is talking about the simplicity of line number
replacement for editing and typing LIST when you need to see a list.
This is an RS-232 port application, after all. It could require
features, such as screen-clear, x/y positioning, and so on, but in
doing so you would expand the code in the target and reduce the set of
"terminals" that one might use on the PC end. I'd tend to go with
simple and basic, here.

>BTW: I'm planning to develop such a system, too. What do you think of
>Modula-2? It is supposed to be more safe than Basic or C, but I don't know
>if it is easy for new programmers and if C or Basic programmers would like
>to use it.

I like Modula-2 and spent a little time reading the Modula-3 book,
though I've never used a Modula-3 compiler and I'm still weak on some
of its concepts. But I like pretty much all languages (well, except
RPG-II unless I am writing very simple reports and COBOL unless there
is a legacy app that needs modification) I've been exposed to. I find
c fine, as well. I would be worried about the Modula-2 compiler for
developing embedded BASIC, mostly for code size and execution time
questions, if not wondering whether or not there was one that targeted
the device I was looking at. c is pretty much ubiquitious, now, for
embedded use and I'd prefer that for that reason alone, if no other.
(With assembly, as appropriate.)

Jon

Jon Kirwan wrote:

> I think the OP is talking about the simplicity of line number
> replacement for editing and typing LIST when you need to see a list.

I don't see why this is simple. You are right, simple to implement, but not
simple to use. I've started programming on C64 with Basic programs and
lines, too (and switched to assembler some months later), but I never
missed it on PC with the usual file editing in my favorite editor (starting
with "Boxer" in DOS, now most of the time Ultraedit), or in a good IDE like
Visual Studio. Writing a simple IDE for Windows, Linux and Mac with
wxWidget is not that difficult.

> I like Modula-2 and spent a little time reading the Modula-3 book,
> though I've never used a Modula-3 compiler and I'm still weak on some
> of its concepts. But I like pretty much all languages (well, except
> RPG-II unless I am writing very simple reports and COBOL unless there
> is a legacy app that needs modification) I've been exposed to. I find
> c fine, as well. I would be worried about the Modula-2 compiler for
> developing embedded BASIC, mostly for code size and execution time
> questions, if not wondering whether or not there was one that targeted
> the device I was looking at. c is pretty much ubiquitious, now, for
> embedded use and I'd prefer that for that reason alone, if no other.
> (With assembly, as appropriate.)

Code size and execution time should be no problem, my targets are bigger
with at least 16k flash and fast. My idea was to start with a virtual
machine, so I'll compile the program on PC and upload some bytecode, only,
which should be very compact, too. Maybe I provide multiple frontend
languages, like Basic, C and Modula. Then the programmer can choose the
language he/she likes most.

--
Frank Buss,
http://www.frank-buss.de, http://www.it4-systems.de

On Mar 10, 9:47*am, Frank Buss <f...@frank-buss.de> wrote:
>
> BTW: I'm planning to develop such a system, too. What do you think of
> Modula-2? It is supposed to be more safe than Basic or C, but I don't know
> if it is easy for new programmers and if C or Basic programmers would like
> to use it.

Modula-2 is fussier in types than BASIC, and less string-friendly.
Since this needs to be simple, an early Pascal variant could also
do (along the lines of Turbo-Pascal) and a 32 bit target, can relax
some
of the Type-Soup, for a simpler implementation.

Newer BASICs are somewhat more structured, so move closer to Modula-2
and there is also IEC 61131

Perhaps a base such as Wirth's earlier PL/0, which DOES mention source
code,
could create a medium-typed compiled language ?

Simpler is better, for the smaller targets

http://en.wikipedia.org/wiki/PL/0

Seems versions are around in Modula-2,
http://fruttenboel.verhoeven272.nl/m4m/index.html
and C++
http://sourceforge.net/projects/pl0-compiler

-jg

On Mon, 9 Mar 2009 22:49:09 +0100, Frank Buss <>
wrote:

>Jon Kirwan wrote:
>
>> I think the OP is talking about the simplicity of line number
>> replacement for editing and typing LIST when you need to see a list.
>
>I don't see why this is simple.

It is VERY easy to teach. Not only from my own experience working
with literally hundreds and hundreds of users (as a tutor, then as a
teacher of classes, and as support staff with a timesharing system.)
People from all walks, a large portion without any prior experience.
At that time, computer expertise (heck, even typing skills) was a bit
short in supply. But it was very easy, by comparison with other
languages I had similar experiences trying to convey to others.

>You are right, simple to implement,

Actually, line editing isn't all that easy to implement if your system
pre-compiles for speed. What we did was when the RUN command was
given was to check a flag -- if the code was in pre-compiled state
(fast interpretive, really), then it just started running. But if it
was still in "text only" mode (editing), then a pre-compile step was
required first. When a line was typed, if the code was already in
pre-compiled state, then it had to be de-compiled back into text, then
the line update made. In addition, the memory requirements were
different in the two stages (variable tables in one case, none in
another; etc.) So it can get a little bit hairy. Though, with
crafted thinking it works smoothly enough.

We could achieve no more than about 1/2 second delay in pre-compiling
code from text source in rather large programs and do this while
dealing with 31 other users at the same time and swapping code on a
timesharing basis (no virtual memory, no stacks [subroutines were
handled like the PDP-8, for example, where the first address of the
routine was stuffed with the return address... so recursion was a
no-no.]) So the users "felt" an acceptable delay during these
conversions. The only annoyance might be when typing in a large
program, typing run, and running out of memory only when starting the
code because the scrunched/precompiled code + variable tables was a
bit larger. The advantage to the pre-compilation step was that EVERY
variable was pre-allocated -- the entire program was scanned and all
variables allocated at the start. So you knew right away if it could
run well.

>but not simple to use.

But that isn't my experience in teaching, tutoring, etc. So I guess
we don't agree.

>I've started programming on C64 with Basic programs and
>lines, too (and switched to assembler some months later), but I never
>missed it on PC with the usual file editing in my favorite editor (starting
>with "Boxer" in DOS, now most of the time Ultraedit), or in a good IDE like
>Visual Studio. Writing a simple IDE for Windows, Linux and Mac with
>wxWidget is not that difficult.

Well, of course. But you probably never had to live with a KSR-35 or
ASR-33, either. But here we get to the nub of it.

It is great having visual editors. You won't get an argument from me
about that. I love being able to edit text without having to retype
entire lines, for example. But I do this as my profession, so I do a
lot of it. It counts, then. For non-programmers, which the OP is
talking about, many other issues become important. For example, when
you typed a line into the system I worked on, it was checked
immediately. If it was wrong, you got feedback instantly about it.
One of the best ways to begin learning programming is to do things
wrong -- and get feedback right away. There are lots of other aspects
here, too. But I think you may really need to see it happening, do
the teaching yourself using this kind of BASIC with non-programmers,
and see how you feel afterwards. I've done all of this, in classroom
settings as well as one-on-one, and I _know_ that line number
replacement is quite practical on that level and that the issues of a
screen-based editor in conjunction would complicate things on many,
many levels. I have strong feelings about this, as you can see.

>> I like Modula-2 and spent a little time reading the Modula-3 book,
>> though I've never used a Modula-3 compiler and I'm still weak on some
>> of its concepts. But I like pretty much all languages (well, except
>> RPG-II unless I am writing very simple reports and COBOL unless there
>> is a legacy app that needs modification) I've been exposed to. I find
>> c fine, as well. I would be worried about the Modula-2 compiler for
>> developing embedded BASIC, mostly for code size and execution time
>> questions, if not wondering whether or not there was one that targeted
>> the device I was looking at. c is pretty much ubiquitious, now, for
>> embedded use and I'd prefer that for that reason alone, if no other.
>> (With assembly, as appropriate.)
>
>Code size and execution time should be no problem, my targets are bigger
>with at least 16k flash and fast. My idea was to start with a virtual
>machine, so I'll compile the program on PC and upload some bytecode, only,
>which should be very compact, too. Maybe I provide multiple frontend
>languages, like Basic, C and Modula. Then the programmer can choose the
>language he/she likes most.

Well, you are talking to programmers then. I have considered the idea
of a nicely partitioned system -- an execution unit that resides on
the target or may reside on a host, an interpreter that _may_ also
reside on the target OR it may also reside on a host system connected
to it, and a compiler as well that may generate final target code in
machine language, as well. I was considering how to modify BASIC to
support constant, initialized arrays that might be placed into flash,
etc. It's nice to have choices.

But the OP's question, if I'm getting the message correctly (and I may
not be), is about non-programmers. And there, I'm in concert with
what was originally said.

Jon

On Mon, 9 Mar 2009 15:10:26 -0700 (PDT), -jg <>
wrote:

>On Mar 10, 9:47*am, Frank Buss <f...@frank-buss.de> wrote:
>>
>> BTW: I'm planning to develop such a system, too. What do you think of
>> Modula-2? It is supposed to be more safe than Basic or C, but I don't know
>> if it is easy for new programmers and if C or Basic programmers would like
>> to use it.
>
>Modula-2 is fussier in types than BASIC, and less string-friendly.
>Since this needs to be simple, an early Pascal variant could also
>do (along the lines of Turbo-Pascal) and a 32 bit target, can relax
>some
>of the Type-Soup, for a simpler implementation.
>
>Newer BASICs are somewhat more structured, so move closer to Modula-2
>and there is also IEC 61131
>
>Perhaps a base such as Wirth's earlier PL/0, which DOES mention source
>code,
>could create a medium-typed compiled language ?

I actually wrote the PL/0 compiler right out of his (black colored)
book. I still have it, in fact, sitting just a few feet away from me.
And modified it, too.

>Simpler is better, for the smaller targets
>
>http://en.wikipedia.org/wiki/PL/0
>
>Seems versions are around in Modula-2,
>http://fruttenboel.verhoeven272.nl/m4m/index.html
>and C++
>http://sourceforge.net/projects/pl0-compiler
>
>-jg

I'm partial to BASIC for non-programmers.

Jon

On Mar 10, 12:56*pm, Jon Kirwan <j...@infinitefactors.org> wrote:
> Well, you are talking to programmers then. *I have considered the idea
> of a nicely partitioned system -- an execution unit that resides on
> the target or may reside on a host, an interpreter that _may_ also
> reside on the target OR it may also reside on a host system connected
> to it, and a compiler as well that may generate final target code in
> machine language, as well. *I was considering how to modify BASIC to
> support constant, initialized arrays that might be placed into flash,
> etc. *It's nice to have choices.

Debug becomes pivotal here. The Line-number/edlin model can really
only
get you so far, then you need to step thru the code, and watch
variables.

Once you do that, the Host/Emulation/Simulation (includes Emulation
via Simulation - umbilical solns) becomes much nicer, then you can
force DOWN the resource in the target, and use the Host more.
umbilical emulation allows a minimal monitor core, and the host runs
a
more local simulator. Also suited to flash/ram splits seen in typical
uC.

Of course that places more caveats on the host.

Still, this pathway allows you to share a lot more of others work, and
also chose
a mature language/debug system for the host, that you clone on the
target,
OR
you decide to implement a TurboPASCAL model entirely in the target,
with a compact editor/debug/Compiler - Chips ARE now big enough to
make
this viable.
A USB terminal could almost be a defacto, as most candidate devices
for this, would includes USB for free.

Next step would be a Flash-Drive stub, where you included a Better PC-
USB-Terminal in a SPI flash, and the target becomes the whole
system...Mobile-Compute-Debug model

-jg

On Mon, 9 Mar 2009 18:43:21 -0700 (PDT), -jg <>
wrote:

>On Mar 10, 12:56*pm, Jon Kirwan <j...@infinitefactors.org> wrote:
>> Well, you are talking to programmers then. *I have considered the idea
>> of a nicely partitioned system -- an execution unit that resides on
>> the target or may reside on a host, an interpreter that _may_ also
>> reside on the target OR it may also reside on a host system connected
>> to it, and a compiler as well that may generate final target code in
>> machine language, as well. *I was considering how to modify BASIC to
>> support constant, initialized arrays that might be placed into flash,
>> etc. *It's nice to have choices.
>
>Debug becomes pivotal here. The Line-number/edlin model can really
>only get you so far, then you need to step thru the code, and watch
>variables.

Non-programmers? Their level of approach is printing out variable
values by inserting lines. Basically. The whole idea of watching
variables would be a bit much -- not so much because they can't get
the idea in general but because of the learning curve for the menu
options of adding, deleting and modifying the added watches. It's
really, really easy to use what they have already learned (adding
statements.) It's just more unnecessary "stuff" to laden them down
with another user interface.

Of course, I really don't know what the OP is intending. (Wish we'd
get some responses.) "It's meant to be a tool for interactive
experimentation of embedded concepts by non-programmer types," seems
to be the guide, though. I imagine this as "turn on a light" by a
single statement that keeps a TRIAC fired and where the actual
detailed code that may monitor zero-crossings, handle phase angle
decisions, etc., is hidden inside the BASIC interpreter. Stuff at
that kind of level, really. Or maybe not. Hard to tell. So maybe
more is better than less. But the OP did clearly say something about
line numbers as the approach -- and I have to count that for something
here.

>Once you do that, the Host/Emulation/Simulation (includes Emulation
>via Simulation - umbilical solns) becomes much nicer, then you can
>force DOWN the resource in the target, and use the Host more.
>umbilical emulation allows a minimal monitor core, and the host runs
>a more local simulator. Also suited to flash/ram splits seen in typical
>uC.
>
>Of course that places more caveats on the host.
>
>Still, this pathway allows you to share a lot more of others work, and
>also chose a mature language/debug system for the host, that you clone on the
>target, OR you decide to implement a TurboPASCAL model entirely in the target,
>with a compact editor/debug/Compiler - Chips ARE now big enough to
>make this viable.
> A USB terminal could almost be a defacto, as most candidate devices
>for this, would includes USB for free.
>
> Next step would be a Flash-Drive stub, where you included a Better PC-
>USB-Terminal in a SPI flash, and the target becomes the whole
>system...Mobile-Compute-Debug model

Okay. Well, it's about time for the OP to jump in. We are proceeding
far beyond the original comment. I feel you may be taking this over
the top a bit, but then you might be right on target for all I know.

(I agree about the USB interface -- RS232 is getting hard to find
these days and USB ports are everywhere, almost. So that would seem
to be the preferred hardware connection. I would expect it to "look
like RS-232," though and be able to use Hyperterm, for example, or
whatever serves the same under Linux.)

I suspect many folks have thought about BASIC as a segue for
non-programmers to do useful things they want to achieve for
themselves. BASIC is probably the closest thing to making that
possible, but what is the right hardware widget and BASIC combination
that appeals to a wide array of non-programmers' interests?

My own focus would be on reaching high school education, allowing a
path for non-programmer students to have some fun while learning and
gathering and processing data and controlling things that move, make
fire, smoke, and flash lights. For example, learning trigonometry in
the context of moving a drill press around and drilling holes is a
great way to provide tactile and sensory information about why sine
and cosine mean something practical and real that can be seen right in
front of them. If they make mistakes, it becomes immediately apparent
and they can laugh a little at it and in the process deepen what those
things mean to them.

But I'm going way afield of the OP, here.

Jon

On Mar 10, 5:36*pm, Jon Kirwan <j...@infinitefactors.org> wrote:
>
> Okay. *Well, it's about time for the OP to jump in. *We are proceeding
> far beyond the original comment. *I feel you may be taking this over
> the top a bit, but then you might be right on target for all I know.

Yes, but I was also partially answering Frank's posts here too...

-' what is possible at low cost' has rather moved in the last few
years,
with large flash uC and USB almost 'there by default'.
(certainly is on the STM32 the OP mentioned)

-jg