Arduino Forum

Using Arduino => Programming Questions => Topic started by: Brig on Apr 16, 2011, 10:30 am

Title: Arduino & thread
Post by: Brig on Apr 16, 2011, 10:30 am
I've googled a little about arduino's thread, and I found the protothread

http://harteware.blogspot.com/2010/11/protothread-powerfull-library.html
http://harteware.blogspot.com/2010/11/protothread-powerfull-library.html

Did somebody try it?
What do you tink about the ptTrhead?
Title: Re: Arduino & thread
Post by: Korman on Apr 16, 2011, 03:13 pm
This is a typical case of: If you need this feature, it might help you. If you can live without it, you're better off without.

On regular PC and more powerful controllers, threads have become the standard way to approach problems because they work quite well on them. But on an Arduino, concurrency and multi-threading are in general a bad idea, except in the few rare cases where they are exactly the needed solution.

So the more interesting questions are:


Korman
Title: Re: Arduino & thread
Post by: Brig on Apr 17, 2011, 11:59 pm
Well... i've a RTC (DS1307), and needs to be "refreshed" to have the real time, so it would be "cleaner" if a thread is dedicate to time update ...
However, it is safer if done in sequence, but ... a thread take away the task of the refresh by functions / user
Title: Re: Arduino & thread
Post by: mowcius on Apr 18, 2011, 12:04 am
Quote

Well... i've a RTC (DS1307), and needs to be "refreshed" to have the real time, so it would be "cleaner" if a thread is dedicate to time update ...
However, it is safer if done in sequence, but ... a thread take away the task of the refresh by functions / user

Notice how nobody else seems to have had this issue...

You have the wrong idea about what you need.
Look at the 'blink without delay' example and consider just creating a function for grabbing the time every so often.
Title: Re: Arduino & thread
Post by: nickgammon on Apr 18, 2011, 12:13 am
Threads are evil. Avoid them.

http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf

For one thing you don't have a heap of memory or program space to be implementing threads. For another, a simple check in a loop will probably suffice, failing that use an interrupt.

Threads introduce their own problems, like concurrent access to the same memory address, so they need to be used in conjunction with locking of parts of your program so this doesn't happen. Some processors have interlocked-increment instructions to help with managing this. I doubt that the Atmega has such things.
Title: Re: Arduino & thread
Post by: Brig on Apr 18, 2011, 12:19 am
Unfortunately I need something that is precise enough, which is guaranteed by the RTC, which also manages the day which comes in handy.

probably no one has had this problem because no one has needed such a thing;)
or maybe my programmer mindset leads me to things rather insane XD

But I saw very "cute " a thread that masked the update time, perhaps with a mutex, just to ensure proper access time, so that each cycle, the thread can get in a couple of seconds to sleep leaving the processor time to advance the other threads (one would have to devote to light sockets, while listening to another user input)
Then, again, will be the distorted mentality of the programmer XD

p.s. are you tolking about http://www.arduino.cc/en/Tutorial/BlinkWithoutDelay ?
how accurate millis()? http://arduino.cc/en/Reference/Millis
Quote
This number will overflow (go back to zero), after approximately 50 days.

This is a significant problem for the application you want to achieve
Title: Re: Arduino & thread
Post by: mowcius on Apr 18, 2011, 12:27 am
Quote
Unfortunately I need something that is precise enough, which is guaranteed by the RTC

You're using a DS1307 so those two comments can't go together - the DS1307 is not that precise.

Ok I'm not quite understanding what you want to do. Do you want to do something at a precise interval?

Title: Re: Arduino & thread
Post by: nickgammon on Apr 18, 2011, 12:33 am

or maybe my programmer mindset leads me to things rather insane XD


Perhaps.


Quote
This number will overflow (go back to zero), after approximately 50 days.

This is a significant problem for the application you want to achieve


That can be worked around. If the time now is less than the last time you took a couple of minutes ago, you got the wrap-around. Then you compensate for it.

I don't see how threads are solving a problem. If the timer is not accurate, the threads won't make it accurate. If the clock is not accurate, the threads won't make it accurate.

In any case you could get a GPS module, which (assuming it gets a signal) will always give you an accurate time.

Failing that, get a temperature-compensated RTC.

