5 ms·

Ask HN: Embedded Scripting Options for Microcontrollers

1 points by uticus 3y ago

Needed for hobby project, maintained by very small team. Haven't decided on specific microcontroller. Needed for general bit-banging, speed and code size are not priorities. So far have considered MicroPython [0] [1] and Lua [2] [3], but open for suggestions for others. What are experiences? [0] https://micropython.org/ [1] https://learn.adafruit.com/category/micropython [2] https://www.lua.org/home.html [3] https://news.ycombinator.com/item?id=8537895

PaulHoule 3y ago
There are these https://en.wikipedia.org/wiki/BASIC_Stamp https://en.wikipedia.org/wiki/BASIC_Stamp
- dingosity 3y ago
  I just looked at https://www.parallax.com/ https://www.parallax.com/ and it seems the BASIC Stamps are being EoL'd, but their remaining stock is on sale. The Propeller (the follow-on to the BASIC Stamp) is kind of interesting and the site implies you can run PBASIC code on the Propeller 2 ( you learn something new every day. ) I used a BASIC Stamp way back when and it wasn't a horrible experience. People dis on BASIC, but if you have a simple app, it's not that bad.
  - PaulHoule 3y ago
    If you want a scripting language appropriate for that environment I think it's OK. You gotta remember that Microsoft BASIC fit comfortably in real small machines back in the day, like my TRS-80 Color Computer that started out with 4K of RAM including video RAM! Personally though I think even C is too high level for the AVR-8 and like coding assembly with the caveat that there are two ways "up" if you outgrow AVR-8, one route is to go to ARM or ESP32 in which case your C is portable, the other is to go to an FPGA with a soft AVR-8 and talk about playing on hard mode.
    - dingosity 3y ago
      Yup. Chuck Peddle (one of the guys largely responsible for the design of the 6502) did an oral history interview with the CHM (Computer History Museum in Mountain View, CA.) In it he discussed their design process. They thought the market for the 6502 was as a controller (cars, HVAC, instrumentation, etc.), not the CPU of a microcomputer. But then Tiny BASIC came along at exactly the right time and hid the messier 6502 design decisions (zero page, weird addressing modes, 256 byte stack, etc.) from a whole bunch of users. So yes... BASIC is absolutely a contender for small systems. But so are MicroLisp and FORTH. Personally, I prefer Lisp, but completely agree Lisp's learning curve is waaay steeper than BASIC's. Same for FORTH. Here's the video, btw: https://youtu.be/enHF9lMseP8?si=atmDesKCxN9eH_6R https://youtu.be/enHF9lMseP8?si=atmDesKCxN9eH_6R
- uticus 3y ago
  reminds me of Jazelle (for Java bytecode in ARM hardware) https://en.wikipedia.org/wiki/Jazelle https://en.wikipedia.org/wiki/Jazelle
dingosity 3y ago
I'm sure I'll get downvoted for mentioning this, but FORTH and Lisp are also options. FORTH is exceedingly simple to implement in assembly and has the benefit that it's easily modifiable, informally verifiable (it's easy to look at the code and convince yourself no one has inserted malware), has essentially zero dependencies and is generally space and CPU efficient on small platforms (I implemented 95% of the dpANS FORTH standard on an 8086 in about 8k of opcodes.) On the downside, the FORTH community seems to be shrinking and many people find postfix notation a bit of a brain-twister. While it's "kind of" portable, it's probably not as portable MicroPython. Both FORTH and Lisp "allow" you to build programming constructs other languages provide out of the box. This is a blessing and a curse. If you ever wanted to change the way a for(){} loop worked, it's not uncommon in these languages. If you just want for(){} loops to work out of the box, you may be annoyed by having to check whether the person who wrote the for(){} keyword in your language is doing what you want. (Forth has the LOOP keyword and lisps like fe or micro-lisp have various flavours of if you use to build your own control structures with macros.) I also imagine you may have to write your own drivers for anything more complex than a UART. I've recently gone back to some of this as I'm working again with old controllers whose dev tools have atrophied. I spent quite a bit of time in the 80s building commercial products with FORTH and Lisp, so I've already climbed up the learning curve. I'm not trying to convince you YOU MUST use FORTH or Lisp, but they're interesting language / environments from a simpler time. ( "This is the tool chain of the Jedi Developer; not as clumsy or random as C++, but an elegant environment for a more civilized age." ) Which is to say... there's still some benefit in learning a little bit about these old systems in that understanding what their constraints and objectives were might help you create evaluation criteria for modern systems.
- uticus 3y ago
  resources for looking into this more (both FORTH and LISP)?
  - dingosity 3y ago
    Aha. One more problem with using FORTH and Lisp for microcontrollers: there don't seem to be very many (any?) sites dedicated to making the language work on micros, just a bunch of sites where people document their own projects. Hmm... I have a couple ESP32 dev boards and a text editor... maybe there's a market for such a site. I think the best you can do is just search for "lisp on <platform>" or "FORTH on <platform>" and see if any of the hits are useful to you.
beardyw 3y ago
It would help to understand the case for scripting vs compiled code. Also for bit-banging speed is essential isn't it?
- RetroTechie 3y ago
  > Also for bit-banging speed is essential isn't it? Maybe, maybe not. Quite a few modern uC's run 100+ MHz, at which point even high level languages become fast. Or have PWM function or even specialized I/O state machines like on RP2040. Or you could call some assembly that does the low-level bitbanging, then process the data in more comfortable language. Things like serial I/O is "check some status bit(s), put byte in memory location, done" on most uC's, I'd think? No reason you can't do that in Python or whatever.

