Dear Jan,
I don't think that I have tested the scenario on "joint TDMA slots or the
Sync frame immediately followed by the
master's payload slot" before. I only tried out the default setup script
with 1 master and 1 slave. Please advice on how to do this.
By the way, how the link state polling timer will affect the real-time
operation?
Regards,
Chun Yeow
On 10/27/07, Jan Kiszka <[EMAIL PROTECTED]> wrote:
>
> Yeoh Chun Yeow wrote:
> > Dear Jan,
> >
> > Please provide me the details on how to do testing.
>
> Just merged your driver with some modifications - hopefully good ones.
>
> My problem is that I don't know the locking requirements of the
> hardware, and that the original Linux driver is no real help here as it
> was built on wrong assumptions about locking. I picked a careful
> approach first and kept what I found, rather extended it. Maybe it would
> be possible to decouple all the PHY handling completely from the
> real-time domain, but that would need deeper analysis of hardware and
> driver.
>
> What I furthermore did is to default-disable the link state polling
> timer. That one is only needed if there is not PHY IRQ and you
> reconfigure your RT network after rtifconfig up. You can re-enable it
> via the module parameter "use_phy_timer".
>
> Another thing I came across is the extremely short TX queue of the
> rt_at91_ether (one slot!). This can be problematic if the TX completion
> interrupt takes longer than a succeeding TX request by the RTnet stack
> (e.g. joint TDMA slots or the Sync frame immediately followed by the
> master's payload slot). Did you already test such scenarios, and did it
> work?
>
> Looking forward to your test results!
>
> Jan
>
>
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
RTnet-users mailing list
RTnet-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rtnet-users
