Forums

Embedded Basic interpreter recommendations?

Started by John Speth March 9, 2009
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. &#2013266080;There is the BASIC available for the >> 8031 core from Intel, "8052 BASIC." &#2013266080;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&#2013266080;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