1 points by uticus 3y ago

PaulHoule 3y ago

There are these https://en.wikipedia.org/wiki/BASIC_Stamp https://en.wikipedia.org/wiki/BASIC_Stamp

dingosity 3y ago
I just looked at https://www.parallax.com/ https://www.parallax.com/ and it seems the BASIC Stamps are being EoL'd, but their remaining stock is on sale. The Propeller (the follow-on to the BASIC Stamp) is kind of interesting and the site implies you can run PBASIC code on the Propeller 2 ( you learn something new every day. ) I used a BASIC Stamp way back when and it wasn't a horrible experience. People dis on BASIC, but if you have a simple app, it's not that bad.
- PaulHoule 3y ago
  If you want a scripting language appropriate for that environment I think it's OK. You gotta remember that Microsoft BASIC fit comfortably in real small machines back in the day, like my TRS-80 Color Computer that started out with 4K of RAM including video RAM! Personally though I think even C is too high level for the AVR-8 and like coding assembly with the caveat that there are two ways "up" if you outgrow AVR-8, one route is to go to ARM or ESP32 in which case your C is portable, the other is to go to an FPGA with a soft AVR-8 and talk about playing on hard mode.
  - dingosity 3y ago
    Yup. Chuck Peddle (one of the guys largely responsible for the design of the 6502) did an oral history interview with the CHM (Computer History Museum in Mountain View, CA.) In it he discussed their design process. They thought the market for the 6502 was as a controller (cars, HVAC, instrumentation, etc.), not the CPU of a microcomputer. But then Tiny BASIC came along at exactly the right time and hid the messier 6502 design decisions (zero page, weird addressing modes, 256 byte stack, etc.) from a whole bunch of users. So yes... BASIC is absolutely a contender for small systems. But so are MicroLisp and FORTH. Personally, I prefer Lisp, but completely agree Lisp's learning curve is waaay steeper than BASIC's. Same for FORTH. Here's the video, btw: https://youtu.be/enHF9lMseP8?si=atmDesKCxN9eH_6R https://youtu.be/enHF9lMseP8?si=atmDesKCxN9eH_6R
uticus 3y ago
reminds me of Jazelle (for Java bytecode in ARM hardware) https://en.wikipedia.org/wiki/Jazelle https://en.wikipedia.org/wiki/Jazelle

dingosity 3y ago

I'm sure I'll get downvoted for mentioning this, but FORTH and Lisp are also options. FORTH is exceedingly simple to implement in assembly and has the benefit that it's easily modifiable, informally verifiable (it's easy to look at the code and convince yourself no one has inserted malware), has essentially zero dependencies and is generally space and CPU efficient on small platforms (I implemented 95% of the dpANS FORTH standard on an 8086 in about 8k of opcodes.) On the downside, the FORTH community seems to be shrinking and many people find postfix notation a bit of a brain-twister. While it's "kind of" portable, it's probably not as portable MicroPython. Both FORTH and Lisp "allow" you to build programming constructs other languages provide out of the box. This is a blessing and a curse. If you ever wanted to change the way a for(){} loop worked, it's not uncommon in these languages. If you just want for(){} loops to work out of the box, you may be annoyed by having to check whether the person who wrote the for(){} keyword in your language is doing what you want. (Forth has the LOOP keyword and lisps like fe or micro-lisp have various flavours of if you use to build your own control structures with macros.) I also imagine you may have to write your own drivers for anything more complex than a UART. I've recently gone back to some of this as I'm working again with old controllers whose dev tools have atrophied. I spent quite a bit of time in the 80s building commercial products with FORTH and Lisp, so I've already climbed up the learning curve. I'm not trying to convince you YOU MUST use FORTH or Lisp, but they're interesting language / environments from a simpler time. ( "This is the tool chain of the Jedi Developer; not as clumsy or random as C++, but an elegant environment for a more civilized age." ) Which is to say... there's still some benefit in learning a little bit about these old systems in that understanding what their constraints and objectives were might help you create evaluation criteria for modern systems.

uticus 3y ago
resources for looking into this more (both FORTH and LISP)?
- dingosity 3y ago
  Aha. One more problem with using FORTH and Lisp for microcontrollers: there don't seem to be very many (any?) sites dedicated to making the language work on micros, just a bunch of sites where people document their own projects. Hmm... I have a couple ESP32 dev boards and a text editor... maybe there's a market for such a site. I think the best you can do is just search for "lisp on <platform>" or "FORTH on <platform>" and see if any of the hits are useful to you.

beardyw 3y ago

It would help to understand the case for scripting vs compiled code. Also for bit-banging speed is essential isn't it?

RetroTechie 3y ago
> Also for bit-banging speed is essential isn't it? Maybe, maybe not. Quite a few modern uC's run 100+ MHz, at which point even high level languages become fast. Or have PWM function or even specialized I/O state machines like on RP2040. Or you could call some assembly that does the low-level bitbanging, then process the data in more comfortable language. Things like serial I/O is "check some status bit(s), put byte in memory location, done" on most uC's, I'd think? No reason you can't do that in Python or whatever.