Lightweight Scripting Language for MCUs

[Sal Ammoniac]

I often need to do some quick prototyping and testing of sensors on some of my MCU platforms and I find myself writing the code in C and compiling it, downloading it, etc. I'd like something like a small scripting language I can interact with over a serial link to a board to send commands to a sensor, look at the output, etc.

Anyone know of a scripting language small enough to run on an ARM Cortex-M4 and not require too many resources?

[coppice]

Lua seems to be the lightweight scripting language of choice/

[hli]

At 43oh, someone referred to "SIMPL". Its a small interpreted language designed as interactive language for embedded systems.

[westfw]

Forth?
Probably too tiny?
Someone should do a bit of host side programming to allow a generic forth to import cmsis-style .xml or .h files to pick up words for accessing the peripherals.

[Kjelt]

Lua seems to be the lightweight scripting language of choice/

+1

[Sal Ammoniac]

Forth?
Probably too tiny?
Someone should do a bit of host side programming to allow a generic forth to import cmsis-style .xml or .h files to pick up words for accessing the peripherals.

Forth is an interesting language. I've tried to like it over the years but just haven't been able to get my head around it. Too weird, plus it has the reputation of being a cult language. I remember back in the 80s lots of guys saying that Forth was about to take over and you weren't on the bandwagon you'd be left behind. Never happened...

The thing that turned me off was the stack-oriented nature of the language. Variables were rarely used--instead you needed to keep track of what was on the stack and invoke operations to copy and move things around on the stack. I tried, but could never keep track of what was where in my head and always had to write tedious comments like (n1 n2 n3 -- n2 n3 n1) for every operation to have any hope of keeping track of where everything was. I also found that if I came back to a piece of code I'd written more than about a few days previously I couldn't understand it without staring at it for a long time.

[mikeselectricstuff]

MMBASIC ?
http://mmbasic.com/

[member_xyz]

micropython, fully interactive runs on wide range of ucontrollers , including STM M4, ESP8266 can connect over wireless wifi web interactive terminal. Based on Python 3 and includes fairly extensive functionality.

http://micropython.org/
http://forum.micropython.org/

[Pack34]

If you really want to go down this road, you could write a firmware for a dev board that simply relays commands from USB to spin and then write a python script to command it.

Or just pick up a USB to spin bridge, like this guy:
https://www.amazon.com/Adafruit-FT232H-Breakout-General-Purpose/dp/B00XW2MD30/ref=sr_1_2?ie=UTF8&qid=1471921175&sr=8-2&keywords=usb+to+spi

[nowlan]

Ive been looking for something that can do Expect for serial comms. Would like to hear anything that supports it, that isnt a full blown ARM/linux.

I guess that micropython mentioned might be close enough.

[mubes]

Ive been looking for something that can do Expect for serial comms. Would like to hear anything that supports it, that isnt a full blown ARM/linux.

I guess that micropython mentioned might be close enough.

Micropython is pretty simple to port too... There's a 'core'  implementation in the distribution directories which is straightforward to integrate into your own code. 

Of course,  OS integration is a how long is a piece of string issue....

Dave

[tggzzz]

There's a common mistake that I've seen repeatedly; I made it once myself.

The chain of events is

• see a need to be able do a few simple things on-the-fly
• create a little scripting language to do those
• then find "oh, if only I could also do X", where X is something like conditional statements, or loops, or globbing/regexps
• add those
• repeat 3 and 4

Very soon the "little language" has grown like cancer until nobody, even the designer, understands all the interactions between features.

The solution is to use an existing language, Forth being the simplest but others have been suggested above.

Oh, as to whether an ARM Cortex M4 would be sufficient... The first full C compiler I used professionally ran on a 64kbyte Z80 CP/M machine. So why don't you just put that in the ARM

[newbrain]

I'll state once again my love for Forth.
Implementations for various MCUs exist, and it's not difficult to roll your own.
Mmmh, I have yet to do it for STM32, now that would be a nice side project (I know it's already available, but I'm in it for the fun).

The programming model based on stacks comes quite natural to me (my fist calculator was an HP one), it can be definitely be confusing for a newcomer.

Success against BASIC was really impossible, as the entry barrier is quite higher.
Then Chuck Moore went astray in stranger and stranger implementations (machine Forth, colorForth)...

[helius]

arrayforth (colorforth) is beautiful. it takes a lot of courage to begin designing something without leaning on convention. Urbit is another example of amazing de novo design.

"If I haven't seen farther, it is from standing in the footprints of giants."

[alexanderbrevig]

I've used Espruino and I have a small LISP running on atmega328 (yes, Arduino) which for me at least - is fun and useful for quick dirty proofing of concepts.

[legacy]

perhaps ... my toy little language might be useful for something, it needs some works, it's an interpreter written in C (on the repository you can find the C++ version, send me a PM for the C version), it's able to support very basic features like loops and if-then-else

Code: [Select]

Program factorial
Begin
    Input n
    factorial = 1
    While n > 1
    Begin
        factorial = factorial * n
        n = n - 1
    End
    Output factorial
End

procedures and functions are not supported, and it's 100% abandonware 

[legacy]

The solution is to use an existing language

also the problem is the editor, what do you use to see the code on the target machine, and what do you use to edit existing lines or to add new lines ?

gwbasic comes with LED (Line EDitor), which is embedded within the interpreter and covers all the needs