Quote

... one would have to devote to light sockets ...


Your requirement to turn the lights on and off automatically must be a lot more precise than mine.
Title: Re: Arduino & thread
Post by: mowcius on Apr 18, 2011, 12:37 am
Quote
Failing that, get a temperature-compensated RTC.

In theory the GPS could be rather less accurate than this - the DS3231 is quite nice but in most applications, completely unnecessary (it does have the crystal and other guff inside it though which makes it rather nice)
Title: Re: Arduino & thread
Post by: Brig on Apr 18, 2011, 12:47 am
I know the problem of counting can be avoided, but I would complicate the code a bit, also to take account of the day etc etc ... of course everything can be done, but I am for the simple things XD

you say you use millis and "caring" for RTC? well ... This brings me to save a class, but I should make myself a library (at least in c) to do something decent (unfortunately, the programmer mentality compels me to do something decent in all cases, trying to ensure stability and maintenance of the code )

Now, it is not something that I need to specify the milliseconds, because the latency of the links, when requested to do when I receive the RTC is already a gap of time ...

Basically I need to run a timer that can be set as desired (not in code) and make that arduino is dedicated to the control of the temporal conditions / environment to turn on / off the jacks
Title: Re: Arduino & thread
Post by: mowcius on Apr 18, 2011, 12:52 am
Ok now I'm completely and utterly confused as to what you're trying to do.
Title: Re: Arduino & thread
Post by: nickgammon on Apr 18, 2011, 01:04 am

... the programmer mentality compels me to do something decent in all cases, trying to ensure stability and maintenance of the code ...


Exactly. Which is why you avoid threads.
Title: Re: Arduino & thread
Post by: Brig on Apr 18, 2011, 01:15 am
My problem is to manage an aquarium. To do this I need to have control over the sockets (on / off).
The decision to turn on / off is due to time or (not &) environmental conditions (eg temperature).
I must therefore have a watch that allows me to assess whether or not it is time to turn on / off a wall.

Currently I have based my project on RTC, which is updated by a method call in the code.
I do not like this, it lets to the programmer the responsibility to ensure that the time is updated (which is needed both with millis () and RTC).
I wanted to introduce a thread to raise the programmer from this responsibility (update the time without calling a method)

From what I understand, you are not advised to use a thread, and suggested to do with millis () what I did with RTC (leaving the code sequence)

p.s. of course I carry around with thread the mutex XD
Title: Re: Arduino & thread
Post by: nickgammon on Apr 18, 2011, 01:19 am

Currently I have based my project on RTC, which is updated by a method call in the code.
I do not like this, it lets to the programmer the responsibility to ensure that the time is updated (which is needed both with millis () and RTC).
I wanted to introduce a thread to raise the programmer from this responsibility (update the time without calling a method)


This thread, it won't be written by a programmer, right?
Title: Re: Arduino & thread
Post by: nickgammon on Apr 18, 2011, 01:23 am
Look, you are making this way, way too complicated.

http://en.wikipedia.org/wiki/KISS_principle

This aquarium isn't rocket science. You have a RTC which, once set, tells you the time to within a few seconds for the next ten years.

In your main loop you check the time (and the temperature), and turn things on and off. That's it.
Title: Re: Arduino & thread
Post by: Brig on Apr 18, 2011, 01:31 am
come, by which we understand each other:)
I know that the thread should write a program, but it seems more correct and beautiful than seeing a RTC.refresh () inside the loop ()
then a thread is more difficult to forget that a line in the loop ().
Then I could put the launch of the thread in the constructor of the RTC, thus making it even more invisible to the user of the library:)

Nick, now I've used the RTC; I can also use the millis(), and as you said, no need for a missile base;)
Just wanted to separate the RTC update the code;) (loop () or other methods)
Title: Re: Arduino & thread
Post by: mowcius on Apr 18, 2011, 01:34 am
Quote
My problem is to manage an aquarium.

An aquarium... is that it?

You really are making this much too complicated.

Quote
but it seems more correct and beautiful

You sure you shouldn't be doing art?

