Lightweight Scripting Language for MCUs - Page 1
Forum section: electronics / general

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: August 22, 2016, 05:34:21 pm
content: 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?

author: coppice
author_rank: Super Contributor
timestamp: August 22, 2016, 05:48:04 pm
content: Lua seems to be the lightweight scripting language of choice/

author: hli
author_rank: Frequent Contributor
timestamp: August 22, 2016, 05:52:00 pm
content: At 43oh, someone referred to"SIMPL". Its a small interpreted language designed as interactive language for embedded systems.

author: westfw
author_rank: Super Contributor
timestamp: August 22, 2016, 08:06:27 pm
content: 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.

author: Kjelt
author_rank: Super Contributor
timestamp: August 22, 2016, 09:04:19 pm
content: Quote from: coppice on August 22, 2016, 05:48:04 pm+1

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: August 22, 2016, 09:07:15 pm
content: Quote from: westfw on August 22, 2016, 08:06:27 pmForth 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.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: August 22, 2016, 09:45:06 pm
content: MMBASIC ?http://mmbasic.com/

author: member_xyz
author_rank: Contributor
timestamp: August 23, 2016, 02:57:15 am
content: 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/

author: Pack34
author_rank: Frequent Contributor
timestamp: August 23, 2016, 03:00:46 am
content: 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

author: nowlan
author_rank: Frequent Contributor
timestamp: August 23, 2016, 04:17:47 am
content: Ive been looking for something that can doExpectfor 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.

author: mubes
author_rank: Regular Contributor
timestamp: August 23, 2016, 07:43:59 am
content: Quote from: nowlan on August 23, 2016, 04:17:47 amMicropython 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

author: tggzzz
author_rank: Super Contributor
timestamp: August 23, 2016, 08:06:59 am
content: There's a common mistake that I've seen repeatedly; I made it once myself.The chain of events issee a need to be able do a few simple things on-the-flycreate a little scripting language to do thosethen find "oh, if only I could also do X", where X is something like conditional statements, or loops, or globbing/regexpsadd thoserepeat 3 and 4Very 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

author: newbrain
author_rank: Super Contributor
timestamp: August 23, 2016, 08:39:22 am
content: 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 anHPone), 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)...

author: helius
author_rank: Super Contributor
timestamp: August 23, 2016, 09:37:33 am
content: 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."

author: alexanderbrevig
author_rank: Frequent Contributor
timestamp: August 23, 2016, 09:49:21 am
content: 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.

author: legacy
author_rank: Super Contributor
timestamp: August 23, 2016, 11:53:25 am
content: perhaps ... my toylittlelanguage 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-elseCode:Program factorialBeginInput nfactorial = 1While n > 1Beginfactorial = factorial * nn = n - 1EndOutput factorialEndprocedures and functions are not supported, and it's 100% abandonware

author: legacy
author_rank: Super Contributor
timestamp: August 23, 2016, 12:02:54 pm
content: Quote from: tggzzz on August 23, 2016, 08:06:59 amalso 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 needssee code (list)edit existing codeinsert new code

author: tggzzz
author_rank: Super Contributor
timestamp: August 23, 2016, 01:11:31 pm
content: Quote from: legacy on August 23, 2016, 12:02:54 pmFor 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.

author: rstofer
author_rank: Super Contributor
timestamp: August 23, 2016, 03:03:21 pm
content: Quote from: Sal Ammoniac on August 22, 2016, 09:07:15 pmForth 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...).

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: August 23, 2016, 04:15:27 pm
content: Quote from: newbrain on August 23, 2016, 08:39:22 amI 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.

author: rstofer
author_rank: Super Contributor
timestamp: August 23, 2016, 05:06:38 pm
content: 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 ARMhttp://www.sifflez.org/lectures/ASE/C3.pdfThis sounds interesting enough that it bears further investigation. It's not like I am short of ARM boards, particularly STM32F's.

author: macboy
author_rank: Super Contributor
timestamp: August 23, 2016, 05:13:55 pm
content: 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.

author: kripton2035
author_rank: Super Contributor
timestamp: August 23, 2016, 05:16:02 pm
content: Quote from: coppice on August 22, 2016, 05:48:04 pm+1

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: August 23, 2016, 05:25:22 pm
content: Quote from: kripton2035 on August 23, 2016, 05:16:02 pmHow "lightweight" is it? I found this on the Lua website:QuoteThat'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?

