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

[Zhang Y. <y.z...@st...>]

 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:)).
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.

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. 

More brainstorming or correction are surely welcome:)

Yuchen



-----Original Message-----
From: rtn...@li...
[mailto:rtn...@li...] On Behalf Of Jan Kiszka
Sent: Thursday, May 19, 2005 4:12 PM
To: Zhang Yuchen
Cc: rtnet-users; 'Orlic, B.'; P.M.Visser
Subject: Re: [RTnet-users] timer support in RTnet?

Hi Yuchen,

> HI, Jan and others,
> 
> in the current stage of RT-FireWire development, I am facing the 
> problem of using a timer for scheduled re-transaction and bus reset issue.
> In Linux 2.6 FireWire stack, this is supported by the nice timered 
> workqueue of kernel2.6. Now, I am seaching for a easiest approach to 
> build or reuse a timered workqueue in RTAI for the RT-FireWire stack. 
> Actually, the same problem also exists in Ethernet. If I am correct, 
> the timer is initialized in Ethernet device driver for each network 
> device (I only checked rt_eepro100.c), but in RTnet, the timer is 
> still based on the linux timer support. So I am wondering if we need a 
> timered workqueue extension like in Linux 2.6 to RTAI.
> 

The RTnet's Ethernet drivers do not contain any timers. Their non-rt
ancestors contain some for media status monitoring, but this is switched off
for the real-time use-case.

The timer required to manage the Ethernet media access based on TDMA is
created as a real-time task. Take a look at the implementation of
tdma_worker in

http://www.rts.uni-hannover.de/rtnet/lxr/source/stack/rtmac/tdma/tdma_worker
.c

It's a big loop executing the currently scheduled job on a TDMA instance
(one instance per managed Ethernet device). Such a job can be to wait on the
synchronisation frame or to delay the execution until the next transmission
time slot arrives and then issue a pending packet.

There are generally several ways to reach a goal. ;)

Jan


PS: Better to discuss on rtnet-developers ;)


-------------------------------------------------------
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-users mailing list
RTn...@li...
https://lists.sourceforge.net/lists/listinfo/rtnet-users