Author Topic: Lightweight Scripting Language for MCUs  (Read 28245 times)

0 Members and 1 Guest are viewing this topic.

Offline Sal AmmoniacTopic starter

  • Super Contributor
  • ***
  • Posts: 1741
  • Country: us
Lightweight Scripting Language for MCUs
« on: August 22, 2016, 05:34:21 pm »
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?
"That's not even wrong" -- Wolfgang Pauli
 

Online coppice

  • Super Contributor
  • ***
  • Posts: 8942
  • Country: gb
Re: Lightweight Scripting Language for MCUs
« Reply #1 on: August 22, 2016, 05:48:04 pm »
Lua seems to be the lightweight scripting language of choice/
 

Offline hli

  • Frequent Contributor
  • **
  • Posts: 257
  • Country: de
Re: Lightweight Scripting Language for MCUs
« Reply #2 on: August 22, 2016, 05:52:00 pm »
At 43oh, someone referred to "SIMPL". Its a small interpreted language designed as interactive language for embedded systems.
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4240
  • Country: us
Re: Lightweight Scripting Language for MCUs
« Reply #3 on: August 22, 2016, 08:06:27 pm »
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.
 
The following users thanked this post: Ian.M

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 6508
  • Country: nl
Re: Lightweight Scripting Language for MCUs
« Reply #4 on: August 22, 2016, 09:04:19 pm »
Lua seems to be the lightweight scripting language of choice/
+1
 

Offline Sal AmmoniacTopic starter

  • Super Contributor
  • ***
  • Posts: 1741
  • Country: us
Re: Lightweight Scripting Language for MCUs
« Reply #5 on: August 22, 2016, 09:07:15 pm »
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.
"That's not even wrong" -- Wolfgang Pauli
 
The following users thanked this post: freda

Online mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 13837
  • Country: gb
    • Mike's Electric Stuff
Re: Lightweight Scripting Language for MCUs
« Reply #6 on: August 22, 2016, 09:45:06 pm »
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline member_xyz

  • Contributor
  • Posts: 47
  • Country: au
Re: Lightweight Scripting Language for MCUs
« Reply #7 on: August 23, 2016, 02:57:15 am »
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/
 
The following users thanked this post: elecdonia

Offline Pack34

  • Frequent Contributor
  • **
  • Posts: 753
Re: Lightweight Scripting Language for MCUs
« Reply #8 on: August 23, 2016, 03:00:46 am »
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
 

Offline nowlan

  • Frequent Contributor
  • **
  • Posts: 649
  • Country: au
Re: Lightweight Scripting Language for MCUs
« Reply #9 on: August 23, 2016, 04:17:47 am »
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.
 

Offline mubes

  • Regular Contributor
  • *
  • Posts: 238
  • Country: gb
  • Do Not Boil
Re: Lightweight Scripting Language for MCUs
« Reply #10 on: August 23, 2016, 07:43:59 am »
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
 

Offline tggzzz

  • Super Contributor
  • ***
  • Posts: 20027
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: Lightweight Scripting Language for MCUs
« Reply #11 on: August 23, 2016, 08:06:59 am »
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 :)
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 
The following users thanked this post: newbrain

Offline newbrain

  • Super Contributor
  • ***
  • Posts: 1740
  • Country: se
Re: Lightweight Scripting Language for MCUs
« Reply #12 on: August 23, 2016, 08:39:22 am »
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)...
Nandemo wa shiranai wa yo, shitteru koto dake.
 

Offline helius

  • Super Contributor
  • ***
  • Posts: 3659
  • Country: us
Re: Lightweight Scripting Language for MCUs
« Reply #13 on: August 23, 2016, 09:37:33 am »
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."
 

Offline alexanderbrevig

  • Frequent Contributor
  • **
  • Posts: 700
  • Country: no
  • Musician, developer and EE hobbyist
    • alexanderbrevig.com
Re: Lightweight Scripting Language for MCUs
« Reply #14 on: August 23, 2016, 09:49:21 am »
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.
 

Offline legacy

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: Lightweight Scripting Language for MCUs
« Reply #15 on: August 23, 2016, 11:53:25 am »
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  :popcorn:
« Last Edit: August 23, 2016, 12:04:00 pm by legacy »
 

Offline legacy

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: Lightweight Scripting Language for MCUs
« Reply #16 on: August 23, 2016, 12:02:54 pm »
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
« Last Edit: August 23, 2016, 12:05:18 pm by legacy »
 

Offline tggzzz

  • Super Contributor
  • ***
  • Posts: 20027
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: Lightweight Scripting Language for MCUs
« Reply #17 on: August 23, 2016, 01:11:31 pm »
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.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 9914
  • Country: us
Re: Lightweight Scripting Language for MCUs
« Reply #18 on: August 23, 2016, 03:03:21 pm »
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...).
« Last Edit: August 23, 2016, 04:41:52 pm by rstofer »
 
The following users thanked this post: elecdonia

Offline Sal AmmoniacTopic starter

  • Super Contributor
  • ***
  • Posts: 1741
  • Country: us
Re: Lightweight Scripting Language for MCUs
« Reply #19 on: August 23, 2016, 04:15:27 pm »
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.
"That's not even wrong" -- Wolfgang Pauli
 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 9914
  • Country: us
Re: Lightweight Scripting Language for MCUs
« Reply #20 on: August 23, 2016, 05:06:38 pm »
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.
 

Offline macboy

  • Super Contributor
  • ***
  • Posts: 2278
  • Country: ca
Re: Lightweight Scripting Language for MCUs
« Reply #21 on: August 23, 2016, 05:13:55 pm »
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.
 
The following users thanked this post: elecdonia

Offline kripton2035

  • Super Contributor
  • ***
  • Posts: 2648
  • Country: fr
    • kripton2035 schematics repository
Re: Lightweight Scripting Language for MCUs
« Reply #22 on: August 23, 2016, 05:16:02 pm »
Lua seems to be the lightweight scripting language of choice/
+1
 

Offline Sal AmmoniacTopic starter

  • Super Contributor
  • ***
  • Posts: 1741
  • Country: us
Re: Lightweight Scripting Language for MCUs
« Reply #23 on: August 23, 2016, 05:25:22 pm »
Lua seems to be the lightweight scripting language of choice/
+1

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

Quote
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?
"That's not even wrong" -- Wolfgang Pauli
 

Offline madires

  • Super Contributor
  • ***
  • Posts: 7951
  • Country: de
  • A qualified hobbyist ;)
Re: Lightweight Scripting Language for MCUs
« Reply #24 on: August 23, 2016, 05:44:47 pm »
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.
 

Offline BloodyCactus

  • Frequent Contributor
  • **
  • Posts: 482
  • Country: us
    • Kråketær
Re: Lightweight Scripting Language for MCUs
« Reply #25 on: August 23, 2016, 06:23:03 pm »
How "lightweight" is it? I found this on the Lua website:

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

you could strip quite a lot out like the compiler side of it and just upload pre bytecompiled scripts etc and remove some of its standard libs you dont need.

check out https://www.lua.org/notes/ltn002.html for info on doing this on an older version of lua.

they got it the core of lua down to 24k

you would have to compiler the lua compiler and the eventual embedded interp code to have the same lua_number size (like int32_t or something instead of double unless you want double) and build the ocmpiler on the same endianness. (well thats what I had to do back in the day)
« Last Edit: August 23, 2016, 06:25:56 pm by BloodyCactus »
-- Aussie living in the USA --
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 27366
  • Country: nl
    • NCT Developments
Re: Lightweight Scripting Language for MCUs
« Reply #26 on: August 23, 2016, 06:29:13 pm »
Lua seems to be the lightweight scripting language of choice/
+1

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

Quote
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?
You need to look for eLua (embedded Lua).
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline krho

  • Regular Contributor
  • *
  • Posts: 223
  • Country: si
Re: Lightweight Scripting Language for MCUs
« Reply #27 on: August 23, 2016, 08:10:12 pm »
There is a pascal from the author of Nuttx. Have no idea if you can just take the interpreter and put is inside your project but its worth a try.
 

Offline TJ232

  • Frequent Contributor
  • **
  • Posts: 331
  • Country: 00
  • www.esp8266-projects.org
    • ESP8266 Projects
Re: Lightweight Scripting Language for MCUs
« Reply #28 on: August 24, 2016, 04:30:03 am »
Lua seems to be the lightweight scripting language of choice/

+1.
Quite nice and easy to use.
You can find a lot of ESP8266 examples, drivers, projects, etc on http://www.esp8266-projects.com

Micropython and ESP Basic are also 2 interpreters that worth a look.

Used lately ESP Basic to quick build a test rig for some boards, nothing fancy, but a less than 30 min job ended with a nice automated validation tool with web interface included :)
ESP8266 Projects - www.esp8266-projects.org
MPDMv4 Dimmer Board available on Tindie: https://www.tindie.com/stores/next_evo1/
 

Offline legacy

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: Lightweight Scripting Language for MCUs
« Reply #29 on: August 24, 2016, 06:27:00 am »
Lua seems to be the lightweight scripting language of choice/

+1.
Quite nice and easy to use.

eLua is also implemented and used by Texas Instruments for their CAS(2) pocket calculators in the TI-NspireCAS line
even the classic version(3) is able to have eLua aboard as "alternative" language(1)

as specifications,  those nspire calculators are ARM mini computers with 32-64Mbyte of ram and 2-10Mbyte of flash
yes: they can run linux, it doesn't make practical sense but as "intellectual challenge" t few linux-ports already exist, the CPU comes with TLB

therefore eLua on those calculators is not a strictly low level like MPUs (e.g. 8051,AVR8,...), it's medium level about the hardware 
but on ebay I have seen a few PIC32 equipped and sold (under 20-30 USD) with a built-in eLua interpreter  :-//


(1) the primary language on those calculators is BASIC, also supported by the old TI89/92,TI83,T84 line
(2) CAS, computer algebra system, something like Mathematica, able to manipulate symbols in mathematical expressions, also able to calculate integrals, differential equations, etc, but not so advanced like PC-software, anyway it comes with a lot of complexity, therefore eLua is a good choice in order "to glue" the user interface with algorithms and mathematical tools, according with feedbacks from users (students) … compared with TI-BASIC, eLua has actually boosted the productivity and reduced the frustration, it's more than appreciated in the last CX2-nspire line
(3) calculators with R1-R2 layout (<=2008 machines), they can have eLua once upgraded to the last firmware available, TIOS-v3.9.0.463
 

Offline Sal AmmoniacTopic starter

  • Super Contributor
  • ***
  • Posts: 1741
  • Country: us
Re: Lightweight Scripting Language for MCUs
« Reply #30 on: August 31, 2016, 11:00:48 pm »
How about Scheme? Does anyone have any experience using this language as an extension language for microcontrollers in the Cortex-M4 class? Are there any good free implementations?

I used to be an enthusiastic GNU Emacs user back in the day and wrote quite a lot of code in its extension language, eLisp.
"That's not even wrong" -- Wolfgang Pauli
 

Offline ebclr

  • Super Contributor
  • ***
  • Posts: 2329
  • Country: 00
Re: Lightweight Scripting Language for MCUs
« Reply #31 on: September 01, 2016, 09:26:35 am »
http://www.cypress.com/products/ez-usb-fx2lp?source=search&keywords=ez%20usb

It's a different approach but extremelly powerfull to do your intent
 

Offline l3VGV

  • Contributor
  • Posts: 12
  • Country: ru
Re: Lightweight Scripting Language for MCUs
« Reply #32 on: March 21, 2021, 01:19:41 am »
Spent more then a 2 weeks researching same topic.

Im using stm32f103c8 'blue pills' mostly, as a HID devices. Even with bloaty HAL libraries i have 45k FLASH and 15k of RAM free, and CPU is never used like at all.

Need to add complex logic on top of my apps. And make it work in hostile environment - user is stupid and can hang device or try to steal my IP with hacking.
So cant run another pure binary, need VM with execution time limits and all OPs arguments check.

User must have access to scripting, thru lightweight config utility. So no GCC! or complete Java compiler.

*

FORTH. Not my kind of syntax(sarcasm).


Good stuf.

If u have like 60k+ FLASH space go for MicroPython, best choice today IMO. Very good code, not fastest one, but we dont need speed anyway. Can run bytecode from FLASH.


If u for new stuff - BERRY, flash footprint with all modules off is 39k! very cool and clean syntax. Cant run bytecode from flash, yet.
https://github.com/Skiars/berry/tree/master/examples


Last thing worth mentioning - PAWN. Very small and blazing fast VM, 15k flash size!. Very good documentation, on language itself and  implementation.
Very bugy compiler(it ether corrupt stack and crush, or go infinite loop). Syntax is poor, but FFI is ok. All static, all compile time. No variable arrays, or dictionaries, or classes and rest of those new nonsense.
But static is good, no memory juggling = no fragmentation.
(im going with that one)


picoC. very slow, so sloooooow. Too slow.


mJS very nice javascript VM, but a litle too big for me.

LUA/eLUA have again strange syntax for my taste, i like classes and structs. and RAM usage is a bit too high for f103c8.(start form 10k).


