0

I want my project to be standing by at the ready for months and years at a time, so I started writing my code to throttle back from polling at delayMicroseconds to just delay. Like, after 15 minutes with no user input, switch from 10 microsecond delay intervals to 10 millisecond (or even 10 second intervals). I wonder if spinning its wheels at warp speed for months on end will wear a path in the circuit pathways? This has got to be a stupid question (or at least make someone chuckle), but I'm really 50/50 at this point: worth the effort for the extra code or won't make a lick of difference? (I know there's my implementation and then there's the right one, but this is where I am right now. FYI, I went with 17 GPIO's in parallel to link my Pi to my teensyduino. add 17 optocouplers, hot glue, hinges, scavenged enclosures etc and this thing looks ridiculous. But I LOVE IT! (It's a mouse that I control over the web)

EDIT Although I didn't mention any concerns about using batteries, their mention didn't really detract from anything. Rather, I welcomed their inclusion because I realized that I had overlooked things more fundamental. I'm always telling others how important ventilation can be and the impact heat can have, but it went right by me this time!

I do value and appreciate the feedback I have gotten. I don't think I will be writing any code to vary polling speed after timing out. But I would still like if someone wanted to directly answer the specific concern I had when posting this question: "At certain times, my program waits for a GPIO pin to change states. I am using the polling method to determine the status of the pin, and I am using this bit of code to do so:

do
{

} while (digitalRead(pin#) == 0); //wait for pin to go high

So, my question is, "Does it make any difference at all, in terms of wear & tear or stress placed on the CPU, how many loops I choose to make in one second? I'm considering something in the range 0.1Hz -> 100kHz Assuming that I keep heat under control and other vital parameters within their nominal operating levels, is it true that the frequency I choose won't make a bit of difference, one way or another?"

Thanks in advance for any interest given to this question.

  • You are just reading inputs? Then I don't see any point in increasing the interval between reads. (Also note that delay, will still keep the CPU busy. It will just continuously poll the time and see if enough time has passes). PS there isn't really a right way. PSS sounds like an awesome setup you have. Maybe ugly but working! – Gerben Dec 21 '16 at 15:11
  • @Gerben I have the teensyduino standing by waiting for instructions from the RPi. When an input changes state, then read the other pins for the screen coordinates (up to 1920 x 1080). My first impression was that doing 10k to 100k loops a second was more CPU load, but then its clock speed doesn't change so it just the same, but then, still there's a factor of 10,000 when comparing activity. So I don't know what to think. It's hard for me to imagine what the physical reality is like at that scale. I just keep imagining the difference between 100 RPM and 100,000 RPM. SILLY!! (or is it?) – user16841 Dec 21 '16 at 15:49
  • Yes, it made me chuckle, that's for sure. There is no difference in doing a delay compared to reading an input as far as the CPU and power consumption are concerned. The CPU doesn't care what it is doing, unless you specifically tell it to go to sleep it will always be "spinning its wheels". – Majenko Dec 21 '16 at 17:18
  • As for the car analogy. Delay is like going 100,00 RPM during checking the inputs, and then pressing on the clutch, but keep the engine going at 100,000 RPM. There is no difference. Delay doesn't halt the CPU or something. – Gerben Dec 21 '16 at 19:36
1

There's nothing to save except battery charge (if your system even uses a battery). It will take just as much energy to delay() as it would to keep polling. The only way to save energy is to put the processor to sleep instead of delaying. And polling will be so brief that you might as well keep the sleep time short, too.

You probably don't need 10 uSec poll intervals; I should think your mouse would be plenty responsive with 1 mSec intervals. If polling takes, say, 100 uSec (and that's a total guess) and you sleep the processor for the other 900 uSec, you'll cut the energy use by 90%. If you don't need to save energy, it won't matter whether, or how long, you delay.

Update:

"Does it make any difference at all, in terms of wear & tear or stress placed on the CPU, how many loops I choose to make in one second? I'm considering something in the range 0.1Hz -> 100kHz Assuming that I keep heat under control and other vital parameters within their nominal operating levels, is it true that the frequency I choose won't make a bit of difference, one way or another?"

Yes, it is true. Your CPU can run full speed continuously, safely. It won't overheat from continuous running. Only if some part of your project is trying to draw too much current through the CPU; then that will cause heating, but the CPU polling a bunch of inputs is well within its specs.

0

For many applications within the realm of Arduino software & hardware development, the only practical concern is to limit the need to write to non-volatile types of memory. Non-volatile types of memory, such as that which stores the Arduino program, do have a finite number of write cycles. However, it is in the 10s (perhaps 100s) of thousands of writes. So is not a concern to most developers.

Running code, however, does put a load on the processor's power source. First we need to understand that a switch in a modern processor require only a minuscule amount of current if left alone. But if asked to change from a 0 to a 1 or 1 to 0, the current spikes. In processors pushed to their limits with 100s of thousands of switches, this extra current turns into heat which must be mitigated less damage is done.

Fortunately, most processors used in Arduinos are not pushed to their limits. So this is rarely a concern. To be clear, the processor chip used on most Arduinos will mostly likely not need a heat sink or fan.

However, even for an Arduino not pushed to its limits, this extra power demand is devastating to the long term life of portable battery operated devices. Programming an Arduino to extend battery life is by no means a trivial task. And certain processors (Arduinos can be made with many different processors) are orders of magnitude better at this then others. But, since most Arduino applications are powered from mains, this too is of little concern.

  • No, there won't be any writes to any non-volatile locations. Maybe store some macros there down the road. And there aren't any concerns about battery life since it draws power from the host USB port it plugs into (in a device running off AC mains). I'm itching to accept your right away if you could just add a line that says (pretty much verbatim) ' – user16841 Dec 21 '16 at 18:36
  • Hmmm I hit 'post – user16841 Dec 21 '16 at 18:42
  • Apparently I can't edit my own comments... Anyway, I'll make sure the heat doesn't pose a problem (I've got all sorts of old cooling fans and heat sinks). If I could just ask you to add a line reassuring me that "there's no need to worry, that chip will be just as happy polling an input pin 100 times a second as it would doing 100,000" I would be most grateful and happy to dispatch your well earned green check-mark! Thanks in advance. – user16841 Dec 21 '16 at 18:50
  • The processor chip used on most Arduinos will mostly likely not need a heat sink or fan. I'll add this to the answer. I believe everyone can only edit a comment for 5 minutes. My rule of thumb is you don't have a heat problem until the chip feels very warm to the touch. – st2000 Dec 21 '16 at 19:07
  • I wasn't allowed to edit for any amount of minutes. Not so much a criticism as surprise. I just need to be more careful of the enter key! – user16841 Dec 21 '16 at 19:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy