
Ruby Arduino Development - freedrull
http://rad.rubyforge.org/
======
gvb
Looking at the code, it is based on RubyToAnsiC

<http://ruby2c.rubyforge.org/>

A nice introduction:

[http://ruby2c.rubyforge.org/svn/ruby_to_c/propaganda/Ruby2C....](http://ruby2c.rubyforge.org/svn/ruby_to_c/propaganda/Ruby2C.pdf)

~~~
sliverstorm
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.

~~~
inoop
_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.

~~~
sliverstorm
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.

~~~
inoop
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?Cat=2556109&k=lpc2387)
[http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&...](http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=ATMEGA1281-16AU-
ND)

~~~
sliverstorm
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

------
lgeek
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?

~~~
atduskgreg
The project is under active development on Github:
<https://github.com/atduskgreg/rad>

~~~
k33l0r
That doesn't look very active to me. Four commits over the last 2 years, with
none of them touching actual code.

~~~
maxogden
You aren't skilled in the art of using Github

~~~
bleusink
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>

------
sigil
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.

------
viraptor
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
What's the benefit? Can you leverage any Ruby libraries? Or is it Arduino
development with Ruby syntax?

------
lagola3000
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
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.

