┬ÁTasker Forum

┬ÁTasker Forum => FreescaleTM MC9S12NE64 => Topic started by: thamanjd on April 28, 2008, 09:48:01 AM

Title: Activity LED timing
Post by: thamanjd on April 28, 2008, 09:48:01 AM
I'm letting the hardware do the activity (and other network) LEDs. Do you know a way of making the activity LED stay on for longer in this mode? I have used utasker to do the LEDs before and i see to remember the activity LED staying on for longer than it is in the hardware controlled mode. At the moment it blinks so fast you can hardly see it.
When uTasker is controlling the activity LED, can i control how long the "blink" lasts for?
Title: Re: Activity LED timing
Post by: mark on April 28, 2008, 10:02:54 AM

The LED flashing time when controlled automatically is determined by the HW.
The NE64 has a HW bug which is described in the errata (number MUCts01898) and also the uTasker tutorial which blinks the LED so fast that it is hardly visible. The only workaround to this is to control it from SW (disable the automatic function and control the connection as GPIO).

The uTasker task fnNetworkIndicator() can be optionally used to control the LEDs instead, as you previously used. In this file the length of the timers can be controlled by the following defines:

#define COLLISION_TIME         (2*SEC)
#define TX_TIME                (0.05*SEC)
#define RX_TIME                (0.1*SEC)

Since the same LED is used for several purposes the blink duration is used to distinguish which one - the times can be adjusted as required.



Title: Re: Activity LED timing
Post by: thamanjd on May 02, 2008, 06:59:32 AM
Ive changed that over to uTasker controlled LEDs now and the activity LED is fine but i can't find any mention of uTasker manipulating the DUPLED (Duplex LED). At the moment with auto negotion enabled the DUPLED is extinguished, but when i was using hardware LED control it is lit.

If uTasker is currently ignoring this LED, is there a way to pick up the current duplex type and manipulate the LED accordingly? I'm expecting the LED to be lit for Full and extinguished for half.

John Dowdell
Title: Re: Activity LED timing
Post by: mark on May 02, 2008, 10:19:33 AM
Hi John

Unfortunately the NE64 allows either all LEDs to be controlled by the PHY or none (otherwise it would have been possible to let the PHY control the duplex line only).

The demo implementation controls the LEDs as on the DEMO board, where the Collision and Duplex LEDs are not connected, which explains why these are not supported.

To add duplex control it will be necessary to slightly modify the interrupt routine of the PHY (__interrupt void ephy_isr(void)) in NE64.c. This interrupt routine is called each time there is a change detected by the PHY - eg. when it has autonegotiated. It may take a small amount of experimentation to get it absolutely right (whether to check on AUTO_NEG_CHANGED or when LINK_UP is signalled, or both) but I believe the flag PHY_R17_DPM contains the information.

There are then two basic methods to control the LED.
1. The GPIO change can be programmed directly in the interrupt routine (easiest)
2. An interrupt event is generated for the fnNetworkIndicator, which then interprets it to either turn on or off the LED. The other indicators use this method so that additional delays etc. can easily be implemented. It will however be necessary to extend the list of global interrupt events to include new ones (something like LAN_LINK_DUPLEX and LAN_LINK_SIMPLEX) and possibly also actively distinguish the LED on the LAN_LINK_DOWN event so that the duplex light doesn't continue to be on when the cable is removed.

Good luck

Tell me if you have any difficulties and I can look more at this.


Title: Re: Activity LED timing
Post by: thamanjd on May 06, 2008, 09:33:51 AM
Do you see anything wrong with the following changes for the collsion LED?

added define for TURN_COL_LED_ON()  and TURN_COL_LED_OFF()   
Code: [Select]
    #define LAN_REPORT_ACTIVITY                                        // Transmissions/receptions and errors are reported to chosen task (for link LED control, etc)

        #define ACTIVITY_LED_OFF()     PTL |= ACTLED;
        #define ACTIVITY_LED_ON()      PTL &= ~ACTLED;
        #define TURN_LINK_LED_ON()     PTL &= ~LNKLED;
        #define SPEED_LED_ON()         PTL = ~SPDLED;
        #define SPEED_LED_OFF()        PTL |= SPDLED;
        #define LINK_DOWN_LEDS()       PTL |= (LNKLED | ACTLED);       \
                                       PTL = ~(COLLED | SPDLED | DUPLED);
        #define TURN_COL_LED_ON()      PTL &= ~COLLED;
        #define TURN_COL_LED_OFF()     PTL |= COLLED;

then for the collision interrupt in network_indicator:
Code: [Select]
                uTaskerMonoTimer( OWN_TASK, (DELAY_LIMIT)(COLLISION_TIME), E_TIMEOUT ); // blink collision LED
and modified the timer event that turns off the led:
Code: [Select]
            if (E_TIMEOUT == ucInputMessage[ MSG_TIMER_EVENT ]) {
                if(ucEvent & (TX_LED_OFF | RX_LED_OFF))
                    ucEvent &= ~(TX_LED_OFF | RX_LED_OFF);
                if (ucEvent & COL_LED_ON)
                    ucEvent &= ~(COL_LED_ON);
Title: Re: Activity LED timing
Post by: thamanjd on May 06, 2008, 10:47:25 AM
can i assume that the DPMD flag in the PHY_PSR register is correct for both auto neg and manual?
Title: Re: Activity LED timing
Post by: mark on May 06, 2008, 01:01:41 PM

The LED control looks good (barring bugs which are not obvious on first look). The task is using its own monostable timer so uses additional flags to be aware which timer is actually working. This will obviously get more complicated when more things are to be displayed by blinking LEDs.

Another method is to use global timers (ref: http://www.utasker.com/docs/uTasker/uTaskerTimers.PDF) so that each LED blink has its own timer. In this case no flag is required and the original event can simply light the corresponding LED and starts its own timer event. When the specific timer event fires the corresponding LED can be extinguished. This is possibly worth doing if the flag coordination becomes increasingly complicated.

As for the DPMD: The PHYs can do wonderful things but I have to admit to not understanding them all by reading the data sheets. I would suggest a few tests in different modes and with a display of the status which the PHY is showing. This will ensure that the theory and the data sheets corresponds with the reality and afterwards the best choice of monitoring can be made without any further surprises later.