CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Results 1 to 4 of 4

Thread: VxWorks With LAN91C111

  1. #1
    Join Date
    Aug 2006
    Posts
    3

    VxWorks With LAN91C111

    Hello Code Gurus:

    We are employing two (2) SMSC LAN91C111 devices on a single Printed Circuit Board (PCB) for two Ethernet ports. The software employs the VxWorks RTOS and the LAN91C111 software driver provided by SMSC. There is an issue in that when the Ethernet cable of one of the devices is reconnected (or sometimes when disconnected), the task that performs the lengthy Auto-Negotiation process for that device is executed and prevents tasks of the other device from executing.

    Virtually every combination of the following methods have been employed in an effort to force the task of the Auto-Negotiate process to be reprioritized and/or rescheduled and/or delayed to allow tasks of the other device to execute:

    1. Employ Round-Robin scheduling to allow tasks of the same priority to execute. This is done by calling the function kernelTimeSlice().

    2. Relocate task of Auto-Negotiate process to the end of the task ready queue. This is done by calling the function taskDelay(0) (zero time delay).

    3. Set task priority level of Auto-Negotiate process to be lower than other tasks. This is done by calling the function taskPrioritySet().

    4. Set spawned task priority level to be higher (and lower) than priority level of netJobAdd() tasks (e.g. task of Auto-Negotiate process). This done by setting the priority level in the function taskSpawn().

    The following observations have been made while monitoring the LAN91C111 Interrupt pin and General Purpose Output Port pin of both devices on the oscilloscope before, while, and after executing the Auto-Negotiate process within the associated task:

    1. The waveforms on the oscilloscope indicate that there is no interrupt contention between the devices.

    2. Setting the General Purpose pin on both devices before each intLock() function is called and clearing the bit after each intUnlock() function is called indicates that there is no contention between the two LAN91C111 devices while locking and unlocking interrupts.

    3. Setting the General Purpose pin on both devices before each semTake() function is called and clearing the bit after each semGive() function is called indicates that there is no contention between the two LAN91C111 devices while taking and giving semaphores.

    4. Each SMSC LAN91C111 interrupt and each netJobAdd task is assigned a unique number which can be identified on the oscilloscope. At various points in the software, the LAN91C111 General Purpose pin is toggled the number of times equal to the number assigned to the current interrupt and current task. This identifies the most recent interrupt and task of both devices and identifies which of the two (interrupt or task) occurred most recently of both devices. This has demonstrated that the Auto-Negotiate process task is indeed preventing the tasks of the other device from executing. We know this because after the Auto-Negotiate process begins for the reconnected device, the waveforms on the oscilloscope indicate that the tasks associated with the interrupts of the other device are not being executed after the associated interrupt occurred.

    It is worthy to note that a simple taskDelay(x) in the task which eventually performs the Auto-Negotiate process will prevent tasks of the other device from executing for the time that the task of the Auto-Negotiate process is delayed.

    Do you have any idea why the VxWorks task of the lengthy Auto-Negotiate process refuses to be reprioritized and/or rescheduled and/or delayed which would allow tasks of the other device to execute?

    Thank you,
    TDB Consulting

  2. #2
    Join Date
    Aug 2006
    Posts
    3

    Re: VxWorks With LAN91C111

    CodeGurus:

    The multiple-device Auto-Negotiation issue with the Standard Microsystems Corporation (SMSC) LAN91C111 driver software has been solved. The problem with the software is that when the Ethernet cable of one of the LAN91C111 devices is reconnected, the task that performs the lengthy Auto-Negotiation process for that device is executed and prevents tasks of the other device(s) from executing.

    In the existing SMSC LAN91C111 software, the code in the ISR (Interrupt Service Routine) that addresses link detection calls the netJobAdd() function to schedule the AdapterReset() function, which performs the Auto-Negotiate process, to be run by tNetTask. Virtually every combination of every available method was employed in an effort to force the task (tNetTask) of the AdapterReset() function to be reprioritized and/or rescheduled and/or delayed to allow tasks of the other device(s) to execute.

    Evidently, tNetTask tasks cannot be reprioritized, rescheduled, or delayed as taskSpawn tasks can be.

    The solution was to have the LAN91C111 ISR do a netJobAdd() of a function which then does a taskSpawn() of the AdapterReset() function. The required software changes to the module lan91c111End.c of the SMSC LAN91C111 software driver follow:

    In the section of code in the lan91c111Int() function that processes the INT_MDINT interrupt, change the netJobAdd() call:
    FROM:
    netJobAdd ((FUNCPTR) AdapterReset, (int) pDrvCtrl,0,0,0,0);
    TO:
    netJobAdd ((FUNCPTR) AdapterResetSpawn, (int) pDrvCtrl,0,0,0,0);

    ADD the function AdapterResetSpawn() to the file lan91C111End.c as follows:
    void AdapterResetSpawn(LAN91C111END_DEVICE *Adapter)
    {
    taskSpawn ("resetask", 250, VX_FP_TASK, 0x2000,
    (FUNCPTR)AdapterReset, (int)Adapter,0,0,0,0,0,0,0,0,0);
    }

  3. #3
    Join Date
    Aug 2006
    Posts
    3

    Re: VxWorks With LAN91C111

    CodeGurus:

    Do you know anyone who has lots of experience with VxWorks tNetTask and could answer the 2 questions below?

    1. Is it true that tNetTask tasks cannot be reprioritized, rescheduled, or delayed as taskSpawn tasks can?
    For details, refer to the comment at the top of the page.

    2. Is it true that tNetTask tasks are not re-entrant?

    Thank you,
    TDB

  4. #4
    Join Date
    Mar 2011
    Posts
    1

    Re: VxWorks With LAN91C111

    I guess that "CodeGuru Forums > Visual C++ & C++ Programming > Network Programming" might not be the best place to ask about VxWorks network issues.

    Did you see my response in comp.arch.embedded ?

    "You appear to be under the impression that netJobAdd() spawns a new task to
    run the job. Actually, all it does is add the job to the (single) job queue
    processed by the (one and only) tNetTask.

    tNetTask handles the jobs in its queue one at a time."

    To answer your first question explicitly:

    | 1. Is it true that tNetTask tasks cannot be reprioritized, rescheduled, or delayed as taskSpawn tasks can?

    Jobs performed by tNetTask are not 'tasks'. If you really want to reorder their execution I expect that you could submit a new job to the queue, but it is quite likely that it will be called very soon after.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  


Windows Mobile Development Center


Click Here to Expand Forum to Full Width




On-Demand Webinars (sponsored)