Embedded Basic interpreter recommendations?

If the HW manufacturers would make microcontrollers with sufficient loadable (10-100 KiB) code space "core" in RAM, it might be possible to reduce the total system power consumption, since the permanent storage "disk" only needs to be powered up to load the overlay/chained segment.

Paul

.

Interesting stats, getting closer to microcontroller space, but still more than Turbo Pascal ...

AM

er,

What was the Lilith Debug support like ? - Single Step, and Break points ? Or do we just rely on the Silicon Debug and use a Host PC for serious debug ?

-jg

It is "only" when read in context - only 600K out of the total of 150MB.

Luxury! Oh - the good old days! Weren't they so much fun! This is 2009 - I also like to revisit the past but I sure would not like to be back there permanently.

My first programming expereince was with an Elliott 903 in the UK in the late 1960's. We had to load the ALGOL60 compiler in from paper tape every time we wanted to switch from SIR the assembler.

A decade or so later my first microcomputer was a Signetics S2650 with a whopping 4k of RAM. Programs had to be typed in in hex and stored to cassette tape. After many weeks of programming I still only managed to fill

1k. Several months ago I was bitten by the nostalgia bug and rebuilt it from scratch. The fond memories didn't take long to vanish once I started to recall how much of a pain it used to be ....

Yet again, later in the 1980's I can recall spend several weeks just working on a menu system. These days I can concentrate on writing the actual applications and get things done. I am still as aware of memory usage and performance as I always was but don't get hung up about it.

When programming for Windows, if a particular approach takes an extra 50kb but means I can get the job done in a day instead of a month then I'm not going to lose any sleep worrying about it. When programming embedded systems I'd agree - our 1980's strategies and experience really come in handy.

-- Chris Burrows CFB Software Armaide: ARM Oberon-07 Development System for Windows

Yes - but Modula-2 had a lot more than the Turbo Pascal of the same period. Turbo Pascal's two main competitive attributes were that it was fast and it was cheap. As a serious software development tool for medium to large applications it had some severe limitations. It was limited to creating 64K COM files, had no linker, no overlay capabilities etc. etc. Most TP programs I saw at the time were hardly recognisable as Pascal - they looked more like assembler because of all the tricks needed to run on the IBM PC.

It had an interactive multi-window 'post mortem' source debugger which enable you to drill down the call stacks identifying source lines and inspecting the value of all of the variables.

The Lilith was a standalone personal workstation - there was no 'Host PC'.

-- Chris Burrows CFB Software Armaide: ARM Oberon-07

Yes, Chris. Similar perspective here.

The one thing I'd add to all this is that _if_ BASIC is being placed in resource starved microcontrollers (and many of them look an awful lot like the resource starved equipment of yester-year), then the techniques applied back then could have good purchase here. Just a thought.

Jon

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.

Chris

But could you also single step, set break points and watch variables ? Any code-size indication on this portion ?

I was talking in the context of this thread, and relative to a M-Code implementation on a uC. With modern uC, you have a reasonable chunk of silcon support for Debug, but often intended to be driven from a remote JTAG master.

ROM is very cheap, and there are uC solutions with largish stable code in ROM (Maxim's DS80C40x for example, have 64K ROM )

-jg

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

No - it was a 'post mortem' debugger. Typically with this sort of system you would use defensive-programming techniques e.g. using assertions to test for pre/post-conditions at strategic points in your code. The intention is to trap any unexpected conditions that occur during testing and then use the PMD to identify the offending code.

A directory listing of debug.obj using Emulith shows 31k (words). However, it would also require the existence of the non-trivial bit- mapped multi-window display management software to function.

Chris

He said it was a "Sage", no mention of an AT. :-) And it probably cost more than an AT, anyway.

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

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

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:

Chris

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?

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.

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.

ing

a

heir

a

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

6.html

-jg

Hi John,

serial

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:

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 snipped-for-privacy@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:

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 snipped-for-privacy@testardi.com

rals

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,

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

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:

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

h e

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

ly

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

-jg

Hi,

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.

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