author: madires
author_rank: Super Contributor
timestamp: August 23, 2016, 05:44:47 pm
content: 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.

author: BloodyCactus
author_rank: Frequent Contributor
timestamp: August 23, 2016, 06:23:03 pm
content: Quote from: Sal Ammoniac on August 23, 2016, 05:25:22 pmyou 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 outhttps://www.lua.org/notes/ltn002.htmlfor info on doing this on an older version of lua.they got it the core of lua down to 24kyou 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)

author: nctnico
author_rank: Super Contributor
timestamp: August 23, 2016, 06:29:13 pm
content: Quote from: Sal Ammoniac on August 23, 2016, 05:25:22 pmYou need to look for eLua (embedded Lua).

author: krho
author_rank: Regular Contributor
timestamp: August 23, 2016, 08:10:12 pm
content: There is apascalfrom 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.

author: TJ232
author_rank: Frequent Contributor
timestamp: August 24, 2016, 04:30:03 am
content: Quote from: coppice on August 22, 2016, 05:48:04 pm+1.Quite nice and easy to use.You can find a lot of ESP8266 examples, drivers, projects, etc onhttp://www.esp8266-projects.comMicropythonandESP Basicare 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

author: legacy
author_rank: Super Contributor
timestamp: August 24, 2016, 06:27:00 am
content: Quote from: TJ232 on August 24, 2016, 04:30:03 ameLua is also implemented and used byTexas Instrumentsfor their CAS(2) pocket calculators in theTI-NspireCASlineeven 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 flashyes: they can run linux, it doesn't make practical sense but as "intellectual challenge" t few linux-ports already exist, the CPU comes with TLBtherefore eLua on those calculators is not a strictly low level like MPUs (e.g. 8051,AVR8,...), it's medium level about the hardwarebut 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 withR1-R2layout (<=2008 machines), they can have eLua once upgraded to the last firmware available, TIOS-v3.9.0.463

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: August 31, 2016, 11:00:48 pm
content: 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.

author: ebclr
author_rank: Super Contributor
timestamp: September 01, 2016, 09:26:35 am
content: http://www.cypress.com/products/ez-usb-fx2lp?source=search&keywords=ez%20usbIt's a different approach but extremelly powerfull to do your intent

author: l3VGV
author_rank: Contributor
timestamp: March 21, 2021, 01:19:41 am
content: 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 forMicroPython, 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/examplesLast 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

author: nctnico
author_rank: Super Contributor
timestamp: March 22, 2021, 12:36:31 am
content: 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.

author: gnuarm
author_rank: Super Contributor
timestamp: March 22, 2021, 02:29:11 am
content: Quote from: Sal Ammoniac on August 22, 2016, 09:07:15 pmThis 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.

author: gnuarm
author_rank: Super Contributor
timestamp: March 22, 2021, 02:32:31 am
content: Quote from: westfw on August 22, 2016, 08:06:27 pmI 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.

author: techman-001
author_rank: Frequent Contributor
timestamp: March 22, 2021, 03:00:24 am
content: Quote from: gnuarm on March 22, 2021, 02:32:31 amThe latest release of SVD2FORTH is out now:https://sourceforge.net/projects/mecrisp-stellaris-folkdoc/files/svd2forth-v3-stm32-20.03.21-F7a01.zipIt'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.

author: l3VGV
author_rank: Contributor
timestamp: March 22, 2021, 06:56:30 am
content: Quote from: nctnico on March 22, 2021, 12:36:31 amWell, 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?

author: JoeyG
author_rank: Regular Contributor
timestamp: March 22, 2021, 07:46:38 am
content: Microphython and CircuitPython, - but Phython on a MCU is not very efficient in terms of speed and memory usage.Another is Micromite basichttps://geoffg.net/micromite.htmlThen there is the basic stamphttps://www.parallax.com/propeller-2/

author: iMo
author_rank: Super Contributor
timestamp: March 22, 2021, 07:15:58 pm
content: @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..

author: gnuarm
author_rank: Super Contributor
timestamp: March 23, 2021, 01:12:15 am
content: Quote from: techman-001 on March 22, 2021, 03:00:24 amIt 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

author: iMo
author_rank: Super Contributor
timestamp: March 23, 2021, 12:15:51 pm
content: 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, howeverPS: 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:[ here you are in your terminal.. ]\ these new words could be saved to F407's flashcompiletoflash: button? 1 porta_idr bit@ ;: PA0sendbuttonstate begin button? >usart6 cr >usart6 key? until ;PA0sendbuttonstate[..here is the usart6 output ]110011Or just to look at the pins A0, C7, B17 input logic levels anytimeCode:[ 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 lazyCode:[ here you are in your terminal.. ]\ these new words could be saved to F407's flashcompiletoflash: 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 usart6ic7 >u6 ib17 >u6 cr ic7 >u6 ib17 >u6 cr ic7 >u6 ib17 >u6[..here is the usart6 output ]011110

author: techman-001
author_rank: Frequent Contributor
timestamp: March 23, 2021, 01:27:50 pm
content: Or if even lazier (using svd2forth) :Code:gpioc.GPIOC_MODER. RW $400208003|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|00 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 0GPIOC_OTYPER. RW $400208043|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|00 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 0GPIOC_OSPEEDR. RW $400208083|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|00 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 0GPIOC_PUPDR. RW $4002080C3|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|00 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 0GPIOC_IDR. RO $400208103|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|00 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 0GPIOC_ODR. RW $400208143|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|00 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 0GPIOC_BSRR write-onlyGPIOC_LCKR. RW $4002081C3|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|00 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 0GPIOC_AFRL. RW $400208203|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|00 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 0GPIOC_AFRH. RW $400208243|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|00 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 0ok.

author: techman-001
author_rank: Frequent Contributor
timestamp: March 23, 2021, 01:34:34 pm
content: And these are all you need to see to know that this F407 Disco is running at 168 MHz.Code:RCC_CR.RCC_CR. $400238003|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|00 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 0ok.RCC_PLLCFGR.RCC_PLLCFGR. RW $400238043|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|00 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 0ok.RCC_CFGR.RCC_CFGR. $400238083|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|00 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 0ok.FLASH_ACR.FLASH_ACR. $40023C003|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|00 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

author: iMo
author_rank: Super Contributor
timestamp: March 23, 2021, 01:46:47 pm
content: What is important to say is the user only writesCode:RCC_CR.RCC_PLLCFGR.RCC_CFGR.as the command in the terminal..

author: gnuarm
author_rank: Super Contributor
timestamp: March 23, 2021, 02:59:04 pm
content: Quote from: imo on March 23, 2021, 12:15:51 pmWhat 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. lolNow 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.

author: tggzzz
author_rank: Super Contributor
timestamp: March 23, 2021, 03:12:05 pm
content: Quote from: gnuarm on March 23, 2021, 02:59:04 pmI 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 keyboardsMind 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?

author: phil from seattle
author_rank: Super Contributor
timestamp: March 23, 2021, 03:18:58 pm
content: Here we go again. I had to key in the bootloader for a PDP 11/40 backwards in the snow. so there.

author: tggzzz
author_rank: Super Contributor
timestamp: March 23, 2021, 03:34:59 pm
content: Bootloader? You mean it wasn't already in the core memory when power was reapplied?

author: phil from seattle
author_rank: Super Contributor
timestamp: March 23, 2021, 04:41:47 pm
content: Quote from: tggzzz on March 23, 2021, 03:34:59 pmNo, the Space Sciences department across the street had a prototype doppler weather radar that regularly corrupted the core memory.

author: gnuarm
author_rank: Super Contributor
timestamp: March 23, 2021, 05:24:26 pm
content: Quote from: phil from seattle on March 23, 2021, 04:41:47 pmThose durn pesky EMC requirements!!!

author: techman-001
author_rank: Frequent Contributor
timestamp: March 23, 2021, 08:59:41 pm
content: Quote from: imo on March 23, 2021, 01:46:47 pmSure, 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.

author: alexanderbrevig
author_rank: Frequent Contributor
timestamp: March 24, 2021, 06:36:51 am
content: 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 interestinghttps://github.com/AlexanderBrevig/yalexhttps://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).

author: iMo
author_rank: Super Contributor
timestamp: March 24, 2021, 07:07:12 am
content: Quote from: gnuarm on March 23, 2021, 02:59:04 pmLinux and teletype..https://hackaday.com/tag/teletype/

author: techman-001
author_rank: Frequent Contributor
timestamp: March 24, 2021, 07:17:20 am
content: Quote from: gnuarm on March 23, 2021, 02:59:04 pmOther 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 ?

author: SiliconWizard
author_rank: Super Contributor
timestamp: March 24, 2021, 04:53:26 pm
content: Quote from: alexanderbrevig on March 24, 2021, 06:36:51 amAt first sight, it kind of looks like a cross between Lisp and Forth.

author: abyrvalg
author_rank: Frequent Contributor
timestamp: March 25, 2021, 11:28:46 am
content: 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).

author: elecdonia
author_rank: Frequent Contributor
timestamp: April 03, 2023, 03:07:06 pm
content: Quote from: tggzzz on March 23, 2021, 03:34:59 pmIn 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).

author: coppice
author_rank: Super Contributor
timestamp: April 03, 2023, 03:56:09 pm
content: Quote from: elecdonia on April 03, 2023, 03:07:06 pmI 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.

author: JoeyG
author_rank: Regular Contributor
timestamp: July 31, 2023, 09:49:22 am
content: +1 mmbasic

author: brucehoult
author_rank: Super Contributor
timestamp: July 31, 2023, 10:17:32 am
content: Quote from: SiliconWizard on March 24, 2021, 04:53:26 pmClose to PostScript and Logo ("forward Polish") too.Could use anonymous blocks for if/else and loops

author: member_xyz
author_rank: Contributor
timestamp: July 31, 2023, 01:09:42 pm
content: https://cicciocb.com/annex32help/V1.482/Basic with lot of built in functions and drivers

author: SpacedCowboy
author_rank: Frequent Contributor
timestamp: July 31, 2023, 03:31:29 pm
content: 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.

author: ag123
author_rank: Contributor
timestamp: August 01, 2023, 06:56:58 am
content: not really scripting, but do anyone mess with Rusthttps://blog.mbedded.ninja/programming/languages/rust/running-rust-on-microcontrollers/and found it any 'better' than C/C++?

author: audiotubes
author_rank: Regular Contributor
timestamp: August 02, 2023, 01:20:37 am
content: Quote from: Sal Ammoniac on August 23, 2016, 04:15:27 pmThe 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.

author: gnuarm
author_rank: Super Contributor
timestamp: August 02, 2023, 03:41:52 am
content: Quote from: audiotubes on August 02, 2023, 01:20:37 amOh, like Forth? Cool.

author: thermistor-guy
author_rank: Frequent Contributor
timestamp: August 02, 2023, 04:54:54 am
content: Quote from: Sal Ammoniac on August 22, 2016, 05:34:21 pmFor 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 havean rpi dedicated to that purpose.Gawk is useful too for processing the raw data.QuoteIn my setup, the approach I would take is to convert the target board (with sensors) into a test instrument, by giving ita 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.

author: brucehoult
author_rank: Super Contributor
timestamp: August 02, 2023, 06:09:37 am
content: Quote from: audiotubes on August 02, 2023, 01:20:37 amMy 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.

author: audiotubes
author_rank: Regular Contributor
timestamp: August 02, 2023, 06:58:37 am
content: 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:@@ 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 CFWHILE DUP SIZE 0. > REPEATDUP HEADCASEDUP "M" == THEN 1000. ENDDUP "D" == THEN 500. ENDDUP "C" == THEN 100. ENDDUP "L" == THEN 50. ENDDUP "X" == THEN 10. ENDDUP "V" == THEN 5. ENDDUP "I" == THEN 1. END# 202h DOERRENDSWAP DROP ROT SWAP +IF 1 FS? THENDUP SIZE 1 - GETI ROT ROT GETI SWAP DROP ROT DUP2IF > THENNEG SWAP DROP SWAP DUP SIZE 1 - ROT PUT1 CFELSEDROP2ENDELSE1 SFENDSWAP TAILENDDROP DUP SIZE 1IF == THEN1 GETELSE\GSLISTENDSWAP STOF\>>

author: DiTBho
author_rank: Super Contributor
timestamp: August 02, 2023, 08:52:17 am
content: Quote from: SpacedCowboy on July 31, 2023, 03:31:29 pmthis post should belong to thethreadwhere I asked "with what?" can I replace Bash scripting

author: DiTBho
author_rank: Super Contributor
timestamp: August 02, 2023, 09:03:49 am
content: Quote from: alexanderbrevig on March 24, 2021, 06:36:51 amdon't take personal, but this stuff is exactly what I do findgood motivationwhen you are a student and need to open your mind by experimenting with different things, andawfulwhen 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.