It's about function not form - when it's stuck on the chip - nobody's gonna see it again so who cares how it's written as long as it works well.
Title: Re: Arduino & thread
Post by: graynomad on Apr 18, 2011, 01:35 am
Well I just found this topic and have no idea what timing accuracy and threads and mutexs can possibly have to do with controlling a socket or two for an aquarium?

Quote
Currently I have based my project on RTC, which is updated by a method call in the code.

So read the time and the temp and make a decision.

Quote
I do not like this, it lets to the programmer the responsibility to ensure that the time is updated

Isn't that the point of an RTC, it does all the updating, you just read the time.

Sorry Brig, I'm as confused as it appears everyone else is :)

______
Rob

Title: Re: Arduino & thread
Post by: Brig on Apr 18, 2011, 01:48 am
The fact is that I do not know how to explain (better than I did) XD

I know what does RTC etc etc ... "my problem" was to ensure that "no one" should clearly read the values ??of RTC and update the variables, but to entrust this task to a thread, working with a mutex, guaranteed variable date and did not require a dedicated line of code updating of the variables (RTC.refresh ())

This is how I would have done if I had to deal with this problem for a PC ...
then it is not a mortal thing, because for now it works sequentially ... But I wanted to use the thread .. this can be said of my problem ...

but if not recommended the use of thread ... I'll try to go as I have done so far, certainly no one dies XD (because then I would have liked, if possible, keep the source of my libraries, but distribute the objects of the same)

or maybe the problem is that I use a translator who can translate phrases incorrectly, or confuse the concepts ... Unfortunately, I have a really rusty English and we will get an eternity to make speeches in English XD
Title: Re: Arduino & thread
Post by: mowcius on Apr 18, 2011, 01:50 am
Some sentences have been hard to understand but the underlying concept of why you can't just have a 'dedicated line of code' for refreshing the RTC is confusing us all.
Title: Re: Arduino & thread
Post by: retrolefty on Apr 18, 2011, 02:44 am
I think for many new to microcontrollers, the idea of threads or concurrency gives the impression of being able to process individual parallel processes and that just does not apply to a single processor arduino board, but rather the terms should be reserved for true multi-core processors. There are several methods to accomplish individual software tasks in a sketch (millis(), interrupts, state machine, etc) but the bottom line for an arduino is that it can only process a single instruction at a time and to handle multiple independent tasks then there is just a whole lot of task switching that will have to be done to emulate true threads or concurrency.

I guess I'm trying to say that for an arduino true threading (or concurrency) can not apply, rather one uses proper program structure to emulate the concept.

Lefty
Title: Re: Arduino & thread
Post by: Brig on Apr 18, 2011, 09:33 am
simply believe it is better to avoid putting the "RTC.refresh ()", solving with something that just works without requiring you to manually refresh, so I thought of the thread.
I know that arduino is uniprocessor, the thread but can also be simulated with the uniprocessor ... For example, simply save the current IC, call the procedure (function) that takes care of thread and eventually make a RET IC-current ...

The only problem is that I know of only D-RISC assembler (for educational reasons) and I could not understand a lot about how to use assembler code in C (and for problems that lack of free time, and do not need to know this part of the C I do not tell me how to do)

But a trivial thread could do that every few lines of code changes made ??IC ... although it is not really a thread ... and in so doing we should go to work on the general assembly, not what connected through C
Title: Re: Arduino & thread
Post by: nickgammon on Apr 18, 2011, 10:30 am
Your heart seems to be in the right place, but this is a $6 microprocessor, not a Pentium 5 (or whatever they are these days).

In exchange for cheap hardware, you have to work a bit harder.

And you haven't really rebutted my link to the "threads are evil" page.

Threads have advantages, and disadvantages (like absolutely everything). You haven't addressed the disadvantages.
Title: Re: Arduino & thread
Post by: Brig on Apr 18, 2011, 02:07 pm
probably the reason of the thread absence is due to the desire to direct the product to the general public, who perhaps had never even write a "hello world " ...

however, the disadvantages of threads can be tied to synchronization ... but with a bit of attention and experience there is more to this case either, since it is natural to you to program in parallel
Title: Re: Arduino & thread
Post by: AWOL on Apr 18, 2011, 02:13 pm
If you want to program parallel processes, use a language designed to express parallelism, like occam, don't use a nasty sequential programming kludge like threads.
Title: Re: Arduino & thread
Post by: jraskell on Apr 18, 2011, 04:15 pm