some more reading attached

« Last Edit: March 21, 2021, 12:10:44 pm by l3VGV »
 
The following users thanked this post: nctnico

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 27366
  • Country: nl
    • NCT Developments
Re: Lightweight Scripting Language for MCUs
« Reply #33 on: March 22, 2021, 12:36:31 am »
Did you get eLua going? It is still on my bucket list to make it work on NXP's ARM microcontrollers but never got time for it.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline gnuarm

  • Super Contributor
  • ***
  • Posts: 2247
  • Country: pr
Re: Lightweight Scripting Language for MCUs
« Reply #34 on: March 22, 2021, 02:29:11 am »
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.

This is a common complaint with Forth.  It does mean the user is stuck in the world of more complex languages and has not taken to heart the ideas that make Forth easy to use. 

There is an explicit stack which is not hidden as it is in other languages.  This removes the complications of syntax for defining and invoking subroutines so that they become the  tools of the language and so are refereed to as simply "words" rather than subroutines.  In fact, "words" is a good way to think of programming in forth, when you define words you are extending the language into an application specific language. 

Once you grasp that idea fully, it is very powerful and leaves you with a magnificent tool moreso than a programming language. 

I've never figured out why people don't like it.  Maybe if they had been exposed to Forth early on, before being "ruined" by other languages they would not have issues accepting the stack or RPN. 
Rick C.  --  Puerto Rico is not a country... It's part of the USA
  - Get 1,000 miles of free Supercharging
  - Tesla referral code - https://ts.la/richard11209
 

Offline gnuarm

  • Super Contributor
  • ***
  • Posts: 2247
  • Country: pr
Re: Lightweight Scripting Language for MCUs
« Reply #35 on: March 22, 2021, 02:32:31 am »
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.

I don't do so much MCU programming these days, but I believe this has already been done.  If someone is interested, I could nose around the Forth groups and ask.

Most of my Forth coding these days is on a PC for operating an FPGA based test fixture for boards that I build.  I likely have a large order coming in and I need to add some things to the test program, so I'll be cracking open that nut again. 
Rick C.  --  Puerto Rico is not a country... It's part of the USA
  - Get 1,000 miles of free Supercharging
  - Tesla referral code - https://ts.la/richard11209
 

Offline techman-001

  • Frequent Contributor
  • **
  • !
  • Posts: 748
  • Country: au
  • Electronics technician for the last 50 years
    • Mecrisp Stellaris Unofficial UserDoc
Re: Lightweight Scripting Language for MCUs
« Reply #36 on: March 22, 2021, 03:00:24 am »
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.

I don't do so much MCU programming these days, but I believe this has already been done.  If someone is interested, I could nose around the Forth groups and ask.

Most of my Forth coding these days is on a PC for operating an FPGA based test fixture for boards that I build.  I likely have a large order coming in and I need to add some things to the test program, so I'll be cracking open that nut again.

The latest release of SVD2FORTH is out now: https://sourceforge.net/projects/mecrisp-stellaris-folkdoc/files/svd2forth-v3-stm32-20.03.21-F7a01.zip

It's designed for Mecrisp-Stellaris, produces a memory map file, a bitfields file and also transforms the SVD into a useful equates.s file for assembly use. Details in the readme.
 

Offline l3VGV

  • Contributor
  • Posts: 12
  • Country: ru
Re: Lightweight Scripting Language for MCUs
« Reply #37 on: March 22, 2021, 06:56:30 am »
Did you get eLua going? It is still on my bucket list to make it work on NXP's ARM microcontrollers but never got time for it.

Well, i downloaded latest version and few docs, but... eLUA site was not updated for so long. End ebuilder is down.

Second, LUA syntax is not for me.

Third, it will use GC. FLASH and RAM footprint is very big, 10k+ RAM for itself(default import tables and system stuff) and much more than 64k FLASH. seems like it for the slightly bigger uc. Maybe it can be striped?

 

Offline JoeyG

  • Regular Contributor
  • *
  • Posts: 122
  • Country: au
Re: Lightweight Scripting Language for MCUs
« Reply #38 on: March 22, 2021, 07:46:38 am »
Microphython and CircuitPython,   - but Phython on a MCU is not very efficient in terms of speed and memory usage.

Another is Micromite basic https://geoffg.net/micromite.html

Then there is the basic stamp  https://www.parallax.com/propeller-2/

 

Offline iMo

  • Super Contributor
  • ***
  • Posts: 4896
  • Country: vc
Re: Lightweight Scripting Language for MCUs
« Reply #39 on: March 22, 2021, 07:15:58 pm »
@Sal: I've been messing with your dilemma for 40years already. The only "really interactive and complete" MCU tool fully running on a target is Forth, imho.  Well, you have to overcome the initial mental barrier first.
Btw, I read a guy from NZ is claiming his Forth can do Basic - ABCForth..
 

Offline gnuarm

  • Super Contributor
  • ***
  • Posts: 2247
  • Country: pr
Re: Lightweight Scripting Language for MCUs
« Reply #40 on: March 23, 2021, 01:12:15 am »
I don't do so much MCU programming these days, but I believe this has already been done.  If someone is interested, I could nose around the Forth groups and ask.

Most of my Forth coding these days is on a PC for operating an FPGA based test fixture for boards that I build.  I likely have a large order coming in and I need to add some things to the test program, so I'll be cracking open that nut again.

The latest release of SVD2FORTH is out now: https://sourceforge.net/projects/mecrisp-stellaris-folkdoc/files/svd2forth-v3-stm32-20.03.21-F7a01.zip

It's designed for Mecrisp-Stellaris, produces a memory map file, a bitfields file and also transforms the SVD into a useful equates.s file for assembly use. Details in the readme.

It seems like for real work on MCUs Mecrisp is gaining the high ground and is on its way to becoming the defacto standard for embedded Forth.  The originator Matthias has put a lot of effort into porting to a number of MSP430 and ARM devices and boards.  I believe he has even ported it to the picoPi (or whatever they call it) as an image rather than an app running under Linux.  I think there is even a version that runs on a custom core in an iCE40 in case that's the way your boat floats. 

But what really sets it apart is that there is a growing set of documentation... something relatively unheard of in the Forth community... or other places.  lol 
Rick C.  --  Puerto Rico is not a country... It's part of the USA
  - Get 1,000 miles of free Supercharging
  - Tesla referral code - https://ts.la/richard11209
 

Offline iMo

  • Super Contributor
  • ***
  • Posts: 4896
  • Country: vc
Re: Lightweight Scripting Language for MCUs
« Reply #41 on: March 23, 2021, 12:15:51 pm »
For example with Mecrisp-Stellaris for stm32f407 CM4 (an example) you got a file called lib_registers.txt with definition words for about 300 registers and bits.

You upload that lib into your F407 once (as a text via terminal for example) and you can play with the registers as you wish. Stellaris can save your dictionary words into its flash, thus all you need for an "interactive work" is to fire up your F407, connect a serial terminal and you can mess with your bits and registers on-line then (and save the new word into the F407's flash when happy).

In order to write a celestial navigation app all you would need is a mechanical teletype worst case.. Would be better if you got a PC which can do copy/paste and work with .txt files, however  :-DD

PS: after powering up the F407 mcu preloaded with the stock libraries and drivers you can send the status of your button wired to pinA0 of portA via Usart6 in a loop for example:

Code: [Select]
[ here you are in your terminal.. ]

\ these new words could be saved to F407's flash
compiletoflash

: button? 1 porta_idr bit@ ;
: PA0sendbuttonstate begin button? >usart6 cr >usart6  key? until ;

PA0sendbuttonstate

[..here is the usart6 output ]
1
1
0
0
1
1

Or just to look at the pins A0, C7, B17 input logic levels anytime

Code: [Select]
[ here you are in your terminal.. ]

1 0   lshift porta_idr bit@ .   1 ok.
1 7   lshift portc_idr bit@ .   0 ok. 
1 17  lshift portb_idr bit@ .   0 ok.

Or when too lazy

Code: [Select]
[ here you are in your terminal.. ]

\ these new words could be saved to F407's flash
compiletoflash

:  ib17 1 17  lshift portb_idr bit@   ;
:  ic7   1 7  lshift portc_idr bit@   ;
:  >u6   >usart6 ;

ib17  .   1     ok.
ic7   .   0     ok.
ib17  .   0     ok.

\ send out input values at pins C7 and B17 via usart6

ic7 >u6 ib17 >u6 cr ic7 >u6  ib17 >u6 cr ic7 >u6 ib17 >u6

[..here is the usart6 output ]

01
11
10


« Last Edit: March 23, 2021, 02:41:41 pm by imo »
 

Offline techman-001

  • Frequent Contributor
  • **
  • !
  • Posts: 748
  • Country: au
  • Electronics technician for the last 50 years
    • Mecrisp Stellaris Unofficial UserDoc
Re: Lightweight Scripting Language for MCUs
« Reply #42 on: March 23, 2021, 01:27:50 pm »
Or if even lazier (using svd2forth) :

Code: [Select]
gpioc.

GPIOC_MODER.  RW   $40020800
3|3|2|2|2|2|2|2|2|2|2|2|1|1|1|1|1|1|1|1|1|1|
1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0
0 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0

GPIOC_OTYPER.  RW   $40020804
3|3|2|2|2|2|2|2|2|2|2|2|1|1|1|1|1|1|1|1|1|1|
1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0
0 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 0 0

GPIOC_OSPEEDR.  RW   $40020808
3|3|2|2|2|2|2|2|2|2|2|2|1|1|1|1|1|1|1|1|1|1|
1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0
0 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 1 0 0 0 0 0 0 0 1 0 0 0

GPIOC_PUPDR.  RW   $4002080C
3|3|2|2|2|2|2|2|2|2|2|2|1|1|1|1|1|1|1|1|1|1|
1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0
0 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 1 0 0 0 0 0 0 0 1 1 0 0

GPIOC_IDR.  RO   $40020810
3|3|2|2|2|2|2|2|2|2|2|2|1|1|1|1|1|1|1|1|1|1|
1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0
0 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 1 0 0 0 0 0 0 1 0 0 0 0

GPIOC_ODR.  RW   $40020814
3|3|2|2|2|2|2|2|2|2|2|2|1|1|1|1|1|1|1|1|1|1|
1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0
0 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 1 0 0 0 0 0 0 1 0 1 0 0

GPIOC_BSRR write-only

GPIOC_LCKR.  RW   $4002081C
3|3|2|2|2|2|2|2|2|2|2|2|1|1|1|1|1|1|1|1|1|1|
1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0
0 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 1 0 0 0 0 0 0 1 1 1 0 0

GPIOC_AFRL.  RW   $40020820
3|3|2|2|2|2|2|2|2|2|2|2|1|1|1|1|1|1|1|1|1|1|
1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0
0 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 1 0 0 0 0 0 1 0 0 0 0 0

GPIOC_AFRH.  RW   $40020824
3|3|2|2|2|2|2|2|2|2|2|2|1|1|1|1|1|1|1|1|1|1|
1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0
0 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 1 0 0 0 0 0 1 0 0 1 0 0
 ok.

 
The following users thanked this post: iMo

Offline techman-001

  • Frequent Contributor
  • **
  • !
  • Posts: 748
  • Country: au
  • Electronics technician for the last 50 years
    • Mecrisp Stellaris Unofficial UserDoc
Re: Lightweight Scripting Language for MCUs
« Reply #43 on: March 23, 2021, 01:34:34 pm »
And these are all you need to see to know that this F407 Disco is running at 168 MHz.

Code: [Select]
RCC_CR.
RCC_CR.   $40023800
3|3|2|2|2|2|2|2|2|2|2|2|1|1|1|1|1|1|1|1|1|1|
1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0
0 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 1 1 1 0 0 0 0 0 0 0 0 0 0 0
 ok.
RCC_PLLCFGR.
RCC_PLLCFGR.  RW   $40023804
3|3|2|2|2|2|2|2|2|2|2|2|1|1|1|1|1|1|1|1|1|1|
1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0
0 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 1 1 1 0 0 0 0 0 0 0 0 1 0 0
 ok.
RCC_CFGR.
RCC_CFGR.   $40023808
3|3|2|2|2|2|2|2|2|2|2|2|1|1|1|1|1|1|1|1|1|1|
1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0
0 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 1 1 1 0 0 0 0 0 0 0 1 0 0 0
 ok.
FLASH_ACR.
FLASH_ACR.   $40023C00
3|3|2|2|2|2|2|2|2|2|2|2|1|1|1|1|1|1|1|1|1|1|
1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0
0 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 1 1 1 1 0 0 0 0 0 0 0 0 0 0
 

Offline iMo

  • Super Contributor
  • ***
  • Posts: 4896
  • Country: vc
Re: Lightweight Scripting Language for MCUs
« Reply #44 on: March 23, 2021, 01:46:47 pm »
What is important to say is the user only writes
Code: [Select]
RCC_CR.
RCC_PLLCFGR.
RCC_CFGR.

as the command in the terminal.. :)
 

Offline gnuarm

  • Super Contributor
  • ***
  • Posts: 2247
  • Country: pr
