Hi, last week, I delved into the current firewire linux drivers, ie., ohci1394+ieee1394. Then I realized the biggest non-real-time point here is the "task handover" between interrupt handler and the corresponding tasklet for the events, like a received packet.The handover is done in the way of "Bottomhalf", which is not considered to be real-time safe. Both of the interrupt handler and the tasklets are defined and registered in ohci1394. The function hpsb_xxx, which is defined in ieee1394, for offering services to the various high-level applications, is invoked in the tasklets of ohci1394. There can be minimally 4 tasklets, respectively for 4 contexts: at (asynchronous transmission) request, at response, ar(asynchronous reception) request and ar response. When isochronous transaction is required, there will be more. But the demuliplexing is done by hardware. In interrupt handler, the software reads the register of the hardware to get the context.
To change the bottomhalf handover, the stack manager mechanism seems to be usable.One option is to build a separate stack_manager for firewire, another is to arrange a new route for firewire in current stack_manager, which could be totally different from the other routes for ethernet. I would like to have your suggestions or questions for this. Currently I lack the knowledge of rtai to understand the internal working of stack_manager. A simple questions is: when the "do_stacktask" of stack_manager is woke up and start running, will it be scheduled away from CPU, not because of the semaphore? Or will it be preempted by other real-time task? Looking forward to your reply. Regards, Zhang Yuchen MSc Student Control Engineering Group University of Twente The Netherlands ------------------------------------------------------- This SF.Net email is sponsored by: InterSystems CACHE FREE OODBMS DOWNLOAD - A multidimensional database that combines robust object and relational technologies, making it a perfect match for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 _______________________________________________ RTnet-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/rtnet-developers
