5 ms·

Mruby/C and picoruby: high level langs in low-level devices?

70 points by rahil627 2y ago

rahil627 2y ago
some people hate to use C. Some people embrace it, even love it (including many game devs!). You have full control! But i wonder, what do HN folks think about these pico implementations of ruby, a complex language made for the tiniest devices, such as sensors? I mean.. is C really that bad?? also, it's very cool they're still being maintained!
- pjmlp 2y ago
  It is a return to the age when we had BASIC and Z80/6502 Assembly, and yes doing memcpy/strcpy all over the place instead of having proper arrays and strings is that bad. At very least, C++. "C++14 For The Commodore 64" https://www.youtube.com/watch?v=nLv_INgaLq8 https://www.youtube.com/watch?v=nLv_INgaLq8
  - RossBencina 2y ago
    > doing memcpy/strcpy all over the place instead of having proper arrays and strings is that bad This presupposes that you're doing string manipulation and raw memory moves. I don't know about other people's code, but in my own experience neither of those things are likely to be happening in embedded code. You're much more likely to pre-allocate all your memory, and use zero-copy patterns where ever possible. I never used a C-string in relation to talking to peripherals (i2c, spi, register mapped) or when doing dsp. Moreover, if you do need to use memcpy it's probably because you are doing something very low level for which memcpy is the best choice.
    - pjmlp 2y ago
      What is embedded nowadays was a home computer in 1980's, so maybe you aren't, as someone that started coding on a Timex 2068, I very much doubt that in general. MISRA and similar exists for a reason.
- deleted 2y ago
  [deleted]
- knowitnone 2y ago
  Then you should use assembly. I mean..is assembly really that bad?
  - rahil627 2y ago
    no. assembly really is that bad.
- nine_k 2y ago
  Make a few small mistakes, even typos, and C becomes really that bad, because you have full control, no restraints, few guard rails. C trades very fast execution for rather slow development, especially of larger code bases, if you want correctness. It's fine for tiny programs though. (Ruby, of course, has its own set of jolly footguns, as any dynamically typed language.)
- RossBencina 2y ago
  I don't think C is bad at all. One good thing about C is that the language is quite minimal, the same can not be said for the current batch of contenders (Zig, Rust). Another good thing about C is that it has strong separation of language standard from implementations, with many implementations provided by diverse suppliers. I also prefer the "batteries not included" philosophy. Obviously C is not without warts (e.g. logical operators precedence). I will leave it to others to fill out the cons. One obvious one is that C does not reflect the parallel compute nature of modern targets (e.g. SIMD) but neither do most serious alternatives. I do think the time is coming (if not already here) where it would be judged legally negligent to professionally employ C in new systems for certain use-cases (network facing, high assurance, ...). At least not without complete formal verification. I'll leave it to the actuaries to work out where the tipping point is.
jononor 2y ago
Will have to look closer at picoruby. I do love MicroPython development. One support thing is how easy it is to combine with C, because to get the most out of microcontroller devices one really needs to use low-level languages from time to time.
bsder 2y ago
256KB ROM/128KB RAM isn't very small. That is larger than the average computer through about 1990 ... (I know people will say I'm being pedantic. However, RAM and Flash define most of the price of a microcontroller. So, a factor of two--especially in RAM--means a significantly smaller and cheaper chip.)
- connicpu 2y ago
  Depends on use case for sure, though I'm not sure why you'd want an interpreted language on a microcontroller unless you had plans to be able to execute dynamically loaded code in the field, which probably means it has some kind of network connection, and 256KB ROM/128KB RAM isn't too big for your Espressif chips and such.
  - bsder 2y ago
    > I'm not sure why you'd want an interpreted language on a microcontroller Using a microcontroller to interrogate itself is a really valuable debugging technique. Generally, you have attach to a UART port and attach a terminal emulator. This is especially important when considering the plethora of sleep modes that now exist for modern SoCs. Debug probes generally put the chip in maximum performance mode which often wipes out the state your trying to debug (especially important for sleep bugs).
- tecleandor 2y ago
  Yeah, but 1990 was 35 years ago and Ruby even didn't exist. And the average computer was quite bigger than a RP2040, and consumed much more power :) I mean, it's very difficult to compare those things. It's a high level language runtime weighting a very small fraction of the JavaScript we're loading on any silly webpage, and we can run in on an stamp sized microcontroller that costs a couple dollars and you'd typically need to program using a relatively low level language. I think it's neat. Edit: I was trying to remember our computer then. I think we already had an Amstrad PC1512 with 512KB of RAM by '87 or '88, and by 1990 the 286s with 1 or 2MB of RAM were already common.
  - 2y ago