Re: Lightweight Scripting Language for MCUs
« Reply #45 on: March 23, 2021, 02:59:04 pm »
In order to write a celestial navigation app all you would need is a mechanical teletype worst case.. Would be better if you got a PC which can do copy/paste and work with .txt files, however  :-DD

What do you have against paper tape?  I would say I had a long history with fond memories of using paper tape, but it is exactly the opposite.  I used it for a short while only because it sucked so badly as soon as I could afford them I bought two 8 inch floppy disk drives which I never did a lot with because they sucked so badly.  The OS would allocate half the remaining disk space for each file opened, so if you wanted a .obj, a .lst and another file output from an assembly pass, the third file opened only got 1/8th of the remaining disk space and often the process would crap out when the file filled up.  At least that never happened with the paper tape punch.  lol

Now from one room in the house I tap into a target board hanging off a raspberry pi in another room and download source code to the target to run tests.  What a Long Strange Trip It's Been. 
Rick C.  --  Puerto Rico is not a country... It's part of the USA
  - Get 1,000 miles of free Supercharging
  - Tesla referral code - https://ts.la/richard11209
 
The following users thanked this post: newbrain

Offline tggzzz

  • Super Contributor
  • ***
  • Posts: 20027
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: Lightweight Scripting Language for MCUs
« Reply #46 on: March 23, 2021, 03:12:05 pm »
What do you have against paper tape?  I would say I had a long history with fond memories of using paper tape, but it is exactly the opposite. 

I started using 5-channel paper tape in 5cps teleprinters. Grim - especially flipping between figure-shift and number-shift. Modern devices have returned to those wretched keyboards :(

Mind you, it was fun watching a 1000cps paper tape reader spew the tape 2m horizontally into a big basket - and stop instantly. Paper cuts? What are they?
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 
The following users thanked this post: iMo

Offline phil from seattle

  • Super Contributor
  • ***
  • Posts: 1029
  • Country: us
Re: Lightweight Scripting Language for MCUs
« Reply #47 on: March 23, 2021, 03:18:58 pm »
Here we go again.  I had to key in the bootloader for a PDP 11/40 backwards in the snow. so there.
 
The following users thanked this post: nctnico, mycroft, elecdonia, iMo

Offline tggzzz

  • Super Contributor
  • ***
  • Posts: 20027
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: Lightweight Scripting Language for MCUs
« Reply #48 on: March 23, 2021, 03:34:59 pm »
Bootloader? You mean it wasn't already in the core memory when power was reapplied?
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline phil from seattle

  • Super Contributor
  • ***
  • Posts: 1029
  • Country: us
Re: Lightweight Scripting Language for MCUs
« Reply #49 on: March 23, 2021, 04:41:47 pm »
Bootloader? You mean it wasn't already in the core memory when power was reapplied?

No, the Space Sciences department across the street had a prototype doppler weather radar that regularly corrupted the core memory.
« Last Edit: March 23, 2021, 04:43:39 pm by phil from seattle »
 

Offline gnuarm

  • Super Contributor
  • ***
  • Posts: 2247
  • Country: pr
Re: Lightweight Scripting Language for MCUs
« Reply #50 on: March 23, 2021, 05:24:26 pm »
Bootloader? You mean it wasn't already in the core memory when power was reapplied?

No, the Space Sciences department across the street had a prototype doppler weather radar that regularly corrupted the core memory.

Those durn pesky EMC requirements!!!
Rick C.  --  Puerto Rico is not a country... It's part of the USA
  - Get 1,000 miles of free Supercharging
  - Tesla referral code - https://ts.la/richard11209
 

Offline techman-001

  • Frequent Contributor
  • **
  • !
  • Posts: 748
  • Country: au
  • Electronics technician for the last 50 years
    • Mecrisp Stellaris Unofficial UserDoc
Re: Lightweight Scripting Language for MCUs
« Reply #51 on: March 23, 2021, 08:59:41 pm »
What is important to say is the user only writes
Code: [Select]
RCC_CR.
RCC_PLLCFGR.
RCC_CFGR.

as the command in the terminal.. :)

Sure, that's one way to do it but I rarely type in anything at the terminal. I might type in "rcc." to get a instant upload of the registers as they are *right now* but I do almost everything in my editor.

Many people here think that one types on some old serial terminal and waits for Forth to reply via a slow UART like C users do with printf debugging.

The reality is that Forth often leads with new things that other systems don't have. Some very smart Forth people are always experimenting with new concepts and pushing the boundaries.

For instance my 'terminal' has no USART component because it works over SWD with full flow control, via USB. It's so fast that I can dump the (pretty printed, formatted) contents of registers as seen in my previous post to my screen in a few microseconds.

You can have the same thing with C if you buy an expensive Segger, but all I need is a STM32 Disco or Nucleo board for the SWD/USB dongle.

I type the Forth source code I want run (in the target MCU) in my editor and when I hit the 'make' button in the editor toolbar, the source is uploaded to the mcu faster than I can see on the SWD terminal screen. Because it's too fast to see we have had to add a terminal beep for warnings and an automatic upload abort for errors.

We want it even faster and are working on a SPI terminal atm plus a bunch of other exciting development aids, such as using an external 16MB SPI flash to store Forth development aids for use with smaller Cortex-M0 devices with only 64KB flash.

These aids might be the entire SVD2FORTH peripheral register pretty print Words, the entire Bitfield Words, ascii pictures of pinouts etc. If we wanted to leave the $2.50 SPI memory chip with the device, we could include schematics and diagnostic flowcharts for the tech servicing it a decade later.

We have already adapted to the new paradigm of MCU's with no internal flash such as the RP2040 where we now store multiple dictionaries in the external QSPI flash.  Mecrisp-Pico Forth was released on 23 Feb 2021, only a month after the RP2040 Pico itself was released for sale. This included the time it took to actually buy Pico devices for development.

In this 'golden age of embedded' where MCU's have never been cheaper, faster, or more featureful, Forth is flourishing.
 

Offline alexanderbrevig

  • Frequent Contributor
  • **
  • Posts: 700
  • Country: no
  • Musician, developer and EE hobbyist
    • alexanderbrevig.com
Re: Lightweight Scripting Language for MCUs
« Reply #52 on: March 24, 2021, 06:36:51 am »
In case it is interesting to some of you, I've made my own small interpreted language that I use from time to time to have a flexible in system debugging and exploration.

It is a work in progress thing, for my personal use. But PRs are welcome if you find this interesting  :-+

https://github.com/AlexanderBrevig/yalex
https://github.com/AlexanderBrevig/yalexide <- the editor/playground for prototyping scripts for larger projects.

There's an example that works on the Arduino Uno (as a proof of concept for small 8bitters) but I tend to use it on larger projects on larger  μCUs (ARM and PIC32 in my case).
 
The following users thanked this post: iMo

Offline iMo

  • Super Contributor
  • ***
  • Posts: 4896
  • Country: vc
Re: Lightweight Scripting Language for MCUs
« Reply #53 on: March 24, 2021, 07:07:12 am »
In order to write a celestial navigation app all you would need is a mechanical teletype worst case.. Would be better if you got a PC which can do copy/paste and work with .txt files, however  :-DD

What do you have against paper tape?  ..
Linux and teletype.. https://hackaday.com/tag/teletype/
 

Offline techman-001

  • Frequent Contributor
  • **
  • !
  • Posts: 748
  • Country: au
  • Electronics technician for the last 50 years
    • Mecrisp Stellaris Unofficial UserDoc
Re: Lightweight Scripting Language for MCUs
« Reply #54 on: March 24, 2021, 07:17:20 am »
In order to write a celestial navigation app all you would need is a mechanical teletype worst case.. Would be better if you got a PC which can do copy/paste and work with .txt files, however  :-DD

What do you have against paper tape? 

Other than the High Speed Paper Tape reader sometimes shooting (a box full of) paper tape across the room like a massive streamer, and having to clean it up, check for tears in the tape etc ?
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14897
  • Country: fr
Re: Lightweight Scripting Language for MCUs
« Reply #55 on: March 24, 2021, 04:53:26 pm »
In case it is interesting to some of you, I've made my own small interpreted language that I use from time to time to have a flexible in system debugging and exploration.

It is a work in progress thing, for my personal use. But PRs are welcome if you find this interesting  :-+

https://github.com/AlexanderBrevig/yalex
https://github.com/AlexanderBrevig/yalexide <- the editor/playground for prototyping scripts for larger projects.

There's an example that works on the Arduino Uno (as a proof of concept for small 8bitters) but I tend to use it on larger projects on larger  μCUs (ARM and PIC32 in my case).

At first sight, it kind of looks like a cross between Lisp and Forth.
 
The following users thanked this post: alexanderbrevig

Offline abyrvalg

  • Frequent Contributor
  • **
  • Posts: 825
  • Country: es
Re: Lightweight Scripting Language for MCUs
« Reply #56 on: March 25, 2021, 11:28:46 am »
Recently I've done something similar to OP's question (scripted/interactive fiddling with STM32 peripherals) without running any MCU code at all, accessing memory-mapped registers over SWD instead.
A simple Python wrapper over pylink (Segger J-Link Python lib) halts the CPU at start and provides low level functions like read32(addr). Higher level classes with reg name properties provide things like stm.GPIOE.BSRR = val. All that with a comfort of a full PC Python (IDE, highlighting, autocomplete etc. At the end I even wrote a simple hw tester GUI polling & displaying ADC values as bars and toggling GPIOs with buttons).
Actually, this approach could be combined with some init code running on the MCU (i.e. use HAL to do complex init, then enter an endless loop and let the PC side continue the job).
 

Offline elecdonia

  • Frequent Contributor
  • **
  • Posts: 399
  • Country: us
Re: Lightweight Scripting Language for MCUs
« Reply #57 on: April 03, 2023, 03:07:06 pm »
Bootloader? You mean it wasn't already in the core memory when power was reapplied?
In the late 1970’s I purchased a heavily used and abused Data General NOVA system where the core memory had burned up (literally). The previous owner replaced it with (then new-fangled) dynamic RAM. No data retained during power off. I manually entered the NOVA bootloader thousands of times from the dreaded row of 16 toggle switches. Fortunately the entire bootloader was something like 28 words in length. And yes, its program input format was paper tape (8 level).
« Last Edit: April 03, 2023, 03:10:31 pm by elecdonia »
I’m learning to be a leading-edge designer of trailing-edge technology.
 

Online coppice

  • Super Contributor
  • ***
  • Posts: 8942
  • Country: gb
Re: Lightweight Scripting Language for MCUs
« Reply #58 on: April 03, 2023, 03:56:09 pm »
Bootloader? You mean it wasn't already in the core memory when power was reapplied?
In the late 1970’s I purchased a heavily used and abused Data General NOVA system where the core memory had burned up (literally). The previous owner replaced it with (then new-fangled) dynamic RAM. No data retained during power off. I manually entered the NOVA bootloader thousands of times from the dreaded row of 16 toggle switches. Fortunately the entire bootloader was something like 28 words in length. And yes, its program input format was paper tape (8 level).
I entered the bootloader on a Nova with core memory quite a few times. Bugs meant it corrupted with annoying frequency, and when it had changed the whole thing was usually scrambled. I used other mini-computers where I had to re-enter the boodloader from time to time, but in most case only a few locations needed correcting. With the Nova and a Perkin Elmer machine it always seemed to need the whole thing re-entered. Its quite a tedious thing to do, but if you do it often enough you get reasonably quick.
 

Offline JoeyG

  • Regular Contributor
  • *
  • Posts: 122
  • Country: au
Re: Lightweight Scripting Language for MCUs
« Reply #59 on: July 31, 2023, 09:49:22 am »
+1 mmbasic
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 4220
  • Country: nz
Re: Lightweight Scripting Language for MCUs
« Reply #60 on: July 31, 2023, 10:17:32 am »
In case it is interesting to some of you, I've made my own small interpreted language that I use from time to time to have a flexible in system debugging and exploration.

It is a work in progress thing, for my personal use. But PRs are welcome if you find this interesting  :-+

https://github.com/AlexanderBrevig/yalex
https://github.com/AlexanderBrevig/yalexide <- the editor/playground for prototyping scripts for larger projects.

There's an example that works on the Arduino Uno (as a proof of concept for small 8bitters) but I tend to use it on larger projects on larger  μCUs (ARM and PIC32 in my case).

At first sight, it kind of looks like a cross between Lisp and Forth.

Close to PostScript and Logo ("forward Polish") too.

Could use anonymous blocks for if/else and loops
 

Offline member_xyz

  • Contributor
  • Posts: 47
  • Country: au
Re: Lightweight Scripting Language for MCUs
« Reply #61 on: July 31, 2023, 01:09:42 pm »
https://cicciocb.com/annex32help/V1.482/

Basic with lot of built in functions and drivers
 

Offline SpacedCowboy

  • Frequent Contributor
  • **
  • Posts: 292
  • Country: gb
  • Aging physicist
