• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 101 subscribers
  • Views 594 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

DSPLink in Real Time

Cristian Tagliaferri
Prodigy 170 points

Hi!

I am working on a OMAPL-138 device in which ARM (linux) and DSP (DSPBIOS) communicate to each other using CHANNEL API coming with DSPLINK.

I am facing with a performance issue on DSP side of my application. Once in a while DSPBIOS takes more than 5ms to wake up the main thread (blocked on a semaphore) after a SEM_post made in an interrupt.

There are no other DSP threads running with higher priority and DSP load is about 50%.

ARM side, linux is running with a heavy load that makes it using almost 100% of CPU often.

I have found out that if I try to unload the ARM core, in order to have about a 25% of CPU load, DSP never misses the 5 ms deadline.

I think that the only connection that could cause such a problem is DSPLINK.

I have found that, ARM side, DSPLINK can run with real time priority:

http://processors.wiki.ti.com/index.php/DSPLink_FAQs#Does_DSPLink_work_in_an_Real_Time_environment.3F_When_I_use_it_I_see_high_latency.3F

Anyway it is not fully described how to do it. What exactly do I have to add in dpc.c ?


/* Set scheduling policy to enable RT */
<add_code_here>


I am not a linux kernel expert so it is quiet difficult to find the correct code.

Thanks.

  • 0
    TI__Genius 12865 points

    Hi Cristian,

    I am guessing that the original author of the FAQ is referring to what is now commonly known as the Linux RT patch: https://rt.wiki.kernel.org/index.php/Main_Page. I am unsure what type of code needs to go into that section, especially given the RT patch has probably evolved over time. You will probably have to do your own research there. This approach also involves updating your Linux OS with the patch, which you may or may not be willing to do. And I am not convinced that applying the patch will necessarily solve the problem.

    Fundamentally, I see two issues: the ARM is heavily loaded - having the ARM application processor running Linux at 100% doesn't leave much headroom to deal with any asynchronous events that comes from e.g. DSP interrupts and user interaction. It may make sense to look for ways to reduce the load in general, or raise the priority of the process(es) involved in DSPLINK communication. Make sure you are using SCHED_FIFO on the ARM side (see http://oreilly.com/catalog/linuxkernel/chapter/ch10.html#94726 regarding scheduling policy).

    The other issue is that on the DSP, after SEM_post is called, some other thread ran and delayed the scheduling of the main TSK, which happens to be the highest priority TSK in the system (I am assuming you meant 'TSK' when you said "no other DSP threads running with higher priority"). So this thread is either a SWI or a HWI, and it is waiting on the ARM to come back with a response. Do you know if you have such a thread on the DSP? If so, you may want to see if there is a way for it to avoid waiting for the ARM. And if you have CCS installed, you can try to halt the execution of the DSP code immediately after the point when the main thread wakes up after the deadline is missed, and then check out the BIOS execution graph in CCS to find out which thread ran.

    Hope this helps,

    Vincent

     

  • 0 in reply to Vincent W.
    Prodigy 170 points

    Thanks for your reply Vincent!

    You hit the issue.

    I made some DSP side tests (where I am more confident) and I solved the problem.

    Yes, I meant that no other TSK are running with higher priority... but I also meant application TSK! Actually there was a DSPLINK TSK configured in the '.tcf' with highest priority (ZCPYLINK_TSK_OBJ).

    I changed its priority in order to be lower than the main task one and now the SEM_post produce an almost instant wake up.

    The only question left is about some side effects of this change. I haven't noticed anything strange so far.

    Now I will try to check what you suggested me ARM side.

    Thank you again!