×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Parallel Programming For the Arduino

Soulskill posted more than 3 years ago | from the head-patting-and-tummy-rubbing-support dept.

Programming 140

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.'"

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

140 comments

Threads (0, Redundant)

OopsIDied (1764436) | more than 3 years ago | (#32592028)

Or instead, people could just implement simple threading and learn something in the process rather than switch to a whole other language just for one problem.

"simple" threading (5, Insightful)

weston (16146) | more than 3 years ago | (#32592152)

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.

 

Re:"simple" threading (1)

OopsIDied (1764436) | more than 3 years ago | (#32592300)

Well I guess for the arduino's case you're right. It's already pretty dumbed down since they remove the need to know about port registers/actual serial communication/etc so not having to worry about threading would fit its purpose. It might be better if the actual arduino people implemented it into its standard language though.

Re:Threads (5, Interesting)

Monkeedude1212 (1560403) | more than 3 years ago | (#32592230)

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?

Re:Threads (2, Insightful)

AlecC (512609) | more than 3 years ago | (#32592266)

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.

Re:Threads (2, Interesting)

TheTrueScotsman (1191887) | more than 3 years ago | (#32594000)

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.

Re:Threads (0)

Anonymous Coward | more than 3 years ago | (#32592324)

Seriously? What is the set of people competent enough to know what to do with an Arduino, but not competent enough to know how to use an interrupt? WHERE IS THAT VENN DIAGRAM?

Re:Threads (-1, Flamebait)

Anonymous Coward | more than 3 years ago | (#32592444)

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.

Re:Threads (1)

Tetsujin (103070) | more than 3 years ago | (#32593168)

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. :)

Re:Threads (1)

tibman (623933) | more than 3 years ago | (#32592510)

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.

Re:Threads (1)

kev0153 (578226) | more than 3 years ago | (#32593606)

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.

That kind of thinking... (3, Funny)

Anonymous Coward | more than 3 years ago | (#32592052)

"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?

Re:That kind of thinking... (2, Insightful)

skelterjohn (1389343) | more than 3 years ago | (#32592070)

Arduinos are allowed to have security holes.

Re:That kind of thinking... (0)

Anonymous Coward | more than 3 years ago | (#32593676)

Arduinos are basically just development kits for Atmel AVR 8-bit microcontrollers. These controllers are embedded in many devices which often control machines which can do actual physical damage or harm. Software quality is an even bigger priority when you're dealing with embedded systems: Updates are harder (often impossible), consequences are expensive and/or dangerous (ask Toyota) and users don't expect "glitches" because the perceived complexity of a device is lower when there is no visible computer.

Re:That kind of thinking... (5, Insightful)

Trepidity (597) | more than 3 years ago | (#32592150)

Next up I suppose you're going to complain about how Legos don't force you to learn proper civil engineering before building things?

Re:That kind of thinking... (4, Funny)

Bigjeff5 (1143585) | more than 3 years ago | (#32592222)

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.

Re:That kind of thinking... (2, Interesting)

jd (1658) | more than 3 years ago | (#32593304)

I was thinking more that all Engineering degrees require a combined combined LEGO/Mecchano device as a final-year project (to demonstrate interoperability), with internship at LEGOLand.

Re:That kind of thinking... (0)

Anonymous Coward | more than 3 years ago | (#32592460)

no, but I will complain that the plural of lego brick is lego bricks...

Re:That kind of thinking... (0)

Anonymous Coward | more than 3 years ago | (#32593898)

Jokes on you, my Lego blocks were made of dark matter and had a near 1:1 ratio in weight with real bricks.

Re:That kind of thinking... (0)

Anonymous Coward | more than 3 years ago | (#32594438)

that was the most insightful comment I read in a while.

Re:That kind of thinking... (0)

Anonymous Coward | more than 3 years ago | (#32592256)

I agree that it's a poor philosophy. Let me turn his argument around:

The users' don't care about Occam. They don't care about how the language is different from C. They don't care how secure it is. Well, if they don't care, then why shouldn't you make it in the best possible way?

This kind of catering-to-the-lowest thinking pops up all over the place. My thing is, you have two groups of people, one that isn't sophisticated enough to know or have an opinion on small things, and one that is expert and does. Why satisfy the higher requirement, since you admit that the casual users won't know the difference anyway?

Personally, if I'm new at something, and I don't have enough in-depth knowledge to have an opinion on how something is being done, then I hope that those who DO have in-depth knowledge choose the better option.

Re:That kind of thinking... (3, Funny)

bb5ch39t (786551) | more than 3 years ago | (#32592306)

I agree with you. In the extreme, it might lead to gas pedals sticking in computer controlled cars. Oh, wait, that's already been done.

Re:That kind of thinking... (1)

jd (1658) | more than 3 years ago | (#32593344)

Admit it! At least the gas pedals didn't stick to the gas tank, causing the tank to rupture horribly over the over-heated engine, thus eliminating any possibility of an official complaint.
.
.
Oh.
.
.
Just been told that's next year's model.

Re:That kind of thinking... (4, Interesting)

John Whitley (6067) | more than 3 years ago | (#32592406)

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.

Re:That kind of thinking... (0)

Anonymous Coward | more than 3 years ago | (#32592776)

Repeat after me: programming languages and frameworks do not make developers dumber.

Mu.

Repeat after me: people who don't want to learn programming will make lousy programmers.

Maybe instead of coming up with straw men, you could address the point made?

Re:That kind of thinking... (0)

Gordonjcp (186804) | more than 3 years ago | (#32593230)

Repeat after me: people who don't want to learn hardware design will make lousy programmers.

If you don't know how the computer works right down to transistor level, how do you expect to understand even a little of what you're doing?

Re:That kind of thinking... (1, Funny)

Anonymous Coward | more than 3 years ago | (#32594536)

If you don't know how the computer works right down to transistor level, how do you expect to understand even a little of what you're doing?

Sure.

How do you expect to understand even a little of what you are programming without understanding Electronics?. Solid State Physics? And without Quantum Electrodynamics?

Re:That kind of thinking... (4, Insightful)

John Whitley (6067) | more than 3 years ago | (#32594384)

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 [cycling74.com] for real-time audio/video signal processing -- very popular in the computer music and visuals world. Labview-based [wikipedia.org] 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".

Re:That kind of thinking... (1)

Monkeedude1212 (1560403) | more than 3 years ago | (#32593616)

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.

If you can find a way to shorten that, just a bit, to 140 characters, that will be the best tweet ever made.

Re:That kind of thinking... (0)

Anonymous Coward | more than 3 years ago | (#32593876)

Your example talks about the opposite: writing efficient code, not writing with the slow, bloated memory heavy runtimes of today's sandboxed software. oh, and no language is going to magically make the intrinsic aspects of the hardware disappear for no cost. You're right that such tools don't necessarily make programmers dumber, but they do encourage them to NOT look behind the curtain so to speak. So when the machinery behind it breaks, they're helpless. Oh, and then there's the fact that the user experience is ruined by performance and memory footprint of their clunky application.

Re:That kind of thinking... (0)

blippo (158203) | more than 3 years ago | (#32594154)

Unfortunately, the idea that a smart guy can write a framework for the rest of us idiots, is what ACTUALLY is causing problems and life long misery.

Most of the times, a problem is as complex as it is; yes you can "abstract away" the horrible details of your synchronization problem - but the nitty gritty details tend to leak through, and when a unforseen (real world) problem hits the framework, it tends to be hard to solve using the framework in a clean way, and you might need spend much more time on bending the framwork, than you ever had to do without it.

What I am saying is that writing a framework is really really hard; at least 10 times more expensive than just coding something that works, and in the end, it won't magically protect you from developers that can't code.

Re:That kind of thinking... (1)

ajlitt (19055) | more than 3 years ago | (#32593816)

Isn't this kind of thinking that lead us to why we have the security holes...

I thought the Arduinos are supposed to be RoHS [wikipedia.org] compliant?

Why do people struggle with this so much? (1)

AthleteMusicianNerd (1633805) | more than 3 years ago | (#32592094)

This just a race condition, which was taught when I was a sophomore in college(and I knew about in high school).

Re:Why do people struggle with this so much? (3, Insightful)

Bigjeff5 (1143585) | more than 3 years ago | (#32592290)

A race condition between two processes is easy. A race condition between three is several times harder. Race conditions between a half dozen processes? Forget about it, at least for the hobbyist.

Race conditions can be notoriously difficult to program around. You can go from 20 lines of code to 200 in a heartbeat with just one or two of them. Get five or six, and your 20 line program needs a thousand lines to deal with it all. That's pretty ridiculous, especially for hobbyists.

If you've got a tool to eliminate the problem completely, why would you poopoo it?

Re:Why do people struggle with this so much? (1)

wurp (51446) | more than 3 years ago | (#32593578)

People address race conditions by adding more code? Yuck. The solution to a bug is rarely to add (significantly) more code.

(Your first problem was using threads to solve something more suited to state engines feeding one another via queues, but that's pervasive.)

Re:Why do people struggle with this so much? (0)

Anonymous Coward | more than 3 years ago | (#32592422)

As someone who's been writing real-time systems for 20 yrs: you don't know what you are talking about. They aren't talking about "simple" race conditions. There is a lot more to designing a multi-threaded system that is correct, than just race conditions. And truly parallel systems, utilizing multiple processors is even harder.

Re:Why do people struggle with this so much? (1)

gyrogeerloose (849181) | more than 3 years ago | (#32592678)

This just a race condition, which was taught when I was a sophomore in college(and I knew about in high school).

Probably because a lot of people who play with the Arudino (including me) are not professional programmers. They're largely self-taught amateurs--typically garage inventors and a surprisingly large number of artists who have probably never even heard of race condition and don't really care, either.

Re:Why do people struggle with this so much? (1)

AthleteMusicianNerd (1633805) | more than 3 years ago | (#32593016)

Given that it will probably take at least a few hours to get that thing working, it would take about 5 minutes to read the wiki on race conditions. That 5 minutes might save the amateur several hours.
So please read it!

http://en.wikipedia.org/wiki/Race_condition [wikipedia.org]

This is actually over complicated, so consider the following example: ( It's hard to do with text, I'd like to draw a pic...nevertheless )

Guy C takes apples every 5 seconds from Guy A and Guy B. If you give Guy A 8 apples and Guy B 11 apples, you would expect Guy C to run off with 19 apples.

Now suppose Guy A trips while running to Guy C and takes 7 seconds to get to Guy C, but Guy B gets to Guy C in 3 seconds. Since Guy C is leaving at 5 seconds regardless, he runs off with only 11 apples rather than the expected 19.

This is a hazard, or a race condition. In order to solve this, you need to inform Guy C that BOTH Guy A and Guy B have apples to bring him, and that he must wait until both have arrived before leaving.

Re:Why do people struggle with this so much? (0)

Anonymous Coward | more than 3 years ago | (#32593892)

The Arduino is based on Atmel microcontrollers, 8-bit microcontrollers to be precise. There are things in these controllers which require in-depth system programming knowledge if you want to use them correctly. For example, interrupt handling is important when reading 16-bit registers. Do it the wrong way and you'll get false data without any indication of an error. Also, these are not fast machines compared to "real" computers, so you can't willy nilly disable interrupts for a few thousand clock cycles either, unless your application is not timing critical at all (and which uC application doesn't have critical timings?) If these people haven't heard of race conditions, then Arduino will introduce them to the concept sooner or later.

Re:Why do people struggle with this so much? (1)

ir (104) | more than 3 years ago | (#32594094)

The artists should stick to art and stay out of technology if they're too lazy to RTFM.

Re:Why do people struggle with this so much? (1)

gyrogeerloose (849181) | more than 3 years ago | (#32594366)

The artists should stick to art and stay out of technology if they're too lazy to RTFM.

You sound like this guy [youtube.com].

Re:Why do people struggle with this so much? (2, Funny)

Haxamanish (1564673) | more than 3 years ago | (#32593446)

This just a race condition, which was taught when I was a sophomore in college(and I knew about in high school).

Are you sure you were not a semaphore?

Python alternative (1, Informative)

PaulIsTheName (1646771) | more than 3 years ago | (#32592142)

Or try PyMite a.k.a. Python-on-a-chip or p14p [google.com] 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.

Re:Python alternative (1)

tibman (623933) | more than 3 years ago | (#32592660)

I think that would be too much for an arduino. Some PyMite requirements: 40 KB program memory; Initializes in 3KB RAM; print "hello world" needs 4KB; 8KB is the minimum recommended RAM.

Arduino hardware: Flash Memory 16 KB (ATmega168) or 32 KB (ATmega328) of which 2 KB used by bootloader
SRAM 1 KB (ATmega168) or 2 KB (ATmega328).

Python alternative (actually not...) (1)

PaulIsTheName (1646771) | more than 3 years ago | (#32592724)

Ah you are right, thanks for looking that up. I just saw AVR and jumped to an incorrect conclusion.

occam (4, Funny)

Anonymous Coward | more than 3 years ago | (#32592160)

occam iits sh like all lel lanparalguages.

Keep a cat out when it has a mouse?? (0)

Anonymous Coward | more than 3 years ago | (#32592268)

How???

Re:Keep a cat out when it has a mouse?? (4, Funny)

ari_j (90255) | more than 3 years ago | (#32592336)

You embed RFID tags in the mice and then keep the door locked if one is detected.

Re:Keep a cat out when it has a mouse?? (2, Informative)

JoelMartinez (916445) | more than 3 years ago | (#32592952)

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

Re:Keep a cat out when it has a mouse?? (2, Informative)

smellsofbikes (890263) | more than 3 years ago | (#32593874)

Here's the hackaday entry [hackaday.com] 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.

Interrupt Service Routines (3, Interesting)

TwineLogic (1679802) | more than 3 years ago | (#32592274)

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.... ;)

Re:Interrupt Service Routines (0)

Anonymous Coward | more than 3 years ago | (#32592348)

It's running Occam by the way, not Ocaml. They are very different beasts.

Parallax Propeller (5, Funny)

BasilBrush (643681) | more than 3 years ago | (#32592328)

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 [wikipedia.org]

Re:Parallax Propeller (1)

vlm (69642) | more than 3 years ago | (#32592616)

I'm somewhat familiar with the Propeller. Parallelizes quite well up to eight simultaneous tasks. Nineth? Well, turn back around and back to hell.

Its about on the level of saying, I've got eight tasks for my arduino, so since they're cheap enough, how about soldering in eight arduino chips. Laughable as this sounds on the surface, in an era of pic microcontroller that are cheaper than a can of soda, its not all that bad of an idea.

On the other hand, if you wanted to run K or M of threads, perhaps the worlds most demented DSP implementation, thats not going to scale so well.

Re:Parallax Propeller (2, Interesting)

BasilBrush (643681) | more than 3 years ago | (#32593038)

I'm somewhat familiar with the Propeller. Parallelizes quite well up to eight simultaneous tasks. Nineth? Well, turn back around and back to hell.

Very true. I've done 2 games with the Propeller, and hit the 8 core ceiling both times. So a lot of people are now doing projects with 2 (or more) propellers.

Maybe not a great choice for production electronics. But great fun for tinkering and one off projects.

Re:Parallax Propeller (2, Interesting)

Jerrry (43027) | more than 3 years ago | (#32593048)

"I'm somewhat familiar with the Propeller. Parallelizes quite well up to eight simultaneous tasks. Nineth? Well, turn back around and back to hell."

In that case take a look at the XMOS chips. Each core supports eight hardware threads and there are 1, 2, and 4 core versions available. Each core runs at 400 MHz. With the 4-core chip, you have 32 hardware threads to work with. Need more? No problem, just add more chips and connect them using the built-in Links hardware. XMOS sells a development board that has 16 of the 4-core chips for a total of 512 hardware threads.

The development tools (IDE, compiler, debugger) for Windows, Linux, and OS X are free downloads from the XMOS site. XMOS has added parallel processing capabilities to C (calling it XC), but the development tools also support C, C++, and assembly. JTAG units are US$50, which is quite reasonable.

Check it out: www.xmos.com www.xcore.com

Disclaimer: I have no relationship with XMOS except as a satisfied customer.

Re:Parallax Propeller (1)

vlm (69642) | more than 3 years ago | (#32593294)

Thats some mighty cool hardware. But I don't think you get my point. Its possible to write software where there is a clearly defined ultra hard permanent fixed limit to the number of threads and no fancy concurrent stuff is necessary between the thread. In that case hardware multi-cores like the propeller and the xmos look beautiful. For example my camcorder has one thread pulling bits off he CCD and stuffing them on the SD card, another thread updating the real time clock, and another thread running the zoom lens in and out. No big deal.

But, what if your thread design is linked to the UI? Simplest example, what if you tried to implement the UI for each automated worker unit in the "Civilization" game as a simultaneous thread, in which case it works great up to 8, or 32, or whatever but inevitably the user is gonna click "increment" when you're already maxed out at which time you get hard failure, kaboom. Actually the Civ example is terrible because all 32 settlers might simultaneously try to irrigate the same tile, because the hardware devices usually have little to no support for the hard parts of concurrency like mutex and race condition things, so they blow up. You didn't mention, and I didn't research if the xmos stuff supports that. Perhaps a real world example would be a hardware accelerated threaded webserver that is lightning fast until it reaches 8, or 32, or whatever simultaneous accesses, at which time it simply and completely fails, which may be completely unacceptable in some apps.

Re:Parallax Propeller (1)

newcastlejon (1483695) | more than 3 years ago | (#32594034)

If it's a microcontroller I'd say it's in an appliance of some sort. Appliances don't run just any application; they just do a few jobs that are decided in advance. So if your ATM, for example, needs more than 8 hardware threads wouldn't you kludge some in software?

I'm not sure the Civ analogy really works here; if you were recreating Civ on a camcorder, knowing what chip you had to work with, you wouldn't write it in such a way that it would fail as you suggest. Or perhaps you wouldn't write it at all... you'd write an OS that could do software threads across multiple cores and just run the one that Sid brought out.

These things aren't designed to play games in my opinion, they generally just sit there unnoticed getting on with running our heating systems, our industrial automation, our alarm clocks, etc. Having 8 threads is fine and dandy but I'll bet you're more likely to see them controlling a robot with 8 limbs rather than 8 settlers.

I'm going to do it! (0)

Anonymous Coward | more than 3 years ago | (#32594128)

I'll do it, there is nothing you can do to stop me!

Imagine a Beowulf Clust--- Error 406

Is it anything like C*? (1)

NotSoHeavyD3 (1400425) | more than 3 years ago | (#32592346)

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.)

Reasonable enough. (3, Interesting)

Animats (122034) | more than 3 years ago | (#32592360)

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?

Re:Reasonable enough. (0)

Anonymous Coward | more than 3 years ago | (#32593314)

Is the ATMega an actual multiprocessing environment, or are they porting Occam over a threads model? I'm confused.

I studied Occam 2 about 16 years ago; loved it.

Re:Reasonable enough. (0)

Anonymous Coward | more than 3 years ago | (#32593500)

Ahh, I see, at heart it is the KrOC compiler I remember from back then.

Propeller Chip (1)

desmondmonster (863068) | more than 3 years ago | (#32592366)

Another option is to use the Parallax Propeller [parallax.com] 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.

Re:Propeller Chip (1)

vlm (69642) | more than 3 years ago | (#32592688)

It's got 8 cores

How well does it handle the 9th thread? How well does the assembly code handle mutexs and race conditions?

working with the Propeller is like advancing to the varsity squad.

Hand the "Varsity eight person rowing team" a ninth oar, sit back and watch the fun?

Re:Propeller Chip (1)

desmondmonster (863068) | more than 3 years ago | (#32592966)

Sure, 8 cores. That'll handle a few servos, audio input/output, light sensor, and video processing, all done natively. After all, it's a microcontroller, good for gadgets and robots. It's not like you're running MapReduce on it.

Re:Propeller Chip (2, Informative)

vlm (69642) | more than 3 years ago | (#32593492)

After all, it's a microcontroller

You italicized the wrong syllables. Should have said microcontroller as it can only parallelize separate hardware threads. You can't, for example, do more than eight software threads.

Here's a mixed model fail for an four person soccer video game:

one cog runs the video out (hardware, OK)
one cog runs the sound out (hardware, OK)
one cog each for each human player, reading each joystick or bluetoothed wiimote or whatever (hardware-ish, OK)
one cog each for each computer controlled AI player (software, danger! danger! danger!)

That adds up to 10 cogs. And success or hard failure depends on a user configurable number of players due to inherent hardware architectural limitations.

A better architecture in this situation would be scrap the hardware accelerated threads and go pure software threading, since none of the threads (well, except video) are terribly computationally difficult.

Also note that lynxmotion sells numerous little robots with up to 32 little servos. Easy if your threads are done in software, not so easy if they are only done in hardware and you only get 8 or whatever.

Re:Propeller Chip (1)

fatboy (6851) | more than 3 years ago | (#32594348)

Why don't you just shift the HID devices into one cog? I am pretty sure that @ 20 MIPS you can read a lot of joystick information and copy it into hub RAM. Same with your AI players.

I wrote a 16 channel DMX light dimmer that uses only 3 cogs. I could squeeze that into 2 cogs if I weren't so lazy. Doing away with interrupts made this a relatively easy project.

Interrupts are bad (1)

gr8_phk (621180) | more than 3 years ago | (#32592446)

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.

Re:Interrupts are bad (1)

ClosedSource (238333) | more than 3 years ago | (#32592734)

I can honestly say in my 20+ years in the industry (including 10 years in embedded systems) I've never heard anyone claim that polling is superior to servicing interrupts.

Now, if you can use a interrupt-driven real-time OS that allows you a lot of flexibility in waking up tasks, that's even better.

Re:Interrupts are bad (1)

vlm (69642) | more than 3 years ago | (#32592850)

I've never heard anyone claim that polling is superior to servicing interrupts.

I can make a tight polling loop in single digit clock cycles. Some processors have extraordinarily long interrupt operations. The type that smacks the entire kitchen sink onto the stack before it'll look up the ISR address and jump to it, latencies at least an order of magnitude longer than the polling loop.

This doesn't just bite midrange procs trying to do ultra fast stuff like video overlay, it also bites ultra low power / ultra low speed procs. At 60 KHZ clock, you might be hard pressed to handle more than a couple thousand interrupts/sec but if you poll, that's a piece of cake.

Depends entirely on processor design and application. Arguably if the software guy "needs" to poll, that's evidence the hardware guy screwed up and/or the specs are simply unworkable.

Or in summary, polling has great latency response, interrupts have (relatively) terrible latency response, and everyone tries to design around that.

Re:Interrupts are bad (1)

ClosedSource (238333) | more than 3 years ago | (#32593120)

Well, as you illustrate, context makes all the difference.

In practice, it seems that long interrupt response is usually associated with processors and supporting hardware that includes pre-fetching, caching and other non-deterministic characteristics that render software loop timing unpredictable. Of course, sometimes that doesn't matter.

Re:Interrupts are bad (1)

blair1q (305137) | more than 3 years ago | (#32593506)

polling has great latency response

Only in situations where, as per your example, you can cram a couple thousand actions per second into a chip executing 60 thousand instructions per second; i.e., everything you do takes a couple dozen instructions or less. Pumping the brakes on an ABS might fit that sort of model, but guiding a car to parallel-park itself will not.

Once your requirements get more complex, and involve a mix of long and short tasks at varying priorities (especially those where the long tasks are low priority and the short ones are safety-critical priority), you'll come running back to interrupt-driven designs and live happily ever after.

Not least because you can modulate the clock speed on an interrupt-driven system to zero when there's no input (and no need for periodic output), lowering your power requirements to current-leakage levels. Try that on a polling system.

Re:Interrupts are bad (1)

KenSeymour (81018) | more than 3 years ago | (#32594160)

If it is a life-safety issue, it shouldn't be on a computer at all, unless it is a safety rated device,
like a safety rated PLC.

Physical or electro-mechanical interlocks are the order of the day. The therac didn't have a safety interlocking
outside of the computer. The code had a race condition which killed people occasionally if the operator typed too fast.

If you have an automated saw, are you going to put a computer between the emergency stop button and the motor
power circuit? I wouldn't, whether it used polling or interrupts.

And the emergency stop button should be normally closed so you discover the loose wire before you need to stop
the saw.

If you use polling in you software, that's alright. But the operating system uses ISRs to gather the data
from the device for you.

Crap (0)

Anonymous Coward | more than 3 years ago | (#32592456)

I'd support making ardruino more "user-friendly", except I have a feeling it will come at the expense of being "hacker-friendly". See pretty much any hacker project that later decided to become user-friendly as an example.

Oh well, I looked forward to learning how to make a knitted cozy for my board.

Re:Crap (1)

Stormgren (17223) | more than 3 years ago | (#32592816)

If you're used to dealing with the AVR, and the C language on the AVR, the Arduino already looks awfully hacker unfriendly.

Re:Crap (1)

Tetsujin (103070) | more than 3 years ago | (#32593380)

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...

Re:Crap (1)

blair1q (305137) | more than 3 years ago | (#32593588)

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.

Re:Crap (1)

Tetsujin (103070) | more than 3 years ago | (#32594106)

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.

Re:Crap (0)

Anonymous Coward | more than 3 years ago | (#32594226)

The Arduino software environment is a library, a bunch of preprocessor macros and a framework. The language is actually C(++) though.

Is that this language that looks like Python? (0)

Anonymous Coward | more than 3 years ago | (#32592742)

They stole their syntay! Argh!

Re:Is that this language that looks like Python? (2, Informative)

Egelmex (1835008) | more than 3 years ago | (#32593030)

Python came out in 1991 but occam in 1983....

Where is the port? (1)

tibman (623933) | more than 3 years ago | (#32592856)

Where is it? I can't find the port. There is a link to: http://www.transterpreter.org/development_download [transterpreter.org]

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.

Re:Where is the port? (1)

Egelmex (1835008) | more than 3 years ago | (#32592906)

As it says in the article there is only a Mac version at the moment, with windows and linux versions coming out for OSCON. If you are using Linux building it yourself is quite trivial. We know the naming is confusing, and I agree a plugin for the arduino IDE would be nice.

cat door (0)

Anonymous Coward | more than 3 years ago | (#32592866)

a cat door that keeps their cat out when the cat comes back with a mouse

sauce?

Google Go? (0)

Anonymous Coward | more than 3 years ago | (#32592872)

Google Go seem to have some of the channel communication idioms and select statement semantics similar to occam.

Now, what is really interesting is how so small CPU is capable of handling parallel execution context to begin with...there is only 2KB of RAM!
I recall somebody made a preprocessor&select/break-statement-based "parallel" execution system w/o context switch state preservation (threads)...

No (0)

Anonymous Coward | more than 3 years ago | (#32593258)

You do not need parallel processing to make the LEDs in your uber-kitsch geek-art project blink on and off. Now GTFO my internets, and go back to reading MAKE.

Artists are NOT going to be programming AVRs (2, Interesting)

Simonetta (207550) | more than 3 years ago | (#32593290)

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.

Re:Artists are NOT going to be programming AVRs (1)

djd20 (1835080) | more than 3 years ago | (#32594334)

I know for a fact that artists with litte or no programming experience have been able to pick occam up on the arduino or RCX. Its challenging when you have to write assembly, not when you have a library designed for that microcontroller and all you need to do is write 5-10 lines of code to start doing 'cool stuff'.

Re:Artists are NOT going to be programming AVRs (0)

Anonymous Coward | more than 3 years ago | (#32594636)

Wow. The adolescent stereotypes aside (e.g. beautiful girls aren't capable of cranking their own code), the idea that artists can't dive in and grok stuff if they feel they need too for a project is just wrong. Typing "digitalWrite(13, 1)" into an Arduino to turn on a LED turns out to be quite doable. Have you actually looked at the emerging art scene lately? You can't shake a stick for hitting a piece of physical computing, some of which are amazing, and run happily off pretty basic machines. Some galleries/programs/events as examples:

http://www.mobius.org/
http://www.nycresistor.com/2010/03/28/first-peek-at-the-arduino-art-show/
http://itp.nyu.edu/itp/
http://eyebeam.org/about/about

Not to mention Processing, a language developed at MIT specifically to help artists out that runs on Macs and PCs and makes e.g. hooking up and playing with camera feeds a snap:

http://processing.org/

Re:Artists are NOT going to be programming AVRs (1)

Zerth (26112) | more than 3 years ago | (#32594640)

I think even an artsy type can plug a camera shield, motor shield, and SD card shield into an Arduino and download an image comparison library.

Somebody probably has a walkthrough on Instructables or arduino.cc so they can do it C&P voodoo style.

An arduino won't be doing video recognition, but it can compare a still picture to an outline of a cat's head once a second, if it has somewhere to store the data.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...