[En-Nut-Discussion] detecting an unplugged network cable

[Coleman Brumley]

I have a simpler example.

Let's say you have an LCD connected to your device which displays the
current "Link" status of the PHY.  I would like the application to be able
to display a character or not based on the PHY Link status.  Similar to the
LED on PHYs. 

The current method in the AT91 is unreliable.   When I attempt to apply this
example, the display doesn't display the current status of the PHY, only
some previous status.  It would be great if there were an application
callback(s) along the line of:

NutPHYLinkConnected()
NutPHYLinkDisconnected()



- Coleman

> -----Original Message-----
> From: en-nut-discussion-bounces at egnite.de [mailto:en-nut-discussion-
> bounces at egnite.de] On Behalf Of Ulrich Prinz
> Sent: Thursday, November 11, 2010 5:20 PM
> To: ticso at cicely.de; Ethernut User Chat (English)
> Subject: Re: [En-Nut-Discussion] detecting an unplugged network cable
> 
> Hi!
> 
> Funny, I thought to open a new thread for some improvements on EMAC
> handling :)
> 
> > I assume this can be handled much better in that the DHCP is
> retriggered
> > and just drop connections if - and only then - the host can't
> reestablish
> > the former IP, because if it loose it's IP the connections
> technically
> > can't be used anymore.
> 
> I thought about the problem a bit and have an opinion how to solve that
> all a bit more elegant but without blowing up the code to much.
> 
> >
> > Ulrich is right that the PHY renegotiates the link and that the MAC
> > has to be reconfigured to the new negoatian, but I don't consider
> this
> > as a major problem unless the new link has different setup and I
> consider
> > almost all upstream ports today to be 100M/FDX cpable.
> >
> But if you ask the PHY for what features have negotiated for the MAC
> setup you should ask the register of the actual established ones, not
> the possible ones :)
> 
> But to keep it simple:
> 
> I intend to add some NutEvents to the EMAC as this is something you
> might use or you might not. The EMAC has three major events:
> 1) EmacFailEvent
> Posted at bootup, informs system about EMAC not ready to do anything.
> Posted again on errors in EMAC/PHY system caused by stack errors,
> persistent disconnection and other big problems.
> 
> 2) EmacConnectEvent
> Posted if link is established, negotiated and ready for transmission.
> Reposted if recovering from 1) or 3)
> 
> 3) EmacDisconnectEvent
> Posted immediately if link failed.
> 
> With this small toolset you should be able to handle IP setup on
> disconnect - reconnect conditions simply by running DHCP in a thread.
> It
> sleeps with timeouts on EmacConnectEvent. Timeout is needed for
> handling
> lease timeouts.
> You may connect to EmacDisconnect Event to do fallback handling or you
> can start a timer to handle short interruptions without breaking all
> connections:
> NutEventWait( EmacDisconnectEvent, NUT_WAIT_INFINITE);
> rc = NutEventWait( EmacConnectEvent, 1000);
> if (rc) {
>    /* Connection has failed to long, stack is down! */
> }
> else {
>    /* Fast enough, nothing to do */
> }
> 
> Why that?
> Now, if you have your EIR running as your alarm clock it might be
> uncomfortable (your boss might find other words) if the network had a
> dropout and you are not getting out of bed right in time.
> 
> With EmacConnectEvent, the EIR recoveres network connection.
> With EmacFailEvent it switches from online radio to SD-Card or a simple
> Buzzer.
> 
> This is only an example. I guess it might be sort of dump if your
> serial-tcp/ip converter somewhere deep in the industry cabinet always
> needs a reboot if the network cable was put into another port of the
> switch or someone stumbled over it.
> 
> But one step after the other.
> What I have in my code now is an EmacCtl() function that allowes
> polling
> of the EMAC/PHY state and it will be extended to allow some settings to
> be modified.
> Step 2 is now to abstract PHY from EMAC and use one phy.c for all
> xyz_emac.c.
> I cannot use _ioctl() for EMAC control as EMAC does not support FILE so
> I have no _fileno(). But EmacCtl() sounds to be fine for me.
> Then I add the informational events.
> 
> For testing I rewrite the httpd example code to meet the new options
> and
> features. I'll add that one too with delivery of the emac updates.
> Strong view on backwards compatibility is taken, until yet no change of
> old code is needed.
> 
> Ok, let me know your opinions.
> And pleas give me an idea why the first ping after DHCP kills the
> system. If I first access the web page I can throw a adaptive ping for
> about 30s to the AT91 before it crashes. But adaptive means, that
> already 25000...32000 pings where handled correctly.
> 
> Best regards and good night
> Ulrich
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion