Go Down

Topic: Arduino & thread (Read 11938 times) previous topic - next topic


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)


My problem is to manage an aquarium.

An aquarium... is that it?

You really are making this much too complicated.

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.


Apr 18, 2011, 01:35 am Last Edit: Apr 18, 2011, 01:52 am by Graynomad Reason: 1
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?

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.

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 Gray aka the GRAYnomad www.robgray.com


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


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.


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.



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


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.
Please post technical questions on the forum, not by personal message. Thanks!

More info: http://www.gammon.com.au/electronics


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


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.
"Pete, it's a fool looks for logic in the chambers of the human heart." Ulysses Everett McGill.
Do not send technical questions via personal messaging - they will be ignored.
I speak for myself, not Arduino.


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.


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:

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).
Please post technical questions on the forum, not by personal message. Thanks!

More info: http://www.gammon.com.au/electronics


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...

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...


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). 


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.

Go Up