Embedded Basic interpreter recommendations?

On Mon, 9 Mar 2009 21:47:03 +0100, Frank Buss <fb@frank-buss.de>
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

> Now, I'll add one of my own. =A0There is the BASIC available for the
> 8031 core from Intel, "8052 BASIC." =A0I don't consider it of much use,
> either, as it isn't in c.

No, but could be recoded in C/ASM fairly easily, with macro calls
etc.? :)

-jg

> My intended target is the STM32 which probably has enough RAM for small
> programs. =A0My intent is to create an embedded controller board with a s=
erial
> 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). =A0It's meant to be a to=
ol
> for interactive experimentation of embedded concepts by non-programmer
> types. =A0I suppose it's much like a Basic Stamp.

If this uses a Terminal, then another angle would be something like
the
original TurboPascal, which IIRC was just 39K for compiler+editor.
Of course, that was mostly x86 ASM, and not open source, but
does give a performance/size reference point.

-jg

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, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Jon Kirwan wrote:
> On Mon, 09 Mar 2009 22:28:40 +0200, Anton Erasmus
> <nobody@spam.prevent.net> wrote:
> 
>> On Mon, 9 Mar 2009 11:04:03 -0700, "John Speth" <johnspeth@yahoo.com>
>> 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.
>> Does it have to be BASIC ? If not then LUA might be a good option.
>>
>> Regards
>>  Anton Erasmus
> 
> I think the "non-programmer types" part of the OP's discussion points
> otherwise.
> 

For a non-programmer doing simple commands, Lua is not really any more 
difficult than Basic.  And if you want to do non-simple stuff, it 
quickly becomes easier.

On Mar 10, 9:47=A0am, 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 kno=
w
> if it is easy for new programmers and if C or Basic programmers would lik=
e
> 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 14:33:07 -0700 (PDT), -jg <Jim.Granville@gmail.com>
wrote:

>> Now, I'll add one of my own. &#4294967295;There is the BASIC available for the
>> 8031 core from Intel, "8052 BASIC." &#4294967295;I don't consider it of much use,
>> either, as it isn't in c.
>
>No, but could be recoded in C/ASM fairly easily, with macro calls
>etc.? :)
>
>-jg

I've looked at it, a bit -- mostly in terms of features from the user
point of view, though.  And on that score, it has a LOT of extras that
are associated closely with the 8031/32 core, itself.  Would need to
carefully cull through all that.  I kind of imagine it easier to start
fresh with clear goals in mind.

Jon

On Mon, 9 Mar 2009 22:49:09 +0100, Frank Buss <fb@frank-buss.de>
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 <Jim.Granville@gmail.com>
wrote:

>On Mar 10, 9:47&#4294967295;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 Mon, 09 Mar 2009 22:51:46 +0100, David Brown
<david.brown@hesbynett.removethisbit.no> wrote:

>Jon Kirwan wrote:
>> On Mon, 09 Mar 2009 22:28:40 +0200, Anton Erasmus
>> <nobody@spam.prevent.net> wrote:
>> 
>>> On Mon, 9 Mar 2009 11:04:03 -0700, "John Speth" <johnspeth@yahoo.com>
>>> 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.
>>> Does it have to be BASIC ? If not then LUA might be a good option.
>>>
>>> Regards
>>>  Anton Erasmus
>> 
>> I think the "non-programmer types" part of the OP's discussion points
>> otherwise.
>> 
>
>For a non-programmer doing simple commands, Lua is not really any more 
>difficult than Basic.  And if you want to do non-simple stuff, it 
>quickly becomes easier.

I'm not thinking about command line stuff.  I've been using c since
1978 (Unix v6) and BASIC in some form or another since... 1972.  So
similar time periods.  I've tried to teach both to non-programmers in
classrooms where I was a paid teacher (Tektronix classrooms.)  And I'm
talking about __non-programmers__, such as secretaries.  I've no
question in my mind which would be easier to gain some early success
with.  Lua is too similar to c in my mind.

Jon