xutopia 2y ago
You can look at the documentation on their web site too: https://picoruby.github.io https://picoruby.github.io
TkTech 2y ago
If this kind of stuff interests you, you may also like micropython[1], which is currently overwhelmingly dominate in this niche. 1: https://github.com/micropython/micropython https://github.com/micropython/micropython
aidog 2y ago
picoruby is a lot of fun. It's a reimplementation of mruby/c which is even smaller. You might be interested in my friend and creator HASUMI Hitoshi's presentation. He shows off his Ruby REPL that runs on the Raspberry Pi pico. Recently he ported picoruby to other microcontrollers. https://youtu.be/WxZNE5zTAjg?si=7DQUcQg80RMZoU0b https://youtu.be/WxZNE5zTAjg?si=7DQUcQg80RMZoU0b
- rahil627 2y ago
  thank you for this!! I <3 Taiwan. lol star wars font. I knew he was special from his GitHub photo XD
- rahil627 2y ago
  oooooooooooh snap! irb/ruby repl on a micro-controller is soooo sick!!
actionfromafar 2y ago
Time to mention Shedskin Python to C++ compiler!
deleted 2y ago
[deleted]
throwaway81523 2y ago
No idea about mruby/C or picoruby but MicroPython is very popular, enough that I'd just settle on it for devices can handle it. It runs nicely in 256k of flash and 32k of ram, on the small adafruit trinket devices. It was shoehorned into the v1 BBC microbit which had 256k of flash and just 16k of ram, but that was apparently painful. Smaller include Lua and maybe Hedgehog Lisp. Below that there is ulisp but that is sort of a toy. Also there is Javacard and J2ME depending on device size. Below that you're probably best off forgoing garbage collection and using Forth or a cross compiled language.
- rahil627 2y ago
  ah yeah, i forgot about Lua! that's def the way to go.
calebh 2y ago
I'm the developer of Juniper, a functional reactive programming language for the Arduino. It's very possible to run high level code on small devices. This even includes things like closures, which Juniper allocates on the stack! https://www.juniper-lang.org/ https://www.juniper-lang.org/
- rahil627 2y ago
  eyyyyy F#! microsoft's best language. hmmm, transpiling to C/C++ def makes sense! I'd wonder if haxe (lang) would work fine too then..! very cool project!

70 points by rahil627 2y ago

some people hate to use C. Some people embrace it, even love it (including many game devs!). You have full control! But i wonder, what do HN folks think about these pico implementations of ruby, a complex language made for the tiniest devices, such as sensors? I mean.. is C really that bad?? also, it's very cool they're still being maintained!

pjmlp 2y ago
It is a return to the age when we had BASIC and Z80/6502 Assembly, and yes doing memcpy/strcpy all over the place instead of having proper arrays and strings is that bad. At very least, C++. "C++14 For The Commodore 64" https://www.youtube.com/watch?v=nLv_INgaLq8 https://www.youtube.com/watch?v=nLv_INgaLq8
- RossBencina 2y ago
  > doing memcpy/strcpy all over the place instead of having proper arrays and strings is that bad This presupposes that you're doing string manipulation and raw memory moves. I don't know about other people's code, but in my own experience neither of those things are likely to be happening in embedded code. You're much more likely to pre-allocate all your memory, and use zero-copy patterns where ever possible. I never used a C-string in relation to talking to peripherals (i2c, spi, register mapped) or when doing dsp. Moreover, if you do need to use memcpy it's probably because you are doing something very low level for which memcpy is the best choice.
  - pjmlp 2y ago
    What is embedded nowadays was a home computer in 1980's, so maybe you aren't, as someone that started coding on a Timex 2068, I very much doubt that in general. MISRA and similar exists for a reason.
deleted 2y ago
[deleted]
knowitnone 2y ago
Then you should use assembly. I mean..is assembly really that bad?
- rahil627 2y ago
  no. assembly really is that bad.
nine_k 2y ago
Make a few small mistakes, even typos, and C becomes really that bad, because you have full control, no restraints, few guard rails. C trades very fast execution for rather slow development, especially of larger code bases, if you want correctness. It's fine for tiny programs though. (Ruby, of course, has its own set of jolly footguns, as any dynamically typed language.)
RossBencina 2y ago
I don't think C is bad at all. One good thing about C is that the language is quite minimal, the same can not be said for the current batch of contenders (Zig, Rust). Another good thing about C is that it has strong separation of language standard from implementations, with many implementations provided by diverse suppliers. I also prefer the "batteries not included" philosophy. Obviously C is not without warts (e.g. logical operators precedence). I will leave it to others to fill out the cons. One obvious one is that C does not reflect the parallel compute nature of modern targets (e.g. SIMD) but neither do most serious alternatives. I do think the time is coming (if not already here) where it would be judged legally negligent to professionally employ C in new systems for certain use-cases (network facing, high assurance, ...). At least not without complete formal verification. I'll leave it to the actuaries to work out where the tipping point is.

