> > > > > > It looks like a corrupt buffer, half sync packet, and half > a config packet. > > > > Not necessarily corrupted, but too long. Where and how did > you capture this frame?
The capture is from my embedded client. The data transfers and packet length count is handled completely by the microcontroller, so I'm confident it is working correctly. > Does it fit into the TDMA cycle? I don't fully understand rtnet to really answer that. I started rtnet on my linux box, and it was waiting for slaves to connect. Sync packets were coming out at the default 5000us interval as well as the rtcfg traffic (client config every 1000ms). I'm not sure why the sync packets were coming out as well as the rtcfg traffic. Is that correct behaviour? I would have thought the sync process would only happen after rtcfg set up was complete. > > > This is coming from my master, a VIA Pico, with a via rhine > ethernet > > controller, using kernel 2.6.24-16-rtai (stock EMC2 deploy). I > > noticed that a comment in the rtnet rhine driver source say > Rhine II, > > but the board has a rhine III. Could it be due to this? > Or is this an undocumented packet? > > I guess the Rhine III is operated by the same driver as the > II in standard Linux. Then is may make some sense to check > the original code for diffs with our version, specifically > for changes that target III support. Thanks, I'll check that. Frank ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ RTnet-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/rtnet-developers
