Embedded Basic interpreter recommendations?

On Mon, 16 Mar 2009 04:00:33 GMT, Jon Kirwan
<jonk@infinitefactors.org> wrote:

>On Mon, 16 Mar 2009 13:56:43 +1030, "Chris Burrows"
><cfbsoftware@hotmail.com> wrote:
>
>>"Jon Kirwan" <jonk@infinitefactors.org> wrote in message
>>news:lifqr4h4rkjsdmo68e7hc2093lao4auu1p@4ax.com...
>>> On Sun, 15 Mar 2009 21:45:44 +1030, "Chris Burrows"
>>>
>>> Well, Lilith had what could only have been considered "HEAVEN" when we
>>> were working on the timesharing system.  256k of RAM?  My gosh! 6MHz?!
>>> Jeesh, darn!  If only.
>>
>>Are you sure we're talking about the same timeframe? In 1983 my home PC had
>>512Kb of RAM and a 6Mhz CPU. Mind you it was a Sage which was a great little
>>system compared with what else was around at the time. However, I still
>>would have given my right arm to have had a Lilith to work on.
>
>Probably not the same timeframe.  I'm talking about machines of 1969
>to 1972, not 1983!
>
>And if you had 512kb of RAM on your IBM AT in 1983 (which would have
>had to have been after August or so, memory serving) you would have
He said it was a "Sage", no mention of an AT. :-)  And it probably
cost more than an AT, anyway.

>had to pay the same price my business did for the AT, which was
>$5,995, I think.  About 6 grand.  I'm not sure, but it might have been
>with 512kb.  Sounds about right.  (No way I could afford that as a
>personal machine, though.  Not even then and certainly no way a decade
>before that, which is the period I was discussing about the timeshared
>BASIC.)
>
>Jon
-- 
ArarghMail903 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html

To reply by email, remove the extra stuff from the reply address.

On Mon, 16 Mar 2009 13:56:43 +1030, "Chris Burrows"
<cfbsoftware@hotmail.com> wrote:

>"Jon Kirwan" <jonk@infinitefactors.org> wrote in message
>news:lifqr4h4rkjsdmo68e7hc2093lao4auu1p@4ax.com...
>> On Sun, 15 Mar 2009 21:45:44 +1030, "Chris Burrows"
>>
>> Well, Lilith had what could only have been considered "HEAVEN" when we
>> were working on the timesharing system.  256k of RAM?  My gosh! 6MHz?!
>> Jeesh, darn!  If only.
>>
>
>Are you sure we're talking about the same timeframe? In 1983 my home PC had
>512Kb of RAM and a 6Mhz CPU. Mind you it was a Sage which was a great little
>system compared with what else was around at the time. However, I still
>would have given my right arm to have had a Lilith to work on.
>
"Sage" as in the 680x0 multi user system?  I have one of those in
storage, if it even still works.  By now, the MFM drive probably has
gone belly up.
-- 
ArarghMail903 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html

To reply by email, remove the extra stuff from the reply address.

<ArarghMail903NOSPAM@NOT.AT.Arargh.com> wrote in message 
news:6t8sr49dbqflouo2ofhpto3bht07j9rsrs@4ax.com...
> On Mon, 16 Mar 2009 13:56:43 +1030, "Chris Burrows"
>>
>>Are you sure we're talking about the same timeframe? In 1983 my home PC 
>>had
>>512Kb of RAM and a 6Mhz CPU. Mind you it was a Sage which was a great 
>>little
>>system compared with what else was around at the time. However, I still
>>would have given my right arm to have had a Lilith to work on.
>>
> "Sage" as in the 680x0 multi user system?  I have one of those in
> storage, if it even still works.  By now, the MFM drive probably has
> gone belly up.

That's the one. I donated mine to a computer museum in the 90's but wished I 
had kept hold of it now. If you want to put yours on eBay let me know and I 
might make a bid for it.

There's a wealth of information about Sage and Stride computers here:

http://www.sageandstride.org/

Chris

On Mon, 16 Mar 2009 22:14:27 +1030, "Chris Burrows"
<cfbsoftware@hotmail.com> wrote:

><ArarghMail903NOSPAM@NOT.AT.Arargh.com> wrote in message 
>news:6t8sr49dbqflouo2ofhpto3bht07j9rsrs@4ax.com...
>> On Mon, 16 Mar 2009 13:56:43 +1030, "Chris Burrows"
>>>
>>>Are you sure we're talking about the same timeframe? In 1983 my home PC 
>>>had
>>>512Kb of RAM and a 6Mhz CPU. Mind you it was a Sage which was a great 
>>>little
>>>system compared with what else was around at the time. However, I still
>>>would have given my right arm to have had a Lilith to work on.
>>>
>> "Sage" as in the 680x0 multi user system?  I have one of those in
>> storage, if it even still works.  By now, the MFM drive probably has
>> gone belly up.
>
>That's the one. I donated mine to a computer museum in the 90's but wished I 
>had kept hold of it now. 
Actually, it turns out that what I have is a Stride 440 w/16 ports.
And UCSD pascal.  I also remember that it has the processor upgrade on
a daughter board.  Also, IIRC, the MFM drive was getting flakey the
last time I tried to do anything with it -- like 10 or 15 years ago.
Does anyone even make MFM drives anymore?

