Parallel Programming For the Arduino 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.'"
That kind of thinking... (Score:3, Funny)
"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: (Score:2, Insightful)
Arduinos are allowed to have security holes.
C can do you wrong (Score:3, Interesting)
#define SET_PIN12(z) ((z)>0)? PORTH |= (1 << 3) : PORTH &= (0
Re: (Score:2)
Re: (Score:2)
You can just use this struct and some preprocessor magic, and then you can define pins if you won't want to bitmask port reads and writes.
typedef struct
{
unsigned int bit0:1;
unsigned int bit1:1;
unsigned int bit2:1;
unsigned int bit3:1;
unsigned int bit4:1;
unsigned int bit5:1;
unsigned int bit6:1;
unsigned int bit7:1;
} _io_reg;
#define REGISTER_BIT(rg,bt) ((volatile _io_reg*)&rg)->bit##bt
#
Re: (Score:2)
If someone's designing Arduino into automotive safety systems, they have bigger problems than russian hax0rz storing up to 16kB of illicit warez in their inadequately protected flash ROM.
BTW, when most people talk about Arduino they are mainly referring to a software platform and its associated libraries.
Re:That kind of thinking... (Score:5, Insightful)
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... (Score:5, Funny)
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: (Score:3, Interesting)
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: (Score:2)
I loved this fitting comic:
http://ahoipolloi.blogger.de/stories/1531403/ [blogger.de]
Unfortunately it’s in German, so I’ll translate:
[Pic 1]
Headline: New trend: Physical incorrectness!
Builder: There’s no law against building that!
[Pic 2]
Headline: The pseudo-informed dogmatic laws of nature disagree.
*Smack!*
Builder: Oww!
Re: (Score:1)
Re: (Score:2)
Actually, they do. You either learn to build strong, light structures, or they are going to keep breaking a lot. Nothing like having a hollow plastic block be the strongest part to really drive home the principles of structural stress and why you should care about it.
Re:That kind of thinking... (Score:4, Funny)
Re: (Score:2)
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... (Score:5, Interesting)
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: (Score:2)
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: (Score:2)
I disagree. I just think that fancy tools like Python, Qt, and Visual Studio Intellisense, all make me dumber in ways that I find acceptable. I'm usually willing to trade being slightly stupi
Re: (Score:3, Insightful)
But they do make promises that they cannot keep. The abstractions they offer leak, so when a developer works with these abstractions, the code develops weird bugs and slowdowns.
No, what forces
Re: (Score:2)
You are making the assumption that you are alone working on a project. Abstractions do leak, and frameworks have bugs. But this does not mean that it's necessary your problem to go around or fix the issue.
While it does offer a great advantage to know the layers of abstraction beneath your code it's not always necessary. In bigger teams you can simply go to whoever made that layer of abstraction and say: "I'm having this problem with $foo, it's breaking when $description."
In a well oiled team people will wor
Re: (Score:1)
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: (Score:1, Funny)
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... (Score:5, Insightful)
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: (Score:2)
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? (Score:1)
Re:Why do people struggle with this so much? (Score:4, Insightful)
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: (Score:2)
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: (Score:2)
Threads and state engines are not orthogonal.
Generally it doesn't matter, but if ultimate optimization is key threads can give better performance than processes because the TLB doesn't need to be flushed when switching between threads.
The cost of course is the added risk/complexity of sharing the memory map between all your threads.
Re: (Score:2)
Sure, but the state engines and the thread mindset (share data and use mutexes/semaphores to control access) are.
Re: (Score:2)
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: (Score:1)
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 1
Re: (Score:2)
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: (Score:3, Funny)
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 (Score:1, Informative)
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: (Score:2)
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...) (Score:1)
Ah you are right, thanks for looking that up. I just saw AVR and jumped to an incorrect conclusion.
occam (Score:4, Funny)
occam iits sh like all lel lanparalguages.
XC (Score:1)
Interrupt Service Routines (Score:3, Interesting)
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: (Score:2)
Re: (Score:2)
Ocaml's spit more.
Parallax Propeller (Score:5, Funny)
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: (Score:2)
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 wo
Re: (Score:3, Interesting)
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: (Score:3, Interesting)
"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
Re: (Score:2)
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 th
Re: (Score:2)
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... y
Re: (Score:2)
6 limbs. You need a thread for overall control and body coordination, and could really use another to keep a look at environment.
Actually, you could easily use hundreds of threads, doing basic processing with senses, integrating data, predicting how the world around you evolves, planning, etc. But certainly need more than "one thread per limb", or the damn thing can't even
Re: (Score:2)
Why would you need one thread per limb? Walking or manipulating an object is probably going to be a coordinated activity between limbs. Probably better to have one thread controlling them all. Likewise, there's no reason not to have one thread dealing with multiple sensors.
Re: (Score:2)
Re: (Score:2)
The Propellor has locks, so mutexes are no problem. Race conditions are a bug that could happen in any concurrent system if a programmer makes a mistake. There's nothing particular about the propellor that would make it more likely.
As to the larger point about it not being scalable to arbitrary numbers of processes, absolutely. But with embedded stuff you ver
Re: (Score:2)
Oh, I forgot to mention that David May, the creator of the XMOS chip, is also the creator of Occam, the language mentioned in TFA.
Is it anything like C*? (Score:2)
Re: (Score:1)
Re: (Score:2)
'Ave at it!
Re: (Score:1)
Reasonable enough. (Score:4, Interesting)
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: (Score:1)
Occam, "clunky"? You mean it doesn't use braces? Or that is uses semantic whitespace, like Python? It's very terse, and has little syntactic sugar. I'd love to see what you'd do to make it less "clunky".
Propeller Chip (Score:1)
Re: (Score:2)
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: (Score:1)
Re: (Score:3, Informative)
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!
Re: (Score:2)
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 (Score:2)
Re: (Score:2)
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: (Score:2)
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
Re: (Score:2)
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: (Score:2)
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
Re: (Score:2)
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
Where is the port? (Score:2)
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: (Score:1)
"Arduino" sounds like Ned Flanders word (Score:3, Funny)
What does the Arduino diddly do?
Artists are NOT going to be programming AVRs (Score:3, Interesting)
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: (Score:1)
Re: (Score:2)
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.
Re: (Score:1)
Actually, I use mine to deconvolve a spherically distorted JPEG into a panorama. It does this very well. It stored data to an SD chip.
Interesting, (Score:3, Interesting)
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.
missed the point... (Score:1)
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.
"simple" threading (Score:5, Insightful)
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: (Score:1)
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 (Score:5, Interesting)
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: (Score:2, Insightful)
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: (Score:2, Interesting)
Re: (Score:3, Insightful)
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.
Re: (Score:1)
Occam (Score:2)
Re: (Score:2)
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: (Score:1)
Re: (Score:2)
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
Re: (Score:2)
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 hu
Re:Keep a cat out when it has a mouse?? (Score:5, Funny)
Re: (Score:2)
Re: (Score:2, Informative)
Re: (Score:3, Informative)
Re: (Score:1)
If you're used to dealing with the AVR, and the C language on the AVR, the Arduino already looks awfully hacker unfriendly.
Re: (Score:1)
Arduino is actually coded in C++, not C.
Just for clarification.
Re: (Score:2)
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 do
Re: (Score:2)
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: (Score:2)
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 tim
Re: (Score:1)
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
Re: (Score:2, Informative)