This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

task change using SEM_post SEM_pend



Hi,

I need some help to do a task change as fast as possible.

 

I have two task at different priority. The task1 do some process and task2 communicate the processed results.

 

The problem is that I need to communicate the results as fast as possible but sometimes it’s taking about 100ms.

 

Thanks.

 

Task2(){//Priority 2

            SEM_pend(semCom,SYS_FOREVER);

            /*do communication*/

}

 

Task1(){//Priority 1

            if(fg_process){

/*do process and analysis*/

}

}

 

PRD_100ms(){

fg_process = 1;

}

 

HWI_pin(){

            SEM_pend(semCom);

}

 

  • It's a little difficult for me to see the problem based on the code you posted.  I didn't understand the HWI_pin() function's SEM_pend call -- is it really a function called by an interrupt?  Shouldn't it be calling SEM_post?

    Also, the tasks should be implemented as loops, so I'm wondering if that part of the code was omitted, since the tasks would terminate once their functions exit.

    In addition, it looks like Task1 should be pending on a semaphore instead of a flag.

    Assuming those comments are already reflected in the code, it appears that Task1 will be made ready to run every 100 ms, but will possibly be preempted at that point by Task2.  So you would see Task1 runn every 100 ms + time to do a frame of communication.

  • Hi David,

    David Friedland said:
    It's a little difficult for me to see the problem based on the code you posted.  I didn't understand the HWI_pin() function's SEM_pend call -- is it really a function called by an interrupt?  Shouldn't it be calling SEM_post?

    You are right, the HWI_pin() function's is function called by an interrupt, and the correct sem command is SEM_post.

    David Friedland said:
    Also, the tasks should be implemented as loops, so I'm wondering if that part of the code was omitted, since the tasks would terminate once their functions exit

    Yes, the taks are in loops.

    David Friedland said:
    In addition, it looks like Task1 should be pending on a semaphore instead of a flag.

    Here a put a flag instead a SEM, it was a part of my code that was working well. So I din't change for a SEM.

    David Friedland said:
    Assuming those comments are already reflected in the code, it appears that Task1 will be made ready to run every 100 ms, but will possibly be preempted at that point by Task2.  So you would see Task1 runn every 100 ms + time to do a frame of communication.

    Yeah, your are right.

    The problem is that the task2 starts and block at SEM_pend, so the task1 run, after a hardware interrupt the SEM_post is done.

    At this point I think that the right operation is that at exit of HWI the blocked task2 run and task1 block, after task2 pend it's block and run the task1.

    But after the exit of HWI, the task2 is taking 100ms to run.

     

    I’ll change the flag for a SEM to see what happen.

    Sorry for don’t be so clear.

    //---------------------------------------------------

    Task2(){//Priority 2

    for(;;){

    SEM_pend(semCom,SYS_FOREVER);

    /*do communication*/

    }

    }

    //---------------------------------------------------

    Task1(){//Priority 1

    for(;;){

    if(fg_process){

    fg_process = 0;

    /*do process and analysis*/

    }

    }

    }

    //--------------------------------------------------- 

    PRD_100ms(){

    fg_process = 1;

    }

    //---------------------------------------------------

    HWI_pin(){

                SEM_post(semCom);

    }

     

     

  • Hi, I found were is the problem

    At really the problem wasn’t at DSP or BIOS. The problem was at my extern interrupt source that didn’t understand the reply made by DSP side.

    Now all is working well.

    Thanks for your attention.