Parallel Programming for Tiny Computers

Ubuntu packages ready for testing

2010-07-19T03:24:00

I can't say that they're perfect, nor can I say that they would make it into the Ubuntu repository. I made these packages, and by "made" I mean "hammered them out of a block of granite until they were so many tiny little shards of granite all over the place." They are not art, they are not to be admired.

But, they do seem to work on the one virtual machine that I have tested them on over and over. And, so far, I haven't removed anything from my system or left it in an inoperable state. Yet.

To use this thing of beauty

Under Ubuntu, you should be able to install our package and have all requirements automatically installed. Java, some tools for Arduino programming, and a number of other packages end up being installed. To get started, you need to add our dev repository to your apt sources:

sudo vim /etc/apt/sources.list

(Feel free to use your editor of choice.) Next, you need to add our repository. This depends on your version of Ubuntu; you can find out what to use by running the following:

uname -a

~~Lucid Lynx (10.04), amd64~~
~~This is a 64-bit version of the most recent Ubuntu. Add this line:~~
deb http://download.transterpreter.org/files/dev/ubuntu/lucid/amd64 binary/
64-bit packages will be updated after OSCON.
Lucid Lynx (10.04), i386/686
This is a 32-bit version of the most recent Ubuntu. Add this line:
deb http://download.transterpreter.org/files/dev/ubuntu/lucid/i386 binary/
Jaunty Jackalope (9.04), i386/686
This is a 32-bit version of the last version of Ubuntu. Add this line:
deb http://download.transterpreter.org/files/dev/ubuntu/jaunty/i386 binary/

After you add that to your sources.list, you should be able to run:

sudo apt-get update

You can install our meta-package, which will pull in several more:

sudo apt-get install occam-pi

This pulls in packages for a native version of occam-pi, a version running on our virtual machine (called the Transterpreter), a version for the Arduino, and a plug-in for jEdit that we call occPlug. they are all prefixed with the name occam-pi, so they are easy to find if you want to get rid of them.

Note: We will, someday, be updating these packages, or even (hopefully) getting source packages into the Ubuntu repositories. When that happens, the repository you just added will need to be removed. But, we don't expect that to happen before the new year, so rest easy.

Using occam-pi

On the command-line, type:

jedit

Now, go to the Plugins menu, find occPlug, and say Start occPlug. After it opens up, close jEdit.

