wildbill:
There is no holy writ that defines whether your code is non-blocking and it doesn't really matter anyway. If your code works to your satisfaction, you're good.
Thanks, Bill. Hopefully I'm not being too annoying! This helps put things in perspective and get an idea of what an appropriate problem-solving approach is for this issue.
Robin2:
Every time through loop() the code will have to decide if it is now time to read the sensor. Will that code actually use more cpu cycles than simply reading the sensor.
If you keep adding functionality to any program there must come a time when the total code is more than that particular microprocessor is capable of dealing with. Then the only options are to omit some functions or use a faster microprocessor.
Using easy-to-understand code on a faster microprocessor is probably a better option than using arcane code to squeeze the last drop of performance from a slower microprocessor. Above all, code should be written so it is easy for you to maintain. Just because something can be done by a super-wizard-programmer does not mean that the technique is appropriate for you - especially if you have no wish to become a super-wizard-programmer.
...R
Thank you Robin, I hope I can someday give back to the community like you do. As with Bill's answer this helps me understand what to look out for. I read on some other topics your code for measuring how long a function execution takes (the 1000 time for-loop with microseconds). Is this how you would measure if your processor is struggling?
Not quite in your question but common mistake is to update a display much faster than necessary. No point updating 500 times per second because no one can read the changes that fast. A clock changes once per second so it makes sense to update the time on the display once per second. Other variables will have their own natural update periodicity.
zheygrudov:
I read on some other topics your code for measuring how long a function execution takes (the 1000 time for-loop with microseconds). Is this how you would measure if your processor is struggling?
If it was struggling you might not need measurements to tell you
Robin2:
Every time through loop() the code will have to decide if it is now time to read the sensor. Will that code actually use more CPU cycles than simply reading the sensor.
That is indeed the question. Performing the timing check tends to require more code than reading the sensor. Where you need to de-bounce, checking with every pass of the loop permits a shorter debounce interval to be employed so you actually get a more timely response (and if the input has not changed, you do not need the time check).
The point about not updating displays more often that a few times a second (not to be confused with animation which does require a faster processor) is important not only for efficiency but readability. Taking the "time" to see whether an update is appropriate - even if the data has changed - is here worthwhile.
Robin2:
If you keep adding functionality to any program there must come a time when the total code is more than that particular microprocessor is capable of dealing with. Then the only options are to omit some functions or use a faster microprocessor.
Code for updating a display (either the Serial Monitor or an LCD) is usually slow and is a good example of where CPU cycles can be saved by doing it less often.
And it is a good example of another issue - it may be possible to update the display either partially (i.e. only the text that has changed) or in stages - for example one line at a time. These techniques can allow CPU cycles to be saved within a single iteration of loop(). And because loop() repeats very frequently the human viewer will not be aware of the staged update.
This staged approach can also be used with some sensors. Rather than request a value and wait for it to be produced it may be possible to request the value, then do other stuff and call back later to get the result. (A bit like phoning for a take-away and only calling at the counter when it is ready).
I would appreciate it if you would click Report to Moderator and ask to have your earlier Thread merged with this one.
I think your Threads have managed to draw together a lot of advice that would be very useful for other Forum readers and I would like to have a single Thread that I could book-mark and then refer other Forum readers to it.
I would appreciate it if you would click Report to Moderator and ask to have your earlier Thread merged with this one.
I think your Threads have managed to draw together a lot of advice that would be very useful for other Forum readers and I would like to have a single Thread that I could book-mark and then refer other Forum readers to it.
...R
Hi Robin, for sure! It's definitely been an eye-opener for me.
Robin2:
Code for updating a display (either the Serial Monitor or an LCD) is usually slow and is a good example of where CPU cycles can be saved by doing it less often.
This staged approach can also be used with some sensors. Rather than request a value and wait for it to be produced it may be possible to request the value, then do other stuff and call back later to get the result. (A bit like phoning for a take-away and only calling at the counter when it is ready).
...R
Is this what is referred to as asynchronous reading of the sensor (Bill also mentioned it in an earlier post)? I did some googling but most of the answers were for C++ on the PC and I couldn't understand them. If this is something you would apply for Arduino is there some resource I could check on it?
With the sensor, when you do a analogRead(,) then you get the result, and then during the next loop you do something with it. Is this what you mean?
zheygrudov:
Is this what is referred to as asynchronous reading of the sensor (Bill also mentioned it in an earlier post)?
Yes.
With the sensor, when you do a analogRead(,) then you get the result, and then during the next loop you do something with it. Is this what you mean?
Not quite what I had in mind, but a valid possibility.
if you study the ADC section of the Atmega328 or Atmega2560 datahsheet youl will see that you can manage the ADC at a lower level than with analogRead(). You could spilt the request for a reading and the collection of the result into two separate actions. These are combined in the analogRead() function.
To be honest analogRead() is fast enough that you would probably not bother with the lower level access.
I did open a fact sheet for the nano's processor I think and it's quite intimidating. However, useful to be aware of the possibility if needed! Thanks Robin.
In the case of a display such as a character LCD with HD44780 controller, it is possible to issue a command and check on successive passes of the loop() for a "ready" signal from the display controller, but it is generally too involved a process to actually do this.
The alternative is to issue the command and then use millis() on successive passes of the loop() to determine that the known time required for the command to complete has passed. Either way, that is the process. Issue the command on one pass through the loop() and enable (flag) a process which on successive passes will determine if the command has completed in which case the next operation or "state" can occur - thus constituting a "state machine".
A number of such state machines can then be stacked within the loop(), implementing distinct and as independent as required, major functions.
A nice tutorial, even if I don't see a need for transitional states. Actions occur on and belong to a state change, before the machine advances to the next state. It also is a very bad example changing the state of some FSM from outside - a FSM should check its starting and stopping conditions itself.
Also see Combie's or my own TaskMacros libraries for simplified coding of state machines.
Just as a point of form, when you post links, please do not click the "Prevent this page from creating additional dialogs" checkbox; this is just a significant nuisance for people trying to follow the links as it moves you on from the posting itself and you have to back out of the link (which some links actually prevent) to get back to the post.
The fact that you are actually offered this option does tend to mislead and imply that there is some sort of benefit to it; there definitely is not. I understand in some cases you do not get offered this checkbox, possibly on the "mobile" version.
