[RTnet-developers] Re: [RTnet-users] timer support in RTnet?

[Jan K. <ki...@rt...>]

Zhang Yuchen wrote:
>  AFAIC, one constraint of the TDMA worker approach is lacking of
> flexibility, i.e. new timer can not be inserted before the next wakeup.
> Of course, flexibility is not really necessary for TDMA scenario, since all
> the time slots are relatively fixed: when a new slot is added, the earlist
> time for it to take place is in next cycle. (Pls Fixme if I am wrong:)).

Yep, the TDMA worker has been designed specifically for the TDMA 
protocol. And this protocol is rather static, although you can change 
the slot configuration during runtime the way you described it. But as 
one cycle more or less does not matter for the reconfiguration which is 
typically user-triggered, thus inherently non-rt, there was no need for 
a more "flexible" timer configuration.

> But in general scenario, it is possible that a new timer has a wakeup need
> which is closer in time than all previous ones. Like in FireWire, timered
> queue is for mix of bus reset and transaction retry or failure detection. 
> Also the queue can be empty.
> 

The timer pattern I typically use with RTAI is always based on tasks: 
one task per timer. In your case, you could consider creating multiple 
tasks instead of only one as TDMA or also RTcfg does. Then you just have 
to take care for synchronising their access to common resources 
appropriately.

> One solution (after brainstorming): we use a realtime task similiar to
> "TDMA-work", and assume the timeout for all asynchronous transactions, i.e.
> between resquest and response, are of the same length, so it is not possible
> to jump the queue (bus reset is not taken into account here, since it is
> really real-time killing). Ok, when the queue is empty, i.e. no asynchronous
> transaciton is going on, the real-time task get blocked on a semaphore
> instead of sleep on timer interrupt. Everytime a new timer is added, the
> queue length should be checked, in case it is zero, a "up" on the semaphore
> should be done. 
> 

Also an option.

Using the timer mechanism RTAI provides (e.g. the rt_alarm_xxx API under 
fusion) is more light-weight than tasks of course, but you have to 
consider that the timer handlers are - by design - executed at least 
under scheduling lock, often (fusion, don't know about classic RTAI) 
also with IRQs turned off. So you shouldn't do much work here...

Jan