Enjoy programming microcontrollers, but frustrated about how difficult it can be to get them to do more than one thing at a time? Well, then you might be interested in Concurrency, an open source programming language and environment specifically designed with multithreading in mind. That means you can write programs that do multiple things at the same time, without interfering with each other. Of course, you could achieve the same things using a stock Arduino with some crafty coding or timer interrupts, however using a purpose-built language such as this could be a great way to get your feet wet in threaded computing. Check out their website for source code and Creative Commons-licensed tutorials!
18 thoughts on “Easy multithreading on Arduino with Concurrency”
Comments are closed.
ADVERTISEMENT
Support Make:
Join Make: Community Today
Join Make: Community Today
….if you have a Mac that is.
For the moment, only the Mac binaries seem to be available. They seem to have every intention of releasing Windows and Linux versions, and the source code and instructions are provided to compile and run on those platforms. Want to give it a try and let us know how it goes?
If you are going to learn another language, than please just let it be C. With C you can really program your Atmell (=Arduinno) and make full use of all its potential.
People it’s not that hard. Take a couple of months to learn and practice and you have a useful skill for the rest of your live instead of another pseudo language
I think there is plenty of space for languages like this one. It’s all about using the right tool for the right job. If you want to be an expert in microcontrollers, I agree, there is no substitute for learning C (really, learning assembler), but if you just want to bang out a couple of control circuits for a project, so you can focus on the parts that you actually care about, then I say by all means, use a language like this and don’t re-invent the wheel.
Besides, there’s more to learning proper multithreading than ‘just learning C’- you have to understand the architecture of the microcontroller, atomic operations, race conditions, etc. It’s not trivial stuff, and learning in steps can help make it more approachable.
I’ve done the learning assembly thing for too many architectures to even discuss. It’s a total waste of time and brain cells. The assembly languages change so for new chips it’s a full time job just keeping up, I learned intel/DOS quite well. I thought “int 21h” would be around forever, now I bet 90% of the people here don’t even know what it was for.
If you learn assembly you’re tied too tightly to the specific line of MCU’s. For any given project, you’re probably better off with sloppy C on the “right” controller over clean tight assembly on “your” controller.
And just to be clear, this is a complete reversal from what I would have said 5 years ago. I think everyone needs to learn this the hard way.
Thanks for your insightful comment, Jason. I didn’t mean to suggest that one should always program in assembler, just that you probably need to go through the process of learning it on at least one architecture, in order to learn how microcontrollers work. It’s also handy to understand if you want to port operating systems to new architectures, or write compilers :-). Again, I think this comes down to choosing the proper tool for the job.
C is nothing special. In fact, it specifically doesn’t allow for multithreading. Most people will want a pseudo language like Concurrency.cc or NesC to provide compiler support for the necessary tools. Granted, NesC / Arduino is based very much on C, so it helps a lot to know C in any case. But don’t pooh-pooh this just because it’s not your preconcieved notion of good enough.
Personally, I’m getting tired of people using/inventing unpopular languages for this sort of thing. You aren’t adding something new that existing languages don’t have. All you’re doing is adding a hurdle to those who do not know the language.
This is a big reason why I’ll never step into the parallax propeller realm. Why the hell would you create a proprietary “spin” language that is so much slower than the equivalent in C? It’s pointless to do so. Use a preexisting language.
First, thank you Matt Mets for your comments. You’re spot on.
@tired: This isn’t a new language. We didn’t invent it. occam was directly inspired by fundamental theory regarding how we reason about parallel programming[1]. And it has been around for several decades.
@martini: I think it is rather unfriendly to say that artists should have to master real-time programming in C just to do print data to their PC while keeping two LEDs blinking. This is exactly what it is good for. Again, occam[2] is not a pseudo-language—it has a history nearly as long as that of C.
@Anonymous #1: We’ve been working on these tools for years. The Arduino port is new (summer 2009), and along with starting a book to support our users, we’ve been rewriting everything about how we build our software. The Mac was done first, so we released everything. We’re finishing up the Windows build system. This, unto itself, is a substantial project. But it will be there soon. (Linux builds very easily, but we’ll package things up there as well.)
If you want to do two things “at the same time” on the Arduino, using occam you literally say “do these two things in parallel.”
PAR
doThis()
andThat()
That’s a fundamentally powerful idea. You cannot do that in C. (But you can write a VM that lets you do it.) The Propeller (a very cool device) gives you this by providing multiple cores. We turn your Arduino into a Propeller chip through software.
[1] http://en.wikipedia.org/wiki/Communicating_sequential_processes
[2] http://en.wikipedia.org/wiki/Occam_%28programming_language%29
kevin,
Don’t let Spin put you off. The Propeller has a very unusual architecture and Spin fits it quite well. Spin bytecode may be slower than machine code but it’s still quite fast and much more compact. Plus, Spin includes an assembler. And the Propeller is just hella fun.
But if you really need C, there are *two* C compilers for the Propeller.
I understand. I think it’s hard enough to just learn new architectures without having to memorize new languages. I already know too many languages, and I just hate that new ones are being invented that aren’t of a new paradigm.
Because of this, if I decided to use C for the Propeller, I would be worse off because everyone else has Spin example code.
The dirty little secret of proprietary languages is:
* lack of portability,
* restrictive copyright
* a legal minefield of intellectual property
This is why companies often embrace a framework, extend it with some company specific property, and attempt to extort consumer market share from perceived competitors.
Apple and Microsoft have been doing this for 25 years.
(.NET, C#, MFC, Carbon, and countless others.)
Thus, even the C/C++ people often take for granted is rarely standard. Notably, even the GCC does numerous things that aren’t supported in many other compilers.
The Propeller could have been quite popular with a simple GPL threading library. But, Parallax has been reselling PICs at ten times their cost for 15 years.
No developer in their right mind will touch such products while other options exist.
What does this have to do with the article? We were talking about a FOSS implementation of a well-established programming language on an open hardware platform. If you don’t like someone’s tool, don’t use it, help them improve it, or go build something better and share it with the world. When you do, please let us know and we will put it up here.
I just don’t understand the hate.
If you consider Arduino to be *only* a tool for training EEs, then perhaps it would be prudent to stick to C. (Not that C is a good language, or a nice language – its standardization and speed are the only things it has going for it.)
But Arduino is not only that – it’s used by hobbyists, designers, and various other people who don’t want to learn programming for a profession so much as learn as little as possible in order to achieve their goals.
For this, C is only going to get in the way. You simply can’t do concurrency in C. It has zero support for it. What you can do is write your own concurrency *system*, and then program that … and for simple cases an ad-hoc approach is going to be successful. But doing a full system on your own is a waste of time if other options exist.
The Arduino (and Mindstorms) both need an easy-to-use, user-friendly environment for creating programs which have concurrency. And let’s face it, most interesting tasks need some level of concurrency. As soon as you have two servos attached, or two sensors attached, you run into this problem.
To my mind, Concurrency for Arduino appears to be completely revolutionary.
As for the arguments in favour of C, I don’t follow. By the same logic, we should not be using microcontrollers at all, but the more “standardized” components such as resistors and transistors. You don’t want vendor lock-in, right? Oh, and why use someone else’s circuit board, when you can breadboard a raw microcontroller and learn more? And you probably shouldn’t be relying on 3rd-party boot loaders either – write your own!
My point is, Arduino may lead some people on to these advanced things, but the learning curve needs to be gentle. Perhaps some people will use Concurrency and find it has timing issues, which can only be gotten around by writing in raw assembler (even C isn’t good enough for strict timing – think of interlacing audio generation and video generation, which is almost – but not quite – impossible). So then they go and learn what they need, *when* they need it. But until then, many people can benefit from easy-to-program concurrency, and may never leave that environment.
I agree with a lot of what you said. What I see as the problem is let’s say a relatively new user spent some good deal of time learning C/C++ to work with arduino. Somewhere down the line he needs to do concurrency. Now if he is going to use concurrency.cc, he will have to learn occam-pi.
Now he spends time learning that and creates his project. He releases the project for others to view and download. Now the people interested who don’t know occam-pi and want to use his code, will now have to learn it.
And what about integrating it into code that already exists? If someone has a big project they were working on and now they need concurrency, do they need to port all that code over to occam-pi?
I just don’t think it’s very helpful to use yet another language for stuff like this. It’s like if I were to come up with some nice interrupt library, but design my own language and provide a compiler in order for you to use it.
Btw, I don’t think C/C++ is the end all be all. But it is what Arduino is based on and if you’re making something for that environment, it’s best to stay with that language.
@Eddie Edwards:
Our mindset in developing our tools is that the people using them *do not want to program*. That is, they’re artists or hobbyists who have a goal that is larger than the code they are writing. Therefore, anything we can do to help get complexity out of their way is a win. (As you point out, add a few sensors and actuators and things can get complex very quickly.)
If what we’re doing doesn’t get us there yet, we’ll keep working at it. Usability matters. We’re a small team, and we all have day jobs, but we’ll do our best. And we’re very open to collaboration and contributions.
@hiddensauce:
You’re right. If I write things in occam-pi, and you want to extend my software, you do have to learn the language. I can’t fix that one. :-/
Now, if you’ve got a lot of C laying around, and you want to integrate it, it is possible. From an occam program you can call code written in C. When we run occam on desktop-class machines (that is, when we write programs to run on Mac/Windows/Linux machines) we make use of OpenGL, SDL, Player, and other libraries that are written in C, but called from occam programs. It isn’t something you can casually do from our end-user environment at the moment, but that isn’t a casual kind of thing.
Where I do think you’re wrong is this statement:
“It’s like if I were to come up with some nice interrupt library, but design my own language and provide a compiler in order for you to use it.”
It isn’t at all. We took an existing language, with decades of work behind it, and ported it to this platform. We did this because the language was originally designed for hardware programming, and the kinds of things people are doing with the Arduino seemed like a natural fit. We’ve even gone a step further, and are developing a library and text (hopefully with feedback from users) that will help make it easy to engage in interesting hardware projects on the Arduino. If you ported Erlang to the Atmega328, *that* would be similar… except Erlang doesn’t do well in 2K of RAM, last I checked. I will claim that learning occam-pi will help you when you move on to Erlang, or Google’s new language Go, or even when you sit down to design your interrupt library.
Thanks for the good comment and for thinking about what the existence of a new tool for the Arduino implies. Personally, I think it’s a very good thing that there’s now another language available for this platform, even if I did help develop the tools. :)
Well, being able to call C is excellent. That shuts up most of my worries. I appreciate what you’ve done and I hope you continue.
Will it be able to call C++ in the future? Or do we make C function frontends to method calls?
Placed a period of time restricted with new music. Like a patent it’s essentially a limited monopoly when typically the obvious case is of course the particular exceptional to nike air max 1 pas cher http://mofact.org/wp-content/temp/ certainly create, utilize, and sell typically the complex innovation for just a limited time period. Once the phrase regarding protection has ended, the branded development penetrates anyone area. Music isn’t diverse subsequently anyone inventing something…