Re: Lightweight Scripting Language for MCUs
« Reply #62 on: July 31, 2023, 03:31:29 pm »
I had a large hardware project (that you now all know about, but has yet to be officially released). Back in the prototype days, it existed on a bunch of largest-on-the-planet FPGAs all wired up with optic interconnect, and we had a Zynq as the boot-controller.

I wrote the firmware for all this, and chose Lua as the scripting language - basically wrote an OS around Lua rather than unix's /bin/sh. I implemented a virtual filesystem interface (flash for permanent storage, Ramdisk mounted as /tmp), so we could store data between runs, and it even ran a boot sequence (looked in /etc/rc.d for scripts prefixed by a number and ran them in numerical order). That handled bringup because all the things we needed to control were bound to objects in the Lua domain, so could be scripted. Lua provided the control structures that let you write useful scripts ("read the value of this register on that i2c device on the specified bus, is it X, then do Y else do Z").

Using the system interactively, there was a Lua shell interface that talked over thunderbolt (via a custom PCIe kernel extension) to a connected Mac, and since all the hardware was bound to objects in the Lua shell people using it didn't have to get me to redo some firmware when they wanted to fiddle with something, they just used the shell to either change things interactively, or rewrite the file in /etc/rc.d and reboot the device if it was a "boot up" stage thing they wanted to change.

I had some fun with this project, even implemented stdio redirection, so you could run a command on the device, and have the output appear on the Mac - or vice versa - which turned out to be really useful for long runs of data collection and interactive monitoring (drawing a graph on a monitor on the wall) over time.

Lua was pretty much perfect for this. Expressive enough to make it a useful language to have around, and completely trivial to bind hardware to objects so the hardware could be easily interacted with. 10/10 would (and did) use again.
« Last Edit: July 31, 2023, 03:34:12 pm by SpacedCowboy »
 

Offline ag123

  • Contributor
  • Posts: 39
  • Country: 00
Re: Lightweight Scripting Language for MCUs
« Reply #63 on: August 01, 2023, 06:56:58 am »
not really scripting, but do anyone mess with Rust
https://blog.mbedded.ninja/programming/languages/rust/running-rust-on-microcontrollers/

and found it any 'better' than C/C++?
 

Offline audiotubes

  • Regular Contributor
  • *
  • Posts: 176
  • Country: cz
Re: Lightweight Scripting Language for MCUs
« Reply #64 on: August 02, 2023, 01:20:37 am »

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

The RPN models have a 4 level stack. The RPL models (HP 48/49/50, maybe others) have an infinite stack and all the stack manipulation words anybody could ever want.
I have taken apart more gear than many people. But I have put less gear back together than most people. So there is still room for improvement.
 

Offline gnuarm

  • Super Contributor
  • ***
  • Posts: 2247
  • Country: pr
Re: Lightweight Scripting Language for MCUs
« Reply #65 on: August 02, 2023, 03:41:52 am »

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

The RPN models have a 4 level stack. The RPL models (HP 48/49/50, maybe others) have an infinite stack and all the stack manipulation words anybody could ever want.

Oh, like Forth?  Cool. 
Rick C.  --  Puerto Rico is not a country... It's part of the USA
  - Get 1,000 miles of free Supercharging
  - Tesla referral code - https://ts.la/richard11209
 

Offline thermistor-guy

  • Frequent Contributor
  • **
  • Posts: 383
  • Country: au
Re: Lightweight Scripting Language for MCUs
« Reply #66 on: August 02, 2023, 04:54:54 am »
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.
...
For controlling my test instruments and acquiring data, I run GNU awk scripts on an rpi3. Some of these tests can take a week, so it's useful to have
an rpi dedicated to that purpose.

Gawk is useful too for processing the raw data.

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

In my setup, the approach I would take is to convert the target board (with sensors) into a test instrument, by giving it
a minimal SCPI-like command set. Then control the target board from an rpi that runs the scripts (Gawk, Perl, Forth, ...).

In cases involving  large amounts of data, the rpi saves it to a NAS with redundant drives.
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 4220
  • Country: nz
Re: Lightweight Scripting Language for MCUs
« Reply #67 on: August 02, 2023, 06:09:37 am »

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

The RPN models have a 4 level stack. The RPL models (HP 48/49/50, maybe others) have an infinite stack and all the stack manipulation words anybody could ever want.

My earlier HP28s has stack limited only by the 32 KB of RAM.

The HP-41C from 1979 (and CV and finally CX in 1983) were the last flagship HP calculators to have a 4-level stack, though it was alphanumeric and could hold (short) strings.


Note that the INMOS Transputer microprocessor had a three level stack.
 

Offline audiotubes

  • Regular Contributor
  • *
  • Posts: 176
  • Country: cz
Re: Lightweight Scripting Language for MCUs
« Reply #68 on: August 02, 2023, 06:58:37 am »
You're right that the later RPN models were not flagships but they had no shortage of features, just that the build quality started to go downhill. But the 41 also did not have the build quality of the HP 67 and the models which came before the HP 41, although the 41 the first HP calc with and LCD display (which by the way, we did not trust at the time!)

The HP 15C is RPN, has flagship status (at least in recent years) and has had 2 special editions come out, the last one this year.

The 35s introduced in 2007 has a 4 level stack and there are other "new" models that also have RPN (4 level stack) at least as an option (30b, etc.) There are some RPN models still in production.

Rather than dates and flagship/not flagship, it's useful to distinguish between RPN and RPL variants. The RPN variants have a 4 level stack, RPL variants have an infinite stack.

Anyway, here's a piece of code I wrote to convert roman numerals to real numbers (useful for dates on those Goldwyn Meyer movies). Yes, RPL is very similar to FORTH but also with some interesting differences.

One major problem is that there isn't any way to keep comments in the code and you probably wouldn't be able to stand keying them in anyway on a calculator keyboard. There are 3rd party tools, but the standard setup is that everything is device-hosted. They have built in kermit servers so I usually try to kermit a copy of my code to a PC and then annotate the file. Not a great workflow, but good enough for smallish projects.

Code: [Select]
@
@ R->A2 (second version)
@ Converts roman numerals to real value
@ Roman numeral input can be single or double-quoted
@ ( roman numeral string --> real value )
@
%%HP: T(3)A(R)F(.);
\<< "" + RCLF SWAP { }
SWAP 1 CF
  WHILE DUP SIZE 0. > REPEAT
     DUP HEAD
     CASE
        DUP "M" == THEN 1000. END
        DUP "D" == THEN  500. END
        DUP "C" == THEN  100. END
        DUP "L" == THEN   50. END
        DUP "X" == THEN   10. END
        DUP "V" == THEN    5. END
        DUP "I" == THEN    1. END
        # 202h DOERR
     END
     SWAP DROP ROT SWAP +
     IF 1 FS? THEN
        DUP SIZE 1 - GETI ROT ROT GETI SWAP DROP ROT DUP2
        IF > THEN
           NEG SWAP DROP SWAP DUP SIZE 1 - ROT PUT
           1 CF
        ELSE
           DROP2
        END
     ELSE
        1 SF
    END
    SWAP TAIL
  END
  DROP DUP SIZE 1
  IF == THEN
     1 GET
  ELSE
     \GSLIST
  END
  SWAP STOF
\>>
« Last Edit: August 02, 2023, 07:39:42 am by audiotubes »
I have taken apart more gear than many people. But I have put less gear back together than most people. So there is still room for improvement.
 

Offline DiTBho

  • Super Contributor
  • ***
  • Posts: 4019
  • Country: gb
Re: Lightweight Scripting Language for MCUs
« Reply #69 on: August 02, 2023, 08:52:17 am »
I had a large hardware project (that you now all know about, but has yet to be officially released). Back in the prototype days, it existed on a bunch of largest-on-the-planet FPGAs all wired up with optic interconnect, and we had a Zynq as the boot-controller.

I wrote the firmware for all this, and chose Lua as the scripting language - basically wrote an OS around Lua rather than unix's /bin/sh. I implemented a virtual filesystem interface (flash for permanent storage, Ramdisk mounted as /tmp), so we could store data between runs, and it even ran a boot sequence (looked in /etc/rc.d for scripts prefixed by a number and ran them in numerical order). That handled bringup because all the things we needed to control were bound to objects in the Lua domain, so could be scripted. Lua provided the control structures that let you write useful scripts ("read the value of this register on that i2c device on the specified bus, is it X, then do Y else do Z").

Using the system interactively, there was a Lua shell interface that talked over thunderbolt (via a custom PCIe kernel extension) to a connected Mac, and since all the hardware was bound to objects in the Lua shell people using it didn't have to get me to redo some firmware when they wanted to fiddle with something, they just used the shell to either change things interactively, or rewrite the file in /etc/rc.d and reboot the device if it was a "boot up" stage thing they wanted to change.

I had some fun with this project, even implemented stdio redirection, so you could run a command on the device, and have the output appear on the Mac - or vice versa - which turned out to be really useful for long runs of data collection and interactive monitoring (drawing a graph on a monitor on the wall) over time.

Lua was pretty much perfect for this. Expressive enough to make it a useful language to have around, and completely trivial to bind hardware to objects so the hardware could be easily interacted with. 10/10 would (and did) use again.

this post should belong to the thread where I asked "with what?" can I replace Bash scripting :D
The opposite of courage is not cowardice, it is conformity. Even a dead fish can go with the flow
 

Offline DiTBho

  • Super Contributor
  • ***
  • Posts: 4019
  • Country: gb
Re: Lightweight Scripting Language for MCUs
« Reply #70 on: August 02, 2023, 09:03:49 am »
yalex

don't take personal, but this stuff is exactly what I do find good motivation when you are a student and need to open your mind by experimenting with different things, and awful when you become a pro and need to develop, debug and maintain that stuff, even because usually no one in your co-workers is willing to get their hands on it.

The opposite of courage is not cowardice, it is conformity. Even a dead fish can go with the flow
 

Offline audiotubes

  • Regular Contributor
  • *
  • Posts: 176
  • Country: cz
Re: Lightweight Scripting Language for MCUs
« Reply #71 on: August 02, 2023, 01:42:46 pm »
this post should belong to the thread where I asked "with what?" can I replace Bash scripting :D

I use SNOBOL4 for that, but I realize that may raise some eyebrows :P
I have taken apart more gear than many people. But I have put less gear back together than most people. So there is still room for improvement.
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 4220
  • Country: nz
Re: Lightweight Scripting Language for MCUs
« Reply #72 on: August 02, 2023, 01:54:01 pm »
this post should belong to the thread where I asked "with what?" can I replace Bash scripting :D

I use SNOBOL4 for that, but I realize that may raise some eyebrows :P

Markov algorithms ftw.
 

Offline SpacedCowboy

  • Frequent Contributor
  • **
  • Posts: 292
  • Country: gb
  • Aging physicist
Re: Lightweight Scripting Language for MCUs
« Reply #73 on: August 02, 2023, 05:09:01 pm »
this post should belong to the thread where I asked "with what?" can I replace Bash scripting :D

You're right :)

