Hi Robin,
Thanks for the reply. I looked over your post and like it. I would have no hesitation recommending that strategy for anyone who wants to move past delay() for timing. I suspect you share my dislike for seeing that in any but the simplest of examples.
It is my desire that the library reduce the complexity that the coder is exposed to by extracting the commonality and putting that where the user need not be bothered. For example, the code needed to print out free RAM stats every two seconds is:
class MemTimer : public Timer {
public:
MemTimer(int t=1000, int r=0):Timer(t,r){};
MemTimer(const MemTimer& e){coln("MyTimer copied");};
void callBack(int late) { // callback when Timer fires
Serial.print("freeMemory()=");
Serial.println(freeMemory());
};
};
void setup() {
tMem.add();
}
That's still a tall order for someone unfamiliar with C++ and part of the reason I'm soliciting comments here. Perhaps someone has a suggestion to improve that.
As far as "go wrong" I hope to avoid that too. I can test the library extensively to verify correct operation. By sharing it, I also get the eyeballs of folks more experienced than myself with Arduino coding that can point out errors in the code. And once the code in the library is fixed, it should remain so. If you need to start from scratch each time you start a project, you are susceptible to introducing bugs each time, such as the suggestion to use switch() rather than if/then/else to manage states (and forgot to break at the end of each state handler.) One of the issues I need to deal with is what happens when the return value from millis() rolls over. When I do solve that, I will have on location in the code to handle the situation rather than having to fix each procedure that checks for a time delay.
best,
hank