simply believe it is better to avoid putting the "RTC.refresh ()", solving with something that just works without requiring you to manually refresh, so I thought of the thread.


That can be solved using one of the hardware timers.  Look at the Timer2 library in the Playground.  You'll see that, once it's set up to run at some interval, there is no regular 'refresh()' call required in the main loop.  Threads are not only not necessary, but the complete opposite of an elegant and clean solution to a rather simple problem.

Though to be perfectly honest, the perceived issues with using a refresh() call in the main loop are questionable as well.  The whole point of loop() is to execute code over and over and over, so any objections to using it for that purpose are objections to it's whole existence.

Utilizing a hardware timer requires the use of an Interrupt, which has it's own suite of snares and hurdles to deal with, and should really only be used when real accuracy is required, and I can't think of anything involved with controlling an aquarium that would require more than second resolution accuracy, never mind millisecond or microsecond resolution accuracy.

So, to put it simply, I simply believe it is better to use an RTC.refresh().  You're creating a problem where there isn't one, and looking for a solution that is more complicated, more error prone, and more obtuse.
Title: Re: Arduino & thread
Post by: nickgammon on Apr 18, 2011, 11:49 pm

probably the reason of the thread absence is due to the desire to direct the product to the general public, who perhaps had never even write a "hello world " ...


Have you read the reference I posted? Since I am assuming you didn't, I'll quote from the Abstract by Edward A. Lee:

Quote
Although threads seem to be a small step from sequential computation, in fact, they represent a huge step. They discard the most essential and appealing properties of sequential computation: understandability, predictability, and determinism. Threads, as a model of computation, are wildly nondeterministic, and the job of the programmer becomes one of pruning that nondeterminism.


There are some serious objections to using threads, so I think it is unfair to claim that they have been omitted because it is a "consumer product" or that the designers stupidly did not think to include them.

For one thing, there is no hardware mutex provision, which is one of the ways you deal with synchronization issues. Second, even with a mutex (eg. implemented in software) you have the "deadly embrace" problem, where thread A locks resource X, and then waits for resource Y. Meanwhile thread B locks resource Y and then waits for resource X. Neither thread will continue, and the program stalls.

So you haven't magically simplified things, you have exchanged one lot of complexity (working with multiple items in a single thread) for a different lot of complexity (managing thread access to mutually-needed resources).
Title: Re: Arduino & thread
Post by: westfw on Apr 19, 2011, 08:56 am
I don't know if the erudite arguments against "threads" are relevant here.  The "protothreads" library that Brig is talking about isn't anything close to real threads...

Quote
I have based my project on RTC, which is updated by a method call in the code.

I gather that the idea is to have a sort of "background thread" that periodically synchronizes the Ardunio's idea of what time it is with an RTC/Calendar chip ?   For purposes of fiddling with AC-controlled (60Hz) sockets and valves and things with relevant timescales based on thermal mass of several hundred pounds of water?

I agree with others that you're making this WAY too complicated.  I would suggest getting rid of the Arduino-side "copy" of the clock entirely, and simply reading the time from the RTC whenever you need it.  No more synchronization problems.  And while reading the RTC may be "slow" compared to other AVR operations, I strongly suspect that it is plenty fast even compared with the 60Hz AC frequencies involved...
Title: Re: Arduino & thread
Post by: pluggy on Apr 19, 2011, 09:35 am
Another way of looking at it, is an Arduino has about the same amount of grunt as a 70's or early 80's home computer, they didn't do threads then, the arduino doesn't do threads now (at least usably). 
Title: Re: Arduino & thread
Post by: Brig on Apr 19, 2011, 12:36 pm
I never said that the creators of Arduino have foolishly entered the thread. I said that because something is non-trivial operation and that not all programmers (particularly novice ones) know how to master in order to simplify the life they have not been included.
Or just as likely not have made them because of the small size of the memory & co.

The KISS principle I know him well, and I do not create great difficulty managing small little thread as I wanted to do, not to mention the problem of dead lock ... I should not have to face because I needed a single mutex ...

I think we should not talk about my project & thread, but only the thread, because they can be used independently of the project.
For that reason I had asked arduino & thread, not my project & thread

As Told by westfw the idea is to have a thread that updates the variables "time" of my project with those that are given by the RTC, because he seemed a natural thread that was dedicated to reading and then update the program variables

Without a doubt my difficulty in explaining, and no command of English are points down in the debate, and as such should focus on the thread in general.
If you understood that to maintain a small and inexpensive processors have not been made ??I'm fine, I just wanted to understand why I had not heard.
Title: Re: Arduino & thread
Post by: mromani on Apr 19, 2011, 05:42 pm
Brig, while I find the (software) threads concept quite fascinating, after reading this (interesting) (forum) thread I still can't understand what is wrong about "polling" the RTC time inside loop().
If you want to practice with threads on the Arduino, fine. But if your main goal is use the Arduino to manage an acquarium, then do yourself a favor and totally forget about threads.
There is the excellent Time library, which maintains the current time either via millis() or communicating with an RTC clock via I2C. This is 99% transparent, i.e. you can code to it and switch back and forth from an RTC to a RTC-less sketch in no time.
It's an excellent choice for periodic tasks.
Other libraries exists in the Playground that are equally good, although not as complete.

HTH
Title: Re: Arduino & thread
Post by: Brig on Apr 19, 2011, 07:40 pm
for didactic reasons I got used to the thread, and as long as this simple things I immediately use they natural ...

I repeat, my problem is a particular case, but should be seen in a wider range, where perhaps one can also do something nice ...
For example, alter the input from the numeric keypad (the phone), leaving a thread waiting on readChar even do a poll ... I find it more appropriate

and then repeat, not a problem, insert the line "RTC.refresh ()" it's just that I would rather not do it, because a programmer who uses my library can forget it, and before finding this little error... while if launch a thread that makes it alone, putting a mutex from Lokke on each access to the variables of RTC ... would be more simple and straightforward ...

personally if I had time, more knowledge of assembler and C more knowledge in general, I'll try to implement them willingly thread on arduino as good exercise!
Title: Re: Arduino & thread
Post by: westfw on Apr 19, 2011, 11:30 pm
In general, the problem with multithreading on a small microcontroller like the AVR is that there is not enough RAM.  A complete process context (32 registers + PC + stack + stack pointer is probably over 100 bytes, and the atmega328 chip used on Arduino only has 2k total.
Title: Re: Arduino & thread
Post by: mromani on Apr 20, 2011, 08:22 am
May I suggest a couple of links:

DuinOS, a FreeRTOS port to the Arduino platform:

http://www.multiplo.org/duinos/wiki/index.php?title=Main_Page

The QP framework (you can find it in the Playground, too):

http://www.state-machine.com/
Title: Re: Arduino & thread
Post by: TerryKing on Apr 30, 2011, 07:19 pm
And add to those 2, QNX which has been implemented on many much slower processors than the ATMEGA328 and which is running thousands of automatic machines of one kind or another in industry today. 

Other viable RTOS kernels have been implemented on processors from the 6502/6800 onwards. I even wrote one in 1980 that pretty much worked  :)  And I wrote lots of EDX based code on Series/1 with only 64K of memory, in the same era.

The main points about 'threads' or 'tasks' like: "Threads, as a model of computation, are wildly nondeterministic" is an argument against nondeterministic coding, not threads.  This is exactly why the QP Framework is based on the idea that all threads MUST be Finite State Machines.  This is a concept that I was able to enforce (Oh, Um, technically lead?) in Semiconductor manufacturing in one IBM plant in the 1990's.. and it DID decrease the instances of "wildly nondeterministic" code.  Requiring that network communications interfaces to process equipment be documented as Finite State Machines was finally accepted practice.  One grudging response was "I think we wasted some time using (this method) but it did make debugging a lot easier".

That said, I DID write a communications protocol using the approach which seemed to work OK and went into production and after it was running on about 20 systems for a few months it became clear that it occasionally crashed.  Ugg... Finally my friend Tony Burke (Who I am glad to credit years later!!!) found the bug. 

So nothing is sacred and nothing is perfectly error free. 

