5 ms·

Ruby Arduino Development

61 points by freedrull 15y ago

lagola3000 15y ago
It may get some flak, but I think it is a very cool project. Dare I ask if a Python version will become available?
- angusgr 15y ago
  Check out Python-on-a-chip, p14p: http://code.google.com/p/python-on-a-chip/ http://code.google.com/p/python-on-a-chip/ Similar idea, although the VM in this case runs on the micro. Last I looked Arduinos had not enough RAM, but some similar boards like Teensy++ did (I actually contributed a proof-of-concept Teensy++ port.) However since then apparently lots of RAM-size optimisations have been added.
lgeek 15y ago
Note, the latest release is from 2008. Edit: "Do you run the Arduino development tool chain on an obscure (i.e., non-OS X) platform?" is a gratuitously condescending in my opinion. Since when's OS X the default/most popular/whatever platform for doing GCC development?
- deleted 15y ago
  [deleted]
- atduskgreg 15y ago
  The project is under active development on Github: https://github.com/atduskgreg/rad https://github.com/atduskgreg/rad
  - k33l0r 15y ago
    That doesn't look very active to me. Four commits over the last 2 years, with none of them touching actual code.
    - maxogden 15y ago
      You aren't skilled in the art of using Github
      - bleusink 15y ago
        What maxogden probably means is that if you look at the Network tab in github, you can see there are multiple active forks. This is the most active one I could find: https://github.com/seips-net/rad https://github.com/seips-net/rad
gvb 15y ago
Looking at the code, it is based on RubyToAnsiC http://ruby2c.rubyforge.org/ http://ruby2c.rubyforge.org/ A nice introduction: http://ruby2c.rubyforge.org/svn/ruby_to_c/propaganda/Ruby2C.pdf http://ruby2c.rubyforge.org/svn/ruby_to_c/propaganda/Ruby2C....
- sliverstorm 15y ago
  Thank god. The day Python and Ruby interpreters are being regularly run on microcontrollers... I will not be happy on that day. Why, you ask? Recall if you will that most ATmega chips, for example, run at 8MHz. Also recall that the Intel 8088 (the brain of the IBM PC) peaks at 10MHz - AND it's 16 bit.
  - msarnoff 15y ago
    The ATmegas can run at up to 20 MHz, and since most instructions are single-cycle, they can approach 20 MIPS. Most Arduinos are clocked at 16 MHz. Memory is the bigger issue, the most popular Arduino variant has 2K of RAM and under 32K of program memory. I wouldn't be surprised if the implementations of Ruby's library functions and data structures (array, hash, etc.) eat up most of it.
  - inoop 15y ago
    sigh It's such a shame that the current embedded systems crowd keeps beating this dead horse. Performance is not the only metric by which to quantify the performance of a system. Any engineer worth his salt knows that everything is a trade-off, and there are many, many projects where embedding an interpreter is a good choice. It can buy you things like design agility, memory safety (robustness, security), run-time linking (remote code updates), garbage collection (robustness), green threads (maintainability due to separation of concerns, memory-efficient if done correctly) In terms of cost, an interpreting JVM will typically be 20x-100x slower than equivalent C code depending on the application (although technically C doesn't do automatic bounds checking and isn't type safe, so it's not really equivalent). Garbage collection often introduces pause times as embedded GC tends to be less complicated than server-grade, but you can still implement time-critical stuff in C. For example, the .NET/TinyCLR based Fez Panda board has no problems doing one-wire because of this. Finally, you tend to be less memory efficient because your high-level language might be OO, doesn't know about bytes/shorts/ints but rather just has the type 'Number', and because of GC. If you blindly follow the 'performance is everything' mantra, you forget that there is a whole slew of applications where you really don't need 20MHz, and where things like robustness and security are way more important than real-time. The few extra K of memory for the micro might cost you a couple of extra cents, but it can save you a lot of development time. Depending on the volume this might be an appropriate choice.
viraptor 15y ago
I can't find a single reference to memory management, which is a really bad sign for a project using small chips. If I can't guarantee that the loaded program will not overflow, what's the point?
iam 15y ago
What's the benefit? Can you leverage any Ruby libraries? Or is it Arduino development with Ruby syntax?
sigil 15y ago
Might be nice for prototyping. I've never been a big fan of the Arduino programming language. It's a thin veneer over C that insulates newbies from "scary" things like port i/o bit twiddling, while not really moving the dial on language expressiveness or presenting a familiar face. Ruby has a shot at both of these. That said -- this is pretty much unimaginable for my current embedded development projects, where C compiler tricks have been the name of the game for some time now. Add a feature, exceed the 8K program memory limit, find something to optimize, repeat. Injecting a Ruby-to-C compiler into this loop would be madness.

61 points by freedrull 15y ago

lagola3000 15y ago

It may get some flak, but I think it is a very cool project. Dare I ask if a Python version will become available?

angusgr 15y ago
Check out Python-on-a-chip, p14p: http://code.google.com/p/python-on-a-chip/ http://code.google.com/p/python-on-a-chip/ Similar idea, although the VM in this case runs on the micro. Last I looked Arduinos had not enough RAM, but some similar boards like Teensy++ did (I actually contributed a proof-of-concept Teensy++ port.) However since then apparently lots of RAM-size optimisations have been added.

lgeek 15y ago

Note, the latest release is from 2008. Edit: "Do you run the Arduino development tool chain on an obscure (i.e., non-OS X) platform?" is a gratuitously condescending in my opinion. Since when's OS X the default/most popular/whatever platform for doing GCC development?

deleted 15y ago
[deleted]
atduskgreg 15y ago
The project is under active development on Github: https://github.com/atduskgreg/rad https://github.com/atduskgreg/rad
- k33l0r 15y ago
  That doesn't look very active to me. Four commits over the last 2 years, with none of them touching actual code.
  - maxogden 15y ago
    You aren't skilled in the art of using Github
    - bleusink 15y ago
      What maxogden probably means is that if you look at the Network tab in github, you can see there are multiple active forks. This is the most active one I could find: https://github.com/seips-net/rad https://github.com/seips-net/rad

gvb 15y ago

Looking at the code, it is based on RubyToAnsiC http://ruby2c.rubyforge.org/ http://ruby2c.rubyforge.org/ A nice introduction: http://ruby2c.rubyforge.org/svn/ruby_to_c/propaganda/Ruby2C.pdf http://ruby2c.rubyforge.org/svn/ruby_to_c/propaganda/Ruby2C....

sliverstorm 15y ago
Thank god. The day Python and Ruby interpreters are being regularly run on microcontrollers... I will not be happy on that day. Why, you ask? Recall if you will that most ATmega chips, for example, run at 8MHz. Also recall that the Intel 8088 (the brain of the IBM PC) peaks at 10MHz - AND it's 16 bit.
- msarnoff 15y ago
  The ATmegas can run at up to 20 MHz, and since most instructions are single-cycle, they can approach 20 MIPS. Most Arduinos are clocked at 16 MHz. Memory is the bigger issue, the most popular Arduino variant has 2K of RAM and under 32K of program memory. I wouldn't be surprised if the implementations of Ruby's library functions and data structures (array, hash, etc.) eat up most of it.
- inoop 15y ago
  sigh It's such a shame that the current embedded systems crowd keeps beating this dead horse. Performance is not the only metric by which to quantify the performance of a system. Any engineer worth his salt knows that everything is a trade-off, and there are many, many projects where embedding an interpreter is a good choice. It can buy you things like design agility, memory safety (robustness, security), run-time linking (remote code updates), garbage collection (robustness), green threads (maintainability due to separation of concerns, memory-efficient if done correctly) In terms of cost, an interpreting JVM will typically be 20x-100x slower than equivalent C code depending on the application (although technically C doesn't do automatic bounds checking and isn't type safe, so it's not really equivalent). Garbage collection often introduces pause times as embedded GC tends to be less complicated than server-grade, but you can still implement time-critical stuff in C. For example, the .NET/TinyCLR based Fez Panda board has no problems doing one-wire because of this. Finally, you tend to be less memory efficient because your high-level language might be OO, doesn't know about bytes/shorts/ints but rather just has the type 'Number', and because of GC. If you blindly follow the 'performance is everything' mantra, you forget that there is a whole slew of applications where you really don't need 20MHz, and where things like robustness and security are way more important than real-time. The few extra K of memory for the micro might cost you a couple of extra cents, but it can save you a lot of development time. Depending on the volume this might be an appropriate choice.

viraptor 15y ago

I can't find a single reference to memory management, which is a really bad sign for a project using small chips. If I can't guarantee that the loaded program will not overflow, what's the point?

iam 15y ago

What's the benefit? Can you leverage any Ruby libraries? Or is it Arduino development with Ruby syntax?

sigil 15y ago

Might be nice for prototyping. I've never been a big fan of the Arduino programming language. It's a thin veneer over C that insulates newbies from "scary" things like port i/o bit twiddling, while not really moving the dial on language expressiveness or presenting a familiar face. Ruby has a shot at both of these. That said -- this is pretty much unimaginable for my current embedded development projects, where C compiler tricks have been the name of the game for some time now. Add a feature, exceed the 8K program memory limit, find something to optimize, repeat. Injecting a Ruby-to-C compiler into this loop would be madness.