• see code (list)
• edit existing code
• insert new code

[tggzzz]

The solution is to use an existing language

also the problem is the editor, what do you use to see the code on the target machine, and what do you use to edit existing lines or to add new lines ?

For scrotty little scripting languages, the problem is far worse: there's no tooling, plus you have to train staff in something they can only use in your company. Usually it is better to invent a domain specific library than a domain specific language.

I've seen a company taken down by their own DSL.

[rstofer]

Forth?
Probably too tiny?
Someone should do a bit of host side programming to allow a generic forth to import cmsis-style .xml or .h files to pick up words for accessing the peripherals.

Forth is an interesting language. I've tried to like it over the years but just haven't been able to get my head around it. Too weird, plus it has the reputation of being a cult language. I remember back in the 80s lots of guys saying that Forth was about to take over and you weren't on the bandwagon you'd be left behind. Never happened...

The thing that turned me off was the stack-oriented nature of the language. Variables were rarely used--instead you needed to keep track of what was on the stack and invoke operations to copy and move things around on the stack. I tried, but could never keep track of what was where in my head and always had to write tedious comments like (n1 n2 n3 -- n2 n3 n1) for every operation to have any hope of keeping track of where everything was. I also found that if I came back to a piece of code I'd written more than about a few days previously I couldn't understand it without staring at it for a long time.

Forth is an excellent choice for a scripting language!  Back in the early '80s, I made a bit of side money writing BIOS code for various hard drives and I spent a few hours at one of the vendors' shop.  Their entire testing operation was built on Forth because it gave them the ability to write code from the bottom up.  Functions that already existing were usable from the command line so creating a new test really involved calling functions that already existed with a different set of parameters.  It is not unlike programming an HP calculator...

I'm not a big fan of Forth but I do recognize the utility for development work.

When I was messing around with the 8080, Z80 and 8085 chips I used to bring up the Intel monitor first.  This gave me basic program load and debug capability.  But right after that I brought up a modified version of Palo Alto Tiny Basic.  Modified in the sense that I added Port and Mem variables and functions.  I could write simple code in Basic to exercise the hardware.  I believe the earliest versions would fit in a 1K EPROM (my memory fades...).

[Sal Ammoniac]

I'll state once again my love for Forth.
Implementations for various MCUs exist, and it's not difficult to roll your own.
Mmmh, I have yet to do it for STM32, now that would be a nice side project (I know it's already available, but I'm in it for the fun).

The programming model based on stacks comes quite natural to me (my fist calculator was an HP one), it can be definitely be confusing for a newcomer.

I tried it a bit back in the early 1980s (I implemented a Forth for a 6502 board I built), but quickly got tired of it for the reasons I mentioned in another post, primarily having to keep track of things on a stack.

There's nothing wrong with stack models--I was an early HP calculator user (HP35) and like RPN. In fact, I've only ever used HP calculators. An HP calculator only has a four level stack, which makes it rather easy to remember what's on the stack. With Forth programs more complex than trivial one liners you have more to keep track of, and this is compounded by operators that manipulate the stack in ways you can't do on an HP calculator (like 2over and 2rot). That, plus the fact that Forth code just looks plain ugly, was enough to turn me off.

[rstofer]

I'm not going to word this correctly but here goes:  Forth programs are built from the bottom up.  It is natural to assume that at the bottom layer there will be some swap, rot, 2over and so on.  As we move up, these may not be all that common.  In testing a disk drive, we tell some lower level function to do a seek followed by calling another function to write and a third function to read.  Perhaps there will be a call to compare the two buffers.  There may not be any low level operations (like swap) required at this level.

Yes, thinking in Forth takes a bit of effort to get started.  So did writing a celestial navigation program for my HP48GX.  But after the first hundred lines or so the code takes on a pattern.

Then we get to the Chicken and Egg problem.  To implement Forth requires, at a minimum, an assembler for the target and most of the larger incantations require a C compiler.  If I had a C compiler, why would I need a scripting language?

Anyway, here is a lecture on implementing a minimal Forth with assembly code for the ARM
http://www.sifflez.org/lectures/ASE/C3.pdf

This sounds interesting enough that it bears further investigation.  It's not like I am short of ARM boards, particularly STM32F's.

[macboy]

I find myself frequently turning to my Bus Pirate to do this type of task. It can talk almost any serial protocol including non-standard ones. It has built-in BASIC scripting. This has limitations, but it is very useful for taking readings, formatting them and displaying them. I downloaded the source and enhanced the scripting engine for my own needs (printing numbers in Hexadecimal format for example). Maybe you are looking for something more powerful, but for just testing sensors, displays, memories, and other serial devices, this works quite well for me.

[kripton2035]

Lua seems to be the lightweight scripting language of choice/

+1

[Sal Ammoniac]

Lua seems to be the lightweight scripting language of choice/

+1

How "lightweight" is it? I found this on the Lua website:

The source contains around 24000 lines of C. Under 64-bit Linux, the Lua interpreter built with all standard Lua libraries takes 245K and the Lua library takes 420K.

That's awfully big! I doubt it would be as large when built for a 32-bit MCU, but it's still not exactly what I'd call lightweight. How much can you strip out of it while maintaining its usefulness?

[madires]

Would some kind of interpreter really speed up the development process? What about time critical or interrupt driven stuff? For "playing" an USB based I/O box connected to your computer might be a better option.