Go Down

Topic: Demonstration code for several things at the same time (Read 125235 times) previous topic - next topic

Coding Badly

If you haven't seen, this is Nock's tutorial:
http://www.gammon.com.au/forum/?id=11411


In case you don't want to / can't remember a five digit number...
http://gammon.com.au/blink

Robin2

#91
Sep 20, 2014, 04:31 pm Last Edit: Oct 02, 2014, 08:35 am by Robin2 Reason: 1

Since this is a sticky it's worth to post this method here as well:


Added 02 Oct 2014 --- @casemod seems to have moved his posts out of this Thread (as was suggested in the next Post) hence this and some of the following posts are in a bit of a vacuum.

Most of the posts in this Thread are about the cumulative error associated with
Code: [Select]
previousmillis = currentmillis;
and how it is better to use
Code: [Select]
previousmillis += time;
or (in your second method)
Code: [Select]
since += time

Please don't confuse newcomers by recommending the deprecated approach in this Thread.

It would probably also be very useful for newcomers if you would modify your Post and add an explanation about how &since works. Most of them will find that concept very confusing without a clear explanation.

...R
Two or three hours spent thinking and reading documentation solves most programming problems.

Robin2


I changed that bit and added a brief description

I posted the code with the intent of helping those trying to "multitask" or do things at the same time, not exactly the issue you mentioned, however if it is not suitable let me know so I can remove it or make further corrections


Thanks.

You don't seem to have changed the line with since = currentmillis.

And I can't see your explanation of the way &since works

Your concept might be better placed in its own Thread titled "A non-blocking alternative to delay()". If you move your code you could keep a link to the other Thread here.

...R
Two or three hours spent thinking and reading documentation solves most programming problems.

GoForSmoke




You don't seem to have changed the line with since = currentmillis.


I changed this line

Code: [Select]
if (currentmillis - previousmillis >= time) {
    previousmillis = currentmillis


with
Code: [Select]
if (currentmillis - previousmillis >= time) {
    previousmillis += time;



If you're using the blinking led as a status light then the first way will let accumulated "late errors" actually show.
What code is "right" is a matter of what your output is for. As an indicator, self-correction is not the best goal.
Nick Gammon on multitasking Arduinos:
1) http://gammon.com.au/blink
2) http://gammon.com.au/serial
3) http://gammon.com.au/interrupts

Robin2


If you're using the blinking led as a status light then the first way will let accumulated "late errors" actually show.
What code is "right" is a matter of what your output is for. As an indicator, self-correction is not the best goal.


Please don't reopen this discussion. It has all been extensively covered in earlier posts and the demo in the first Post in the Thread has taken all the discussion into account. My only concern is that @Casemod's contribution might confuse newcomers. He has said he will move it to another Thread.

...R
Two or three hours spent thinking and reading documentation solves most programming problems.

Nick Gammon


If you haven't seen, this is Nock's tutorial:
http://www.gammon.com.au/forum/?id=11411



Nick's tutorial. :P

My examples there actually do have the creep which is mentioned earlier. Putting aside coding issues, this creep is based on the fact that you reset the timer when the event is noticed, not a fixed interval from when it should have been noticed.

In the case of flashing an LED, this isn't an issue.

Let me give you an example in real-life terms. Say you get a credit card statement in the mail, and you have 30 days to pay. The 30 days is from when the statement was sent, not from when you receive it (which might be a few days later). The creep is in the delivery time (or maybe in the time it takes you to notice the mail).

To have the statements come every 30 days, the sender simply adds 30 days to when they sent the last one. To have the creep, they would add 30 days to when you received the mail.
Please post technical questions on the forum, not by personal message. Thanks!

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

GoForSmoke

Sorry about that Mr. Gammon, Sir! One quoted mistype that's never going to die, is it? IIRC, I did fix the original.

In the bills case it is desired to keep the billing cycle regular.  Apps should fit needs. Been there, wrote the packages.

I want a status light to tell me more about the running of the software, not less. I've got one now that doesn't so much creep as leap whenever the GSM element runs. It's for someone else and free work so I'm not going to fix that library but wow does it need unblocking!

I thank you again for your great tutorials that put words to what I never put words to. My right-brain thinking ways don't do that and I end up with poor explanations for thoughts that are more like working pictures. What can I say? Literally! It's been great to be able to link people to your full, coherent explanations instead of my poor attempts.