I just read that thread (hadn't seen it before) and for a custom-everything OS, Lua was pretty much perfect for the startup sequence, and came with the added bonus of making all the interactive use a snap, because I'd already done all the work of binding the I2C, SPI, DMA etc to objects within the Lua environment. Writing a shell around this was trivial.

I can't say I'd forgo bash on a real system, but to do it on a bare-bones minimal system, it really worked well.
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 27366
  • Country: nl
    • NCT Developments
Re: Lightweight Scripting Language for MCUs
« Reply #74 on: August 02, 2023, 06:57:30 pm »
So far I have used both Micropython and Lua to implement high-level logic in embedded software.

The main problem I found with Micropython is that it is an all-or-nothing approach. With a bit of hacking I have succesfully integrated Micropython into a C project that uses FreeRtos but the fact Micropython uses Python scripts to pre-process strings make the whole build setup less than perfect (calling external, modified Micropython make files to make it all work). Also creating my own Python modules isn't as straightforward as I would like.

I'm also moving ahead with Lua for use on microcontrollers. I'm working on a fork that can be used in an OS-less round robin style scheduler. The big advantage is that I can basically copy all the Lua stuff into a C project, set the include directories and it will compile just fine. I second SpacedCowboy's opinion that Lua is easy to integrate into C/C++ programs to add scripting functionality.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 
The following users thanked this post: DiTBho

Offline helius

  • Super Contributor
  • ***
  • Posts: 3659
  • Country: us
Re: Lightweight Scripting Language for MCUs
« Reply #75 on: August 02, 2023, 08:45:20 pm »
Yes, RPL is very similar to FORTH but also with some interesting differences.
RPL is dynamically typed, and knows the type of every object. Forth is untyped, and doesn't know the type of any object. That is such a large difference that the claimed similarity seems overstated.

RPL also is able to assign (and remember) a label attached to any object, as well as units for number objects. Not many other languages have that capability (I believe one might be Clojure?)

The absence of comments in stored programs is expected, based on the fact that the programs are stored in parsed form (as opposed to ASCII text). This is a problem that also arose in Lisp 1.5 and INTERLISP, and the approach there was to use a (COMMENT ...) form that was defined to do nothing. Since RPL is postfix, there is no simple way to achieve that, although you could simply write "Comment..." DROP to nullify the stack effect of the comment.
 

Offline audiotubes

  • Regular Contributor
  • *
  • Posts: 176
  • Country: cz
Re: Lightweight Scripting Language for MCUs
« Reply #76 on: August 02, 2023, 10:17:24 pm »
They're very similar in that they both use a stack-based paradigm, and that code is written by building up solutions from (ideally small) words that perform a specific function.
I have taken apart more gear than many people. But I have put less gear back together than most people. So there is still room for improvement.
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 4220
  • Country: nz
Re: Lightweight Scripting Language for MCUs
« Reply #77 on: August 02, 2023, 10:59:56 pm »
The absence of comments in stored programs is expected, based on the fact that the programs are stored in parsed form (as opposed to ASCII text). This is a problem that also arose in Lisp 1.5 and INTERLISP, and the approach there was to use a (COMMENT ...) form that was defined to do nothing. Since RPL is postfix, there is no simple way to achieve that, although you could simply write "Comment..." DROP to nullify the stack effect of the comment.

But isn't that *precisely* a simple way to do exactly the same thing?

Or do ...

Code: [Select]
« DROP » → COMMENT «
  "get qty" COMMENT
  "Qty:" PROMPT
  "get unit price" COMMENT
  "Price:" PROMPT
  "display total" COMMENT
  → Q P « "Total " Q P * →STR + MSGBOX »
»

... and be happy.
 

Offline helius

  • Super Contributor
  • ***
  • Posts: 3659
  • Country: us
Re: Lightweight Scripting Language for MCUs
« Reply #78 on: August 03, 2023, 01:54:22 am »
It certainly has the same effect. But (unlike program syntax), comments' only purpose is to be read by humans, and the postfix construction is not easy to read. Even Forth uses parenthesized comments, set off before and after by easily identified brackets.

I should clarify that the INTERLISP style of comment is no longer used in Lisp code since around 40 years ago. It was a kludge based on the problem of programs being stored and edited in a parsed form, which was abandoned as the Common Lisp standard displaced older dialects.
 

Offline gnuarm

  • Super Contributor
  • ***
  • Posts: 2247
  • Country: pr
Re: Lightweight Scripting Language for MCUs
« Reply #79 on: August 03, 2023, 03:50:37 am »
It certainly has the same effect. But (unlike program syntax), comments' only purpose is to be read by humans, and the postfix construction is not easy to read. Even Forth uses parenthesized comments, set off before and after by easily identified brackets.

In Forth, it's much more common to denote comments by a backslash, with the comment ending at EOL

\ On test failure, set output frequency
: Test20kHz ( -- )  20000 GetAmpMeas . ;
CR .( Done loading Test20kHz)

The last line was part of the debugging code I added to isolate a problem.

It's not postfix that is hard to read, it is poorly written programs in any form that are hard to read.   One thing that is important in Forth, which is not so important in other languages, is to write code that is clear and simple.  Other languages allow, or even promote poor program design.
Rick C.  --  Puerto Rico is not a country... It's part of the USA
  - Get 1,000 miles of free Supercharging
  - Tesla referral code - https://ts.la/richard11209
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 4220
  • Country: nz
Re: Lightweight Scripting Language for MCUs
« Reply #80 on: August 03, 2023, 06:26:30 am »
comments' only purpose is to be read by humans, and the postfix construction is not easy to read.

I would never dream of saying such a thing!! I've used postfix languages a lot (mostly PostScript). But ok ....

 

Offline Smokey

  • Super Contributor
  • ***
  • Posts: 2696
  • Country: us
  • Not An Expert
Re: Lightweight Scripting Language for MCUs
« Reply #81 on: May 16, 2024, 09:10:15 pm »
What is the state of things with embedded systems scripting in 2024?

My requirements are actually pretty minimal.  I have a fully functional ESP32 system (ESP-IDF, so FreeRTOS and all that) to which I want to embed a user scripting engine so the user can make their own simple LED animations.  It needs to be setup so they don't need to externally compile and flash anything (which they don't actually have access to do anyway).  Anyone know of something that would solve that problem?
« Last Edit: May 16, 2024, 09:13:13 pm by Smokey »
 

Offline tggzzz

  • Super Contributor
  • ***
  • Posts: 20027
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: Lightweight Scripting Language for MCUs
« Reply #82 on: May 16, 2024, 09:17:12 pm »
What is the state of things with embedded systems scripting in 2024?

My requirements are actually pretty minimal.  I have a fully functional ESP32 system (ESP-IDF, so FreeRTOS and all that) to which I want to embed a user scripting engine so the user can make their own simple LED animations.  It needs to be setup so they don't need to externally compile and flash anything (which they don't actually have access to do anyway).  Anyone know of something that would solve that problem?

Forth.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 27366
  • Country: nl
    • NCT Developments
Re: Lightweight Scripting Language for MCUs
« Reply #83 on: May 16, 2024, 09:24:41 pm »
What is the state of things with embedded systems scripting in 2024?

My requirements are actually pretty minimal.  I have a fully functional ESP32 system (ESP-IDF, so FreeRTOS and all that) to which I want to embed a user scripting engine so the user can make their own simple LED animations.  It needs to be setup so they don't need to externally compile and flash anything (which they don't actually have access to do anyway).  Anyone know of something that would solve that problem?
I've used Micropython for a similar situation. Embedded Lua (emblua, not eLua!) could be more suitable though as this is easier to integrate but in my case the customer insisted on using Python. Micropython needed a bit of hacking to integrate it into a C based ESP32 project and use the flash filesystem to read/store a script. The ESP32 IDF environment offers a Posix file I/O layer so Micropython has to be told it runs on a Unix system but still use a defined heap space.
« Last Edit: May 16, 2024, 09:37:19 pm by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14897
  • Country: fr
Re: Lightweight Scripting Language for MCUs
« Reply #84 on: May 16, 2024, 09:58:57 pm »
Forth and Lua. Could also be a minimal, ad hoc scripting "language" if neither of the existing solutions are small enough to fit in said MCU.
The "MCU" is a hard requirement here.
What you can fit in a ESP32, or otherwise some other similar MCU with (relatively) a lot of Flash memory and RAM, is one thing, what would fit in a MCU with a lot less memory available is another entirely.
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 27366
  • Country: nl
    • NCT Developments
Re: Lightweight Scripting Language for MCUs
« Reply #85 on: May 16, 2024, 10:20:00 pm »
Forth and Lua. Could also be a minimal, ad hoc scripting "language" if neither of the existing solutions are small enough to fit in said MCU.
The "MCU" is a hard requirement here.
What you can fit in a ESP32, or otherwise some other similar MCU with (relatively) a lot of Flash memory and RAM, is one thing, what would fit in a MCU with a lot less memory available is another entirely.
For embLua you mostly need flash. Like 128kB to be on the safe side. A simple Lua script needs a few kB of RAM at most. IIRC I have done tests using an LPC1225 which has 8kB of RAM. For Micropython 32kB of RAM is a good start.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline Smokey

  • Super Contributor
  • ***
  • Posts: 2696
  • Country: us
  • Not An Expert
Re: Lightweight Scripting Language for MCUs
« Reply #86 on: May 16, 2024, 11:02:04 pm »
https://github.com/szieke/embLua

Quote
embLua requirements
To run scripts which do something 'meaningful' embLua needs:

RAM: 1k Stack, 11k Heap
ROM (not optimized code): 120 on MSP430, 90k on Renesas
C-Library
 

Offline Picuino

  • Super Contributor
  • ***
  • Posts: 1020
  • Country: es
    • Picuino web
Re: Lightweight Scripting Language for MCUs
« Reply #87 on: May 17, 2024, 08:01:41 am »
EDIT:
Has anything been said about TCL yet?
Does anyone know it as a scripting language for microcontrollers?

https://wiki.tcl-lang.org/page/Small+Tcl
https://tinytcl.sourceforge.net/
« Last Edit: May 17, 2024, 08:06:27 am by Picuino »
 

Offline tellurium

  • Frequent Contributor
  • **
  • Posts: 267
  • Country: ua
Re: Lightweight Scripting Language for MCUs
« Reply #88 on: May 17, 2024, 08:29:30 am »
If the anticipated code is trivial, one can consider very, very stripped down Javascript:

https://github.com/cesanta/elk/

And yeah, TCL!
Another tiny implementation is here:
https://github.com/zserge/partcl (code)
https://zserge.com/posts/tcl-interpreter/ (article)
« Last Edit: May 17, 2024, 08:32:10 am by tellurium »
Open source embedded network library https://github.com/cesanta/mongoose
TCP/IP stack + TLS1.3 + HTTP/WebSocket/MQTT in a single file
 

Online coppice

  • Super Contributor
  • ***
  • Posts: 8942
  • Country: gb
Re: Lightweight Scripting Language for MCUs
« Reply #89 on: May 20, 2024, 06:12:22 pm »
EDIT:
Has anything been said about TCL yet?
Does anyone know it as a scripting language for microcontrollers?

https://wiki.tcl-lang.org/page/Small+Tcl
https://tinytcl.sourceforge.net/
I would avoid TCL, not because of anything inherently wrong with it, but because it has slumped from a prominent mainstream position to obscurity. Everything I know that is written in TCL is something old that is being maintained, but almost certainly wouldn't be started afresh in TCL. Its frequently hard to get people to put the effort into even simple maintenance of TCL code, which is often really sad. When a language gets in that state you aren't going to get much buy in from others. You are on your own.
 

Offline Smokey

  • Super Contributor
  • ***
  • Posts: 2696
  • Country: us
  • Not An Expert
Re: Lightweight Scripting Language for MCUs
« Reply #90 on: May 20, 2024, 06:51:51 pm »
It seems like embLua is a clear winner at this point (memory footprint, functionality, language complexity, etc), at least for embedding scripting into an already existing codebase like I need.  Am I wrong?
 

Online coppice

  • Super Contributor
  • ***
  • Posts: 8942
  • Country: gb
Re: Lightweight Scripting Language for MCUs
« Reply #91 on: May 20, 2024, 06:55:27 pm »
It seems like embLua is a clear winner at this point (memory footprint, functionality, language complexity, etc), at least for embedding scripting into an already existing codebase like I need.  Am I wrong?
A lot of people who use it stick with it, so it seems to be a solution that results in reasonable levels of contentment.
 

Offline ksjh

  • Contributor
  • Posts: 27
  • Country: de
Re: Lightweight Scripting Language for MCUs
« Reply #92 on: May 20, 2024, 07:26:49 pm »
A while ago, I was looking for compact ESP32-C3 boards on AliExpress and found some marked "LuatOS-Core", so I tried to find out more about those boards and stumbled upon https://wiki.luatos.org/ when trying to find the pinout of those boards. I did not try LuatOS at all or look at it in more detail, but I thought it could be useful for your project. There seem to be implementations for the ESP32-C3 and the ESP32-S3, source is available on gitee, I did not check the licensing.
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 27366
  • Country: nl
    • NCT Developments
Re: Lightweight Scripting Language for MCUs
« Reply #93 on: May 20, 2024, 07:41:45 pm »
A while ago, I was looking for compact ESP32-C3 boards on AliExpress and found some marked "LuatOS-Core", so I tried to find out more about those boards and stumbled upon https://wiki.luatos.org/ when trying to find the pinout of those boards. I did not try LuatOS at all or look at it in more detail, but I thought it could be useful for your project. There seem to be implementations for the ESP32-C3 and the ESP32-S3, source is available on gitee, I did not check the licensing.
The problem with Luatos is that it tries to provide a one-size-fits-all solution (like many other similar projects). These typically don't work. A better approach is to write the low level stuff in C and then use scripting for a implementing high-level logic only. This allows to implement a safety barrier between low level control stuff and the high level functionality.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 
The following users thanked this post: ksjh

Offline gnuarm

  • Super Contributor
  • ***
  • Posts: 2247
  • Country: pr
Re: Lightweight Scripting Language for MCUs
« Reply #94 on: May 20, 2024, 08:44:52 pm »
It seems like embLua is a clear winner at this point (memory footprint, functionality, language complexity, etc), at least for embedding scripting into an already existing codebase like I need.  Am I wrong?

Isn't the memory footprint of embLua rather large?  I've seen forth implementations that fit in a very few kB of flash (like ~4 kB) and around 256 B of RAM.  One advantage is that properly implemented, forth applications use very little program storage.   

Did I misunderstand the memory footprint of embLua?
Rick C.  --  Puerto Rico is not a country... It's part of the USA
  - Get 1,000 miles of free Supercharging
  - Tesla referral code - https://ts.la/richard11209
 

Offline Smokey

  • Super Contributor
  • ***
  • Posts: 2696
  • Country: us
  • Not An Expert
Re: Lightweight Scripting Language for MCUs
« Reply #95 on: May 20, 2024, 09:41:50 pm »
It seems like embLua is a clear winner at this point (memory footprint, functionality, language complexity, etc), at least for embedding scripting into an already existing codebase like I need.  Am I wrong?

Isn't the memory footprint of embLua rather large?  I've seen forth implementations that fit in a very few kB of flash (like ~4 kB) and around 256 B of RAM.  One advantage is that properly implemented, forth applications use very little program storage.   

