Slashdot Mirror
Parallel Programming For the Arduino
blackbearnh writes "As more non-traditional programmers start playing around with embedded platforms like the Arduino, the limitations and complications of interrupt-driven event handling can become an annoying barrier to entry. Now a group of academics have ported the parallel-processing language Occam to the Arduino. In an interview on O'Reilly Answers, Matt Jadud of Allegheny College describes how Occam helps artists using the Arduino in their installations, and how the advent of low-cost computing platforms is changing the educational experience for proto-makers in school. 'Basically, an artist or a tinkerer or a hacker has a goal. They don't really care about learning Occam. They don't care about how this language is different from C. They just want to make a cat door that keeps their cat out when the cat comes back with a mouse. Or they want to make some kind of installation piece. Trying to focus as much on the user and the possible goals they might have is what's motivating our work right now.'"
Next up I suppose you're going to complain about how Legos don't force you to learn proper civil engineering before building things?
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
just implement simple threading
Sure, and they could just learn to fly too, instead of relying on some convenient form of transportation that solves the problem for them.
Threads are the famed "simple, clean and wrong" general solution to parallel programming tasks. The *concept* and *implementation* of threads can be simple, sure, but if you're working on anything other than simple problems, the trouble of keeping track of everything that's going on can become very challenging very quickly.
a whole other language just for one problem.
It's a big problem. Learning another language is generally a smaller problem. Particularly if you're the kind of Real Programmer(TM) that we're probably going to hear can manage with threads just fine.
Tweet, tweet.
occam iits sh like all lel lanparalguages.
I've been pushing for that for years! All children should have a proper engineering degree before playing with legos! I mean, have you seen what some kids come up with? Totally unworkable.
Security is mostly a superstition... Avoiding danger is no safer in the long run than outright exposure. - Helen Keller
In my limitted experience, threads are one of the more difficult things for... people to understand. I find it difficult to describe their position, which I think Matt Jadud had a tough time too, (See how he said "an artist or a tinkerer or a hacker"). In my situation, I have a friend who is taking an engineering major at the local university. Now, a little background information; I don't know how it is in other cities across the world, but here, Engineering at the university is considered one of the hardest courses. You know, really ridiculously high drop out rates, cause most people can't handle it. Opening orientation, they say look to your left, look to your right. 2 out of the 3 of you won't make it past second year. So anyone who manages to make it through the first 2 years of Engineering gets this perception that they know to do stats as well as a stats major or know how to program as good as a programming major.
Anyways, so my buddy is in engineering, and he knows enough C++ to essentially do any calculation he wants through the command line. He hasn't had to work with GUI's or anything like that. The most he did was a turn based Star Trek game where the command prompt simply reprints the "game board" everytime you make a move or perform an attack, prompting the player what to do at the end of each turn.
So he tends to be the kind of user that they target with these kinds of ports. He's already loaded with a bunch of information in some other field. Be it engineering, arts, hacking, radio signals, whatever. They don't have a whole lot of time to run through the tutorials to learn threading and how its supposed to be done properly. There's no telling how long it'll be before they get into an issue with threading and they won't have enough knowledge on how to fix it and it'll be a big headache if they went and built their entire code that revolves around this segfault they created.
So thats where these other languages come in. They are similar enough to a common language like C that anyone who does a beginner course can pick them up. They offer the features that users WANT without all the complications that come with learning how its done.
I know, I know, teach a man to fish, right? But what if he only ever needs 1 fish in his entire lifetime?
The best option for people who want to learn about parallel programming on an embedded processor is the Parallax Propeller. Genuine 8 core system on a chip, programmed to the bare metal. And so much fun.
http://en.wikipedia.org/wiki/Parallax_Propeller
You embed RFID tags in the mice and then keep the door locked if one is detected.
Isn't this kind of thinking that lead us to why we have the security holes, shoddy programming, and bloat-ware today? People just want to code and not to learn the ins and outs required to craft a well-heeled, tuned, and functioning program or application?
Repeat after me: programming languages and frameworks do not make developers dumber. It's this kind of thinking that forces every developer-user of a complicated system to be continually faced with issues outside of their domain of expertise, or even just the current problem focus. *That's* what causes these problems.
For example, when doing embedded programming some years back, I noted that team members working on codec optimization were starting to crank out bad, broken ad-hoc synchronization logic to take advantage of some unique parallel hardware. Their specialties ran into numerical analysis and implementing low-level numerical optimizations, not into synchronization algorithms. I could take these folks and run them through an OS class, and walk them through the inevitable sea of mistakes...
Or I could do what I did: I created a framework that abstracted away all of the platform synchronization concerns. They did their jobs neatly and cleanly by writing a class that contained some shared state and implementing just two virtual methods that embodied the parallel work. They were much happier, and the whole team was much happier because there was now *one* place to look for synchronization bugs. This was quickly hammered out into a very stable foundation for the other teams' work.
Allowing our programming languages, libraries, and frameworks to do the heavy lifting so we humans can focus on the real problems we want to solve pretty much describes the history of real progress in software development.
Repeat after me: people who don't want to learn programming will make lousy programmers.
Fine then: the statement above is garden-variety developer egocentric stupidity. TFS' statement is right, these folks want to get their work done, but the specific tools are irrelevant. The qualities of those tools for the task are the only things that matter.
It's insulting and stupid to propose that those looking to program and leverage an *Arduino* for their personal projects are somehow slackers uninterested in learning. Maybe they're just interested in learning what they want to, not what you want them to. I've walked the path of deep knowledge of programming, CS, etc. I've put my thousands and thousands of hours in. It's a good one for those who enjoy it, but it's not the end-all, be-all for all people.
Lots of people "want to learn", but at the same time they don't have that "ten thousand hours to mastery" to invest in a new domain (here, programming/CS). There's a spectrum here: on one end, the deep knowledge of an experienced programmer. On the other, those who want and need to access the power of programming but don't want to be burdened with oceans of complexity and specialized domain knowledge. I'll apply an existing term, "end-user programming", for this.
The most successful end-user programming environment by far is the spreadsheet. It provides simple, tabular model and some fairly rich programming capabilities within its scope. Another great example is the Max/MSP/Jitter environment for real-time audio/video signal processing -- very popular in the computer music and visuals world. Labview-based systems (which includes the Lego Mindstorms stuff) are another great example. Each of these environments is rich enough to allow programming, learning, and exploration. And all provide environments that are tailored to specific problem domains.
There's a place in the middle, often called by programmers "tools for the task", where a programmer doesn't have to bend over backwards to address certain hairy problem domains. Libraries, frameworks, and programming languages can all meet these needs in their various ways -- even to the extreme that it transforms what some people consider the nature of "programming".