After you have started the occPlug, and closed jEdit, go ahead and open it again and continue. (The first time you run the occPlug, it does some configuration that we shouldn't do in the package.)

At this point, you can start exploring the book... but, note, it needs some updating. That's next on the list as we finish getting ready for OSCON. In the meantime, you can look at the examples in our OSCON examples directory, which all work against the newest versions of Plumbing.

Let us know how you get on on the users mailing list; your feedback is very welcome.

Driving a servo with Plumbing

2010-07-09T03:24:00

We have been tearing things apart in the Plumbing libraries over the past two weeks. Specifically, we've been separating out concerns -- we keep asking "is this code architecture specific, or platform specific?" This is a hard question, as we're trying to cleanly support multiple platforms (Arduino, Arduino Mega, Seeeduino Mega, and the ArduPilot Mega) while also supporting multiple architectures (The ATmega328 and ATmega1280).

Drew and Radu recently worked out servo control via PWM. This lets us set up servos, set their position, and then "walk away." While it limits the number of servos we can control on a given platform, it does mean that we get robust control of the servo without a lot of work on our part.

A servo, or tiny motor.

Here's some example code Drew committed to the repository to demonstrate usage (and test his implementation a bit).

Driving a servo.

In parallel, Drew is executing three processes. First is the hearbeat() process. This blinks the Arduino's LED on and off, letting us know nothing has crashed. (All robots should have a heartbeat.) The second process running is the servo process, which takes two parameters: a pin and a channel. Drew has declared the channel s as being of type SERVO, which we defined as a command channel to carry messages and data to the servo process.

Then, the third process is written in-line as a sequence of steps (SEQ) followed by an infinite loop (WHILE TRUE). He starts by sending a sequence of four command messages to the servo process:

s ! min ; 650
This sends the min command with the additional value of 650 to the servo process. This means that the minimum pulse width for driving the servo should be 650 μsec.
s ! max ; 2350
This says to set the max pulse with to 2350.
s ! div ; 4
This says that we want four evenly-spaced divisions in the range (from min to max) that we just defined.
s ! pos ; 0
This sets the servo position to 0.
s ! start
This actually turns on the servo.

This process then delays for two seconds, and falls into an infinite loop. (There's infinite loops in heartbeat() and servo()... you just can't see them.) In this loop, Drew goes from position 0 to 4, and then back down. All he does is send the position number to the servo over the channel s.

What's nice about this is that we can later stop the servo, update the values for the minimum and maximum, change the number of divisions (the servo process defaults to 180 divisions -- in fact, all of the values have sensible defaults), and send a start message again.

Perhaps this looks complicated. Personally, I think it's a very powerful interface to servo control, and because we encapsulated servo control in a parallel-safe process, we can easily control multiple servos at the same time, doing some cool synchronous (or asynchronous) things with our tiny little motors of goodness.

I'll try and get some video up tomorrow. Note, also, that everything described here might change... but it certainly seems like a really nice way to do servo control.

Omer and Adam talk about the ccc board

2010-07-03T03:03:00

Omer and Adam spoke at OSHUG, the Open Source Hardware Group, in London this week. Check them out talking with DJ Walker-Morgan about the concurrency.cc board.

Adam Sampson and Omer Kilic talking with Dj Walker-Morgan after #oshug from Matt Lucht on Vimeo.

I'm very jealous. You see, I'm in Meadville, Pennsylvania. This is a very nice town, but it isn't London. Having lived in Canterbury for five years, I kinda miss my friends overseas, and I do miss a decent pub with good ale. Sigh

Keep an eye on the blog and our Twitter stream (http://twitter.com/concurrencycc); we're gearing up for OSCON, and have been making some big changes. In terms of platforms, we have support for the Arduino Mega (yay!), the ArduPilot Mega (yay!), and 8MHz variants of the Arduino (untested! yay!). In terms of libraries, we have servo control sketched in, a nascent implementation of TWI (or I²C), and ... one or two more goodies may make it in before "release." I have crude Debian (.deb) and Fedora (.rpm) packages rolling, so if you're brave, and want to give things a go, send me a note. (It stuffs a few things in /opt, so it doesn't really require that much bravery.) We don't have our Windows installer done yet, but that's still on target for late July. (A lot of this is motivated right now by a student-run UAV project, hence the ArduPilot Mega.)

Awesome-awesome. I love the smell of software projects coming together...

Slashdot!

2010-06-17T03:03:00

We got picked up by Slashdot today. Wootness.

We're currently in a fast-and-furious hack mode leading up to OSCON. If you're interested in trying out our tools, you can grab our book and download a Mac version of our development environment (friendly-friendly), build from source under Linux, or (if you want to live dangerously), join our users list, introduce yourself, and ask nicely if you can try (the currently very ghetto) Debian binary package.

If you keep your eyes on this blog or our Twitter stream, you'll hear when our Windows installer is ready, and when packaging is nice and clean for both Ubuntu/Debian and Fedora.

We're always happy to support new people exploring new languages; please feel free to join our mailing lists and ask questions. We're here to help!

Web updates, c.cc hardware, and the Cardboarduino!

2010-04-24T16:38:00

First, we're slowly working towards making the site easier to navigate. Our main page now prominently features "Downloads" and "Community," which should improve things.

Second, we're still working on completing builds for all platforms -- several of us are college faculty, and we're pretty slammed this time of year. We'll get there, though, since we want everything nice and pretty for OSCON in July.

Third, we have some nice progress on the hardware front, but I can't speak at length about it. I will say that I need to get an order for bits and bobs on the way so that I can build some of our test boards, and once that is done we can start considering some large orders. Mostly, I want to survive the semester...

On the hardware front, though, I can safely say that the Cardboarduino was a complete success. Student after student have been finishing their board, plugging in their Atmega328p, and things Just Work. The students working with them had little to know prior experience with electronics, and we have seen success after success roll in. From the professor's point of view, that's wonderful.

I'll post pictures once I have them... and, in case you were wondering: yes, the Cardboarduino is programmed using the Plumbing libraries.

No Google Summer of Code

2010-03-18T20:31:00

No Google Summer of Code interns for concurrency.cc this year, but that did not come as a great surprise. This years application was in large motivated by us having talked about submitting to GSoC for a few years, but never actually doing it. We have never really had enough time to do the application and we have not seen ourselves as an organisation with the right profile to get accepted. However, without submitting an application there is no chance of getting accepted and this year we decided to just do it. We did, did not get accepted, and now have some time to reflect on what would make us more attractive as a mentoring organisation for GSoC in the future. Building a bigger and more active community is probably a good start in this respect.

So, while we're not going to get any Google Summer of Code interns this year, that should not stop anyone from downloading the software, joining the mailing lists, and doing awesome stuff.

Congrats to all the organisations that did get accepted.

Mailing list and archives fixed

2010-03-18T19:31:00

For a long time, there weren't many "new" people working with our tools. Therefore, our lists lived behind an https:// address with a self-signed certificate. This caused problems for many people. If nothing else, it threw big scary warnings claiming Bad Things were about to happen.

I've moved things around. Our lists are now completely open.

Our list for users of process-oriented programming (things like Plumbing, or JCSP, etc.) is users@concurrency.cc (list homepage).
Our list for developers working on these kinds of tools (contributing to Plumbing, etc.) is developers@concurrency.cc (list homepage).

Please join in the fun. I'll try and get another post up over break about things that are going on with the team. (Also, we'll know whether we're a GSoC participant!)

Google Summer of Code

2010-03-13T08:59:00

Yesterday we submitted an application for the 2010 Google Summer of Code. You can find our application and ideas right on this site. We won't know if we have been accepted as an institution until the 18th of March, but if you are interested in doing a Google Summer of Code project with us it is probably worth contacting us about it now. Even if we don't get accepted as a mentoring institution, we would of course still be more than happy for anyone to come and join the project and do cool stuff!

If you want to get in touch with us about Google Summer of Code and projects drop a note to developers@concurrency.cc (list homepage).

Around the WWW

2010-03-07T14:20:00

This is the first of a series of posts where we point to things we've found on the WWW, and do our best to address some questions/share some thoughts about our tools.

To answer the question that we've received several times and seen in a number of places, Windows is coming.

The St. Louis Area Robotics Group

A few weeks back, a thread was started on the St. Louis Area Robotics Group forums regarding our libraries and the Arduino/robotics.

The original poster (gifted) pointed out that while the native Arduino programming environment provides threading via protothreads, it doesn't necessarily make it easier to handle multiple events taking place simultaneously. This past week, I had students working on a challenge involving three LEDs fading in and out on three PWM channels; as each finished its fade cycle, it would "ask" for a new reading from an ADC channel. I encourage students working with dataflow languages like occam to first draw a picture of their program:

We call this a "dataflow" language because the entire basis for programming in occam is one where we are communicating data from one parallel process to another. Hence, it is useful to think of values "flowing" from one process to the next. I'll break things down fully here:

Step 1

The fader process gets done bringing it's specific LED (in this case, the LED on pin 11) to full brightness and back. At this point, it wants a new reading from the ADC to determine how fast or slow it should fade. So, fader signals the switch process that a new reading is desired. (So you know, the fader process does not know who is listening—it just knows that it wants a new reading, so it sends out a SIGNAL.)

Step 2

The switch process grabs the SIGNAL and then signals the adc process that a new reading is desired. From the point of view of adc, it has been sitting quietly doing nothing, simply waiting for someone to ask for some data.

Step 3

The adc takes a reading from pin 0.

Step 4

The adc process communicates its reading down the adcResp channel, and proceeds to begin waiting again.

Step 5

The switch process takes the value it received from adc (it was waiting), and sends that on to the fader process (who is also waiting).

There is a 1:1 correspondence between this diagram and the code we write. If you want to see an implementation of this tri-LED fader, you can see it in our repository. I'll eventually write this up as a sequence of short chapters in the book, but I simply haven't had time yet. (And, actually, that code needs some comments. I use replicated syntaxes to keep it short, but those should probably be explained.)

Plumbing is for concurrency

So, yes... we think this is good for robotics, because a lot of robotic control is about reading from and reacting to sensors. We <3 the Arduino because it is a low-cost microcontroller that lots of people use for exactly these kinds of applications—but we think it's too difficult to manage this kind of complexity in C, especially for programmers just starting point.

And, for tmaiden on the St. Louis robotics forums: we use the word parallelism to denote when things happen "at the same time," and use the word "concurrency" to mean "the appearance of simultaneity." I don't know if others make this distinction, but we do... because when we use our tools on multicore devices, we get parallelism. When the Arduino goes multicore, our domain will be technically incorrect, and we'll have to go get parallelism.cc.

And those .cc domains are expensive.

Did I write that?

2010-02-14T13:58:00

Meredeth Patterson (maradydd)¹ commented on the preface to "Plumbing for the Arduino":

This is how you write an introduction that makes people care about what your project does. This is how you take a specialty solution, heretofore useful to and understandable by only people who already understood process algebra and the pi-calculus, and present it as another tool for people's toolboxes right alongside hammers and screwdrivers. If you want to drive a nail, get a hammer; if you want to do parallel tasks in real-time, get occam-π.

The hard thing about giving your work away is not knowing whether it has value. I know there are bugs in the book (Zoro Feigl already found one...), and I know it can be improved. That's the nice thing about getting it out there for people to use—they can push back, and we can improve our software and our text.

And that really makes me feel good.

There's a few other people who found our project in the past week or so and started exploring it. I'll point to those over the next couple of days. The early adopters—people exploring something new—really are exciting to work with. You can see learning taking place as well as more work piling up, because you now know you've got more things to improve and more documentation to write. (I happen to think that's a good thing.)

You have to pronounce "maradydd" in the Welsh. ↩

Mailing lists and updates

2010-02-12T17:57:00

Tap tap

I have no idea if this blog is read by anyone, but hopefully you put our RSS feed in your reader if you were interested in news and updates.

Twitter

We created a dedicated Twitter feed for the site. You can follow concurrencycc for updates. For example, when the book updates, or the blog, we'll write a short note. All signal, no noise. I hope. I'm not a Twitter expert.

Mailing Lists

We have two new mailing lists:

users@concurrency.cc (list homepage)
developers@concurrency.cc (list homepage)

You can join either or both of these lists by visiting their Mailman subscription pages. (Or, if you want, drop matt at concurrency dot cc an email.)

These are not strictly limited to people exploring occam on the Arduino. Our long-term goal is that people exploring process-oriented programming find a home for their projects under this domain. If you start exploring Plumbing and have questions, that is a great place to ask. Everyone involved in the creation of Plumbing (and, for that matter, everyone working on occam-π) can be found there.

If you're interested in contributing to the Plumbing libraries (or, the virtual machine underneath it), or you want to help bring occam to another hardware platform, join developers@concurrency.cc. That is the space where we discuss the tools that make things like Plumbing possible. Again, we're all there.

Book Updated

Two (three?) new chapters appeared last weekend. Also, Zoro (who seems to do some very cool art) dropped an important note to bookbugs.

Every program you write for the Arduino that uses Plumbing needs to start with this line:

#INCLUDE "plumbing.module"

This line of code brings in all of the support you need to program the Arduino in occam. Our intention is that the tools you use for programming the Arduino will ultimately insert that line automatically. (Or, perhaps we'll change our minds about that.) Either way, I've updated the first chapter so that it is included there. I am not going to update all of the code examples in the book at this time, simply because that will 1. take longer and 2. upset my pagination. Also, the group needs to discuss (on developers) whether we're going to make that line go away or not.

Summary

We have a new Twitter feed, new mailing lists, and updates to the book (now on revision 2010-02-12). Enjoy!

The website goes live

2010-01-31T03:27:00

While we've had concurrency.cc for a while, we haven't actually loaded content into the site.

Now, we have links to the book we've started, hardware developed by members of the group, a blog (including Atom and RSS feeds), and... who knows what else!