>If you want to put yours on eBay let me know and I might make a bid for it.
Even though I have no use for it, I hadn't planned on selling it.  I
haven't a clue what it might be worth.

And, it's not the oldest computer that I have.  :-)  I have some core
memory minis that date to the middle 70s.

>There's a wealth of information about Sage and Stride computers here:
>
>http://www.sageandstride.org/

Ok, thanks.  I will look at it.
-- 
ArarghMail903 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html

To reply by email, remove the extra stuff from the reply address.

On Mar 12, 3:52=A0am, "John Speth" <johnsp...@yahoo.com> wrote:
> > Okay. =A0Well, it's about time for the OP to jump in. =A0We are proceed=
ing
> > far beyond the original comment. =A0I feel you may be taking this over
> > the top a bit, but then you might be right on target for all I know.
>
> I'm the OP.
>
> My intent is this: Sometimes here at work we have a project idea. =A0Then=
 a
> circuit with a microcontroller comes along and the marketing types have
> little to no software requirements. =A0I could spend all my time writing
> throw-away code asking "Is this what you wanted?" at the end of each
> iteration. =A0It would be simpler for me to just let my associates have t=
heir
> own way with the circuit. =A0It woud allow them to develop ideas and walk=
 a
> mile in my shoes as a bonus. =A0The language shouldn't be an impediment.

Here is another angle on the problem.
If we accept that any target-hosted compile/debug is going to be
always a constrained compromise, and be highly custom in nature, and
look that Flash drives are currently ~$5 - close to a small volume CD
rom and more HW related..

What about a system that simply INCLUDES a FlashDrive, with a mobile-
compute set of tools - size, speed usability constraints go, but the
tools are still 'included in the product' ?.

Two USB cables may be needed, but that's not a brick wall.
One for the Mobile-Compute tools, and one for the Debug pathway.
With this config, you can draw on a much larger user-base, and use
tools better suited to the tasks.

Some uC platforms are quite close to this already

Things like the STM32 Primer2, and the new Atmel AVR32
http://www.atmel.com/dyn/corporate/view_detail.asp?FileName=3DATEVK1105_3_1=
6.html

-jg

Hi John,

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

Are you settled on STM32?

I have StickOS, mentioned in one of the earlier replies, that runs on
PIC32 and a bunch of Freescale MCUs which was intended for this exact
purpose, and does almost exactly what you want...  You can log into the MCU
interactively, write and debug your program, save it to an internal flash
filesystem, run commands in immediate mode, interactively debug, etc.

StickOS BASIC allows you to define "pin variables" that are bound to pins
that can be configured for digital I/O, analog I/O, frequency or servo
output, etc., and then as you examine or manipulate those variables, the
pins are correspondingly affected.  You can manipulate pins and peripherals
interactively at the command line as well as programmatically in a BASIC
program.

Full details on StickOS (and downloads for 11 MCUs, from 8-bit to 32-bit)
are on the web at: http://www.cpustick.com/index.htm

Each new port takes between a day and a week, depending on the MCU and
toolset, and you're the second person in a week who has asked about the
Cortex M3, so that bumps it up the priority list... :-)  Basically, StickOS
can run on almost any MCU with 128k or more of flash and 8k or more of RAM.
 We compile to bytecode (line-by-line, transparently) so it is pretty fast
on a 32-bit MCU -- the PIC32 exceeds 100k lines/second.

If you want to explore this option, feel free to drop me an e-mail at
rich@testardi.com...  I'm pretty heavily loaded for the next few weeks, but
could get to this right after then.

Also, if you don't mind me potentially hijacking your thread just for a
moment, I'm dying to know if this project mentioned by Jon Kirwan was
actually the HP Timeshare BASIC:

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

Because that was what inspired me to write StickOS!!!

Ever since High School I have thought that was the most amazing way to
learn computers, and now I am hoping to pass that on to the kids today, to
help teach embedded systems.  That's my dream, anyway.

-- Rich
rich@testardi.com
http://www.cpustick.com/index.htm

On Apr 8, 11:10=A0pm, "rtestardi" <r...@testardi.com> wrote:
> StickOS BASIC allows you to define "pin variables" that are bound to pins
> that can be configured for digital I/O, analog I/O, frequency or servo
> output, etc., and then as you examine or manipulate those variables, the
> pins are correspondingly affected. =A0You can manipulate pins and periphe=
rals
> interactively at the command line as well as programmatically in a BASIC
> program.
>
> Full details on StickOS (and downloads for 11 MCUs, from 8-bit to 32-bit)
> are on the web at:http://www.cpustick.com/index.htm