In a similar way, Proof is in the nontrivial application running clean for 1000 hours. Anyone writing some QP FRamework stuff on the free Arduino version?  I HOPE to get some time on this even though I should be writing other stuff.  "But Mom, I LOVE writing RTOS stuff  =( =(  it's SO cool." And the .NET guys and the IphoneAPP guys don't know WHAT the hell you're even talking about...

Title: Re: Arduino & thread
Post by: westfw on Apr 30, 2011, 10:19 pm
Quote
QNX which has been implemented on many much slower processors than the ATMEGA328

How do you figure?  I thought the smallest thing QNX ran on was a relatively good-sized x86?
In any case, "slow" isn't the problem.  RAM is the problem.  There are lots of nice multitasking systems that run fine on a system with 256K of RAM, but will have big problems on a system with 256K of flash and 8k of RAM...
Title: Re: Arduino & thread
Post by: TerryKing on May 01, 2011, 07:01 am

Quote
QNX which has been implemented on many much slower processors than the ATMEGA328

How do you figure?  I thought the smallest thing QNX ran on was a relatively good-sized x86?


Maybe I'm older than you  ;)

Today QNX is supported on ARM, PowerPC and X86 etc, and now on the Blackberry Tablet  :)   

But 25 years ago QNX did run on some of the earlier microprocessors that existed then. I'll try to find a reference, other than my recall of semiconductor process equipment running it...

Modern QNX has features that could never be supported on machines with very limited memory... 

But the QP framework has working examples running on Arduino, so they have some stuff figured out for 2011.

I'd mainly like to see some set of known solutions for Arduino beginners to start to encounter apparent concurrency without going back to school to learn about interrupt latency and directed graphs.


Title: Re: Arduino & thread
Post by: graynomad on May 01, 2011, 07:17 am
We used QNX for building control on a 6809-based computer in the 80s, I don't remember the details but it's probably fair to say it had 64k RAM.

One assumes though that QNX has gone the bloatware track like everything else.
______
Rob
Title: Re: Arduino & thread
Post by: nickgammon on May 01, 2011, 07:55 am
Ah, the old 6809. I like the Wikipedia article about it, in particular the HCF instruction (Halt and Catch Fire).

http://en.wikipedia.org/wiki/Halt_and_Catch_Fire

I don't suppose the Atmega has one of those?
Title: Re: Arduino & thread
Post by: TerryKing on May 01, 2011, 08:57 am

We used QNX for building control on a 6809-based computer in the 80s, I don't remember the details but it's probably fair to say it had 64k RAM.
...


Thanks for validating that my personal memory is still retrieving!   Hadda be someone associated with "Gray", I guess..
Title: Re: Arduino & thread
Post by: graynomad on May 01, 2011, 09:39 am
And then there was XPR (eXecute PRogrammer) LDN (LoaD Nothing) and a lot of other funny ones around a few years ago.

______
Rob
Title: Re: Arduino & thread
Post by: TerryKing on May 01, 2011, 10:24 am
Here's a comparisons of RTOS possibilities for Arduino: http://www.out--there.com/blog/rtos-for-arduino/ (http://www.out--there.com/blog/rtos-for-arduino/)
Title: Re: Arduino & thread
Post by: AWOL on May 01, 2011, 11:40 am
Quote
And then there was XPR (eXecute PRogrammer)

My personal favourite was the PowerPC's EIEIO instruction
Title: Re: Arduino & thread
Post by: graynomad on May 01, 2011, 11:49 am
That was on the Old MacDonald variant of that processor wasn't it?

______
Rob
Title: Re: Arduino & thread
Post by: nickgammon on May 01, 2011, 11:51 am

My personal favourite was the PowerPC's EIEIO instruction


So you are not referring to:

Quote
A "computer bought the farm" message is an error message displayed on GNU Hurd when one of the servers that provide kernel-like functions reaches a "hopeless" situation (after which it is usually terminated). This is a rough equivalent of a kernel panic in monolithic Unix-like kernels. Its corresponding error code is the Hurd-specific EIEIO, a reference to the folk song Old McDonald Had a Farm.


But rather:

Quote
Enforce In-Order Execution of I/O is an assembly language instruction used on the PowerPC computer processor used to prevent one memory or I/O operation from starting until the previous memory or I/O operation completed.


So, "do things in the order I tell you to"?