next topic »

[Reply #45 on:]

I second RobertBerger's comments.

Let's see what the future brings and also how well arduino will be accepted by "professionals" who know how to program. Besides, as you say, once you understand the concepts of multi-threading it's much easier than poking around in ISR and re-inventing semaphores, mutexes and message queues...

Professional software engineers have been using RTOSes in critical embedded systems for over 40 years with computers no more powerful than the Arduino.

For the Apollo 11 in 1969, a real time kernel that could support eight tasks was used.  The Apollo Guidance Computer was about like a very slow 644 AVR.  It had 4 KB RAM and 72 KB ROM.  There were two computers, one in the command module and one in the lander.

In the early 1970s I worked on a control system for a large particle accelerator that used a preemptive RTOS on MODCOMP II computers.  These machines had either 32KB or 64KB of core memory.

I do agree that few Arduino projects need a RTOS and fewer Arduino users have the skills, training, and experience to use a RTOS effectively.

My ports of ChibOS/RT and FreeRTOS show that a RTOS can be used a library without modifying the Arduino core.  Download the RTOSes and examples here http://code.google.com/p/beta-lib/downloads/list.

[Reply #46 on:]

Interesting reading about old times

Somewhat surprised about the resistance against threads, before I started programming on arduino I don't think I have made a program that don't use multiple threads in several years.. Extremely practical and puts things where they need to be.. The alternative is implementing it yourself if you need to do more than one thing, calling functions from loop and testing in the functions if they need to run..

Would be better having having a preemptive os with shiftOut and spi etc. able to do what they need. I assume there are significant delays a lot of places that could be utilized by other threads .

[Reply #47 on:]

Somewhat surprised about the resistance against threads

I'm not. The simple fact is, threads are hard. They are full of subtle traps and even harder to get right once synchronization betweens an issue. Add to the fact that many Arduino projects are created by people with no programming background, threads should be avoided by the majority of Arduino users. Their use should be discouraged, though perhaps not with the veracity frequently shown here.

I've seen many threaded projects created by self proclaimed thread gurus which were only "mostly right." The projects experienced odd failures which were difficult to track down. And in case its not clear, projects which use threads which are implemented, "mostly right", are in fact completely wrong. Threads by their very nature are relatively unforgiving.

Tracking down threading problems on a full blown computer can be difficult in the best of times. Tracking down threading problems on a very limited environment such as Arduino, can be nearly impossible. Those without a background in programming absolutely should step very lightly.

, before I started programming on arduino I don't think I have made a program that don't use multiple threads in several years.. Extremely practical and puts things where they need to be.. The alternative is implementing it yourself if you need to do more than one thing, calling functions from loop and testing in the functions if they need to run..

You say that as a programmer with threading experience. But that experience can also lead to very subtle failures, given the right (or wrong) use cases, without a background in real time. The fact is, most of the threading cases I've seen used with Arduino have been soft realtime use cases. Should someone require hard realtime, I expect many of these same users would experience problems. IMO, its the fact that soft real-time seems to be the norm, is why so many who choose to use threads on Arduino have met with success. Soft realtime, by its very nature, is far more forgiving than hard realtime.

Would be better having having a preemptive os with shiftOut and spi etc. able to do what they need. I assume there are significant delays a lot of places that could be utilized by other threads .

Keep in mind preemption adds latency and consumes relatively lots of RAM; especially if call depth is deep. The fact is, many Arduino users have no idea what a stack is nor understand the implications of my previous statement. IMO, co-operative multitasking meets the majority of needs for typical Arduino class of problems. Personally, I'd love to see a co-operative multitasking framework become embraced by the Arduino community.

I don't want to give the impression I'm anti-threading as so many others here appear to be. I am not anti-threading. In fact, I'm working on projects which do use threads. And in most cases, I'm using ChibiOS; including a port to the atmega8. That said, if you believe your project requires a preemptable kernel, your project must be fairly complex. Chances are, most people can make do, and have space to spare, by using a co-operative scheduler or even the more primitive event libraries and worst case, the basic timer math (which also can contain subtle traps for overflow).

If people want to make recommendations for a small and Arduino friendly co-operative OS, I'd love to hear about them. Regardless, from time to time some bad anti-threading information is provided by the community but I absolutely don't fault them for it. Threading is hard and even harder to do right.

[Reply #48 on:]

I don't care if it's soft or hard as long as it's preemptive. You'll have some serious crap on your hands if you have a requirement to for example blink a led every second and do some computation taking a long time (>200ms would probably look weird)..

As long as you are aware of timing issues I find threads relatively forgiving. Besides, if you never try you will never learn so that's not really a good reason not to have it in arduino. Better to start a thread learning page with warning to people that they will have to expect to use some time learning threading..

The latency and ram requirements on the chibios page seems quite reasonable.. And I don't have any illusions that my current projects require a preemptive kernel, but I have one in the not too distant future that will. Chibios seems to work fine with arduino so I don't really care what happens with arduino in threading respect. Also protothreads apparently work with arduino, but back in my school days I found them a bit cumbersome to use, albeit cool and small.

The more independent functions you add, the more sense threading makes. Turning one led on and off from two different threads doesn't make too much sense and has serious timing issues. I tried it the other day and it was rather cool though.. (if turned on, blink every 10ms)

[Reply #49 on:]

I'm not against threads; I just strongly advise the typical Arduino user against their use in order to avoid problems that will surely follow. I've done lots of synchronization bug fixing in commercial and open source code, even in country-wide telecommunication systems currently running on the top first-world countries. When I say threading is hard, it is. It's hard to do it right (note that the real issue is thread synchronization, not the threads per se); not the trivial stuff like a pair of threads each blinking its own LED, of course, but who needs a do-nothing-useful program. I myself choose to use a preemptive model if the threading one isn't really needed. Or, if have a thing or too that really need accurate timing, just use a timer interrupt to do that little thing (as less as possible) and have a non-threaded main program.

Many threaded programs out there are like a semiconductor used a bit out of spec - one day, maybe, it will bite you.

[Reply #50 on:]

I'm not against threads; I just strongly advise the typical Arduino user against their use in order to avoid problems that will surely follow. I've done lots of synchronization bug fixing in commercial and open source code, even in country-wide telecommunication systems currently running on the top first-world countries. When I say threading is hard, it is. It's hard to do it right (note that the real issue is thread synchronization, not the threads per se); not the trivial stuff like a pair of threads each blinking its own LED, of course, but who needs a do-nothing-useful program. I myself choose to use a preemptive model if the threading one isn't really needed. Or, if have a thing or too that really need accurate timing, just use a timer interrupt to do that little thing (as less as possible) and have a non-threaded main program.

Many threaded programs out there are like a semiconductor used a bit out of spec - one day, maybe, it will bite you.

This is something people just don't understand. I completely agree with everything you said and I too am a threading advocate. Threading is hard. Bluntly, anyone who thinks otherwise don't really have the experience to say otherwise. I know that sounds trollish, and perhaps it is, but its still completely true.

And as you said, spawning a thread isn't hard. Thread synchronization is hard. Thread resource management is hard. Its funny how many times I've seen people declare threading is easy and show me code to illustrate how easily they did complex things only to then turn around and point out numerous synchronization bugs. And that's the problem with threads. Just because it appears to work, doesn't mean it will always work or that the implementation is correct. The worst kinds of threading bugs are those which surprise you every 100 hours because some odd workload places the stars in just the right alignment. Added is the fact that uniprocessor threading, by its nature, tends to hide synchronization issues.

Aside from all that, most people don't understand the difference between hard and soft real time. Even many programmers who are used to dealing with threads are frequently caught off guard by hard real time and don't immediately realize the schedulers used in hard real time behave differently than the batch, pre-emptive schedulers they are accustomed. Made even worse, many programmers fail to do the basic math to ensure there is enough work units in a given unit of time to satisfy the demand for units in the same unit of time. Things appear to work but just don't work at the right times.

Long story short, threads are awesome, but threading right, is hard. Its definitely not a new programmer's friend.