author: audiotubes
author_rank: Regular Contributor
timestamp: August 02, 2023, 01:42:46 pm
content: Quote from: DiTBho on August 02, 2023, 08:52:17 amI use SNOBOL4 for that, but I realize that may raise some eyebrows

author: brucehoult
author_rank: Super Contributor
timestamp: August 02, 2023, 01:54:01 pm
content: Quote from: audiotubes on August 02, 2023, 01:42:46 pmMarkov algorithms ftw.

author: SpacedCowboy
author_rank: Frequent Contributor
timestamp: August 02, 2023, 05:09:01 pm
content: Quote from: DiTBho on August 02, 2023, 08:52:17 amYou're rightI 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.

author: nctnico
author_rank: Super Contributor
timestamp: August 02, 2023, 06:57:30 pm
content: 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.

author: helius
author_rank: Super Contributor
timestamp: August 02, 2023, 08:45:20 pm
content: Quote from: audiotubes on August 02, 2023, 06:58:37 amRPL 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..." DROPto nullify the stack effect of the comment.

author: audiotubes
author_rank: Regular Contributor
timestamp: August 02, 2023, 10:17:24 pm
content: 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.

author: brucehoult
author_rank: Super Contributor
timestamp: August 02, 2023, 10:59:56 pm
content: Quote from: helius on August 02, 2023, 08:45:20 pmBut isn't that *precisely* a simple way to do exactly the same thing?Or do ...Code:« 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.

author: helius
author_rank: Super Contributor
timestamp: August 03, 2023, 01:54:22 am
content: 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.

author: gnuarm
author_rank: Super Contributor
timestamp: August 03, 2023, 03:50:37 am
content: Quote from: helius on August 03, 2023, 01:54:22 amIn 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.

author: brucehoult
author_rank: Super Contributor
timestamp: August 03, 2023, 06:26:30 am
content: Quote from: helius on August 03, 2023, 01:54:22 amI would never dream of saying such a thing!! I've used postfix languages a lot (mostly PostScript). But ok ....

author: Smokey
author_rank: Super Contributor
timestamp: May 16, 2024, 09:10:15 pm
content: 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?

author: tggzzz
author_rank: Super Contributor
timestamp: May 16, 2024, 09:17:12 pm
content: Quote from: Smokey on May 16, 2024, 09:10:15 pmForth.

author: nctnico
author_rank: Super Contributor
timestamp: May 16, 2024, 09:24:41 pm
content: Quote from: Smokey on May 16, 2024, 09:10:15 pmI'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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: May 16, 2024, 09:58:57 pm
content: 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.

author: nctnico
author_rank: Super Contributor
timestamp: May 16, 2024, 10:20:00 pm
content: Quote from: SiliconWizard on May 16, 2024, 09:58:57 pmFor 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.

author: Smokey
author_rank: Super Contributor
timestamp: May 16, 2024, 11:02:04 pm
content: https://github.com/szieke/embLuaQuote

author: Picuino
author_rank: Super Contributor
timestamp: May 17, 2024, 08:01:41 am
content: 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+Tclhttps://tinytcl.sourceforge.net/

author: tellurium
author_rank: Frequent Contributor
timestamp: May 17, 2024, 08:29:30 am
content: 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)

author: coppice
author_rank: Super Contributor
timestamp: May 20, 2024, 06:12:22 pm
content: Quote from: Picuino on May 17, 2024, 08:01:41 amI 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.

author: Smokey
author_rank: Super Contributor
timestamp: May 20, 2024, 06:51:51 pm
content: 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?

author: coppice
author_rank: Super Contributor
timestamp: May 20, 2024, 06:55:27 pm
content: Quote from: Smokey on May 20, 2024, 06:51:51 pmA lot of people who use it stick with it, so it seems to be a solution that results in reasonable levels of contentment.

author: ksjh
author_rank: Regular Contributor
timestamp: May 20, 2024, 07:26:49 pm
content: 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 uponhttps://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.

author: nctnico
author_rank: Super Contributor
timestamp: May 20, 2024, 07:41:45 pm
content: Quote from: ksjh on May 20, 2024, 07:26:49 pmThe 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.

