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.'"
"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."
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?
This just a race condition, which was taught when I was a sophomore in college(and I knew about in high school).
Or try PyMite a.k.a. Python-on-a-chip or p14p if you really must... Also features threads and is a little more mainstream than Occam. And people do actually care about the amount of mental capacity goes to their tools while making the cat door open and close.
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.
XMOS (http://xmos.com/) has developed a mostly-C language with a few Occam-like extensions, which might also be worth considering. It's called XC (http://www.xmos.com/system/files/xcuser_en.pdf/).
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?
Occam was intended as a reply to all the problems that can happen with threading, The ides with Occam is that a lot of the things that can go wrong with threads simply cannot happen in Occam. Think of it as Java to threading's C. Just as you cannot create random pointers in Java, you cannot lock random mutexes in Occam (which doesn't have mutexes),
Traditional threading really is assembler level coding for parallelism; Occam tries to move to a high level language.
Consciousness is an illusion caused by an excess of self consciousness.
There is no limit to the functionality of Interrupt Service Routines (ISR) and the interrupt-driven "event model," as the OP put it.
Programming an ISR may be difficult, but even the topic of this post, a parallel environment running on the Arduino, will be based upon ISR routines. The user-level programs will not interact with ISRs, but the Ocaml implementation will abstract them.
Fundamentally, the hardware will continue to use interrupts to signal the availability of data from human input devices. Therefore, the fastest and most direct way to access this data is to write an assembly language ISR. The difficulty is that embedded systems programming such as this requires specialized technical knowledge on the part of the programmer.
Clearly the Ocaml solution posted will ease the burden on the coder, and that is a good thing. But the way it works is not that it no longer uses ISRs. It almost certainly implements its own ISRs and polling routines. In this way, it will be like a library. The beneficial result is that individual programmers do not have to reimplement the ISRs. But there is no benefit in, and no possibility of, eliminating the very needed ISR itself.
Personally, I question whether the MCUs selected for the Arduino are appropriate for the "cute tech" market that the Arduino-series-PCB-module (a.k.a. "shield") manufacturers seem to be going for. Possibly the availability of Ocaml will bring the platform more in line with, e.g., the BasicStamp or similar. Overall, I see an impedence mismatch between what people would like to do (make costumes) and what they get (asking their friends to write code for them).
The fundamental first step will be describing to the Ocaml environment how it is that the peripherals have been wired to the chip. Then the Ocaml environment can, presumably, service these interfaces either through ISRs or polling. We'll see what transpires in simplifying the Arduino software landscape.... ;)
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.
Just curious. When I was an undergrad they had a parallel programming course and the language we used was C*. Basically it was C with this add on called a shape. Really it was just an array (Could be multi-dimentional) of virtual processors and associated data. (Basically a short, long, etc.) Then you'd just do a where statement on this array of processors. So in the where statement you'd just list the instructions you wanted done and each virtual processor would each run those instructions themselves. (Been a long time since I programmed in it.) It was actually pretty neat and worked pretty well. (They had us write a program to solve systems of linear equations. It was cool.)
Did you know 80 to 90% of the moderators on slashdot wouldn't recognize a troll even if one dragged them under a bridge.
Good idea. I'm impressed that they were able to cram Occam into an Atmel ATMega. Occam syntax is rather clunky by modern standards, but it gets the job done. It has a sane concurrency model and is safer than C.
Next, Ada?
Another option is to use the Parallax Propeller microcontroller. It's got 8 cores, 80Mhz clock speed, and 32k of ram, and you can either program in its higher-level Spin language or get right down into assembler. The Arduino is fun to learn on and accessible to people who don't have a strong programming background, but working with the Propeller is like advancing to the varsity squad.
In general, one should try to avoid interrupts whenever possible. I thought years of VB programming and the therac 25 taught people the pitfalls of event driven software. Think about polling, fixed time steps, and state machines. Now we're talking embedded systems and video games. To be fair, interrupts are unavoidable for some things - just try to minimize that and keep the interface between IRQ and non IRQ code minimal too.
I don't think you can use the word "simple" with threading on the arduino. I've seen several proto-thread type deals but nothing approaching multi-threading. The problem isn't just making sure you don't have functions that block. Some IO stuff needs to be timed like serial/i2c and you have to be careful about interupts taking too much time.
http://soylentnews.org/~tibman
Ah you are right, thanks for looking that up. I just saw AVR and jumped to an incorrect conclusion.
If you're used to dealing with the AVR, and the C language on the AVR, the Arduino already looks awfully hacker unfriendly.
"All those tubes and wires and careful notes!"
Where is it? I can't find the port. There is a link to: http://www.transterpreter.org/development_download
But that link is for a Mac-only tool chain of some sort. Does this mean the arduino IDE will be replaced with this Transterpreter thing? If they have a library or something drop-in for the arduino IDE (written in java), i would think it would work for any platform.
http://soylentnews.org/~tibman
I read this story a *long* time ago, but I remember that someone built a cat door that used a webcam to capture the silhouette of his cat as he entered the cat door. The software would look at the shape, and use a computer learning algorithm to "recognize" the cat ... that way, when he tried to enter with a mouse in his mouth, it would block him. It also had the effect of keeping out raccoons because it obviously wouldn't fit the profile
Python came out in 1991 but occam in 1983....
What does the Arduino diddly do?
Arduino IS the platform for people who don't know how to use an interrupt. Everyone who knows how stuff works skips the Arduino since it don't really add anything useful.
I don't know... I mean, I started out with PICs. My wife bought me an Arduino for Christmas last year - I don't know that I ever would have bought one myself, but I've enjoyed it. It's kind of handy having a dev. board, with some good power supply options and a PC interface built-in, and it's kind of handy to be able to pick up "shield" hardware and run pre-made code to try things out...
Sometimes I feel like it's made me kind of lazy - like I'm coming to rely too much on other people's code and hardware designs... So I try not to overuse it. :)
Bow-ties are cool.
Arduino is actually coded in C++, not C.
Just for clarification.
I'm an AVR programmer. I prefer to work with assembler, because I come from an electronics background and assembler is closer to the electrons. I can, and occasionally do, work in C on the AVR and Visual BASIC on the PC.
Let me say, this stuff is hard. It's hard for programmers and electronic technicians. It's really hard for hobbyists and people who have little technical background. Artists are not going to be programming AVRs to make cool performance art projects with Arduinos. OK, maybe one or two, but not many.
Even rock-bottom beginning simple stuff like blinking an LED or making a beep when a button is pressed can be challenging on a microcontroller. It's not hard to know what to do; it's hard to actually do it and make it work 100% all the time.
Your average guy or performance artist is NOT going to be making a cat door that won't let the cat in the house with a mouse. Let's see, the cat pushes on the door with its nose. This flips a sensor that activates a camera that relays an image of the cat's face to a microcontroller. The MCU parses the pixels to determine that the image sector of the mouth of the cat is significantly different from the analysis of previous images of the cat's face. The door won't open.
Now if you're reading this, then yes, you can program something that might be able to do this. You're a Slashdaughter, for Christ's sake, you can do anything technical, and you know it.
But you wouldn't be able to do it on a $1.59 microcontroller. And you sure wouldn't be able to do it if you didn't have thousands of hours of programming experience and technical training.
It doesn't matter what language or integrated development environment that you use, it's just not going to happen.
And frankly, most of the cool projects that performance artists want to do with computers would require a real gigahertz/gigabyte/advanced_OS PC to do, not an 8-bit microcontroller with 1K of RAM that can just barely run a microwave oven, let alone a telephone.
Performance artists want professional-level programming ability and talent at bargain-basement artists prices. But if you're not a beautiful woman into performance art who has the ability to hook up her beautiful friends to nerdy techno-geeks who actually do the programming, it's unlikely to happen.
If you're used to dealing with the AVR, and the C language on the AVR, the Arduino already looks awfully hacker unfriendly.
How's that?
I mean, the Arduino Introduction page claims that the Arduino programming language is something called "Wiring", right? I've never really understood that. It looks like C or C++. As far as I can tell, it's just a set of libraries on a C++ environment.
And if you don't like the Arduino programming environment, you don't need to use it. You can compile your code outside of the Arduino environment, and send it to the Arduino board with avrdude... All you'd need to do is make sure your program doesn't expect to occupy the flash space occupied by the bootloader... Though if you programmed the Arduino with ISP, you could overwrite the bootloader if you wanted...
Bow-ties are cool.
They essentially defined their entire language in a couple of pages.
That's not C, and it sure isn't C++.
It's a tiny subset of either, but, like English, it's the subset pretty much any speaker can speak. And, like the commonly-spoken subset of English, it quickly hits its limitations should up anything complicated and technically constrained come.
I fall into the tinkerer category. I just built a robot using an Arduino as the brain. This would have been useful for some of the servo and sensor inputs I was trying to do.
Here's the hackaday entry about the feline facial recognition project. The actual project itself is located on a pretty slow server, so you'll have to just go with that, but the idea (from 2003) is what you say: it lets in cats that aren't carrying stuff in their mouths, but doesn't let in raccoons or skunks, and since he's captured pictures of them trying to get in, that's pretty useful.
Nostalgia's not what it used to be.
I did Occam in the 80s and server-side Java now. Java is way more powerful for parallel processing and the simplification in Occam (essentially a built-in parallel functional transform aka the 'threaded for loop') can be replicated with a fairly simple Java library that almost any experienced programmer has written for themselves. I literally use one every day. Only newbies are wrestling with Thread.start() and mutex locking. Everybody else has abstracted this long ago.
They essentially defined their entire language in a couple of pages.
That's not C, and it sure isn't C++.
It's a tiny subset of either, but, like English, it's the subset pretty much any speaker can speak. And, like the commonly-spoken subset of English, it quickly hits its limitations should up anything complicated and technically constrained come.
Please explain. I really haven't seen any evidence that the Arduino programming environment reformulates "sketch" source code before passing it to GCC... The Wikipedia page for Arduino describes "Wiring" as a C++ library and says that Arduino "sketches" are written in C++...
I would expect, as an optimization for the microcontroller, that features like exceptions and virtual methods might not be supported... Otherwise, anything they could do to impede access to C++'s capabilities seems like a waste of time.
Bow-ties are cool.
I've been playing with the Arduino and ran into these examples last night. The objective of the macro below is to set (1) or reset (0) a single bit in an 8-bit register. Register PORTH is mapped to 8 pins I/O pins on the Arduino and we want to control one of them: pin 12. This is the code I found. It's very helpful in that it shows register-to-pin mapping. (Pin 12 has previously been set as an output pin.)
//writes a 1 to PIN12 //writes a 0 to PIN12
/</< 3) : PORTH &= 0b11110111
//reads 1 or 0 into temp depending on PIN13's state
// or
... //reads 1 or 0 into temp depending on PIN13's state
// returns 0 or 0x08
.....
#define SET_PIN12(z) ((z)>0)? PORTH |= (1 << 3) : PORTH &= (0 << 3)
Then usage would simply be like the following:
SET_PIN12(1);
SET_PIN12(0);
There are some problems with this. ((z)>0) will not do what the programmer intended if z, an int, is negative. And there's no need to test for Z being non-zero. The expression should be replaced with z alone.
The first statement of the conditional if, (1 << 3) : PORTH, works fine as it sets the desired bit to 1 while leaving the other bits as-is. But PORTH &= (0 << 3) resets ALL 8 bits to zero. I suspect he was thinking that (0<<3) is 11110111.
In any case, PORTH &= 0b11110111 functions properly. (The Arduino language is a subset of C++ with a few additions.) A simpler version is
#define SET_PIN12(z) (z ? PORTH |= (1
Another example. This is their code to read an input on pin 13. (Pin 13 has been set as an input pin.)
#define READ_PIN13(z) ((PINL & 0x08) > 0) ? (z) = 1 : (z) = 0
Usage would be
READ_PIN13(temp);
So we have
(z) = 0;
(z) = 1;
being executed. I didn't realize this would compile.
The macro functions correctly but I simplified it and changed its usage from a conditional if to to a simple assignment
#define READ_PIN13 ((PINL & 0x08) > 0)
//
temp = READ_PIN13;
I was tempted to simply further to
#define READ_PIN13 (PINL & 0x08)
But since there was a lot of this kind of (proper) code I didn't go that far.
#define HIGH 1
//
temp = READ_PIN13;
if (temp == HIGH) {... // tests temp == 1, versus "true" (non-zero)
After looking through lots of code on the web sites it got me thinking about how easy it is produce C code with unintended consequences.
This is interesting and I hope that it helps bring in new people to the embedded field. Having easy tools to introduce people to a system can make a big difference in the learning curve. Once they get hooked they can start to learn how to do things manually.
For things like the ARM, Blackfin, etc. having multitasking is a huge benefit. But on lower end systems like PIC, AVR, etc. it's really just for show and tell.
I have a fair bit of experience programing these low end devices and the golden rule is ISRs (Interrupt Service Routines) for everything. Everything should be done via ISRs, and when not running an ISR the chip should be in low power mode. A lot of embedded systems are battery powered and they simply don't have the power to waste on things like polling. If you have no choice but to poll (and there are very, very few cases for this) then use a timer ISR. Additionally ISRs give you interrupt priority and hard-realtime responses, something that many applications (especially safety) require.
Putting occam on Arduinos should help people get started on these devices, but I seriously doubt it will see any use in the professional world.
PAR is not the important part of Occam. The fact that all message passing is synchronous and there is zero aliasing is what is important (it prevents a ton of errors, makes automatic reasoning about the programming much easier too). You can do synchronous message passing in any language, you can try to program aliasing free in any language too ... but few people do. They'd rather create abstractions for mutex locking and then rely on programming convention and programmer infallibility for their correct use.
Modern Occam isn't 80's Occam by the way, creating complex data structures is much easier and you can pass data by reference for instance (the local reference gets destroyed when passed).
See: http://en.wikipedia.org/wiki/JCSP - CSP for Java, why write your own, probably incorrect abstraction when good libraries for this already exist?
Half the battle is accessibility. Arduino does that well. It accomplishes what many want it to do without fuss and esotericisms of "good" code. I'd rather have a set of tools I can work with for a one-off task. It beats waiting for an uppity code jockey who insists that it will take 4 weeks, $14k in developer tools,$2k in class fees, etc., to accomplish what a lot of sixth graders eagerly do in a few evenings from scratch. I've seen it happen- right where I work, and it is frustrating.
I remember Occam I learned it back in 1993, it was designed to power specialized multi-CPU machines, transputers, microprocessor with dedicated high speed serial connects to there peer microprocessors. The company that made the transputer INMOS went burst, and disappeared into Olivetti and the transputer was never seen again. I'm surprised that Occam is still going after all this time. It wasn't a bad language and had parallelism as a very low level, which would make it useful for graphics programming or matrix maths, where you could split a for loop over multiple processors, were the answers where independent of result for other indexes.
Agreed, Arduino definitely grows on you. My day job involves a lot of PIC assembler, often targeting micro-power and energy harvesting applications. My first time using an Arduino, I thought, "Wow, this is a noob toy." The second time: "Cool, I don't have to write my own string/memory/i2c/etc. libraries?" Third time: "How did I ever live without this?"
Obviously, hand-written assembler is still king for my production work, but banging together a quick test (or test fixture!) with the Arduino platform is a huge time saver. One of these days I'm hoping to port some of the micropower tricks & toys back to the platform, just to see the applications that ravening hordes of weekend hardware tinkerers will come up with.
Caveat Emptor is not a business model.
hello
I'm one of the creators of Arduino.
The language is c++, we just hide a couple of the most "scary" elements to beginners (mostly the includes at the beginning of the code)
anything you write after that is c/c++
"They essentially defined their entire language in a couple of pages." actually a lot of people would find this appealing...
if you don't like the IDE you can use a makefile to compile the code
m
--
There is one edge case - what if the mouse is inside the cat? Are you going to deny access until it has passed? Or perhaps the RFID chips should be made to be digestible?
I don't know about you, but my cat is already shrouded in enough tinfoil to solve that case. That said, I'm thinking about taking off the foil suit, since an undigested RFID tag means increased likelihood of cat vomit on the carpet. It's a difficult judgment call more than it is a technical issue.
Absolutely, this sort of behavior is why we have security holes.
A cat door is one of the biggest security holes there is. You never know what kind of cat/burglar might come in through the door. I mean, it could even be a cue:cat, or a /usr/bin/cat(1), or worse yet, a LOLCAT.
--Joe
Why write our own? Because we love doing it!
As for that old chestnut, CSP: I'll quote the Bard:
"There are more things in heaven and earth, Horatio, Than are dreamt of in your philosophy."