Interesting package
It says free download, and does not mention restrictions ?

Is this  compatible with any PC Basics,
(eg FreeBASIC, or OpenOffice.org Basic, which has a nice IDE )

- that would allow users to test algorithms in a PC environment, and
code
a PC end in a similar language...
-jg

Hi,

>Interesting package
>It says free download, and does not mention restrictions ?

Well, the only restriction is the cya disclaimer "for evaluation purposes,
with no warrantee whatsoever" -- I don't expect folks to try and sell it or
to put it in a space shuttle. :-)

Feedback would definitely be appreciated, though, if you do anything
significant with it -- it is still changing radically month-to-month, with
new ports all the time (it's now a toss-up between PIC24 and STM32 for the
next one).

>Is this compatible with any PC Basics,

No.  It's a very simple BASIC -- simpler than anything else I found -- and
very much geared for embedded MCU pin and peripheral control.

You can see the whirlwind command and statement tour in the Quick
Reference Guide at: http://www.cpustick.com/downloads/quickref.v1.60.pdf

>- that would allow users to test algorithms in a PC environment, and
>code a PC end in a similar language...

You can run it on your PC just by loading up the StickOS for Windows
software simulation from the Downloads page -- that's how we do all our
automated testing, so it's a fine way to test algorithms, etc.  Obviously
pin and peripheral functionality doesn't work on the PC -- it's a very
simple port of the guts of the BASIC.

-- Rich

On Apr 9, 2:42=A0pm, "rtestardi" <r...@testardi.com> wrote:
>
> Feedback would definitely be appreciated, though, if you do anything
> significant with it -- it is still changing radically month-to-month, wit=
h
> new ports all the time (it's now a toss-up between PIC24 and STM32 for th=
e
> next one).

One suggestion would be to add a SIZE column to your MCU's page ?

Be interesting to see how large the StickOS is, on the various cores
(or two Size columns, if there is a minimalist / full feature option?)

>
> >Is this compatible with any PC Basics,
> You can run it on your PC just by loading up the StickOS for Windows
> software simulation from the Downloads page -- that's how we do all our
> automated testing, so it's a fine way to test algorithms, etc. =A0Obvious=
ly
> pin and peripheral functionality doesn't work on the PC -- it's a very
> simple port of the guts of the BASIC.

Perhaps some 'pins' could be added  via the parallel port ?
Does that PC simulation include Step/Watch debug features ?

-jg

Hi,

>One suggestion would be to add a SIZE column to your MCU's page ?
>Be interesting to see how large the StickOS is, on the various cores
>(or two Size columns, if there is a minimalist / full feature option?)

There are just two flavors of StickOS -- one that includes USB host mode
(for PIC32 and MCF5225x) and one that doesn't.  But the different MCUs
support different UI transports for the command-line (Ethernet, USB, UART)
and different numbers and types of pins and peripherals, so the overall
size comparison might be misleading (an Ethernet stack on the MCF5223x is
basically the same size as StickOS itself; whereas a UART driver on the
MCF51QE128 is basically 0 bytes in comparison).

My experience with the different MCUs is that code size is *almost*
constant between them (at full optimization levels) -- within maybe 10%. 
When we have MCUs with more flash, we typically just expand the size of the
"flash filesystem", allowing you to store more BASIC programs (other than
the current one you are running).

Just as a baseline picture, the "average" code sizes for the various
modules of StickOS are:

bytecode compiler and decompiler:  10k bytes
bytecode execution engine:          6k bytes
bytecode access and merge module:   4k bytes
variable access module:             3k bytes
pin access module:                  4k bytes
basic command interpreter:          3k bytes
zigflea wireless transport:         3k bytes

Just as a few quick notes, you can infer from the module list we don't
actually store BASIC source code anywhere -- it is discarded as soon as the
statement is entered...  We store only the compiled bytecode, and then
decompile it when the user wants to list the program or edit lines...  We
also store initial program edits in RAM, and then merge them with a "base
program" in flash, to avoid unnecessary flash memory writes; once we have a
full flash page of edits pending, we merge the RAM and base programs and
rewrite flash.  The wireless transport supports point-to-point as well as
relays, and both a UI transport stream as well as "remote variable" updates
from MCU to MCU.

>Perhaps some 'pins' could be added  via the parallel port ?
>Does that PC simulation include Step/Watch debug features ?

All the debug features work on the PC simulation, so you can single step,
use breakpoints/watchpoints, examine/modify variables in immediate mode,
use edit-and-continue, etc.  The PC version was meant to be able to
exercise all of the non-pin and non-UI transport functionality of the
StickOS code, thru an automated test suite.

-- Rich