Hi, Jan thesedays, I was reading the book<<Real-Time Systems, Design Principles for Distributed Embedded Applications>> of Hermann Kopetz (that's why I stopped generating idea for a while:)). It's a very nice book, expecially as a guide book for Time-Triggered Protocol. Also the Fault-Tolerance is concerned, for which the solution is specific for TTP.
> > Ah, this make FireWire even more Ethernet-like ;). And it > also means that the IP and Packet Socket multicasting API of > Linux should be adaptable, we may only need some tweaking > where it comes to FireWire specific addressing at the lowest level. > > BTW, the "channel" abstraction for outgoining packets could > be passed from the user to the stack through the socket > priority field (which is tranfered to rtskbs upon packet > creation). This value, formerly only expressing the priority > when queuing an rtskb in the TDMA layer, now also contains a > bit range which is used to address specific TDMA2 output time > slots in latest RTnet. Why not using the same mechanism for > addressing the respective FireWire iso channel? > Yes, this could be a solution. > > Well, even your real scenario needs some sychronisation: the > bus driver and the passenger have to coordinate the bus entry > - otherwise someone might get squeezed... ;) > > For FireWire, such "squeezing" may happen if memory is > changed by the CPU while the controller is accessing it via > DMA (as long as the DMA access is not atomical, but this is > too hardware-depended). > According to the spec of DMA, if both CPU and controller attempt to access same memory in one memory access cycle, the controller will win, so called "cycle stealing". But for one iso packet, I think more than one cycles are needed, so not atomical and the synchronization problem exists. But one RT-Image, e.g. the data from one sensor, normally only has up to 64 bits (unsigned long long), so for access of one RT-Image, it could be atomical. But I need to study DMA further to get a precise conclusion. BTW it may be possible to implement the "automatic re-transmission of a certain peice of memory" in DMA. (This is what I learned from the spec of OHCI).In the DMA of Firewire, CPU can put some discriptors in the DMA-mapped memory, consisting of command (to control the controller) and the data to send. The previous discriptor has a pointer to next one, if not, then it is the end of this transmission, and the DMA context should go to sleep until CPU put some new discriptors and wake it up. If we make the pointer point to the current discriptor itself, then the same memory will be re-transmitted at 8Khz. Then the question is whether we should do the "automatic re-transmission...." even if it can be implemented, because it will introduce quite a lot of extra traffic if the RT-Image is not changed so quickly. > > Ok, I see this makes sense if you share an iso channel > between multiple local users. But it would become redundant > if there is only a single user, doesn't it? > Yes, maybe we can make a configuration option for that, i.e. for the node surely to have only one server ( process that actively sends some data), we dont need the PM layer, so all the APIs in application will use another definition. But anyway, if we have more than one servers in one node, it is not good to have seperate channels for each, cause it will produce quite a lot of interrupts and use up the bandwidth quickly. Yuchen ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ RTnet-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/rtnet-developers