author: gnuarm
author_rank: Super Contributor
timestamp: May 20, 2024, 08:44:52 pm
content: Quote from: Smokey on May 20, 2024, 06:51:51 pmIsn'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?

author: Smokey
author_rank: Super Contributor
timestamp: May 20, 2024, 09:41:50 pm
content: Quote from: gnuarm on May 20, 2024, 08:44:52 pm12K 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.

author: gnuarm
author_rank: Super Contributor
timestamp: May 21, 2024, 12:00:39 am
content: Quote from: Smokey on May 20, 2024, 09:41:50 pm120 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 theonlycode 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.

author: westfw
author_rank: Super Contributor
timestamp: May 21, 2024, 02:55:51 am
content: 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.

author: brucehoult
author_rank: Super Contributor
timestamp: May 21, 2024, 07:39:24 am
content: Quote from: westfw on May 21, 2024, 02:55:51 amI 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.

author: nctnico
author_rank: Super Contributor
timestamp: May 21, 2024, 08:52:57 am
content: Quote from: gnuarm on May 21, 2024, 12:00:39 amThat 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.

author: tellurium
author_rank: Frequent Contributor
timestamp: May 21, 2024, 09:27:31 am
content: 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 - elkBoth 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.

author: gnuarm
author_rank: Super Contributor
timestamp: May 21, 2024, 11:06:24 am
content: Quote from: nctnico on May 21, 2024, 08:52:57 amForth 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?QuoteForth 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.

author: nctnico
author_rank: Super Contributor
timestamp: May 21, 2024, 12:18:59 pm
content: Quote from: gnuarm on May 21, 2024, 11:06:24 amYou 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.

author: gnuarm
author_rank: Super Contributor
timestamp: May 21, 2024, 01:24:27 pm
content: Quote from: nctnico on May 21, 2024, 12:18:59 pmOf course, you can include any aspect of an OS into any program. I'm not clear what your point is.QuoteI 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.

author: peter-h
author_rank: Super Contributor
timestamp: May 21, 2024, 02:02:17 pm
content: QuoteBASICI 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.

author: westfw
author_rank: Super Contributor
timestamp: May 21, 2024, 08:00:15 pm
content: QuoteWe 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.

author: brucehoult
author_rank: Super Contributor
timestamp: May 21, 2024, 10:20:06 pm
content: Quote from: westfw on May 21, 2024, 08:00:15 pmSure 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.htmlhttps://github.com/jart/sectorlispIf 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).

author: tellurium
author_rank: Frequent Contributor
timestamp: May 22, 2024, 07:38:20 am
content: Quote from: brucehoult on May 21, 2024, 10:20:06 pmThat's just insane. Thank you so much for sharing.

author: peter-h
author_rank: Super Contributor
timestamp: May 22, 2024, 08:15:25 am
content: 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 editorbut that's because the product also contains a Pascal compiler.For sheer "hacking productivity" Basic wins hands down.

author: Doctorandus_P
author_rank: Super Contributor
timestamp: May 24, 2024, 04:06:10 am
content: 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.

author: brucehoult
author_rank: Super Contributor
timestamp: May 24, 2024, 05:02:07 am
content: Quote from: Doctorandus_P on May 24, 2024, 04:06:10 amThe Milk-V Duo is getting quite popular. For $5  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).https://arace.tech/collections/milk-v-duo

author: SiliconWizard
author_rank: Super Contributor
timestamp: May 24, 2024, 05:37:55 am
content: 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.

author: nctnico
author_rank: Super Contributor
timestamp: May 24, 2024, 07:27:24 am
content: Quote from: Doctorandus_P on May 24, 2024, 04:06:10 amWith 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.

author: Smokey
author_rank: Super Contributor
timestamp: May 24, 2024, 07:36:39 am
content: Quote from: nctnico on May 24, 2024, 07:27:24 amyup

author: gnuarm
author_rank: Super Contributor
timestamp: May 24, 2024, 08:54:21 am
content: Quote from: nctnico on May 24, 2024, 07:27:24 amSounds a lot like forth.

author: westfw
author_rank: Super Contributor
timestamp: May 24, 2024, 08:58:17 am
content: QuoteTo 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.

