Count-up software Timer behaviour

Hi,
Reading through the API, it seems that the software timers are designed as count-down to zero (whether auto reloading or single shot).
I need to have a timer that counts up so at any time I know how many ticks or time has elapsed form the moment that software timer has started.
How do you do that in freeRTOS?
Thank you

The software timers calculate the tick count at which they should execute, and are then placed in a list of active timers in the order in which they expire - the scheduling mechanism for the timer task then works as per any other task - the task being unblocked by the scheduler when its block time expires just as a task is unblocked when calling vTaskDelay(), or blocking on a queue with a timeout. In that sense I don’t think the software timers count up or down.

Thank you Richard,
sorry, I didn’t explain myself properly.

What I want to implement is measurement of how long a key (for example) has been pressed without having to continuously updating a counter variable (lets say every 1 ms).

Two separate cases:

  1. the user pressed a button, then at the moment of pressing the timer/counter starts and at release the time is read and, depending on how long that was, different actions are performed.

  2. same as above but in between multiple message are sent to implement something similar to a keypad with autorepeat. First message (BUTTON_DOWN) is sent after debounce then (BUTTON_PRESSED) is sent after the button has been pressed for the initial “long” time then every half a second while the button is kept down a BUTTON_AUTOREPEAT then finally BUTTON_RELEASED when the button is released

The first one is the one I was referring to in my original post.
The second one I also need to implement and am wondering the best way/practice to implementing it using RTOS functionality.

Thank you :slight_smile:

you can call xTaskGetTickCount() or xTaskGetTickCountFromISR() resp. at any time to record time stamps and build deltas from that.

Does that answer your question?

Thank you RAc,
yes that answers my first question.

Any pointers on the second one in terms of practical ways to implementing it in RTOS environment?

Also it looks like xTaskGetTickCount() returns a TickType_t which is 32 bits. If the tick is every 1ms that is around 50 days.
Purely out of curiosity, what happens if an application needs to measure times longer than that?

Thank you

For longer times, there is a second counter of how many times the tick counter has overflowed, so that gets you a very long time.

Also, in my experience, most systems don’t need a 1ms tick, but can use one that is slower. If you tick is 10ms, then the 50 days becomes 500 days, which is a fairly long time, and anything wanting to time thing THAT long, likely actually wants a real Real Time Clock.

I’m using vTaskSetTimeOutState in conjunction with xTaskCheckForTimeOut for various timing related things. They take care about tick count wraps internally.

The way I handle such a system is the button generates an interrupt on any change (and then disables the interrupt). The interrupt sends a notification to the button processing task.

If the button is up, the button change task waits with a long timeout, (maybe checking at a long interval, just in case something blocks the interrupt), so I can detect a change. If I no change has happened, I re-enable the interrupt (and perhaps check for long presses), If I see a change, I leave the interrupt disabled, send the Button change message and block for a debounce time, and only then re-enable the interrupt (maybe checking for a second change.) If the button is pressed, I use a shorter time-out to detect ‘long presses’.

IF the button might ‘glitch’ and make a bounce that shouldn’t be counted, you don’t send the message until after the debounce time.

what exactly are you looking for? Code snippets?

Thank you all.

RAc,
if you have some you are ok to share then yes, that would be great!
Otherwise general description of the implementation strategy/logic

Thank you :slight_smile: