This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Well its working but ...


Chuck McManis wrote:
Ok, so its working. Even better pings are nice and fast :
-------------------------------------------------------------
ping 192.168.110.122
PING 192.168.110.122 (192.168.110.122): 56 data bytes
64 bytes from 192.168.110.122: icmp_seq=0 ttl=64 time=0.261 ms
64 bytes from 192.168.110.122: icmp_seq=1 ttl=64 time=0.237 ms
64 bytes from 192.168.110.122: icmp_seq=2 ttl=64 time=0.244 ms
64 bytes from 192.168.110.122: icmp_seq=3 ttl=64 time=0.247 ms
64 bytes from 192.168.110.122: icmp_seq=4 ttl=64 time=0.237 ms
64 bytes from 192.168.110.122: icmp_seq=5 ttl=64 time=0.238 ms
64 bytes from 192.168.110.122: icmp_seq=6 ttl=64 time=0.240 ms
64 bytes from 192.168.110.122: icmp_seq=7 ttl=64 time=0.242 ms
^C
--- 192.168.110.122 ping statistics ---
8 packets transmitted, 8 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.237/0.243/0.261/0.007 ms
--------------------------------------------------------------
Quarter millisecond is definitely in the ball park.

The way I got it to work was to force the RXEnable flag in CR0 at the end of the TxSent interrupt service routine. Basically before I exit I turn RXEnable on regardless and it stays set through calls to the ISR/DSR and packets are received. If I don't turn this flag on there it gets reset at some point and the device stops receiving packets :-(.

So a couple of questions for Gary or anyone else who knows the ethernet driver internals.

So which is the "preferred" (and by that I mean the one that is used by most people so it gets the most testing) network stack ? Because I'm somewhat familiar with the FreeBSD one I chose it and was surprised to see ECOS complaining that it couldn't set multicast address groups. (Not sure what I'd do with them). So my driver simply lies at the moment to keep the stack from calling that function again and again and resetting the interface... any way, why does it want to do that?

Either you have broken hardware (possible, but rare) or somewhere else in your driver code there is a place that's not so careful with CR0 that's resetting the bit inadvertently. I'd track down all places where those control registers are being manipulated and make sure that it's not just a case where a bit is not being preserved.

I don't know anything about your particular hardware, but maybe there's
some magic like if all the Rx buffers go full, then Rx enable is dropped?
Or perhaps there is some error condition that causes this that you're not
testing for?

If you don't find anything else, at least your solution of always forcing
the Rx enable seems correct - if the driver is active, then the receiver
must be as well.


The second question is this output from the httpd test (which just calls init_all_network_devices())


Route - dst: 0.0.0.0, mask: 0.0.0.0, gateway: 192.168.110.254

So basically this is like the static route to tell every packet that is sent to any address should go out of my network adapter? I was expecting

route: 192.168.110.0 mask 255.255.255.0, gateway: 192.168.110.254.

If the 0.0.0.0 route is just a stand-in for "default route" then I'm certainly ok with that, just wondering why it wouldn't say route: default.

This is the case - 0.0.0.0 stands for any (default). The routine that prints it just doesn't spell out this special case.


The last question is that I periodically get my dsr called with no interrupt event. I'm wondering why. Nothing seems to have interrupted. I can use that to go check the Phy to see if the link state has changed but other than that was wondering who called in so to speak.

The DSR can only be called if the corresponding ISR tells the system to do so. My guess would be that there was an ISR (actual interrupt) that happened and your driver did something that cleared the interrupt condition [or indicator thereof] before the DSR got called. Notice that the DSR in an ethernet driver is not actually called directly by the ISR/DSR scheme, but rather by a thread in the interrupt stack and it can be a *long* time between the ISR and the "DSR'.

--
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]