Command languaje for tiny microcontrollers

[Picuino]

An interpreted language allows us to program and test with the microcontroller faster than with compiled languages, but there are not many options to choose from. Here I present a few and the solution proposed by zserge.

LUA
Is a good interpreted language. Powerful and flexible.
It occupies little space (200kB flash) but it is too much for small microcontrollers.
On larger microcontrollers, its garbage collection system makes it not recommended for real time applications.

FORTH
Is the opposite. Powerful, fast, occupies only 2kB of flash and is suitable for real time systems.
The problem it has is that it tends to create read-only programs. Very complicated for an average user.

TCL
An extendable language, born out of frustration with having to build custom command languages again and again, is in fact very simple.

PARTCL
TCL Adapted to microcontrollers:
   https://zserge.com/posts/tcl-interpreter/
   https://github.com/zserge/partcl

Features:
    ~600 lines of "pedantic" C99 code
    No external dependencies
    Good test coverage
    Can be extended with custom Tcl commands
    Runs well on bare metal embedded MCUs (~10k of flash is required)
    Code distributed under MIT license

[Picuino]

Another TCL interpreter in ~500 lines of code is Picol:
Code: http://antirez.com/picol/picol.c.txt
Wiki: https://wiki.tcl-lang.org/page/Picol

[tellurium]

Another option:
A very cut-down JavaScript implementation: https://github.com/cesanta/elk

less than 1500 lines of code,
takes only ~100 bytes for the VM,
can run on Arduino Nano with 2k RAM

zserge, in fact, was one of the contributors of elk.

[RoGeorge]

How small is tiny?

Is MicroPython small enough?

Microcontroller targets can be as small as 256kiB flash + 16kiB RAM, although devices with at least 512kiB flash + 128kiB RAM allow a much more full-featured experience.

https://github.com/micropython/micropython

[Picuino]

MicroPython is too large for 8-bit microcontrollers. And the garbage collection system does not allow using it for real-time systems.
Tiny in this context can mean 10-20kB at most, to make room for more program parts and customizations.

[nctnico]

MicroPython is too large for 8-bit microcontrollers. And the garbage collection system does not allow using it for real-time systems.
Tiny in this context can mean 10-20kB at most, to make room for more program parts and customizations.

Why would you want to use a scripted language for realtime systems? And you really need to define what is realtime. Once per second is also realtime but not a problem to achieve using a scripted language.

IMHO a much better approach is to let the scripted language do housekeeping + high level logic and run regular C code to do tasks that need to be done quickly in parallel. I have been working on a modified version of LUA that can be used together with C software that is organised as a super-loop. Still, LUA takes around 80kB of flash on ARM and a minimal script already needs 12kB of RAM (including the LUA compiler). In principle it works but I want to add some debugging facilities to it so you can do on-target debugging using a command line interface.

[Picuino]

I want a scripting language to make programs that test commands made with C code.

I program low level routines in C and test them until they work.
Then I want to make a program that calls this low level routines as needed, in which I will make many changes to tune it and that I do not care that it is slow in execution, but flexible and fast when programming it.
In the end I can convert that code to C once it is well debugged.

Another solution I have thought of is to use an interpreted language in the computer, which sends codes through the serial port. Each code corresponding to a call to a routine or an argument. And that sometimes the microcontroller responds by sending return messages to the computer.

In short, I want to have a scripting language to handle small microcontrollers.

Realtime may be 0.1s or 0.01 seconds, depending on the context.

[globoy]

I'm curious, can you give an example of what you do with one of the small TCL implementations?  What kind of system it's running on?  I took a quick (but not exhaustive) look at their source and it doesn't appear they do things like interface with a micro's peripherals (perhaps without the addition of custom commands).  They don't seem to have native filesystem access (for small systems with a filesystem in flash or on an SD Card).  I've used TCL in the distant past as a scripting language on unix/linux systems.  I am probably being dense, but I'm missing how they help on low-end systems like 8-bit micro-controllers.

[Picuino]

Another one for Arduino.

TinyBasic Plus
https://github.com/BleuLlama/TinyBasicPlus

[Picuino]

I'm curious, can you give an example of what you do with one of the small TCL implementations?  What kind of system it's running on?  I took a quick (but not exhaustive) look at their source and it doesn't appear they do things like interface with a micro's peripherals (perhaps without the addition of custom commands).  They don't seem to have native filesystem access (for small systems with a filesystem in flash or on an SD Card).  I've used TCL in the distant past as a scripting language on unix/linux systems.  I am probably being dense, but I'm missing how they help on low-end systems like 8-bit micro-controllers.

I am not sure how to adapt TCL to microcontrollers. All arguments are strings and that doesn't get along with arguments that must be integers or bytes or bits. You have to do a conversion which is not trivial.

Maybe the old BASIC that was in the early personal microcomputers is a better option.

What kind of system it's running on?

I'm thinking in Arduinos (Atmega328P) or equivalent PIC microcontrollers. 8bit microcontrollers with ~32kB flash and 2kB RAM.

[Picuino]

Another option:
A very cut-down JavaScript implementation: https://github.com/cesanta/elk

less than 1500 lines of code,
takes only ~100 bytes for the VM,
can run on Arduino Nano with 2k RAM

zserge, in fact, was one of the contributors of elk.

I have been testing ELK v2.2.0 for Arduino UNO and a minimal program (blink led) occupies almost all the Flash memory (30010 Bytes).
It's a bit big for small micros.

[tggzzz]

I want a scripting language to make programs that test commands made with C code.

I program low level routines in C and test them until they work.
Then I want to make a program that calls this low level routines as needed, in which I will make many changes to tune it and that I do not care that it is slow in execution, but flexible and fast when programming it.
In the end I can convert that code to C once it is well debugged.

Don't over-think the problem; just try something and see.

Personally I'd go with Forth, since it is readily available, without "brick walls", well documented, and simple.

You will be peeking/poking a device to verify the hardware and your understanding, then combining peek/pokes to make useful composite operations, then combining those into test sequences. That's bottom-up programming, and there's nothing wrong with that!

Forth is ideally suited to bottom-up programming.

[Picuino]

We will have to give it a chance.


NanoFORTH
https://www.arduino.cc/reference/en/libraries/nanoforth/

[fchk]

Do you know FICL?

https://ficl.sourceforge.net/

very fast, very mature.

fchk

[Picuino]

NanoFORTH v1.4.0
Multitasking.
blink program
   Flash = 14184 bytes (43%)
   RAM = 278 bytes (13%)

I am not able to do a simple for loop of 10000 steps to evaluate its speed.
That's the problem with FORTH, it reminds me the HP48 calculator and its RPN system. Somewhat complicated.

[Picuino]

Do you know FICL?

https://ficl.sourceforge.net/

No. Thank you.
It appears to be an implementation of FORTH for 32-bit and 64-bit microprocessors, but fairly easy to port to other systems.

[SiliconWizard]

Regarding Lua:

- You may want to have a look at eLua if you haven't already: http://www.eluaproject.net/ (not sure it is still maintained though, unfortunately.)
- Another option if the Lua language is attractive for your application, but you're OK with compiled rather than interpreted (which actually can be a huge benefit unless you need an interactive interpreter) is Nelua: https://nelua.io/ . It's a fantastic project. Now of course, it will require some work to make an environment work for your particular target - it's not a "plug-and-play" solution.

[rstofer]

Back when dinosaurs roamed the earth, I wanted a higher level language for testing new 8085 projects.  The Intel monitor was a start but was console interactive, not scripted.

Along came Palo Alto Tiny Basic (thanks to Li-Chen Wang).  I could write code for any hardware I wanted to include in the system.  It was far from perfect but it used less than 2k of PROM.  Google shows quite a bit has happened since the early '80s and Tiny Basic is still around.  One addition was an interface to CP/M which added a file system and standardized console IO.

When I would create a new system, the first software would be the Intel Monitor just to see if memory was working properly and perhaps to test serial IO.  Very soon thereafter, I would implement Tiny Basic.  Sometimes I would load it with the Monitor, other times I would burn it into the PROMs.  Source is still available for several versions.

https://en.wikipedia.org/wiki/Tiny_BASIC

[Picuino]

Thanks. Perhaps a very good option for 32bit micros.

I'm trying to use nanoFORTH on Arduino.

Code: [Select]

: BLK 1 5 OUT 0 5 OUT ;
BLK
Produces a pulse of 50us duration.

Code: [Select]

: BLKS 0 FOR BLK NXT ;
100 BLKS
Reset the microcontroller. It does not work. I don't know why.

[Picuino]

Code: [Select]

: BLK 1 5 OUT 0 5 OUT ;
: FBK 0 FOR BLK NXT ;
100 FBK

Now it really works. It has a cycle time of 150us (6660Hz). Not too fast. Similar to TinyBASIC

[rstofer]

Personally I'd go with Forth, since it is readily available, without "brick walls", well documented, and simple.

You will be peeking/poking a device to verify the hardware and your understanding, then combining peek/pokes to make useful composite operations, then combining those into test sequences. That's bottom-up programming, and there's nothing wrong with that!

Forth is ideally suited to bottom-up programming.

Back in the late '70s, I went to a factory where they built disk drives and SCSI controllers.  They used FORTH as their lab language of choice.  The code was written bottom up so they could add a new test by just invoking some previously defined words for primitive operations.  They were highly enthusiastic for this approach to testing.

[pqass]

I played with https://www.flashforth.com/ a couple of years ago.  It seems nice.
Assembler source (for avr, pic18, pic24), ready to burn hex file (for 328,32u4,2560), and docs/tutorials are provided.
Can do multi-tasking, spi, i²c, bare metal ops, ...
https://pajacobs-ghub.github.io/flashforth/ff5-quick-ref.html
https://pajacobs-ghub.github.io/flashforth/elements-of-flashforth-5.html
https://pajacobs-ghub.github.io/flashforth/ff5-tutorial-guide.html

[Picuino]

TinyBASIC
Flash: 8020 bytes (24%)
RAM: 1375 bytes (67%)

Code: [Select]

>10 FOR I = 1 TO 10000
>20 DWRITE 5, HIGH
>30 DWRITE 5, LOW
>40 NEXT I
>RUN
Cycle time of 550us (1820 Hz)

[Picuino]

I played with https://www.flashforth.com/ a couple of years ago.  It seems nice.
Assembler source (for avr, pic18, pic24), ready to burn hex file (for 328,32u4,2560), and docs/tutorials are provided.
Can do multi-tasking, spi, i²c, bare metal ops, ...

Good option, but it overrides the Arduino or PIC bootloader where it is installed.

[tellurium]

If your goal is to make a well tested code, why not developing in С but on a linux/mac/windows, and abstract/stub the hardware calls.
Basically, write a unit test in C, stubbing the HW, and when it is well tested, your C code is ready to be moved to the uC.