I just came across the library elapsedMillis.h which can be installed with the Arduino-IDE-libraby manager
This library offers variables that get updated automatically every millisecond / microsecond
So the non-blocking blink-example gets as easy and short like this
#include <elapsedMillis.h>
// variables of type elapsedMillis get automatically incremented each millisecond
elapsedMillis MyTestTimer = 0;
const byte OnBoard_LED = 13;
void setup() {
Serial.begin(115200);
Serial.println("Setup-Start");
Serial.println("elaspedMillis-Demo");
pinMode(OnBoard_LED, OUTPUT);
digitalWrite(OnBoard_LED, LOW);
}
void loop() {
if ( MyTestTimer >= 1000) { // check if more than 1000 milliseconds have passed by
// first thing to do set variable back to zero
// so counting up starts again with zero
MyTestTimer = 0;
digitalWrite(OnBoard_LED, !digitalRead(OnBoard_LED) );
}
}
// to explain on this very compact line of code
// digitalWrite(OnBoard_LED, !digitalRead(OnBoard_LED) );
// digitalWrite(IO-Pin-Number, IO-Status)
// Write sets the IO-Status to LOW or HIGH
// digitalRead(IO-Pin-Number) returns the status of the IO-PIN (LOW or HIGH)
// Read read IO-Pin-Status even in case of the IO-pin beeing an OUTPUT
// the "!" is the not operator which just inverts the result
// !LOW = HIGH, !HIGH = LOW
// digitalRead(IO-Pin-Number) gives a LOW / HIGH
// and the NOT-operator "!" inverts it to HIGH / LOW
// all in all read status of IO-Pin, invert that status
// set this value as the new output-status of the IO-Pin
// all in all result IO-Pin is switched LOW/HIGH ON/OFF
What disadvantages do you see in comparison with the "classical / basic" use of function millis() with the
unsigned long currentMillis;
unsigned long previousMillis;
unsigned long Period;
currentMillis = millis();
if (currentMillis - previousMillis >= Period) {
previousMillis = currentMillis
stuff
I can't see any disdvantages (yet) just advantages of beeing much easier to understand
It’s a tossup at best and probably depends on personal style and habits.
I don’t like adding a library. If I don’t need to. I like to see the code that does my bidding and I like writing it.
I don’t like magic objects whose behaviour is not clearly and rapidly discernable. For that reason I don’t like, for example, operator overloading, which can be truly abused.
Little steps towards the kind of thing a real operating system provides are to me just annoying playthings cooked up for personal satisfaction and are a serious detriment to learning, like I think everyone should, what’s really going on under the hood so to speak.
I met this whole thing more than halfway by learning about millis(). At least it’s a function so I can see it’s going to go away and come back with something. Once internalized it is useful, the old style construct you provide is what many are accustomed to and would instantly recognize as an idiom right away. And move on.
I'll take the opposite position. If you look at the source code in elapsedMillis.h, you'll see that it does exactly what you would do to handle millis() timing "manually". The only disadvantage I could see would be a little bit extra overhead from calling the class functions. But, I think it's a great demonstration of Abstraction and Encapsulation ... two of OOP's primary tenets.
It rather depends on whether you want help. Any unusual library you add to your code is likely to shrink the pool of people that can assist you if you have a problem with your code. That set of folks is pretty small here already.
I note though that rather more of your posts are offering advice than asking for it, so perhaps the point is moot.
I'm halfway inclined to think it should have been a core method from the beginning. Maybe too late now though as it would be an anomaly that requires another library install...
Maybe it's time for a standard upgrade layer, a kind of "Arduino++"... although getting everyone to agree on what should be included would be a challenge. Many individuals have sort of done this, but not with the required depth and breadth afforded by a public, group effort.
I really think streaming I/O is more beginner friendly than the print methods. I include a streaming library any time I do any significant text output, because it makes line formatting a breeze. With very minor exceptions, it is also congruent with the usual streaming in C++, so the documentation and tutorials are relatively numerous. That's an example of something that almost anyone could benefit from.
In my opinion, the greatest need is for an easy way for beginners to implement all the variations of non-blocking code (but when pressed, I can't think of an easy way).
One disadvantage: Every time you set, change, or fetch the value, it calls millis() again. It is designed to work like an integer variable but it can change value at any time.
operator unsigned long () const { return millis() - ms; } // Get Value
elapsedMillis & operator = (unsigned long val) { ms = millis() - val; return *this; } // Set value
I prefer to have "unsigned long currentTime = millis();" at the top of loop() and use the same time value throughout the loop.
Another disadvantage: The only defined arithmetic operators are + and - (including += and -=).
johnwasser:
Another disadvantage: The only defined arithmetic operators are + and - (including += and -=).
What others would you ever use / need?
EDIT:
johnwasser:
I prefer to have "unsigned long currentTime = millis();" at the top of loop() and use the same time value throughout the loop.
Yea, that's a good point when you have multiple timed events going on each with their own millis() start time.
EDIT #2:
But, since I'll only do crude timing with millis() it's usually not an issue. For more precise timing I'll use hardware timer techniques and since most of my work is on Teensy 3.2/5/6 boards, the time wasted on the extra call(s) to millis() is in the noise and far out weighed by the convenience of the elapsedMillis class.