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
------------------------------------------------------- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click _______________________________________________ RTnet-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/rtnet-developers
