Naguissa
[question] Does it support setting multiple timers?
Hi @Naguissa , thank for this amazing library! Just a question, does it support multiple timers?
Regards
No, it whould be a compatibility nightmare among all mcus, even among stm32 line itself.
I have pending to create a broker library, but for sure it whould be in ms range instead on us.
Thank you, that would be awesome! Could you spoil some details and pseudocode on what you have in mind and mean by broker?
Hi @Naguissa I really love your lib! I had the same question as @paaspaas00 , if the lib supports multiple timers. I'd really need a multi-architecture multiple-timers lib, even in the millisec region. It would absolutely be a game changer! Any news/developments on this? Thanks for you outstanding work btw, it's really lovely!
I've it coded but still has incorrect timing and I'm debugging it: https://github.com/Naguissa/uTimerBrokerLib
Hello @Naguissa, I've been experimenting with this kind of things recently and I've managed to put together a very drafty library thing to do the broker thing, here it is https://github.com/paaspaas00/ardutimer there's lot to do, from overflow checks to supporting all events stop/play, and it's pretty drafty but the basic thing seem to work. Basically it adds the events to an array and schedules uTimerLib to run the nearest next event callback. Basically it goes from scheduled event to scheduled callback via setting a timer in uTimerLib, dunno if that's what you're doing too. Maybe you can use it, np if you want to take inspiration from it! I'm a bit busy now and cannot really continue with it.
For the moment, it has a .ino that is arduino uno specific (blink its led), but it's just to try it out. The lib is generic, only deps are standard libs and uTimerLib
@Naguissa hi, I've been comparing your lib to @paaspaas00 one, looks like you're triggering the timer at fixed intervals, 1 ms apart, while @paaspaas00 lib is using an array with events and calculating the time to the next tick every time, firing the corresponding event then.
Paaspaas00 lib is working fine as far as I could verify, maybe the two designs can be merged to one single lib where one can use your approach if a more constant deterministic triggering is needed and paaspaas00 approach when maximum efficiency is needed instead, if I am understanding it correctly (asking @paaspaas00 too for confirmation). As far as I can tell the code layout is pretty similar otherwise
@Ubodduq yep exactly, I'm basically setting the timer to the next-to-be-triggered event in the prev-event timer callback, hopping from event to event, resetting the timer each time and setting it with a time period which is the difference between the current timestamp and the closest event to be triggered, from an array taking into account the periodicity of all the events. It's a mouthful but really this boils down to a few lines of code as you see 😄
Both ways have pros and cons: his method should be more efficient, specially with few timers or long periods, and mine has more previssible overhead. Still, my method is still not finished so it's not an option right now.
@Naguissa @paaspaas00 tell me guys if you need some help in testing/developing. I'm not a pro in C++/Arduino, but I could be of help there
1st release published!
https://github.com/Naguissa/uTimerBrokerLib/releases