Software Timer behaviour

Hello,
if I read the docs regarding software timers correctly, timer.reset and timer.start behave the same way (they both start a stopped timer and they both reset to “0” a started timer).

My problem is that I need to start a timer in the main loop and disable it after the callback function has completed (it is a series of timed events that needs to start at a specific condition in the loop). Am I forced to use a flag so that timer.start is not called every loop iteration (but only once) or am I approaching this in a wrong way?

Thank you

@madian, perhaps it would easier to help if you explained what you are trying to achieve with the timer.

A flag is fine I’d say, but if you desperately don’t want to use a flag, you can use the “newly” (in 0.5.0) introduced function Timer.isActive() to check if the timer is already running.

Thank you ScruffR, after I was gathering my answer for peekay I spotted isAvailable() on the docs page. In my defense it’s a rather large paragraph gap between changePeriodFromISR() and dispose()_isAvailable() so I didn’t see it at first:)

@peekay I am building what I think is the first competition grade mega sumo robot that has a photon :stuck_out_tongue:
and we have an armada of robots that have to upgrade from 8bit microcontrollers. Over the last few years mega sumo has become extremely challenging and a robot can have hundreds of tactics and very complex behaviour algorithms. I’m experimenting with the advantages of the photon (OTA programming is fantastic, lifting a 270 kg-equivalent robot just to plug an usb cable was awful, I can now test all my tactics extremely fast without ever taking the robot off the ring). UDP telemetry works better than I thought after I read threads where ScruffR suggested other ways than wifi. I also ported most of the line sensors // port expanders//shift register code to the photon and it feels extremely stable.

Thank you, I hope you don;t mind if I ask for help when I get stuck again.

3 Likes