jononor 2y ago

Will have to look closer at picoruby. I do love MicroPython development. One support thing is how easy it is to combine with C, because to get the most out of microcontroller devices one really needs to use low-level languages from time to time.

bsder 2y ago

256KB ROM/128KB RAM isn't very small. That is larger than the average computer through about 1990 ... (I know people will say I'm being pedantic. However, RAM and Flash define most of the price of a microcontroller. So, a factor of two--especially in RAM--means a significantly smaller and cheaper chip.)

connicpu 2y ago
Depends on use case for sure, though I'm not sure why you'd want an interpreted language on a microcontroller unless you had plans to be able to execute dynamically loaded code in the field, which probably means it has some kind of network connection, and 256KB ROM/128KB RAM isn't too big for your Espressif chips and such.
- bsder 2y ago
  > I'm not sure why you'd want an interpreted language on a microcontroller Using a microcontroller to interrogate itself is a really valuable debugging technique. Generally, you have attach to a UART port and attach a terminal emulator. This is especially important when considering the plethora of sleep modes that now exist for modern SoCs. Debug probes generally put the chip in maximum performance mode which often wipes out the state your trying to debug (especially important for sleep bugs).
tecleandor 2y ago
Yeah, but 1990 was 35 years ago and Ruby even didn't exist. And the average computer was quite bigger than a RP2040, and consumed much more power :) I mean, it's very difficult to compare those things. It's a high level language runtime weighting a very small fraction of the JavaScript we're loading on any silly webpage, and we can run in on an stamp sized microcontroller that costs a couple dollars and you'd typically need to program using a relatively low level language. I think it's neat. Edit: I was trying to remember our computer then. I think we already had an Amstrad PC1512 with 512KB of RAM by '87 or '88, and by 1990 the 286s with 1 or 2MB of RAM were already common.
- 2y ago

xutopia 2y ago

You can look at the documentation on their web site too: https://picoruby.github.io https://picoruby.github.io

TkTech 2y ago

If this kind of stuff interests you, you may also like micropython[1], which is currently overwhelmingly dominate in this niche. 1: https://github.com/micropython/micropython https://github.com/micropython/micropython

aidog 2y ago

picoruby is a lot of fun. It's a reimplementation of mruby/c which is even smaller. You might be interested in my friend and creator HASUMI Hitoshi's presentation. He shows off his Ruby REPL that runs on the Raspberry Pi pico. Recently he ported picoruby to other microcontrollers. https://youtu.be/WxZNE5zTAjg?si=7DQUcQg80RMZoU0b https://youtu.be/WxZNE5zTAjg?si=7DQUcQg80RMZoU0b

rahil627 2y ago
thank you for this!! I <3 Taiwan. lol star wars font. I knew he was special from his GitHub photo XD
rahil627 2y ago
oooooooooooh snap! irb/ruby repl on a micro-controller is soooo sick!!

actionfromafar 2y ago

Time to mention Shedskin Python to C++ compiler!

deleted 2y ago

[deleted]

throwaway81523 2y ago

No idea about mruby/C or picoruby but MicroPython is very popular, enough that I'd just settle on it for devices can handle it. It runs nicely in 256k of flash and 32k of ram, on the small adafruit trinket devices. It was shoehorned into the v1 BBC microbit which had 256k of flash and just 16k of ram, but that was apparently painful. Smaller include Lua and maybe Hedgehog Lisp. Below that there is ulisp but that is sort of a toy. Also there is Javacard and J2ME depending on device size. Below that you're probably best off forgoing garbage collection and using Forth or a cross compiled language.

rahil627 2y ago
ah yeah, i forgot about Lua! that's def the way to go.

calebh 2y ago

I'm the developer of Juniper, a functional reactive programming language for the Arduino. It's very possible to run high level code on small devices. This even includes things like closures, which Juniper allocates on the stack! https://www.juniper-lang.org/ https://www.juniper-lang.org/

rahil627 2y ago
eyyyyy F#! microsoft's best language. hmmm, transpiling to C/C++ def makes sense! I'd wonder if haxe (lang) would work fine too then..! very cool project!