transterpreter » Always Where

Parallel Programming for the Arduino at HackPGH!

What: Parallel Programming on the Arduino

When: Friday, December 10, 19:00 – 21:00 GMT-5

On December 10, I’ll be heading down to Pittsburgh for my first ever visit to Hack Pittsburgh! Now, you could claim that my lack of visits is because I’m a bad maker, or you could just accept that faculty are busy people, and having a toddler multiplies that effect.

But the making must happen! In this particular case, the making will be more along the lines of programming. I’ll introduce the basics of the programming language occam, a parallel programming language that has been around for roughly 30 years. Along with colleagues at the University of Copenhagen (Denmark), University of Dundee (Scotland), and University of Kent (England), we’ve made it possible to write occam programs for the Arduino, and have gone a step further in developing Plumbing, a library that simplifies many common tasks on the Arduino. We also have the start of a book on the subject which (hopefully) will get refreshed over Turkey Break.

If you’re looking to attend, you should do the following:

Bring an Arduino.
I have a few I can lend, but you should bring your own.
Download and install our software.
We have a free and open source environment for you to use when writing occam programs for the Arduino. It runs on Mac, Windows, and Linux.
Grab the book.
We have a CC-licensed book you should grab. You don’t have to print it (save the trees!), but you might want to have it on hand. So you know: I expect to update this over Turkey Break, so watch the Twitter feed (or the c.cc blog) for notice when that happens!
Subscribe to our Twitter feed.
We’re @concurrencycc on Twitter.

I’ll assume you don’t have any particular programming experience, unless the crowd who shows up happens to be a bunch of expert embedded systems developers, in which case we’ll adapt. If you have any questions, or anything you’d like to try and do in particular, drop an email to matt @ concurrency.cc, or (better yet!) join our users mailing list and drop your ideas there.

I’m also hoping to bring some students down as well, so it should be a good time.

OSCON is good

I’ll have to write a longer post later, but I thought I’d just mention that OSCON is a great conference. Our presentation went well, and we’ve had a lot of great conversations with people about all kinds of things in the open source world.

More later… for now, it’s time to head out the door.

(Related, our parallel programming environment for the Arduino is now available on Ubuntu, Windows, and Mac. Hooray for packaging! And, I need someone to help me work through how to do proper source packages for some of the complexities I’m facing on the Fedora/Ubuntu side. Packaging compilers is not a lot of fun…)

dinosaurs and uavs

This past week, Radu and Drew worked through the details of setting up PWM-based servo control on the Arduino. This gives us robust control over servos from our occam-pi based programming environment without having to interrupt our execution every 20ms to update a servo.

Here, the Science Dinosaur demonstrates how things work.

Radu and Drew’s work is “foundational,” in that it lays foundations for other projects. (We’re excited about moving on to some more interesting explorations shortly.) The servo control is absolutely necessary for another summer project we have going: the <a href=”http://rockalypse.org/blogs/flyinggator/”>Flying Gator UAV</a>. This flying robot (an “unmanned aerial vehicle”) is being custom built by Ian, and Ian and Anthony are developing the control system in occam-pi on the ArduPilot Mega. This combination gives us a lot of real-time safety, which we hope translates to “no surprises” when we are actually executing our code on a functioning UAV.

The nice thing about the ArduPilot is that is has a built-in hardware override, so that even if your code goes wrong, you can take control over your aircraft with a radio.

Here, you can see Ian taking the fuselage (that means “body” in airplane-speak) out for a test spin. Our aircraft is incredibly overpowered, it turns out.

You can follow an aggregation of all the students’ work at planet.rockalypse.org.

xmos / xc

I work on a software project that helps make an interesting, parallel language with a long history run on lots of tiny computers. More details can be found online.

Specifically, we run code that used to run on a processor called the Transputer. It was developed by a company called INMOS. Today, there is a company called XMOS, and it has some of the same people involved who used to be involved in INMOS. However, the world is a different place today, and I think XMOS is the right idea at the right time for a lot of very interesting applications.

In this forum post, ~~one of the XMOS peeps~~ a member of the XMOS community was wondering aloud about the state of ~~their language, XC~~ the native language of the XCore line, XC. They have realized at XMOS that more people now use their tools externally than internally. (This is a very good thing… users kinda matter.) So, a few questions were asked. I quote:

1) Releasing the current roadmap for XC – showing bugs, features and plans for future development with some timescales. This will enable developers – customers – to feedback on what is important to them and also plan for future improvements to the language. In particular, any plans for typed channels or protocols, process mobility, relocatable, dynamically-loaded code and modules (a reserved word), are very important to members of this community, as recent discussions have shown.