author: Nominal Animal
author_rank: Super Contributor
timestamp: May 24, 2024, 09:07:45 am
content: I've recently noticed that even in systems programming, fast but lightweightexpression evaluationis 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; seeman 3 regexandPOSIX basic regular expression syntax).In all cases I tend to have acontextobject (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-ineval()function takes a global and a local dictionary (perfect forcontext) where even other built-ins can be overridden to limit the language facilities. In JavaScript, one can create aFunction objectusing the expression, but either all context variable names are listed as function parameters, or the expression uses e.g.thisbase object (so all references are of formthis.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.

author: brucehoult
author_rank: Super Contributor
timestamp: May 24, 2024, 09:13:42 am
content: Quote from: westfw on May 24, 2024, 08:58:17 amI 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.

author: nctnico
author_rank: Super Contributor
timestamp: May 24, 2024, 10:25:15 am
content: Quote from: westfw on May 24, 2024, 08:58:17 amI 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.

author: JPortici
author_rank: Super Contributor
timestamp: May 24, 2024, 10:49:51 am
content: Quote from: Nominal Animal on May 24, 2024, 09:07:45 amObligatory:I would personally go with a flavour of basic.

author: Picuino
author_rank: Super Contributor
timestamp: May 24, 2024, 11:21:56 am
content: 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.pdf2.https://en.wikipedia.org/wiki/RPL_(programming_language)On the other hand an interpreted language is sometimes faster than the compilation and burning process.

author: Nominal Animal
author_rank: Super Contributor
timestamp: May 24, 2024, 11:55:30 am
content: Quote from: JPortici on May 24, 2024, 10:49:51 amThat referred to only theinterface, 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.

author: tggzzz
author_rank: Super Contributor
timestamp: May 24, 2024, 01:24:03 pm
content: Quote from: Nominal Animal on May 24, 2024, 09:07:45 amTo 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 beaccess to local variables, e.g. to get/set control parameters "visible" on the front panel or over GPIBno if-then-else statements, nor anything equivalentno procedures/functions/macrosThat should ensure DSL cancer doesn't occur.

author: nctnico
author_rank: Super Contributor
timestamp: May 24, 2024, 01:40:47 pm
content: Quote from: brucehoult on May 24, 2024, 09:13:42 amWhile 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.

author: NorthGuy
author_rank: Super Contributor
timestamp: May 24, 2024, 02:09:10 pm
content: Quote from: brucehoult on May 24, 2024, 09:13:42 amMoreover, 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?

author: Nominal Animal
author_rank: Super Contributor
timestamp: May 24, 2024, 02:11:06 pm
content: Quote from: tggzzz on May 24, 2024, 01:24:03 pmYep. 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 likeSTEP_SIZE = 0.1 ;mm per stepHowever, if the user happens to have a belt drive, it would make things much better documented if they could usebelt_pitch = 2 ;mm, using GT2 beltpulley_teeth = 20pulses_per_turn = 400 ;half-steppingSTEP_SIZE = belt_pitch * pulley_teeth / pulses_per_turnwhere 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 usethread_pitch = 8 ;mm, using T8x8pulses_per_turn = 400 ;half-steppingSTEP_SIZE = thread_pitch / pulses_per_turnThe "standard" solution is to split the step size into two or more parameters, so that instead of specifying theSTEP_SIZEdirectly, 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.

author: nimish
author_rank: Regular Contributor
timestamp: June 06, 2024, 02:29:12 am
content: It's 1000x faster to bring up a sensor board with micropython/circuitpython than to write and flash compiled firmwarei 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

author: tggzzz
author_rank: Super Contributor
timestamp: June 06, 2024, 08:18:31 am
content: Quote from: nimish on June 06, 2024, 02:29:12 amThere are other tools that can be considered for that, e.g. a BusPirate5.

author: Picuino
author_rank: Super Contributor
timestamp: June 07, 2024, 01:35:32 pm
content: https://github.com/totalspectrum/tinyscriptQuote

author: nimish
author_rank: Regular Contributor
timestamp: June 07, 2024, 10:40:45 pm
content: Quote from: tggzzz on June 06, 2024, 08:18:31 amThat'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

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: June 12, 2024, 07:40:29 pm
content: Quote from: iMo on March 22, 2021, 07:15:58 pmI 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.

author: gnuarm
author_rank: Super Contributor
timestamp: June 16, 2024, 09:38:15 pm
content: Quote from: Sal Ammoniac on June 12, 2024, 07:40:29 pmWhat forth did you use? I know there are many which run on ARMs.