[SURVEY] Ruby in embedded applications

[treefrog]

Hi folks,
I'm interested in finding out how widespread the use of Ruby is in
embedded applications. Perhaps you do development for a jukebox
manufacturer who uses Ruby to handle playlists, billing etc. with a C
library doing all the driver stuff

So, if you do embedded development (or work with people who do) I'd be
interested in:
1. Do you use Ruby in embedded applications.
2. If not do you use use Perl or Python instead (why?)
3. Would you use Ruby if "they" let you?

Best regards,

treefrog

 

[Keith Nicholas]

We use uCLinux....which there is a python port for....But no ruby port
that I know of....If there was a ruby port we'd probablly use it.=20
Mainly, of course, we use C++.

 

[Thomas Sondergaard]

I took a look at embedding ruby but went with mozilla's
javascript-engine called spidermonkey instead because

* Spidermonkey is just one .dll/.so. It may be possible to reduce ruby's
interpreter to just that, but it doesn't come like that out of the box (rpm)
* I can run as many javascript interpreters as I want and start and stop
them when I want and reinitialize them.
* Threading is supported

Thomas

 

[Kev Jackson]

We've just got an embedded project involving C + RTL? (some kind of
FPGA/ASIC definition language), and SWIG. I've convinced the people
involved that C will be fine for low-level stuff, but for the
application logic we should use a high-level language to minimize our
effort (memory management etc). I'm pretty sure that we'll be using
ruby (project lead is a fan of Why's guide). As for why we chose/are
considering ruby - no compilation (we're both sick of that damn compile
phase), support from SWIG interfaces, easily interface with C libraries
etc, clean OO.

Kev

 

[Daniel Amelang]

For most RTOS apps, support for native threading is a must, which
eliminates ruby right away

Besides that, one of the points of a RTOS is immediate response
(talking microseconds here) to hardware interrupts. I end up having to
fine-tune my C/assembly to keep the response snappy.

Of course, there are many cases where ruby does make sense an embedded
environment, I just haven't come across any of them. I hope to someday


Dan

 

[Joel VanderWerf]

Hi folks,
I'm interested in finding out how widespread the use of Ruby is in
embedded applications. Perhaps you do development for a jukebox
manufacturer who uses Ruby to handle playlists, billing etc. with a C
library doing all the driver stuff

Well, tangentially...

We're using ruby for a customized IP transport layer and for messaging
services that will function as a platform for distributed applications
for vehicle-infrastructure communication based on DSRC wireless at the
roadside and GPRS cellular modems for backhaul. The applications are
being developed by several car companies, OEMs, and a traffic probe data
consulting co. The idea is to do everything from getting restaurant and
traffic info to the driver to automated diagnostics and support to
safety alerts.

Ruby is running on the roadside boxes (running RTLinux, sitting in
signal controller cabinets, so it's sorta embedded) and on a message
exchange server, and probably also some test vehicles. The partner
companies will be using our C library to send and receive messages
between their cars and their servers, but ruby is in the middle.

It's not for production code, just for a demo at the ITS World Congress
in S.F. involving 10s of cars and about 40 roadside units (wireless
access points).

In future projects, we may be moving some of the ruby code into a C
driver, but I will argue for keeping the higher level logic in ruby.
Also, we have another project to develop the lower DSRC protocol layers
in FPGA. (DSRC is the band designated for roadway communication.)

 

[Phil Tomson]

Hi folks,
I'm interested in finding out how widespread the use of Ruby is in
embedded applications. Perhaps you do development for a jukebox
manufacturer who uses Ruby to handle playlists, billing etc. with a C
library doing all the driver stuff

So, if you do embedded development (or work with people who do) I'd be
interested in:
1. Do you use Ruby in embedded applications.
2. If not do you use use Perl or Python instead (why?)
3. Would you use Ruby if "they" let you?

I haven't used Ruby in embedded applications simply because I haven't had
the opportunity.

But mostly I wanted to ask a question of you based on your return email
address: Will we be seeing Ruby show up in any Motorola phones someday
soon?

Phil

 

[Phil Tomson]

We've just got an embedded project involving C + RTL? (some kind of
FPGA/ASIC definition language), and SWIG. I've convinced the people
involved that C will be fine for low-level stuff, but for the
application logic we should use a high-level language to minimize our
effort (memory management etc). I'm pretty sure that we'll be using
ruby (project lead is a fan of Why's guide). As for why we chose/are
considering ruby - no compilation (we're both sick of that damn compile
phase), support from SWIG interfaces, easily interface with C libraries
etc, clean OO.

This sounds really interesting - are you at liberty to provide more
details?

Reading between the lines of your post: It would seem that you're
developing an ASIC or FPGA with an embedded CPU and then you plan to run
the Ruby interpreter on that CPU?

Phil

 

[Kev Jackson]

This sounds really interesting - are you at liberty to provide more
details?

A few more, we have the project, but the docs are in Japanese so some of
the details are a little bit vague (at least for me!)

It's a small project for the company (who I won't mention) to test
off-shore development here in Vietnam. They have a processor (ASIC/FPGA
still unclear exactly about it) that performs some kind of image
processing. They have an original set of test data in a special format
which can be read using RTL (this is the vague bit). They have another
algorithm (in C this time), but they don't have any test data.

Our task is to create compatible data for both the RTL version and the C
version (using the RTL data as as starting point). After that we have
to run both algorithms with the data set and compare output
(algorithmically). Finally we have to actually look at the images and
ensure we can't "see" any artefacts. The comparator program should be
fairly easy (at least in Ruby), converting the data will be the tricky part.

Reading between the lines of your post: It would seem that you're
developing an ASIC or FPGA with an embedded CPU and then you plan to run
the Ruby interpreter on that CPU?

Phil

Nope, not quite and not really embedded ruby at all, just Ruby to
test an embedded processor (at least that's my understanding of the
translated docs so far)

 

[Daniel Kelley]

I'm interested in finding out how widespread the use of Ruby is in
embedded applications. Perhaps you do development for a jukebox
manufacturer who uses Ruby to handle playlists, billing etc. with a C
library doing all the driver stuff

So, if you do embedded development (or work with people who do) I'd be
interested in:
1. Do you use Ruby in embedded applications.
2. If not do you use use Perl or Python instead (why?)
3. Would you use Ruby if "they" let you?

I'm using ruby in an embedded Ethernet switch application as a
replacement (or adjuct, really, it's damn hard to dislodge a ton of
TCL code!) to a TCL API test application, so it's not delivered with
the product, but embedded in a test mode and used internally.

d.k.

 

[Kero]

I'm interested in finding out how widespread the use of Ruby is in
I have Ruby running on iPAQ (linux) for years!

'coz I laid my hands on ruby and the ipaq roughly at the same time.
python is used much more heavily by the handhelds.org/familiar distro.

Familiar is open enough. I provided ruby packages for it

But mostly I wanted to ask a question of you based on your return email
address: Will we be seeing Ruby show up in any Motorola phones someday
soon?

Give me any smartphone running linux and I'll put ruby on it.
There are definitely (some) speed issues in this area, but give it some time
and they'll go away (yarv, even faster hardware).

+--- Kero ------------------------- kero@chello@nl ---+
| all the meaningless and empty words I spoke |
| Promises -- The Cranberries |
+--- M38c --- http://members.chello.nl/k.vangelder ---+

 

[treefrog]

Dan,
thanks for your response. Embedded isn't all RTOS - our network
products have some RTOS stuff on them (anything involving GSM / GPRS
has some pretty tight timing windows), but a lot of it has no strict
real time limits. So I guess I'm interested in where and how Ruby could
be used in an emedded context.

Why do you think that native threading is so important?

Best regards, treefrog

 

[treefrog]

Hi Phil,
I'm on the wrong sid eof Motorola - I do networks not phones :-( But
the last time I asked i was told Java and BREW only. I guess JRuby is
the only option at the moment.

Best regards, treefrog

 

[Daniel Amelang]

Dan,

thanks for your response. Embedded isn't all RTOS - our network
products have some RTOS stuff on them (anything involving GSM / GPRS
has some pretty tight timing windows), but a lot of it has no strict
real time limits. So I guess I'm interested in where and how Ruby could
be used in an emedded context.

My guess is wherever you don't need tight timing windows
Interfacing with the hardware at the very low level (like reading
from/writing to specific hard-wired memory addresses) is a harder too
(in ruby) but I guess you could create a C extension for that, too.
=20

Why do you think that native threading is so important?

All the embedded development I do is on a RTOS, where you have a large
number of threads running concurrently (normally waiting on their
various signals/interrupts). Ruby currently couldn't reproduce this
behavior because it doesn't have native threads. You can't
simultaneously block on multiple interrupts in ruby. Even if I spawned
the native threads in a C extension, I'd run into problems because
ruby isn't reentrant. Just think of all the async signals in a typical
RTOS app. Your ISRs can't run any ruby code because of the lack of
reentracy in the interpreter.

Even with reentracy, you'll end up writing C extensions for
interfacing with your IO devices, handling your interrupts, and your
tight timing windows. By then, you may have run out of parts of your
app to code in ruby. Maybe not. For what I've done in the embedded
world, there hasn't been much left for ruby to do.

But, like I said in my first post, (and you pointed out in your
reply), my scenario is not representative of all embedded development.
I'm just responding to your survey.

Dan