Did I misunderstand the memory footprint of embLua?

12K RAM, 120K ROM is fine for an ESP32 I think.  If this was a smaller micro, I would probably need to reconsider.
Also the thing I definitely Don't Want is a scripting firmware that acts like an OS.  I already have my program which needs FreeRTOS because of the Wifi on the ESP32, so I don't want anything conflicting with that.
 

Offline gnuarm

  • Super Contributor
  • ***
  • Posts: 2247
  • Country: pr
Re: Lightweight Scripting Language for MCUs
« Reply #96 on: May 21, 2024, 12:00:39 am »
It seems like embLua is a clear winner at this point (memory footprint, functionality, language complexity, etc), at least for embedding scripting into an already existing codebase like I need.  Am I wrong?

Isn't the memory footprint of embLua rather large?  I've seen forth implementations that fit in a very few kB of flash (like ~4 kB) and around 256 B of RAM.  One advantage is that properly implemented, forth applications use very little program storage.   

Did I misunderstand the memory footprint of embLua?

12K RAM, 120K ROM is fine for an ESP32 I think.  If this was a smaller micro, I would probably need to reconsider.
Also the thing I definitely Don't Want is a scripting firmware that acts like an OS.  I already have my program which needs FreeRTOS because of the Wifi on the ESP32, so I don't want anything conflicting with that.

120 kB of flash is not what I call a small footprint.  I don't know what you mean by "acts like an OS".  Forth only does what you tell it to do.  It is very much like a scripting language, with either compiling code, or executing from a command line.  While there are forths which run on bare metal, these are less common on larger CPUs, and typically are programs under an OS.  However, forth can be the only code on a small MCU, which is why it can fit in only 4 kB of flash (what you call ROM).  There aren't many MCUs with ROM these days.
Rick C.  --  Puerto Rico is not a country... It's part of the USA
  - Get 1,000 miles of free Supercharging
  - Tesla referral code - https://ts.la/richard11209
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4240
  • Country: us
Re: Lightweight Scripting Language for MCUs
« Reply #97 on: May 21, 2024, 02:55:51 am »
I think the winner is probably some flavor of BASIC, but no one wants to admit it.  :-)

It doesn't help that there is so little cross-platform standardization of low-level primitives for BASICs.
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 4220
  • Country: nz
Re: Lightweight Scripting Language for MCUs
« Reply #98 on: May 21, 2024, 07:39:24 am »
I think the winner is probably some flavor of BASIC, but no one wants to admit it.  :-)

I really don't think so :-)

The only advantage simple BASIC has is the line numbers facilitate easy program editing when you don't have a real full-screen text editor. But the line numbers quickly become an impediment to program growth. And only global variables and IF/GOTO .. just ugh.

If you add control structures and functions with arguments and local variables and structs or dictionaries then you lose the few advantages BASIC started with and might as well use Lua or a TinyC or Python or Scheme etc.
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 27366
  • Country: nl
    • NCT Developments
Re: Lightweight Scripting Language for MCUs
« Reply #99 on: May 21, 2024, 08:52:57 am »
It seems like embLua is a clear winner at this point (memory footprint, functionality, language complexity, etc), at least for embedding scripting into an already existing codebase like I need.  Am I wrong?

Isn't the memory footprint of embLua rather large?  I've seen forth implementations that fit in a very few kB of flash (like ~4 kB) and around 256 B of RAM.  One advantage is that properly implemented, forth applications use very little program storage.   

Did I misunderstand the memory footprint of embLua?

12K RAM, 120K ROM is fine for an ESP32 I think.  If this was a smaller micro, I would probably need to reconsider.
Also the thing I definitely Don't Want is a scripting firmware that acts like an OS.  I already have my program which needs FreeRTOS because of the Wifi on the ESP32, so I don't want anything conflicting with that.

120 kB of flash is not what I call a small footprint.  I don't know what you mean by "acts like an OS".  Forth only does what you tell it to do.  It is very much like a scripting language, with either compiling code, or executing from a command line.  While there are forths which run on bare metal, these are less common on larger CPUs, and typically are programs under an OS.  However, forth can be the only code on a small MCU, which is why it can fit in only 4 kB of flash (what you call ROM).  There aren't many MCUs with ROM these days.
That is not a very fair comparison. The 90k to 120k for Lua includes: compiler to create bytecode, math, string, table support, bit-operations and various other features like key-value pairs. For math support, the floating point library is also linked in (which is included in the size). All in all you get a fairly complete package from embLua. Micropython is even better featured with things like filesystem support and modules to deal with JSON (for example).

'Act like an OS' means that the script language is the only way to get something done which is typically not what you want because it would require the script language libraries to also abstract ALL the peripherals on a microcontroller. The latter is where these attempts / projects typically go wrong as the number of platforms they support is just 2 or 3 out of thousands of different microcontrollers out there.
« Last Edit: May 21, 2024, 10:04:32 am by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline tellurium

  • Frequent Contributor
  • **
  • Posts: 267
  • Country: ua
Re: Lightweight Scripting Language for MCUs
« Reply #100 on: May 21, 2024, 09:27:31 am »
There are several ways of looking at the scripting language's role. I see at least two:

1. A complete development platform. Everything, including filesystem / networking / string processing like JSON - is developed using that language. A "host" firmware provides a very basic, minimal set of primitives to the VM (e.g. memory / registers access), and the VM does the rest. An example of such approach - micropython.

2. A simple engine that just allows to orchestrate things that is provided by the "host" firmware. The "host" firmware implements a very rich set of primitives (API) - filesystem, networking, strings, etc - and a VM just "imports" those, and provides an easy way to orchestrate the functionality. Like, "read sensor value every 10 seconds and report to MQTT" - a script just uses an imported timer API to register a timer, and inside that timer function, calls imported API to read sensor values,  and use another API to send values over MQTT formatted as JSON - again, using an imported API. An example of such approach - elk

Both approaches qualify as "scripting engines", but the expectations would differ quite a bit depending on the (1) or (2) assumptions.

There are blends that sit in between, I think embLua is an example of such a blend. Hence the prior comments about the comparison unfairness - which I'd agree on. The ground work (filesystem, networking, periperal access, string handling, etc etc) has to be done anyway - the only question is where that ground work is done: on the host or on the VM side, by the host/VM vendor or by the user.
« Last Edit: May 21, 2024, 09:40:48 am by tellurium »
Open source embedded network library https://github.com/cesanta/mongoose
TCP/IP stack + TLS1.3 + HTTP/WebSocket/MQTT in a single file
 

Offline gnuarm

  • Super Contributor
  • ***
  • Posts: 2247
  • Country: pr
Re: Lightweight Scripting Language for MCUs
« Reply #101 on: May 21, 2024, 11:06:24 am »
It seems like embLua is a clear winner at this point (memory footprint, functionality, language complexity, etc), at least for embedding scripting into an already existing codebase like I need.  Am I wrong?

Isn't the memory footprint of embLua rather large?  I've seen forth implementations that fit in a very few kB of flash (like ~4 kB) and around 256 B of RAM.  One advantage is that properly implemented, forth applications use very little program storage.   

Did I misunderstand the memory footprint of embLua?

12K RAM, 120K ROM is fine for an ESP32 I think.  If this was a smaller micro, I would probably need to reconsider.
Also the thing I definitely Don't Want is a scripting firmware that acts like an OS.  I already have my program which needs FreeRTOS because of the Wifi on the ESP32, so I don't want anything conflicting with that.

120 kB of flash is not what I call a small footprint.  I don't know what you mean by "acts like an OS".  Forth only does what you tell it to do.  It is very much like a scripting language, with either compiling code, or executing from a command line.  While there are forths which run on bare metal, these are less common on larger CPUs, and typically are programs under an OS.  However, forth can be the only code on a small MCU, which is why it can fit in only 4 kB of flash (what you call ROM).  There aren't many MCUs with ROM these days.
That is not a very fair comparison. The 90k to 120k for Lua includes: compiler to create bytecode, math, string, table support, bit-operations and various other features like key-value pairs. For math support, the floating point library is also linked in (which is included in the size). All in all you get a fairly complete package from embLua. Micropython is even better featured with things like filesystem support and modules to deal with JSON (for example).

Forth includes the "compiler", math and string support.  Of course, this is all configurable.  In 4 kB, it likely won't include much math support, but that should not be so large to add. 

When you talk about filesystem support, I thought you didn't want OS functionality.  Wouldn't that include the filesystem?


Quote
'Act like an OS' means that the script language is the only way to get something done which is typically not what you want because it would require the script language libraries to also abstract ALL the peripherals on a microcontroller. The latter is where these attempts / projects typically go wrong as the number of platforms they support is just 2 or 3 out of thousands of different microcontrollers out there.

Forth currently supports hundreds if not thousands of MCUs/CPUs.  Mecrisp is one that supports many variants of MSP430 chips along with many ARMs.  It is fairly easy to port.  If the ISA is the same as one you have, you only need to provide support for the UART and it is up and running.  As you say, peripheral support is needed, but that's not really what an OS is typically about in my experience.  Small MCU forths often run bare metal, while forths on larger MCUs/CPUs often run under an OS.  Small MCU forths are typically used over a serial port through a PC. 
Rick C.  --  Puerto Rico is not a country... It's part of the USA
  - Get 1,000 miles of free Supercharging
  - Tesla referral code - https://ts.la/richard11209
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 27366
  • Country: nl
    • NCT Developments
Re: Lightweight Scripting Language for MCUs
« Reply #102 on: May 21, 2024, 12:18:59 pm »
It seems like embLua is a clear winner at this point (memory footprint, functionality, language complexity, etc), at least for embedding scripting into an already existing codebase like I need.  Am I wrong?

Isn't the memory footprint of embLua rather large?  I've seen forth implementations that fit in a very few kB of flash (like ~4 kB) and around 256 B of RAM.  One advantage is that properly implemented, forth applications use very little program storage.   

Did I misunderstand the memory footprint of embLua?

12K RAM, 120K ROM is fine for an ESP32 I think.  If this was a smaller micro, I would probably need to reconsider.
Also the thing I definitely Don't Want is a scripting firmware that acts like an OS.  I already have my program which needs FreeRTOS because of the Wifi on the ESP32, so I don't want anything conflicting with that.

120 kB of flash is not what I call a small footprint.  I don't know what you mean by "acts like an OS".  Forth only does what you tell it to do.  It is very much like a scripting language, with either compiling code, or executing from a command line.  While there are forths which run on bare metal, these are less common on larger CPUs, and typically are programs under an OS.  However, forth can be the only code on a small MCU, which is why it can fit in only 4 kB of flash (what you call ROM).  There aren't many MCUs with ROM these days.
That is not a very fair comparison. The 90k to 120k for Lua includes: compiler to create bytecode, math, string, table support, bit-operations and various other features like key-value pairs. For math support, the floating point library is also linked in (which is included in the size). All in all you get a fairly complete package from embLua. Micropython is even better featured with things like filesystem support and modules to deal with JSON (for example).

Forth includes the "compiler", math and string support.  Of course, this is all configurable.  In 4 kB, it likely won't include much math support, but that should not be so large to add. 

When you talk about filesystem support, I thought you didn't want OS functionality.  Wouldn't that include the filesystem?
You don't need an OS for filesystem support. Look at Fatfs for example which can work with a wide range of flash devices.

Besides that, it looks like Mecrisp needs quite a bit more than just 4kB or ROM. More like 16kB to 32kB.
« Last Edit: May 21, 2024, 12:22:11 pm by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline gnuarm

  • Super Contributor
  • ***
  • Posts: 2247
  • Country: pr
Re: Lightweight Scripting Language for MCUs
« Reply #103 on: May 21, 2024, 01:24:27 pm »
It seems like embLua is a clear winner at this point (memory footprint, functionality, language complexity, etc), at least for embedding scripting into an already existing codebase like I need.  Am I wrong?

Isn't the memory footprint of embLua rather large?  I've seen forth implementations that fit in a very few kB of flash (like ~4 kB) and around 256 B of RAM.  One advantage is that properly implemented, forth applications use very little program storage.   

Did I misunderstand the memory footprint of embLua?

12K RAM, 120K ROM is fine for an ESP32 I think.  If this was a smaller micro, I would probably need to reconsider.
Also the thing I definitely Don't Want is a scripting firmware that acts like an OS.  I already have my program which needs FreeRTOS because of the Wifi on the ESP32, so I don't want anything conflicting with that.

120 kB of flash is not what I call a small footprint.  I don't know what you mean by "acts like an OS".  Forth only does what you tell it to do.  It is very much like a scripting language, with either compiling code, or executing from a command line.  While there are forths which run on bare metal, these are less common on larger CPUs, and typically are programs under an OS.  However, forth can be the only code on a small MCU, which is why it can fit in only 4 kB of flash (what you call ROM).  There aren't many MCUs with ROM these days.
That is not a very fair comparison. The 90k to 120k for Lua includes: compiler to create bytecode, math, string, table support, bit-operations and various other features like key-value pairs. For math support, the floating point library is also linked in (which is included in the size). All in all you get a fairly complete package from embLua. Micropython is even better featured with things like filesystem support and modules to deal with JSON (for example).

