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.