Rferreira:
Bainesbunch, I'm also interested to add more capabilities to the library. My main problem is that I don't have abundant access to electronics components. But feel free to colaborate. New members are realy needed for this project.
I hope you don't mind some constructive criticism. If it were me, I'd go with a looper idiom. This way, the act of looping is completely detached from the logic of each widget's loop. This has some nice advantages in that it allows for the creation of a generalized, powerful, message passing mechanism, possibility of inlinned loop, reduction of code size (important here) helps prevent one widget from causing others to miss critical windows, and is especially useful for timer based events.
A looper implementation would look something like the following pseudo code. Obviously various schemes can be implemented based on your actual requirements and preferred method of dispatch. So don't get too caught up in the specifics.
setup {
Looper myLooper ;
Timer myTimer( myLooper ) ;
MyButton1 myButton1( myLooper ) ;
MyButton2 myButton2( myLooper ) ;
}
loop {
myLooper.loop() ;
}
Then, rather than have a loop method defined in each looper aware widget, you would define an "execute" or "fire" method which would execute for that iteration through the loop.
Also, I noticed your addTimer method uses realloc. It seems realloc is buggy unless you have the latest avr-libc. It needs to be 1.7.x to avoid the bug from what I read.
Furthermore, your timer-loop implementation runs in linear time. That's bad for anyone who may have a lot of timers; especially when most of then are disabled. In fact, for anyone who may have a lot of timers, the implementation itself may lead to late timer execution/notification. For starters, you might want to look at a linked-list implementation, which would remove the need for a realloc as well as keeping your enabled and disabled timers in two different lists. Of course, ideally, there would not be a linear walk of timers for every loop (especially checking to see which ones are enabled, only to ignore disabled), rather, we would only care about the latest timer, and only ever need to look at the next timer to execute, only ever needing to look at the head of our linked list. That would, of course, require re-evaluation at timer addition rather than every loop interval. Basically forcing timer execution to O(1) [or O(1) + O(n-1) for late timers] and linear time for adding, deleting, and disabling timers.
And speaking of message handling, once you have something like the above, you can now register messages with handlers and/or have the widgets register messages with the looper. Then, when one widget sends a message, the looper can efficiently dispatch the message to another widget's message handler without widget a or b actually knowing about each other.
Aside from that, I love the fact you're trying to standardize on some design patterns. I especially appreciate you're doing this in C++ rather than C.