I didnt see a reference to timers in the API. Is there support in FREE RTOS for timers?

Richard has a timers module he can send you but most people just use the tick hook to do what they want.

Thanks I will check out the "tick hook"

Thanks I will check out the "tick hook"

I am porting this http://larytet.svn.sourceforge.net/viewvc/larytet/gmpC/AOS/aosTimer.h?view=markup timers to freeRTOS. I can contribute the code under LGPL or GPL license if there is interest in such code. Please, let me know. Any API and implementation tips and ideas are highly appreciated. Thank you.

Please do contribute, this would make a good palce
http://interactive.freertos.org/forums/135282-any-other-files-any-other-manufacturers-any-other-business

Hi, Please find here reworked API https://www.assembla.com/code/freertos/subversion/nodes/FreeRTOS_Posix/Timer/Timer.h I will appreciate any feedback. Thank you, Arkady.

Ah – interesting.  Are you planning on a full (well as full as practical for a small embedded kernel) POSIX layer for FreeRTOS?  If so you should post a link to it in the FreeRTOS Interactive forum when you think it is complete enough. I have some ideas for how to add timers into FreeRTOS, but not in a POSIX way.  I hope to do this, someday…you know how it is.

I should have provided some explanation as to why timers are not there currently.. The primary reason is that they are very difficult to implement in a deterministic and most importantly efficient way. There are on the other had very easy to implement indeed if you are not concerned with those kernel attributes in an particular application, but core code has to be more generically applicable. Most dynamic timer implementations (where a timer can be created and destroyed at run time) require such timers to be stored in a linked list of one form or another – and accessing the timers from both interrupt code and task code means that their data structures have to be protected with a critical section. Also, timer lists by their nature are normally traversed within the tick interrupt. For the reasons mentioned above (interrupt responsiveness and determinism) there is nowhere in the FreeRTOS code where linked lists are traversed while interrupts are disabled. Regards.

I appreciate the feedback. I am not going to implement POSIX timers. Not in this development cycle. Regarding performance I will avoid any not O(1) operations. Definitely no per tick traversing of the list of running timers is going to happen. Timer task(s) is going to sleep until the next timer expires. The suggested API will cover some rather large segment of application which require
- multilple coexisting timers
- timeout(s) known at compilation time
- set of different timers (different timeouts) is relatively small See below application notes
*   The system requires multiple (more than one) started timers with the same timeout. If your
*   system needs only one or two timers at any moment it is easier to use tick hook. Typical
*   application – data transfer timers serving multiple connections (sockets).
*
*   In the system run one or more timers tasks handling different timer sets. Every timer
*   set contains one or more timer lists.
*
*   Function StartTimer allocates free entry from the stack of free timers and places
*   the timer in the end of the timer list (FIFO). Complexity ~O(1)
*
*   Timer task waits for the expiration of the nearest timer, calls application handler
*   TimerExpired, find the next timer to be expired using sequential search in the
*   set (always the first entry in a timer list). Timer task removes stopped timers from
*   the list of running timers and returns the timers to the pool of free timers.
*   Complexity ~ O(size of set)
*
*   Function stop timer marks a running timer as stopped. Complexity ~O(1) Thank you, Arkady.

Part II. For some reason my previous reply failed to appear here. I am trying to cover as many different scenarios as possible. For example, I let the application to avoid interrupt/task scheduler disable/enable operations by allowing to handle timers expiration and start/stop in the some context. Not every application will be designed this way, but this is definitely a good alternative to consider. The API allows to use a dedicated timer task or a timer interrupt. I am investing significant effort in compilation time configuration. Definitely this API is not for each and every case. It is not generic enough if the application demands timers with precise  (no rounding is possible)  and arbitrary timeout. Such application requires some form of ordered by expiration time list of timers. Complexity of the start timer will likely not be O(1). The API is not simple and small if the application requires only one or two timers which always expire (I think that there is a clever solution for this, but I need more time). I need your help with the system requirements, different application designs (link task or interrupt) and so on. Thank you, Arkady

I am finishing the implementation. I will appreciate code review. The source is here https://www.assembla.com/code/freertos/subversion/nodes/FreeRTOS_Posix/Timer Any comment will help. Thank you.