• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 99 subscribers
  • Views 627 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

PRD_tick() vs TSK_tick()

d200guy
Intellectual 555 points

DSP: TMS320C28346

PC: Windows XP

IDE: Code Composer 4.1.2

BIOS: 5.41

I don't intend to use the CLK or PRD modules in my application, but I do call SEM_pend, MBX_pend, and TSK_delay.  I can find plenty of documentation that says to disable "Use CLK Manager to drive PRD" and then call PRD_tick() in the application, but spra829 figure 1 seems to indicate that I could call TSK_tick() and perhaps save a little more overhead?  Does anyone know if there are any pitfalls doing this?

  • 0
    Intellectual 555 points

    Yes, I'm doing motor control and running at a very high and consistent rate (driven by an ePWM), so I thought I could spare some overhead by just calling TSK_tick() there.

  • 0
    Intellectual 555 points

    By the way, thanks for the response!  This is my first TI E2E post to get a one!

  • 0 in reply to d200guy
    TI__Guru*** 125430 points

    If you have interrupts that are firing at a regular interval then you could potentially call it from your ISR.  *HOWEVER*, you need to use the BIOS dispatcher if you wish to call this API from your ISR.  Generally speaking most motor control customers are trying to keep latency to an absolute minimum.  Using the dispatcher will add a bit of latency to your ISR since it will cause BIOS to run a bit of code prior to executing your ISR.  So in trying to save yourself some overhead you might end up creating additional overhead.

    Personally I recommend sticking to "the usual route" and just leaving CLK manager enabled.  You'll have fewer issues and a happier experience!

  • 0 in reply to Brad Griffis
    Intellectual 555 points

    My ISR needs to post some SEMs anyway, so I've created it as a dispatched HWI.  I'll try this, but I will keep your recommendation in mind if I start having problems.  Thanks again!

  • 0 in reply to d200guy
    TI__Mastermind 18320 points
    One additional note from my side...
    I think Brad's advice is basically sound - you would indeed need to use the dispatcher to implement an ISR that calls TSK_tick().  But if you need to use a dispatcher HWI anyways, then I think calling TSK_tick() is a good way to go.  This is precisely why that API call was created in the first place.
     
    One question in mind however is whether you really need a tick at all.  You mention that you are using SEM_pend and MBX_pend.  If you are not specifying a timeout for these calls (i.e., SYS_FOREVER), then no tick would be needed for them.  You also mention using TSK_delay().  Do you mean TSK_sleep?  And if so, do you really need to?  This call is typically used for a time slicing scheme among multiple tasks at the same priority.  If you can implement your system as a true premptive multitasking system then that would remove the need for TSK_tick there as well.  And then you could disable CLK entirely, as the BIOS scheduler does not need a time base to function.
  • 0 in reply to David Friedland
    Intellectual 555 points

    That's a really interesting idea, but my application isn't far enough along to be sure I won't need timeouts.  Also, I'm using TSK_sleep to manage rate-based tasks without involving PRD and to pause tasks while hardware is busy.  Bad style?

  • 0 in reply to d200guy
    TI__Mastermind 18320 points

    Possibly.  But if you really need an independent time base to control your system you may not have a choice. If you can do without it you should be able to end up with something that is more efficient and deterministic.

    Yet another thing to think about in your software design (if you can bear it), is also to look at whether you truly need to implement these threads as tasks.  BIOS also provides Software Interrupts, which are threads that are similar to ISRs in that they run to completion.  You may find that using SWIs may ultimately be more efficient.  From a memory usage perspective they can be superior, since all SWIs run use a single stack, versus TSKs which each use a separate stack.

  • 0 in reply to David Friedland
    Intellectual 555 points

    The DSP/BIOS environment is new to my organization, so we're still learning the ropes when it comes to making good design decisions.  I used tasks because that format is the most familiar to my team on other platforms.  We often like to measure the stack utilization of each task so that we can ensure required margins.  Also, many of my tasks use local variables before the while(1) { <task code>}, so it seems that SWIs would make me convert locals to globals (less efficient?). 

    Anyway, it's another concept I'll try to keep in mind as we go forward.  Thanks again for all the pointers!