• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 100 subscribers
  • Views 1860 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.

SWI vs. TSK

BAS
Expert 2370 points
Hi,

How to maintain a real-time when time to fill a buffer is shorter than processing it ? I want to maintain a real-time capturing and processing but don't understand how should I do it because in my application, time to fill the buffer is shorter than processing it. In this case, should I restrict HWI to trigger about the same time which is required to process it ?

I would appreciate if you help me understaing the concept when TSK or SWI should be used ?

Thanks.

  • 0
    Mastermind 6240 points

    Hi,

    About the time to fill the buffer, can you use multiple buffering (http://en.wikipedia.org/wiki/Multiple_buffering) ?

    BAS said:
    I would appreciate if you help me understaing the concept when TSK or SWI should be used ?

    Task is used when you wait for data to be ready, for instance and runs forever like a while (1).

    SWIs runs to completion. See the BIOS manual for more info (http://www.ti.com/general/docs/lit/getliterature.tsp?baseLiteratureNumber=spruex3).

  • 0 in reply to Johannes
    Expert 2370 points

    Johannes,

    Multiple buffering is one option but processing time is bit longer than filling time. How to synchronize them ?

    In my case, new data is always ready before the processing of the data is done. If HWI triggers when new data is available, it will preempt the TSK or SWI, after servicing the new HW interrupt, will it resumes execution at point where preempted ?

    SWI runs to completion, does that mean even after new buffer is filled, it will process the same old buffer first ?

    Thanks.

  • 0
    TI__Mastermind 20480 points

    Hi BAS,

    think of a Swi similar to a Hwi. It was created with the intent to allow reduced execution time in an interrupt context while providing a very high priority in processing over any other Task. There is no single solution how to solve your problem, but these are the items to be aware of.

    • It must finish execution, which means it can't be blocked by any RTOS primitives (Semaphore, Gates, etc...) (As to what Johannes said)
    • It can be preempted by a Hwi, after which the Swi will resume execution assuming no other Hwi or higher priority Swi is ready to run.
    • A Swi starts its execution when it gets posted from a Hwi, Swi, or Task. A Swi will run only once if multiple Swi_post()'s were called. A Swi will run multiple times (for every Swi_inc()) if you call Swi_inc().
    • Like Hwi's, Swi's use the system stack.

    Blocking on RTOS primitives is only permissible in a context of a Task. In either case, a Swi or Task will resume execution where it left off at the time of preemption. You may have to guard your critical sections shared with a Hwi with Hwi_disable() and Hwi_restore() calls.

    When your data buffer has been filled a Semaphore_post() can be used to synchronize your data processing within a Task(), or a Swi_post() if this is done within a Swi.

    You may want to look into using a DMA to collect new data while giving the CPU more time (by not preempting it with a Hwi/Swi) to process existing data.

    I hope this helps a bit.

  • 0 in reply to Tom Kopriva
    Expert 2370 points

    Hi TOM,

    Thanks for your help. I have still few confusions. Please help me out.

    1. Task can be blocked, what is the advantage of this feature ? Swi can't be blocked but after serving HWI it will resume execution where it was preempted. Aren't both the same thing ?

    2. I am already using uPP, that has DMA to collect data which is very fast comparing to the time taken for processing it. You said there could be many solution to my problem, will you please mention any one ? I have no prior experience of doing that.

    Thanks for your help.

  • 0 in reply to BAS
    TI__Mastermind 20480 points

    Hi BAS,

    BAS said:
    1. Task can be blocked, what is the advantage of this feature ? Swi can't be blocked but after serving HWI it will resume execution where it was preempted. Aren't both the same thing ?

    Sorry for the confusion, what I meant with "blocked" is to "wait (block) during execution until necessary resources are available", not to stop code execution to service a higher priority Hwi/Swi/Task.

    You don't want to have to periodically check a flag that is set a peripheral (e.g. by a UART) every xyz milliseconds when you could have the Task "blocked" or pending on a Semaphore. Whenever the Semaphore gets posted, then your Task gets notified that it can now continue its code execution (for example processing a command string received by the UART). As to which primitives are available and how to use them is covered in the SYS/BIOS User's Guide.

    When using a Swi or Hwi, you can't "block" (e.g can't wait for a Semaphore_pend()) but you can still get preempted by another higher priority Swi or Hwi.

    BAS said:
    2. I am already using uPP, that has DMA to collect data which is very fast comparing to the time taken for processing it. You said there could be many solution to my problem, will you please mention any one ? I have no prior experience of doing that.

    You can perhaps store all if it in a buffer and process it after the collection finished. Or try multi-buffering your data (as to what Johannes mentioned), e.g. process data in a buffer while the DMA transfers data into another one. Take an interrupt when the buffer is full and swap them (if your CPU has processed it already). Perhaps if one CPU isn't enough, you may want to have a multi-core device split the work.

  • 0 in reply to Tom Kopriva
    Expert 2370 points

    Hi Tom,

    Thanks for your detailed answer.