2) Releasing the current implementation of XC – the compiler and tools – so that the community can develop, improve, and learn from the implementation and the language, as well as be equally invested in its future.

Regarding number one: a language will not survive without community. And, while a community will invest in what it cannot control (eg. Twitter), this is a different kind of community. For XC to grow and be useful as a language, the users must have input. This does not mean that language design decisions should be made by people who have no idea how to design languages—but, that said, the people who use the language know what would, and would not, be useful to them.

Regarding number two: there is no doubt that the compiler should be open source. It is one thing to invest in a hardware platform that is closed: we do that every day. But I do not want to build software with tools that might be taken away from me at any time, or modified in ways that destroy my business. If I buy an XS1-L1, I want to know that code written with compiler version 1.3.2 will be able to be built and compiled for the rest of time. I want the option of never updating the compiler, if I need to.

But, more importantly, an open compiler framework would make it much easier to port occam-pi to the XMOS platform. Again, though… I have no desire to do work on a platform that is locked away from me. If XMOS were to move their compiler into a git repository, I could check it out, explore, and contribute.

There is no universe in which opening the compiler can damage XMOS. If their language is ported to another hardware platform, it means more people using XC—meaning, more potential users of their hardware. If new languages are ported to the XC, it means more potential users of their hardware. If someone decides XC is ugly, and designs a new front-end that is friendlier and more expressive, it means more potential users of their hardware. Have I made my point?

Compilers should be open. Period.

Updated 20100623: See comments for reason.

release early, release often

Last summer, I had the good fortune of taking part in Red Hat’s 2009 POSSE. It was an absolutely excellent experience, and many of the things we did and talked about have required much reflection and continued conversation for the ideas to take root. It also took some hutzpah: along with a colleague (and super-ninja support from Mel), we dove off a cliff this past term along with 40 of our students, introducing them to the Fedora project as seen through the eyes of the Marketing and Design teams.

I thought I would share a highlight from the day, though, that goes back to when Christian and I were at RH last summer. We shared with the group work we had been doing on making parallel programming more approachable. Specifically, we had recently completed a port of our virtual machine to the Arduino, thus bringing the venerable language occam to this popular embedded platform. (If you don’t know what an Arduino is, please… crawl out from underneath your IBM Model M keyboard, go to SparkFun or NKC Electronics, and buy one.)

An Arduino in its native habitat.

We thought our tools needed more work before we released. Our POSSE mentors were floored that we hadn’t released already! We realized that “release early, release often” really does mean getting your software out before it is fully baked. In our case, we were worried that the 70+ pages of book (incomplete) and only having installer support for one platform (Mac) wasn’t far enough along… this, apparently, is around version 3.8-RC2 for most projects.

Or, not. But their point was made. So, we released. I put the tools into use in my classroom (things worked just fine), and we decided we’d just keep pushing and promoting. As a result, we will be presenting at OSCON later this summer (very exciting), and we have two contributors from the world at large who are exploring the use of our tools in their own projects. We’ve created a “community” space in our repository and given them commit access, as well as a branch (in one case) so they can add new low-level features without worrying about leaving trunk in a broken state.

More than anything else, having the new contributors is what makes it fun. People poking at what we’ve done, asking questions, and trying new things… that’s a blast. Today, we got picked up by Slashdot, and my sincere hope is that we’ll pick up a few more explorers before the week is out.

If anyone is interested, I now have a (very gross) binary Debian package that you can explore — join the users mailing list and inquire if you want to try it out. We’ll get our IDE for Windows done soon, and put the polish on the site as we head off to share the fruits of our efforts at OSCON.

So, remember: radical transparency and release early, release often.

plumbing goes to hollywood…

Or, at least, OSCON. I think I’m supposed to put one of these somewhere… for now, I’ll put it on my blag. We’re talking about parallel programming on the Arduino. Tray shwet.

The semester is over, grades are in, and now I hit the road for points east: Syracuse, Boston, DC, and then home again. After that, road-trip to Albuquerque, NM. No, don’t ask.

Then, it’s a flight home, and we dig into research. Very, very exciting.

cccboard in the wild

The concurrency.cc board (cccboard) was photographed in the wild being its own bad self. Some of the Kent crew made their way to a meetup in London of the OSHUG, the Open Source Hardware Group, hosted by Osmosoft. psd shot this picture:

Yes, Omer’s step-up circuit lets our Atmega328-based board run off a single AA battery. Very, very nice. I have six boards, but no bits and bobs. That must be remedied!

This summer, we have students working on ARM ports (the Fluke) and an autonomous aircraft based on the Arduino. This is, as we like to say in the group, Very, Very Exciting.

plumbing is released

