Ruby Arduino Development(rad.rubyforge.org)
rad.rubyforge.org
Ruby Arduino Development
http://rad.rubyforge.org/
6 comments
Thanks for pointing that out.
Looks like ruby2C has been abandoned (Activity Percentile: 0%), which is a shame. High level languages that compile down to C are such a powerful idea, but it's a concept that doesn't seem to get that much attention and traction (developers seem to have given up to either low level languages like C/C++ or higher level languages that limit the portability of their code). The strongest project I'm aware of is ooc [1], which was created and is (currently slowly) developed by some really clever folks, but it could really use some more love.
[1] http://ooc-lang.org
Looks like ruby2C has been abandoned (Activity Percentile: 0%), which is a shame. High level languages that compile down to C are such a powerful idea, but it's a concept that doesn't seem to get that much attention and traction (developers seem to have given up to either low level languages like C/C++ or higher level languages that limit the portability of their code). The strongest project I'm aware of is ooc [1], which was created and is (currently slowly) developed by some really clever folks, but it could really use some more love.
[1] http://ooc-lang.org
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.
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.
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.
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.
I'm not a performance freak, it's just a question of available resources. Your Fez Panda board is an outlier with massive amounts of RAM and flash, and a very high performance core. That .NET embedded framework requires 256K flash, 64K RAM minimum.
Normally I wouldn't care in the slightest what language you use, but I guess you could say I am nervous that interpreted languages would be favoured due to popularity and familiarity rather than sound design decisions, and rapidly take over the embedded market.
Normally I wouldn't care in the slightest what language you use, but I guess you could say I am nervous that interpreted languages would be favoured due to popularity and familiarity rather than sound design decisions, and rapidly take over the embedded market.
Well you can run a VM in much smaller footprints. I can run Java on at Atmega128 for example, with multiple threads, GC, etc. Sun had a reduced JVM running on 2K MSPs (no GC, single-thread). It just depends on how much of the functionality you want, how much of a class library, and where you put the trade-off between speed and memory consumption.
As for features, the chip in the panda costs $13.44 in single quantities, and $8.13 in volume. An Atmega1281 costs $13.12 in single quantities, and $7.32 in volume. I can see how having a .NET runtime built into your chip with a class library to drive all your peripherals is worth a few extra cents.
> Normally I wouldn't care in the slightest what language you use, but I guess you could say I am nervous that interpreted languages would be favoured due to popularity and familiarity rather than sound design decisions, and rapidly take over the embedded market.
I'd say C is currently favored due to popularity and familiarity rather than sound design decisions. Either way, why would you be nervous about global trends? The embedded systems world is easy to predict, it's always 10-20 years behind the rest. We'll be programming in JavaScript before long :D
source:
http://search.digikey.com/scripts/DkSearch/dksus.dll?Cat=255... http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&...
As for features, the chip in the panda costs $13.44 in single quantities, and $8.13 in volume. An Atmega1281 costs $13.12 in single quantities, and $7.32 in volume. I can see how having a .NET runtime built into your chip with a class library to drive all your peripherals is worth a few extra cents.
> Normally I wouldn't care in the slightest what language you use, but I guess you could say I am nervous that interpreted languages would be favoured due to popularity and familiarity rather than sound design decisions, and rapidly take over the embedded market.
I'd say C is currently favored due to popularity and familiarity rather than sound design decisions. Either way, why would you be nervous about global trends? The embedded systems world is easy to predict, it's always 10-20 years behind the rest. We'll be programming in JavaScript before long :D
source:
http://search.digikey.com/scripts/DkSearch/dksus.dll?Cat=255... http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&...
You're right on the price comparison. I don't actually use the ATmegas, they are just popular, which is why I discussed them. I personally prefer MSP430's most of the time, which can be had as cheaply as $0.50
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.
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.
As far as I understand it, it compiles a subset of Ruby to C. It is a real subset of Ruby because it does not support meta-programming.
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?
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?
The project is under active development on Github: https://github.com/atduskgreg/rad
That doesn't look very active to me. Four commits over the last 2 years, with none of them touching actual code.
You aren't skilled in the art of using Github
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
[deleted]
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.
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.
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?
What's the benefit? Can you leverage any Ruby libraries? Or is it Arduino development with Ruby syntax?
It may get some flak, but I think it is a very cool project.
Dare I ask if a Python version will become available?
Dare I ask if a Python version will become available?
Check out Python-on-a-chip, p14p:
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.
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.
http://ruby2c.rubyforge.org/
A nice introduction:
http://ruby2c.rubyforge.org/svn/ruby_to_c/propaganda/Ruby2C....