Forth includes the "compiler", math and string support.  Of course, this is all configurable.  In 4 kB, it likely won't include much math support, but that should not be so large to add. 

When you talk about filesystem support, I thought you didn't want OS functionality.  Wouldn't that include the filesystem?
You don't need an OS for filesystem support. Look at Fatfs for example which can work with a wide range of flash devices.

Of course, you can include any aspect of an OS into any program.  I'm not clear what your point is.


Quote
Besides that, it looks like Mecrisp needs quite a bit more than just 4kB or ROM. More like 16kB to 32kB.

I seem to recall there are versions that run in a 4 kB flash chip, likely one of the MSP430s.  But even at 16 kB, that's an order of magnitude smaller than 120 kB!  The point is, forth can run on nearly all MCUs.  BTW, Mecrisp is simply one that I've used.  There are many forths available for many MCUs, CPUs, DSPs and even CPUs on FPGAs!

When you write ROM, I assume you mean flash, right?  It's hard to find MCUs with ROM these days.
Rick C.  --  Puerto Rico is not a country... It's part of the USA
  - Get 1,000 miles of free Supercharging
  - Tesla referral code - https://ts.la/richard11209
 

Offline peter-h

  • Super Contributor
  • ***
  • Posts: 3780
  • Country: gb
  • Doing electronics since the 1960s...
Re: Lightweight Scripting Language for MCUs
« Reply #104 on: May 21, 2024, 02:02:17 pm »
Quote
Anyone know of a scripting language small enough to run on an ARM Cortex-M4 and not require too many resources?

BASIC :)

I implemented some Tiny Basic, under 2k IIRC, on a Z80.


Tongue in cheek of course, because you will have fun porting Z80 asm to ARM32. But there is probably a C version of one of the many Basics.
« Last Edit: May 21, 2024, 02:04:17 pm by peter-h »
Z80 Z180 Z280 Z8 S8 8031 8051 H8/300 H8/500 80x86 90S1200 32F417
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4240
  • Country: us
Re: Lightweight Scripting Language for MCUs
« Reply #105 on: May 21, 2024, 08:00:15 pm »
Quote
The only advantage simple BASIC has is the line number [based editing]

If you add control structures and functions with arguments and local variables and structs or dictionaries then you lose the few advantages BASIC started with and might as well use Lua or a TinyC or Python or Scheme etc.
   