The concurrency.cc logo

I am excited to announce the release of Plumbing, software and documentation to support artists and makers in the programming of low-cost, open-hardware
platforms like the Arduino. The Plumbing libraries are a collection of parallel components written in occam-pi , a small language with a long history.

Last summer, we decided that it was time to bring six years of work regarding runtimes for parallel languages to the Arduino, a popular open platform for exploring the of art, electronics, and computing. In doing so, we decided that documentation would be critical in this effort. Documentation became a focus because we decided as a team that users matter. In designing and documenting Plumbing, we kept our focus on the students, artists, and makers who might do something amazing with our tools.

I think we’ve taken some substantial risks. Many people have contributed many thousands of hours of development time in our software (to say nothing of the years invested in occam-pi), and we will soon be releasing hardware as part of this effort as well. For me, the most substantial is the commitment to publishing our book, Plumbing for the Arduino, under a Creative Commons BY-SA license. That means that anyone can modify, distribute, and sell our work, as long as you give us credit.

Giving our book away is substantial because publishing is part of how academics are evaluated and keep their jobs. By giving away our book, we must now convince our respective institutions that publishing under the Creative Commons will force us to produce a better product (on an ongoing basis) than editorial review would, as well as reach more readers than if we found a publisher (who would then claim copyright over our creation). Or, we must find a publisher who is interested in helping develop and market our text while allowing it to continue to be available under a free and open license. (If you know one, please have them drop me a note to me at matt at concurrency dot cc.)

concurrency.cc and the materials made available from that site have been in development for years. I’m glad to finally see everything settling in place so people can easily download and explore the tools we have spent so many years working on. If you do, let me know how things go. (We’ll have mailing lists up soon, I promise… but for now my job as a professor calls, and it’s going to be a busy few days…)

Thanks to Dave Humphrey, GDK, and the rest of the POSSE crew. For months the encouragement to just release! has been kicking around my head. That message helped keep us on track as we reworked build systems, wrote text, built websites, and generally did all that stuff that no one thinks about when bringing a project together.

And we’ll get a Fedora RPM done as soon as we can. (In the meantime, you can build from source like the rest of us.)

concurrency.cc board prototype from Omer Kilic on Vimeo.

it's alive!

Omer passed on this picture:

That is a concurrency.cc Arduino-compatible board fired up and ready to go. As you can see, the vias aren’t really lined up that well, which may account for some intermittent USB-to-serial weirdness that he is chasing down at the moment.

Awesome job, Omer! If all goes well, I think we’ll have around 40 to 50 students at Allegheny building their own computers next semester in courses I’m teaching or co-teaching, another handful at Kent, and who knows… perhaps I’ll find another place to bring these into my students’ experience next term.

I remain hopeful that our final boards will be purple, and that the ability to expressly direct parallel code for an affordable embedded platform like the Arduino will be of use to many. One step at a time, though: we need to get revisions done on our existing book chapters, write the next five we have outlined, get Windows and Linux distributions done… it seems like a lot, but we’ll get there.

I’ll have to write a longer reflection at some point, but the long and short is that I’m very excited to see our project coming together on multiple fronts for distribution: robust software, source-to-binary builds, hardware that showcases our tools, and a text that provides structure and guidance for non-programmers to get into hardware exploration one small step at a time. When you start a project like this, you want all of these things from the start… but sometimes, it takes lots of small steps, side explorations, and unsure starts to get you to where you want to go.

concurrency.cc boards are in

For years, my colleagues and I have been working on lightweight runtimes for parallel languages. To put our work in context, we’ve often targeted small robotics platforms like the LEGO Mindstorms for demonstrating the power of a parallel-safe language for real-time systems. This summer, we realized that the Arduino was a marvelous, open-source platform with an energetic community of developers and users, so we ported our language and tools to the Atmega328.

We have a Mac environment done, are working on Windows, and will have a Linux release by January. This, however, is quite exciting:

Omer (Vimeo, Twitter), a PhD student at the University of Kent and our resident hardware guru, did a modified Arduino design that includes more LEDs (along with a few other nice changes, like a mini-USB connector and a lower-profile power jack that will easily work with LiPoly batteries). The extra LEDs are important, because we wanted a board that made it easy to demonstrate the power of a parallel runtime right from the start without any additional/external components.

I’m especially excited about being able to buy these in bulk and sell them to students at cost for use in classes. Next semester, students in Programming Languages as well as my second-semester first-year seminar titled “Technology and Activism” will build and program their own computers. It will be awesome.

We currently have placeholder material up at concurrency.cc, but soon we’ll have binaries of all of the tools and documentation up that let you start writing parallel programs for your Arduino!