1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

Re: Embedded Basic interpreter recommendations?

Discussion in 'Embedded' started by Jon Kirwan, Mar 9, 2009.

  1. Jon Kirwan

    Jon Kirwan Guest

    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, Mar 9, 2009
    #1
    1. Advertising

  2. Jon Kirwan

    Frank Buss Guest

    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
     
    Frank Buss, Mar 9, 2009
    #2
    1. Advertising

  3. Jon Kirwan

    Jon Kirwan Guest

    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, Mar 9, 2009
    #3
  4. Jon Kirwan

    Frank Buss Guest

    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
     
    Frank Buss, Mar 9, 2009
    #4
  5. Jon Kirwan

    -jg Guest

    On Mar 10, 9:47 am, Frank Buss <> 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
     
    -jg, Mar 9, 2009
    #5
  6. Jon Kirwan

    Jon Kirwan Guest

    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
     
    Jon Kirwan, Mar 9, 2009
    #6
  7. Jon Kirwan

    Jon Kirwan Guest

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

    >On Mar 10, 9:47 am, Frank Buss <> 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
     
    Jon Kirwan, Mar 9, 2009
    #7
  8. Jon Kirwan

    -jg Guest

    On Mar 10, 12:56 pm, Jon Kirwan <> 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
     
    -jg, Mar 10, 2009
    #8
  9. Jon Kirwan

    Jon Kirwan Guest

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

    >On Mar 10, 12:56 pm, Jon Kirwan <> 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
     
    Jon Kirwan, Mar 10, 2009
    #9
  10. Jon Kirwan

    -jg Guest

    On Mar 10, 5:36 pm, Jon Kirwan <> 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
     
    -jg, Mar 10, 2009
    #10
  11. Jon Kirwan

    cfb Guest

    On Mar 10, 8:10 am, -jg <> wrote:
    > On Mar 10, 9:47 am, Frank Buss <> 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.
    >


    It doesn't have to be an early Pascal variant - Oberon-07 satisfies
    the above:

    http://www.inf.ethz.ch/personal/wirth/Articles/Oberon.html

    > 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
    >


    I did a fair bit of work extending PL/0 to make it into something
    usable - added REPEAT loops, SIZE, ORD and CHR, record and string
    assignments etc. etc. However, that all that went into cold storage
    when I changed direction and started the Armaide project with the
    Oberon-07 compiler:

    http://www.cfbsoftware.com/armaide

    The Oberon-07 compiler in Armaide runs on Windows but I have used it
    to compile itself to ARM code. The object files occupy about 80k bytes
    - plenty small enough to fit in the Flash ROM of many ARM MCUs.

    On a related track I've also been experimenting recently with an
    interpreter based on Wirth's Lilith M-Code Interpreter. The source
    code of the M-Code Modula-2 compiler and related documentation
    (including a listing of the interpreter) are at:

    http://www.cfbsoftware.com/modula2

    --
    Chris Burrows
    CFB Software
    Armaide: ARM Oberon-07 Development System for Windows
    http://www.cfbsoftware.com/armaide
     
    cfb, Mar 10, 2009
    #11
  12. Jon Kirwan

    cfb Guest

    On Mar 10, 2:36 pm, Jon Kirwan <> wrote:

    >
    > (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.)
    >


    RS232 communication is so much easier to implement and is not a major
    problem even if you only have USB sockets on your computer. You can
    get cables with an RS232 plug at one end and a USB plug at the other
    with the converter built into the plug that work well and cost less
    than $20.

    --
    Chris Burrows
    CFB Software
    Armaide: ARM Oberon-07 Development System for Windows
    http://www.cfbsoftware.com/armaide
     
    cfb, Mar 10, 2009
    #12
  13. Jon Kirwan

    Frank Buss Guest

    Jon Kirwan wrote:

    > 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.


    Maybe you are right for people with no prior computer experience.
    Timesharing systems sounds a bit old. I think it is difficult today to find
    someone who has never used a computer before. And then it is the same in
    all programs: It doesn't matter, if you write in a textarea in a HTML form
    in an internet cafe, or a letter with a word processor on your PC or Mac:
    You can see all lines at once, move cursors and edit like you want, insert
    lines etc. I think many pepole would get angry, if you try to replace this
    with a C64 line edit interface or something like Edlin. Why should this
    change, if someone writes programs?

    But to support your opinion a bit: I've seen inexperienced computer users
    trying to write letters and it really hurts to see how they insert empty or
    text lines by pressing spaces until the rest of the text is moved one line
    down. But most people learn the meaning of "Enter" and the ideas of the
    usual editing programs with cursor keys, insert etc., very fast. But maybe
    a good idea to give a short tutorial for absolute computer beginners how to
    use the editor in my IDE.

    --
    Frank Buss,
    http://www.frank-buss.de, http://www.it4-systems.de
     
    Frank Buss, Mar 10, 2009
    #13
  14. Jon Kirwan

    Jon Kirwan Guest

    On Tue, 10 Mar 2009 04:33:32 -0700 (PDT), cfb
    <> wrote:

    >On Mar 10, 2:36 pm, Jon Kirwan <> wrote:
    >
    >> (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.)

    >
    >RS232 communication is so much easier to implement


    No question.

    >and is not a major
    >problem even if you only have USB sockets on your computer. You can
    >get cables with an RS232 plug at one end and a USB plug at the other
    >with the converter built into the plug that work well and cost less
    >than $20.


    Well, there is that I grant you. I guess we don't disagree.

    Jon
     
    Jon Kirwan, Mar 11, 2009
    #14
  15. Jon Kirwan

    Jon Kirwan Guest

    On Tue, 10 Mar 2009 20:15:49 +0100, Frank Buss <>
    wrote:

    >Jon Kirwan wrote:
    >
    >> 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.

    >
    >Maybe you are right for people with no prior computer experience.
    >Timesharing systems sounds a bit old.


    I'm older.

    >I think it is difficult today to find
    >someone who has never used a computer before.


    Even if people have had more opportunities for _contact_, it may not
    mean much more than that. Mass produced books have been around a very
    long time, now -- centuries -- and most everyone has had more
    opportunity to _see_ them around. But I still know a lot of families
    with no more than 5 or 6 books in their home; less than that which
    they may have read. Computers have been in the atmosphere for far
    less time, too. My lifetime is very short and the transition has been
    taking place during it.

    I'm just being argumentative above, though. You made a point.

    On that, I'm not sure what to make of it. So I'd just repeat that
    although you might be suggesting (I can't tell, yet) something to the
    contrary of my earlier experiences, I have actually taught computer
    courses in a 4-yr university as recently as 10 years back. I didn't
    find anything in that experience to suggest I should change my mind.

    What I did find different is the distribution of people interested in
    becoming programmers as a professional choice. The computer field did
    (then, at least) attract people from a much wider spread of talents
    and interests than when I was getting involved. And the advance of
    available software has meant that people with far less breadth of
    training and scientific inclinations were enabled to actually do
    things that produced useful results for others. So the base of the
    pyramid widened out a lot. That's both good and bad.

    But non-programmers are still human beings and must take first steps
    like most anyone, even in my day. A toddler today is little different
    than a toddler 50 centuries ago -- they both struggle to learn how to
    walk mostly in similar ways.

    >And then it is the same in
    >all programs: It doesn't matter, if you write in a textarea in a HTML form
    >in an internet cafe, or a letter with a word processor on your PC or Mac:
    >You can see all lines at once, move cursors and edit like you want, insert
    >lines etc. I think many pepole would get angry, if you try to replace this
    >with a C64 line edit interface or something like Edlin. Why should this
    >change, if someone writes programs?


    I'm not sure what the OP is targeting, so it's difficult to get going
    on this.

    Just to be difficult, though, there is a huge advantage in being able
    to type in "PIN5 = 1" and see an LED light up. Without having to go
    into an editor. This is one of the reasons why I said someone would
    bring up Forth. It's like that, too. Except that it really isn't
    right for beginners, in my opinion.

    Look, I'm no teaching expert. I have some years of experience
    teaching a few languages to high school students with little or no
    experience; and in teaching assembly language, computer architecture,
    concurrent programming and operating systems as part of a 4 yr course
    at the 2nd and 3rd year arena. This does not mean I'm right, it just
    means that I am not completely without some experience. I've found
    BASIC easier at getting non-programmers excited about what they were
    doing. And I've tried other approaches.

    I don't mean to say other ways can't be made to work well, too. Just
    that for who I am and what skills I bring to the teaching table and
    those I've been exposed to, it's been easier this way. Maybe it's
    just me or the groups I've had the luck of knowing.

    >But to support your opinion a bit: I've seen inexperienced computer users
    >trying to write letters and it really hurts to see how they insert empty or
    >text lines by pressing spaces until the rest of the text is moved one line
    >down. But most people learn the meaning of "Enter" and the ideas of the
    >usual editing programs with cursor keys, insert etc., very fast. But maybe
    >a good idea to give a short tutorial for absolute computer beginners how to
    >use the editor in my IDE.


    Well, let's just leave it here. Really, the OP is dead silent about
    all this and I think it's not our turn, anymore.

    As I said earlier, I like the idea of using microcontrollers together
    with tangible things that smoke, spark, move, explode, etc., because
    that is how you motivate young students into doing the hard work it
    takes to get past some of the learning involved. We humans are like
    many other animals -- we like shiny objects. "It's pretty!" At a
    young age, before one has had time to develop the intrinsic
    motivations to get one through tough, abstract problems and reasoning,
    there is a need for external stimulation as payback for the work
    ahead. Why did I bang my head against the wall, reading the same book
    on optics 5 times over, before enough of it gelled to be useful?
    Because I wanted to build my own telescope to look at the stars and we
    lived hand-to-mouth at the time and there was no other possible way
    for me. Why did I spend so much time in the University library (as a
    high school student at the time) reading about chemistry? Because I
    wanted to make fireworks and firecrackers on my own. I got paid for
    my effort. I don't need those things now. I've crossed some of the
    harder barriers and matured a bit and once you do that, pieces in the
    larger picture of life on earth and the universe begin to show you a
    picture all of its own and you begin to crave seeing more of that, so
    you don't need the smoke and flames anymore. But before that
    intrinsic motivation precipitates, it's action, fire, smoke, etc....

    That's the part that interests me. Passing on an abiding interest in
    using microcontrollers as a segue (not an end of itself, or even just
    an occupation) to learning about the world. Like learning to use a
    keyboard isn't about learning keyboards as an occupation -- its about
    facilitating writing for other purposes. At first, all you do is
    watch your fingers. Eventually, you get past that and stop thinking
    about where your fingers are at and you then can be fully engaged in
    what you write, not how you write it. Programming and
    microcontrollers are, largely now for me, a means to access the world
    around me -- an inexpensive tool to try some idea in optics, or
    chemistry, or physics -- maybe also to explore something in
    mathematics. It pays the bills at times, yes. But that is only
    something in my peripheral vision -- it's not my focus. It's like
    moving fingers to hit keys. I don't look at my fingers anymore and I
    don't look at the programming lines so much anymore, either. I
    already have learned the techniques for most things I care about and I
    don't find focusing on those details holding my interest that much,
    now. I'm focused on the application and what that application can
    teach me about the world around me.

    Or so I sometimes like to imagine I do.

    Jon
     
    Jon Kirwan, Mar 11, 2009
    #15
  16. Jon Kirwan wrote:

    > Just to be difficult, though, there is a huge advantage in being able
    > to type in "PIN5 = 1" and see an LED light up. Without having to go
    > into an editor. This is one of the reasons why I said someone would
    > bring up Forth. It's like that, too. Except that it really isn't
    > right for beginners, in my opinion.
    >


    Or in Forth you type in "PIN3 PORTB ON" and see the led light up.

    If the OP can live with 16 or 8 bit processors, there are some ready
    working alternatives.

    PIC18F and dsPIC30F :
    User Guide : http://flashforth.sourceforge.net/
    Download : http://sourceforge.net/projects/flashforth/

    megaAVR:
    http://amforth.sourceforge.net/

    These are self contained Forth systems that only need a serial line
    for communication.

    You can interpret commands and compile code directly into Flash.
    Very good for exploring those particular micrcontrollers.
    The teacher can build up special easy to use words for controlling
    whatever stuff you want to control.

    The code editing is done in files on the PC.
    When you want to compile just send the file as ASCII text over
    the serial line.

    Mikael
     
    Mikael Nordman, Mar 11, 2009
    #16
  17. Jon Kirwan

    Frank Buss Guest

    John Speth wrote:

    > I learned basic on a PDP-11 i in the 70's. I could execute "n=12" then
    > "print n" interactively or I could assign line numbers and run, as in "10
    > n=12" then "20 print n" then "run". That's what I want. Extensions for the
    > micro like peek and poke would be necessary.


    Editing source code and interactivity is orthogonal. Maybe you and Jon
    Kirwan are right and for non-programmers with no previous word processing
    experience, it is easier to learn this PDP-11 (and C64) interface.

    A more modern approach would be GUI, but with an additional command line
    interface, like a Lisp REPL, or with separate windows, one for input and
    one for output, like I've seen and used in Squeak (a Smalltalk
    implementation). Then for the Lisp environment, e.g. with Lispworks, you
    have an additional text editor and you can hit "compile" to compile the
    content (and other included things) into the runtime system, where you can
    call the compiled functions etc. from the REPL. In Smalltalk it is even
    more integrated and (being object oriented) you have an object browser and
    you can inspect methods and open them in an editor. This would be the C64
    concept, but in an advanced style: instead of "LIST 30-50", move cursor up,
    change content in line 40 (or even more worse: re-enter the whole line,
    with your changes) and finally press enter to recompile, it would be
    "inspect setLed" from the command line (or browse a function list in the
    GUI), which opens an editor, where you change the content by clicking the
    mouse to the text you want to change (which is another problem, if you use
    pure RS232), then hitting "save" to compile it to the runtime envionment,
    which finally can be tested interactively on the command line.

    BTW: I think using Basic is a good idea for my system. Modula is more
    clean, but more complicated. I've learned Basic, too, as my first language
    and it was very easy. But when I write programs in Pascal-like languages,
    like VHDL, I still make syntax errors (do I need a semicolon at this place
    or is this an error? Ok, I think Modula has improved the syntax a bit, but
    still some discipline is required, like one place where you define
    variables, then "begin" etc.), so this would require a really good editor
    support to avoid user frustration, which is easier for Basic.

    --
    Frank Buss,
    http://www.frank-buss.de, http://www.it4-systems.de
     
    Frank Buss, Mar 11, 2009
    #17
  18. Jon Kirwan

    -jg Guest

    > I did a fair bit of work extending PL/0 to make it into something
    > usable - added REPEAT loops, SIZE, ORD and CHR, record and string
    > assignments etc. etc. However, that all that went into cold storage
    > when I changed direction and started the Armaide project with the
    > Oberon-07 compiler:
    >
    > http://www.cfbsoftware.com/armaide
    >
    > The Oberon-07 compiler in Armaide runs on Windows but I have used it
    > to compile itself to ARM code. The object files occupy about 80k bytes
    > - plenty small enough to fit in the Flash ROM of many ARM MCUs.


    That's just the compiler ? - What about linker, and library OBJ files,
    and
    and Editor, with inbuilt Debug ....... (aka TurboPascal ) ?

    I see this uses .NET, which means it would not make the cut, for
    Jon ;)

    ( Not sure I'd agree with the removal of LOOP either...
    and the change in RETURN -
    Still, I guess Size and Speed matter less these days...
    )

    > On a related track I've also been experimenting recently with an
    > interpreter based on Wirth's Lilith M-Code Interpreter. The source
    > code of the M-Code Modula-2 compiler and related documentation
    > (including a listing of the interpreter) are at:


    interesting.

    -jg
     
    -jg, Mar 12, 2009
    #18
  19. Jon Kirwan

    Jon Kirwan Guest

    On Thu, 12 Mar 2009 01:45:02 -0700 (PDT), -jg
    <> wrote:

    ><snip>
    >I see this uses .NET, which means it would not make the cut, for
    >Jon ;)
    ><snip>


    I still have and use 80486 computers, running on Win98SE. Have you
    ANY IDEA what a program depending on .NET does to one of them??? I'm
    talking about tiny programs here, that depend on .NET to run.

    Long ago, I'd written my own MD5 program that runs in DOS under
    Win98SE (and later incarnations, yes.) I used it so that clients
    getting stuff from me could verify file versions, if there was any
    question about it. (Folks rename things, at times.) One day, I
    happened upon a Win32 program that allowed drag and drop and was very
    easy to use for some of my clients and I decided to point then in that
    direction. It was about as fast as my own (I didn't make precise
    measurements, but it was close enough.) The program fired up very
    fast and was easy to use and was free. So far, so good, yes? Then
    the author made a change to .NET for the same program. In fact, there
    was NO differences at all in the prior version and the new version
    except that he said he'd decided to change over to .NET for this new
    version (perhaps looking forward to other features once that "port"
    was done and working.) I loaded it over and tried it out. It took
    almost two minutes to just load up!!!

    Now, once I'd paid that price and .NET was "up", it did admittedly
    come up a bit quicker. Maybe in less than a minute, but still very
    very much longer than the earlier version, which was present and ready
    in about one second or less. It just wasn't worth the hassle anymore.

    Windows once ran "okay" in 8 Meg and pretty darned good in 16. Then
    it needed 32. Then 64. Now, a gig is considered pitiful. Widgets
    negotiate for positioning in toolbars or other widgets, toolbars dock
    now, there are interfaces just to enumerate the interfaces and then
    interfaces for those to enumerate the functions available, and 64
    layers/interrupt levels for handling events, rings upon rings, layers
    upon layers, ....

    And despite the fact that computer hardware has advanced at a pace
    that boggles the mind (front side transactions that operate in
    parallel with transaction, error, cache hit and data phases all
    operating on the same clock, levels of caching not only in the cpu(s)
    but in the chipset, read around writes, relaxed transactions rules for
    graphics [where the order of arrival isn't all that important], etc.),
    with multi-GHz internal cycle times, many stages of cache and
    buffering going out to slower memories, huge memories unthinkable not
    so long ago, and so on.... Microsoft STILL manages to find ways to
    slog such a machine down to a crawl.

    Don't even think of getting me started. Yeah. .NET = .NOT.

    ;)

    Jon
     
    Jon Kirwan, Mar 12, 2009
    #19
  20. Jon Kirwan

    cfb Guest

    On Mar 12, 6:45 pm, -jg <> wrote:

    > > On Mar 10, 5:20 pm, cfb <> wrote:
    > > I did a fair bit of work extending PL/0 to make it into something
    > > usable - added REPEAT loops, SIZE, ORD and CHR, record and string
    > > assignments etc. etc.


    Sorry - I should have said Oberon-0 (the later incarnation of PL/0)
    from Wirth's compiler construction book:

    http://www-old.oberon.ethz.ch/WirthPubl/CBEAll.pdf

    >
    > > The Oberon-07 compiler in Armaide runs on Windows but I have used it
    > > to compile itself to ARM code. The object files occupy about 80k bytes
    > > - plenty small enough to fit in the Flash ROM of many ARM MCUs.

    >
    > That's just the compiler ? - What about linker, and library OBJ files,
    > and
    > and Editor, with inbuilt Debug ....... (aka TurboPascal ) ?
    >


    Linker ~10k
    Library OBJ files = zero K for a simple app like Blinker, ~ 6k for
    runtime error trapping and reporting ala TP 1.0 via RS232.

    I haven't considered an editor yet. I'd do the same as somebody else
    suggested - do the primary editing on the PC with the terminal
    emulator. Have a simple editor on the target to fix simple compilation
    errors.

    > I see this uses .NET, which means it would not make the cut, for
    > Jon ;)
    >


    For the .NETphobes the compiler, linker and loader are both written in
    Component Pascal so a Win32 version of the command-line versions could
    easily be built using Oberon microsystems BlackBox compiler.

    > ( Not sure I'd agree with the removal of LOOP either...
    > and the change in RETURN  -
    > Still, I guess Size and Speed matter less these days...
    > )


    True. Can't see that size or speed are too relevant though - it's all
    in the interest of reliability / security / maintainability /
    testability i.e. a return to the old idea of a rigorous single-entry /
    single-exit approach for all blocks of code. Yeah, I also groan when
    I'd really like to code a couple of exits from my loops or procedures.
    However, although it takes a bit more effort I've found that nine
    times out of ten the resulting code is far more digestible.

    --
    Chris Burrows
    CFB Software
    Armaide: ARM Oberon-07 Development System for Windows
    http://www.cfbsoftware.com/armaide
     
    cfb, Mar 13, 2009
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    3
    Views:
    451
    Jon Kirwan
    Mar 9, 2009
  2. Anton Erasmus
    Replies:
    2
    Views:
    341
    Jon Kirwan
    Mar 10, 2009
  3. M.O.B. i L.
    Replies:
    1
    Views:
    576
    Jon Kirwan
    Mar 9, 2009
  4. -jg
    Replies:
    0
    Views:
    355
  5. -jg
    Replies:
    1
    Views:
    257
Loading...

Share This Page