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.
This sounds very interesting!
I think, for mapping Firewire on the Ethernet model (as a first step at least), only the asynchronous contexts are relevant. How do these request/response handshakes work? What is the difference to the xmit handlers of Ethernet drivers and their reception interrupt handlers? When I want to transmit a packet via Firewire, what steps has to be performed in software? On the other side, how much demultiplexing is done by the hardware on reception? MAC addresses, or also some higher layer addresses? How does the data path look like in that case?
In other words, what happens in-between:
at request - at response - ? - transmit payload to node X ar request - ? - receive payload from node Y ar response -
Whenever you may find out some more details about the programming model of isochronous data, this would be interesting for future improvements.
Scenario A: Node 1 sends its sensor data regularly to Node 2-4.
Scenario B: All nodes exchanges their input data and output commands on a regular basis.
Scenario C: Application A on node 1 transmits its data every 10 ms to application B on node 2, application C on node 3 does the same to application D also on node 2.
Could those scenarios easily be mapped on isochronouse Firewire? On which abstraction level can the streams be multiplexed and demultiplexed?
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.
Cannot give you an advice yet as I do not fully understand the data paths. The job of the stack manager is to demultiplex the protocol type and forward the incoming packet to the respective protocol handler (IP, RTmac, user-defined protocols, ...). Do you have to do some work before this step for Firewire? Or what do you mean with different routes?
Generally, using two stack managers may be useful if you want to prioritise one over the other. Otherwise, having two tasks will likely only increase the overhead for handling incoming packets. A simple differentiation upon rtskb dequeuing which type of packet need special preparation (i.e. Firewire) should be more efficient. At some point, both the Ethernet and the Firewire path should become one again, at least for asynchronous traffic and in case there is no advanced high-layer hardware demultiplexing available.
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?
The stack manager is by default running at the highest but one priority in the system (the TDMA output task has the highest one in a standard setup). Therefore, it is normally not interrupted. It's task is to find the recipient of a packet - either a user task, an internal service task (RTcfg), or some important handler running inside the stack manager's context (callback handlers, RTmac/TDMA, etc.). The stack manager is trigger by the signal of a driver which just placed a new packet inside the manager's queue. You may say, the stack manager is a heavy-weighted tasklet ;).
Jan
------------------------------------------------------- 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
