Karl Reichert wrote: > Back from holidays, do here we go again ... I will give an abstract > about what's going on here with Nadym and me and our problems here: > > The problem is, that aren't able to establish a RTnet connection > between two desktop PCs. When they act as a master, they send their > synchronisation frames at the right time, down to a cycle length of 2 > ms (and most probably less then that). When they act as a slave, the > fail to sync, because the TDMA cycle number in which they ask for the > reply calibration frame lies already in the past. > > As we're using an Intel Core 2 Duo and an AMD Athlon XP here, we're > talking about completly differently harware (including mainboards). > IMO we do not face any SMI problems, because as discussed in the > xenomai list, latency tests are showing good results and running them > as a master works flawless, no delayed or missing sync frames or sth > similiar. > > So I'm asking for suggestions, hints, tricks ... or a roadmap how to > track this weird error down. My idea is to get into RTnet sources and > use kprintf(). Any better ideas? And suggestion were to start this? > Anything I have to keep in mind when using this call?
Basically the right way to go: Instrument the RTnet core in order to find the point from which on things go mad. If you look at the recent thread with Chun Yeow about his the AT91 work, you will find hints and procedures how to dig into this. Questions and findings, as usual, to this list, but note that at least I am no longer quick in replying (means don't stop if questions arise, continue even while waiting on replies). What I would analyse if I were you: - Is the request frame sent in the right slot according to the sender? - If not, what happened between the "correct" TDMA sync frame arrival and the delayed requests transmission (=>tracer)? - If yes, what happens on the master in the meantime (=>tracer)? The tracer is specifically then helpful if you are yet lacking a full picture of the data flow inside RTnet. It grabs the involved functions for you, and you can then go to the code and lock at it offline. Jan
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