Nick Gammon on multitasking Arduinos:
1) http://gammon.com.au/blink
2) http://gammon.com.au/serial
3) http://gammon.com.au/interrupts

LarryD

Robin2
I am sure people new to programming will find your work very beneficial.
One comment, if a newcomer reads through the whole thread I think they may a bit confused with all the discussions.
IMHO it would be best to chop everything after your example which incorporates the the discussed creep code modification.
Thanks for your time on this.
Thanks to the software guys for there explanations also.

No technical PMs.
The last thing you did is where you should start looking.

Robin2


One comment, if a newcomer reads through the whole thread I think they may a bit confused with all the discussions.


I have been wondering about this as well, but I am concerned that I may be too close to the subject to take an objective view.

I have added a note for newcomers at the top of the first Post.

...R
Two or three hours spent thinking and reading documentation solves most programming problems.

GoForSmoke

I just wish that you had explained the central problem of blocking code explicitly.
That is why I still link to Nick's blog. He does a good job of doing that.



Nick Gammon on multitasking Arduinos:
1) http://gammon.com.au/blink
2) http://gammon.com.au/serial
3) http://gammon.com.au/interrupts

Robin2


I just wish that you had explained the central problem of blocking code explicitly.
That is why I still link to Nick's blog. He does a good job of doing that.


As I say in the opening post (the only one that really matters for a newcomer) I just set out to give an extended example of the BWoD concept. I was not trying to monopolize the subject.

I like Nick's stuff - I have bookmarked several items.

But I also think it is a good idea to be able to direct people to material within the Arduino website.

It is always difficult to know how to pitch a teaching item. Some people like to read the theory. Others just want to get stuck in.

...R
Two or three hours spent thinking and reading documentation solves most programming problems.

GoForSmoke

I agree with your goals very much.

But to some of this I liken it to teaching the 2 + 2 = 4 and 3 + 3 = 6 without teaching what 2 and 3 are. I want beginners to be able to say 2 + 3 = 5 without having to memorize it, look it up or get a library to do it for them.

If you don't have your fundamentals down then you make fundamental mistakes. Bits, bytes and logic are the ABC's, 123's and +-x/ operators of computing. Arrays are the spelling words and structure is grammar. Everyone with a solid grounding in those will be able to make easier sense of the rest. The how and why is more important than the what and that gets demonstrated every day here which is why I try to hand out fundamentals where I find a lack.
Nick Gammon on multitasking Arduinos:
1) http://gammon.com.au/blink
2) http://gammon.com.au/serial
3) http://gammon.com.au/interrupts

Robin2


But to some of this I liken it to teaching the 2 + 2 = 4 and 3 + 3 = 6 without teaching what 2 and 3 are.


I see that.

I guess I started from the assumption that the reason WHY would have been explained in whatever Reply told the OP not to use delay() and to look at this as an example of how to get by without it.

It seems to me that the newcomers have no difficulty understanding that delay() gets in the the way of concurrency - but they don't immediately grasp how to use millis() to replace it.

If you can suggest 2 or 3 lines (not more!) for insertion into my original post I will certainly consider it.

...R
Two or three hours spent thinking and reading documentation solves most programming problems.

robtillaart


Why is the usage of break an argument against switch()? That is the same as saying the use of else is an argument against if... It are code constructs to make an algorithm easier to maintain and give the compiler means to optimize the code.


For a switch statement there are at least 2 ways to compile to machine code while an if then else ladder (expressed functionally equivalent) cannot. One reason is that for a switch statement the compiler knows immediately that there is one element in an "is equal" compare, which is every time the same (e.g. optimize in a register). For an if then else ladder every comparison is a new one for the parse tree, which might be optimized later. In switch statements every case must be disjunct, semantics forces that. In an if then else ladder you can do the same comparison multiple times.

A switch statements allows a fall through which can be used for simple OR or for reducing double code. An if then else ladder has no (straightforward) equivalent for that.

For me the only drawback of the switch statement is that it does only support simple integer types and not complex or aggregate like strings and structs. BUt that is by design so I can (have to) live with that.

Rob Tillaart

Nederlandse sectie - http://arduino.cc/forum/index.php/board,77.0.html -
(Please do not PM for private consultancy)

Go Up
 


Please enter a valid email to subscribe

Confirm your email address

We need to confirm your email address.
To complete the subscription, please click the link in the email we just sent you.

Thank you for subscribing!

Arduino
via Egeo 16
Torino, 10131
Italy