We were talking about memory footprints on smaller microcontrollers (although OP asked about a Cortex-M4, so perhaps we shouldn't have gone there.)
Minimal BASICs have been done in 2k of program memory and insignificant amounts of RAM.  8051 BASIC fit in 8k and had floating point support!  The other languages you mention don't have much hope of fitting in an 8bit PIC, AVR, ST8, or etc.
You pretty much have a choice between BASIC and Forth, and more people know how to program in BASIC.
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 4220
  • Country: nz
Re: Lightweight Scripting Language for MCUs
« Reply #106 on: May 21, 2024, 10:20:06 pm »
Quote
The only advantage simple BASIC has is the line number [based editing]

If you add control structures and functions with arguments and local variables and structs or dictionaries then you lose the few advantages BASIC started with and might as well use Lua or a TinyC or Python or Scheme etc.
   
We were talking about memory footprints on smaller microcontrollers (although OP asked about a Cortex-M4, so perhaps we shouldn't have gone there.)
Minimal BASICs have been done in 2k of program memory and insignificant amounts of RAM.  8051 BASIC fit in 8k and had floating point support!  The other languages you mention don't have much hope of fitting in an 8bit PIC, AVR, ST8, or etc.
You pretty much have a choice between BASIC and Forth, and more people know how to program in BASIC.

Sure they do!

First off, the size of soft floating point routines is irrelevant to the language as it's the same for all. Unless of course the language is defined to use FP not integer, like Javascript or Microsoft BASIC.

There are subsets of C and Lisp implemented in a single x86 floppy disk sector (512 bytes).

https://xorvoid.com/sectorc.html

https://github.com/jart/sectorlisp

If you've got a whole 2K or 8K to play with then you can have a pretty good language and implementation.

The entire executable for Turbo Pascal 1.0 (including editor, compiler, debugger) was 39,731 bytes. Re-code that into AVR and I bet it would fit into an ATMega328's 32k.

The problem with PIC and AVR is that you can't run code from RAM, so you're limited to compiling to bytecode and interpreting that (which token-threaded and address-threaded Forth is a subset of).
 
The following users thanked this post: tellurium

Offline tellurium

  • Frequent Contributor
  • **
  • Posts: 267
  • Country: ua
Open source embedded network library https://github.com/cesanta/mongoose
TCP/IP stack + TLS1.3 + HTTP/WebSocket/MQTT in a single file
 

Offline peter-h

  • Super Contributor
  • ***
  • Posts: 3780
  • Country: gb
  • Doing electronics since the 1960s...
Re: Lightweight Scripting Language for MCUs
« Reply #108 on: May 22, 2024, 08:15:25 am »
The great thing about Basic is that you don't need to provide a text editor, which is another whole load of work, and you need to make assumptions like is the terminal a VT100 etc. I did all this many years ago - a Wordstar compatible editor :) but that's because the product also contains a Pascal compiler.

For sheer "hacking productivity" Basic wins hands down.
Z80 Z180 Z280 Z8 S8 8031 8051 H8/300 H8/500 80x86 90S1200 32F417
 

Offline Doctorandus_P

  • Super Contributor
  • ***
  • Posts: 3559
  • Country: nl
Re: Lightweight Scripting Language for MCUs
« Reply #109 on: May 24, 2024, 04:06:10 am »
I have an interest in this topic too. My main goal is automated test equipment, for example a standalone DMM like appliance that can run custom scripts to convert, log and show sensor data. One of the Ideas I had is whether the old Acorn Archimedes could be ported to a ARM Cortex Mx. Modern microcontrollers have plenty of power to run such a system.

But in the end, I'm leaning towards the path that it just does not make much practical sense.
Small Linux systems have been available cheaply, and they are powerful enough to run any of a number of scripting languages of your choice. There is no need to cope with "exotic" languages, or partial implementations such as micro python. When having a file system, you also have an easy place to store library code for reuse, and plenty of ram for more complicated things if you need it. It also allows you to use any language you are already familiar with. Having to learn a new language, just to run some scripts on your uC (and it's limitations for partial implementations) is completely avoided this way.

Maybe it makes sense if your gadget is battery powered. I'm not familiar with how low your power consumption can get on the smallest Linux systems. But even then you will still need some way of entering your program on the target hardware. You could add a display / keyboard but that is a lot of extra work, and power consumption for a decent sized display becomes problematic if you're thinking microcontroller level power consumption.

This makes the most logical choice some serial terminal, which implies usage of a PC (laptop) with display & keyboard. But when you have a PC available, you may as well use a full blown IDE, possibly compile your program and flash your microcontroller. The myriad of advantages (code highlighting, copy & Paste, loading libraries, jumping to function implementations, debugging, etc) are so big that I see very little room where fiddling on uC to get some code to work would make sense.

So if the question is "Can it be done?" the answer is sure, there are already plenty of examples in this thread.
But if the question is "Does it make sense?" then you have a very different set of variables to consider.
« Last Edit: May 24, 2024, 04:12:27 am by Doctorandus_P »
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 4220
  • Country: nz
Re: Lightweight Scripting Language for MCUs
« Reply #110 on: May 24, 2024, 05:02:07 am »
Small Linux systems have been available cheaply, and they are powerful enough to run any of a number of scripting languages of your choice.

The Milk-V Duo is getting quite popular. For $5 [1] it has a 1.0 GHz 64 bit Linux CPU, a 700 MHz 64 bit microcontroller CPU, 64 MB RAM. You can run emacs and gcc on the Linux side (or of course those full blown scripting languages), build either Linux or embedded code. Embedded code is simply copied into a special file system location to "flash" the microcontroller core.

IIRC, power consumption is something like 0.5W?

Of course with Arm there are the Raspberry Pi Zero and Pico, but they split the functionality into two boards and the $5 price the Zero once was was not a proper commercial price (i.e. they would not allow you to buy 1000 of them at that price ... Milk-V would love you for such an order).

[1] https://arace.tech/collections/milk-v-duo
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14897
  • Country: fr
Re: Lightweight Scripting Language for MCUs
« Reply #111 on: May 24, 2024, 05:37:55 am »
Yep, sometimes you need a Linux environment and a sizable amount of RAM compared to a typical MCU, but still don't need the power of a Raspberry Pi and GB's of RAM, which would just be wasted.
And you have two cores inside the same chip - I don't know yet how they share RAM or busses, but that should beat anything requiring collaboration between a RPi and an external MCU, via USB, SPI or whatever. Also the second core is pretty fast compared to your average MCU. Actually, it even has a third core, 8051-based, although I don't care much about that, not sure what use it has. Still, that's 3 cores for you, one running Linux and two being essentially like MCUs.

As I remember, it draws about 0.3W for a typical load.

Haven't gotten around to testing it yet, but that should be fun.
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 27366
  • Country: nl
    • NCT Developments
Re: Lightweight Scripting Language for MCUs
« Reply #112 on: May 24, 2024, 07:27:24 am »
This makes the most logical choice some serial terminal, which implies usage of a PC (laptop) with display & keyboard. But when you have a PC available, you may as well use a full blown IDE, possibly compile your program and flash your microcontroller. The myriad of advantages (code highlighting, copy & Paste, loading libraries, jumping to function implementations, debugging, etc) are so big that I see very little room where fiddling on uC to get some code to work would make sense.
With Micropython and Lua you don't need fiddling. Just use your favorite IDE (like Eclipse) and develop & debug on a PC. When the scripts shows signs of life, upload to the microcontroller. A serial debugging CLI interface is extremely handy though. And I disagree on languages being cut-down. Micropython and embLua are complete implementations of Python and Lua, just with less libraries out of the box. There is no reason to not add more libraries if needed.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 
The following users thanked this post: Smokey

Offline Smokey

  • Super Contributor
  • ***
  • Posts: 2696
  • Country: us
  • Not An Expert
Re: Lightweight Scripting Language for MCUs
« Reply #113 on: May 24, 2024, 07:36:39 am »
This makes the most logical choice some serial terminal, which implies usage of a PC (laptop) with display & keyboard. But when you have a PC available, you may as well use a full blown IDE, possibly compile your program and flash your microcontroller. The myriad of advantages (code highlighting, copy & Paste, loading libraries, jumping to function implementations, debugging, etc) are so big that I see very little room where fiddling on uC to get some code to work would make sense.
With Micropython and Lua you don't need fiddling. Just use your favorite IDE (like Eclipse) and develop & debug on a PC. When the scripts shows signs of life, upload to the microcontroller. ...

yup
 

Offline gnuarm

  • Super Contributor
  • ***
  • Posts: 2247
  • Country: pr
Re: Lightweight Scripting Language for MCUs
« Reply #114 on: May 24, 2024, 08:54:21 am »
This makes the most logical choice some serial terminal, which implies usage of a PC (laptop) with display & keyboard. But when you have a PC available, you may as well use a full blown IDE, possibly compile your program and flash your microcontroller. The myriad of advantages (code highlighting, copy & Paste, loading libraries, jumping to function implementations, debugging, etc) are so big that I see very little room where fiddling on uC to get some code to work would make sense.
With Micropython and Lua you don't need fiddling. Just use your favorite IDE (like Eclipse) and develop & debug on a PC. When the scripts shows signs of life, upload to the microcontroller. A serial debugging CLI interface is extremely handy though. And I disagree on languages being cut-down. Micropython and embLua are complete implementations of Python and Lua, just with less libraries out of the box. There is no reason to not add more libraries if needed.

Sounds a lot like forth. 
Rick C.  --  Puerto Rico is not a country... It's part of the USA
  - Get 1,000 miles of free Supercharging
  - Tesla referral code - https://ts.la/richard11209
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4240
  • Country: us
Re: Lightweight Scripting Language for MCUs
« Reply #115 on: May 24, 2024, 08:58:17 am »


Quote
just use your favorite IDE (like Eclipse) and develop & debug on a pc


To me, “scripting language” implies the ability to edit and run interactively on the target system, probably without creating a full “program.”
That may be a silly requirement, since the likely tool is probably a full pc anyway.   But… Python and BASIC definitely qualify, but not a tiny C or Pascal.  (Some debuggers might qualify.  MIT used a debugger as their “shell” on their ITS machines, and people used to use msdos “debug” to create short asm programs.
 

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 6514
  • Country: fi
    • My home page and email address
Re: Lightweight Scripting Language for MCUs
« Reply #116 on: May 24, 2024, 09:07:45 am »
I've recently noticed that even in systems programming, fast but lightweight expression evaluation is much more useful than a full-blown scripting language.

As I mentioned before in this thread, for microcontrollers I typically only need access to variables in RAM, occasionally functions; in systems programming, also string manipulation and even regular expressions (which in POSIXy systems are included in the base standard C library and thus do not "cost" anything extra; see man 3 regex and POSIX basic regular expression syntax).

In all cases I tend to have a context object (in C, a structure that often contains a hash table of "variables" and another of "functions" and "operators" the expression can access), often shared across a few expressions, but also with more than one context in a single application.

The nicest interface for this is in Python-Python –– I mean, when evaluating Python expressions in Python, but not when using Python as an embedded language –– since its built-in eval() function takes a global and a local dictionary (perfect for context) where even other built-ins can be overridden to limit the language facilities.  In JavaScript, one can create a Function object using the expression, but either all context variable names are listed as function parameters, or the expression uses e.g. this base object (so all references are of form this.variable_or_function) –– this is because it uses an array instead of a dictionary to represent function arguments ––; workable, but not perfect.

(Okay, another wall of text. Get to the point already! >:()

Thus, I'd love a modular lightweight scripting language suited for microcontrollers that one could easily strip down to (or pick only the) expression evaluation and C function call machinery.  I notice several of you have already written small interpreters for embedded use (at 32-bit Cortex-M scale we already have several options noted in this thread), but paying more attention to this type of modularity and minimalism might be warranted.  I particularly like the division between global and local states, with both states as separate objects/structures supplied to the evaluator, along with the string or token stream representing the expression.
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 4220
  • Country: nz
Re: Lightweight Scripting Language for MCUs
« Reply #117 on: May 24, 2024, 09:13:42 am »


Quote
just use your favorite IDE (like Eclipse) and develop & debug on a pc


To me, “scripting language” implies the ability to edit and run interactively on the target system, probably without creating a full “program.”
That may be a silly requirement, since the likely tool is probably a full pc anyway.   But… Python and BASIC definitely qualify, but not a tiny C or Pascal.  (Some debuggers might qualify.  MIT used a debugger as their “shell” on their ITS machines, and people used to use msdos “debug” to create short asm programs.

I don't see anything that prevents using C or Pascal for this. A humble ATMega328 has almost as much flash as the total size of Turbo Pascal 1.0. Many microcontrollers have a lot more e.g. various ESP32 models have hundreds of KB each of RAM and flash.

A C implementation can easily use indirect calls to functions (at very little speed penalty), allowing individual functions to be edited or re-entered and recompiling just that function.
 
The following users thanked this post: tellurium

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 27366
  • Country: nl
    • NCT Developments
Re: Lightweight Scripting Language for MCUs
« Reply #118 on: May 24, 2024, 10:25:15 am »


Quote
just use your favorite IDE (like Eclipse) and develop & debug on a pc


To me, “scripting language” implies the ability to edit and run interactively on the target system, probably without creating a full “program.”
I disagree. It doesn't make much sense to develop high level c.q. complex algorithms on a limited platform. Just like you would do with a C algorithm, you develop, test & debug on a PC and then run it on a microcontroller. Whether it is C, Python or Lua, my development workflow is pretty similar.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline JPortici

  • Super Contributor
  • ***
  • Posts: 3485
  • Country: it
Re: Lightweight Scripting Language for MCUs
« Reply #119 on: May 24, 2024, 10:49:51 am »
(...) Python (...)

(Okay, another wall of text. Get to the point already! >:()

Obligatory:


I would personally go with a flavour of basic.
 
The following users thanked this post: Nominal Animal

Offline Picuino

  • Super Contributor
  • ***
  • Posts: 1020
  • Country: es
    • Picuino web
Re: Lightweight Scripting Language for MCUs
« Reply #120 on: May 24, 2024, 11:21:56 am »
HP has many programmable instruments, which is a very valuable quality for the end user (not necessarily for the developer).
1. https://www.keysight.com/us/en/assets/9018-41161/user-manuals/9018-41161.pdf
2. https://en.wikipedia.org/wiki/RPL_(programming_language)

On the other hand an interpreted language is sometimes faster than the compilation and burning process.
« Last Edit: May 24, 2024, 11:40:27 am by Picuino »
 

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 6514
  • Country: fi
    • My home page and email address
Re: Lightweight Scripting Language for MCUs
« Reply #121 on: May 24, 2024, 11:55:30 am »
(...) Python (...)
I would personally go with a flavour of basic.
That referred to only the interface, not language per se!  As in, when embedding such an expression evaluator or even a full script interpreter, I would love to have a similar interface, that takes 1) the text or token stream to be interpreted, 2) a global context, and 3) a local context.  Global context would contain objects and functions accessing the firmware, and local context any local variables and perhaps functions the user has defined.

I don't care much about the language family or syntax details, because I find it easy to adjust to whatever is available.  I do care about how it is interfaced to, from the embedded firmware; and how well the interpreter/engine state can be manipulated.

I do NOT want engines or frameworks that grab ownership of everything, with their internal state a black box, and expect the firmware implementer to acquiesce to the scripting engine/framework model; as if the engine/framework is what is supposed to be running all the time, and only courteously interrupted by the rest of the firmware.  Those utterly suck.  I want an embeddable modular part, not a grabby framework that forces me to work within it.
« Last Edit: May 24, 2024, 11:58:04 am by Nominal Animal »
 

Offline tggzzz

  • Super Contributor
  • ***
  • Posts: 20027
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: Lightweight Scripting Language for MCUs
« Reply #122 on: May 24, 2024, 01:24:03 pm »
I've recently noticed that even in systems programming, fast but lightweight expression evaluation is much more useful than a full-blown scripting language.

To avoid the almost inevitable cancer-like growth of "small" domain scripting languages/libraries (DSLs), limiting it to expression evaluation is an interesting idea.

My requirements would be
  • access to local variables, e.g. to get/set control parameters "visible" on the front panel or over GPIB
  • no if-then-else statements, nor anything equivalent
  • no procedures/functions/macros

That should ensure DSL cancer doesn't occur.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 
The following users thanked this post: Nominal Animal

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 27366
  • Country: nl
    • NCT Developments
Re: Lightweight Scripting Language for MCUs
« Reply #123 on: May 24, 2024, 01:40:47 pm »


Quote
just use your favorite IDE (like Eclipse) and develop & debug on a pc


To me, “scripting language” implies the ability to edit and run interactively on the target system, probably without creating a full “program.”
That may be a silly requirement, since the likely tool is probably a full pc anyway.   But… Python and BASIC definitely qualify, but not a tiny C or Pascal.  (Some debuggers might qualify.  MIT used a debugger as their “shell” on their ITS machines, and people used to use msdos “debug” to create short asm programs.

I don't see anything that prevents using C or Pascal for this. A humble ATMega328 has almost as much flash as the total size of Turbo Pascal 1.0. Many microcontrollers have a lot more e.g. various ESP32 models have hundreds of KB each of RAM and flash.

A C implementation can easily use indirect calls to functions (at very little speed penalty), allowing individual functions to be edited or re-entered and recompiling just that function.
While true, that negates one of the major advantages of a scripted language: a scripted language runs in a well defined sandbox. So even if the user does something crazy in a script, there are no chances of having memory overflows or pointer problems.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3205
  • Country: ca
Re: Lightweight Scripting Language for MCUs
« Reply #124 on: May 24, 2024, 02:09:10 pm »
I don't see anything that prevents using C or Pascal for this. A humble ATMega328 has almost as much flash as the total size of Turbo Pascal 1.0. Many microcontrollers have a lot more e.g. various ESP32 models have hundreds of KB each of RAM and flash.

Moreover, you can compile on PC. You just write something, press a button, it gets compiled, programmed, runs and you observe the results. If you want to change something, you just edit the text and repeat over. You can do much more than with scripting - interrupts, timing. And you retain all copies of your source, so if you want to go back to something, it's just few clicks of a mouse. Or, you can run a debugger, stop it where you want and observe the results.

What is wrong with that?
 

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 6514
  • Country: fi
    • My home page and email address
Re: Lightweight Scripting Language for MCUs
« Reply #125 on: May 24, 2024, 02:11:06 pm »
My requirements would be
  • access to local variables, e.g. to get/set control parameters "visible" on the front panel or over GPIB
  • no if-then-else statements, nor anything equivalent
  • no procedures/functions/macros
Yep.  Depending on the use case, one might also wish to disable redefinition of user-defined variables (read-only global/local context), too.

As a practical example, consider some stepper motor motion controller configuration:

To convert between steps and human length units, you need something like
    STEP_SIZE = 0.1 ; mm per step

However, if the user happens to have a belt drive, it would make things much better documented if they could use
    belt_pitch = 2 ; mm, using GT2 belt
    pulley_teeth = 20
    pulses_per_turn = 400 ; half-stepping
    STEP_SIZE = belt_pitch * pulley_teeth / pulses_per_turn
where for illustration only, I've used uppercase for the actual configuration item, and lowercase for user-defined variables.

After switching to a ball screw, users might use
    thread_pitch = 8 ; mm, using T8x8
    pulses_per_turn = 400 ; half-stepping
    STEP_SIZE = thread_pitch / pulses_per_turn

The "standard" solution is to split the step size into two or more parameters, so that instead of specifying the STEP_SIZE directly, you specify some terms (typically a numerator and a denominator).  I don't like that AT ALL, because it hides what is actually important to the firmware, and instead tries to force some kind of pattern or way the device is to be used.
 

Offline nimish

  • Regular Contributor
  • *
  • Posts: 175
  • Country: us
Re: Lightweight Scripting Language for MCUs
« Reply #126 on: June 06, 2024, 02:29:12 am »
It's 1000x faster to bring up a sensor board with micropython/circuitpython than to write and flash compiled firmware

i wouldn't use it for anything at the extremes of performance but it's a great little tool for interactively messing with i2c/spi devices
 

Offline tggzzz

  • Super Contributor
  • ***
  • Posts: 20027
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: Lightweight Scripting Language for MCUs
« Reply #127 on: June 06, 2024, 08:18:31 am »
i wouldn't use it for anything at the extremes of performance but it's a great little tool for interactively messing with i2c/spi devices

There are other tools that can be considered for that, e.g. a BusPirate5.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline Picuino

  • Super Contributor
  • ***
  • Posts: 1020
  • Country: es
    • Picuino web
Re: Lightweight Scripting Language for MCUs
« Reply #128 on: June 07, 2024, 01:35:32 pm »
https://github.com/totalspectrum/tinyscript

Quote
Introduction

This is tinyscript, a scripting language designed for very tiny machines. The initial target is boards using the Parallax Propeller, which has 32KB of RAM, but the code is written in ANSI C so it should work on any platform (e.g. testing is done on x86-64 Linux).

On the propeller, the interpreter code needs about 3K of memory in CMM mode or 5K in LMM. On the x86-64 the interpreter code is 6K. The size of the workspace you give to the interpreter is up to you, although in practice it would not be very useful to use less than 2K of RAM. The processor stack is used as well, so it will need some space.

tinyscript is copyright 2016-2021 Total Spectrum Software Inc. and released under the MIT license. See the COPYING file for details.
 

Offline nimish

  • Regular Contributor
  • *
  • Posts: 175
  • Country: us
Re: Lightweight Scripting Language for MCUs
« Reply #129 on: June 07, 2024, 10:40:45 pm »
i wouldn't use it for anything at the extremes of performance but it's a great little tool for interactively messing with i2c/spi devices

There are other tools that can be considered for that, e.g. a BusPirate5.

That's a lot more work than simply loading a different firmware image once not to mention it cannot replicate how the specific MCU you are using would actually communicate
 

Offline Sal AmmoniacTopic starter

  • Super Contributor
  • ***
  • Posts: 1741
  • Country: us
Re: Lightweight Scripting Language for MCUs
« Reply #130 on: June 12, 2024, 07:40:29 pm »
@Sal: I've been messing with your dilemma for 40years already. The only "really interactive and complete" MCU tool fully running on a target is Forth, imho.  Well, you have to overcome the initial mental barrier first.
Btw, I read a guy from NZ is claiming his Forth can do Basic - ABCForth..

I didn't realize this thread, which I created nearly 8 years ago was still alive.

Personal update: I ended up implementing Forth for the STM32. It's about 1200 lines of ARM assembly code plus Forth code to implement more complex words. I don't use it very often, but when I need it it does come in handy.
"That's not even wrong" -- Wolfgang Pauli
 

Offline gnuarm

  • Super Contributor
  • ***
  • Posts: 2247
  • Country: pr
Re: Lightweight Scripting Language for MCUs
« Reply #131 on: June 16, 2024, 09:38:15 pm »
@Sal: I've been messing with your dilemma for 40years already. The only "really interactive and complete" MCU tool fully running on a target is Forth, imho.  Well, you have to overcome the initial mental barrier first.
Btw, I read a guy from NZ is claiming his Forth can do Basic - ABCForth..

I didn't realize this thread, which I created nearly 8 years ago was still alive.

Personal update: I ended up implementing Forth for the STM32. It's about 1200 lines of ARM assembly code plus Forth code to implement more complex words. I don't use it very often, but when I need it it does come in handy.

What forth did you use?  I know there are many which run on ARMs.
Rick C.  --  Puerto Rico is not a country... It's part of the USA
  - Get 1,000 miles of free Supercharging
  - Tesla referral code - https://ts.la/richard11209
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf