• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 82 subscribers
  • Views 312 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.

TMS320F28384S: Questions about SYSBIOS project without Tasks only SWIs and HWIs

Wesley C
Intellectual 925 points
Part Number: TMS320F28384S
Other Parts Discussed in Thread: SYSBIOS

Hi everyone,

I would like some help in defining the PROs and CONs of eliminating Tasks and using only SWIs and HWIs in a SYSBIOS project.

So far, I understand that:

HWIs and SWIs must run to completion thus no forever loops, no pends. Likely lots of static variables in functions or global variables to keep track of states.

HWIs and SWIs live on the system stack, so no separation like how tasks allow the .taskStack memory section. Static analysis/code trace will likely be harder due to this.

Some questions:

Is there any limitation on where I can place the system stack or how large it can get? Would there be any issue with having the system stack include multiple RAMs?

Are there any modules within SYSBIOS that would be basically eliminated by removing Tasks?

How would debugging the code be affected? I understand single-stepping the code will hit the end of context of SWI/HWI.

Thanks for your help!

  • +1
    TI__Guru 52355 points
    Wesley C said:
    Is there any limitation on where I can place the system stack or how large it can get? Would there be any issue with having the system stack include multiple RAMs?

    Only the usual limitations on the stack, like the size of the stack pointer. For example on the C28x it's 16 bits, so some of the higher GSxRAMs are out of reach. It's fine to have it span multiple contiguous RAM blocks.

    Wesley C said:
    Are there any modules within SYSBIOS that would be basically eliminated by removing Tasks?

    The only thing I can think of that creates a Task is Idle, but it'll just create an infinite loop in BIOS_start when BIOS.taskEnabled = false.

    Wesley C said:
    How would debugging the code be affected? I understand single-stepping the code will hit the end of context of SWI/HWI.

    Nothing else comes to mind. As you've pointed out, single stepping may be a bit painful because of the context switch, but you'll still be able to use breakpoints and ROV.

    Whitney

  • 0 in reply to Whitney Dewey
    Intellectual 925 points

    Hi Whitney,

    Can you answer or provide some links/direction as to when would be the best time to use a SWI vs a Task? Is there anything related to frequency or overhead where it would be best to use one versus the other?

    Thanks,

    -Wes

  • 0 in reply to Wesley C
    Intellectual 925 points

    Hi Whitney,

    Another question related to the SWI vs Task. How would scheduling be effected here? Clock SWIs are the lowest priority SWI, correct? So I would expect that any scheduling using Clocks would become the lowest priority (other than the Idle task). Is there perhaps another way to create clock-like functionality that would be higher than the SWIs? Maybe a HWI based on Timer, I suppose?

    Thanks again,

    -Wes

  • 0 in reply to Wesley C
    TI__Guru 52355 points

    The SYS/BIOS User Guide chapters for Swis and Tasks have links to some training videos that discuss the properties of each that I think may be helpful. Have you seen those?

    The Clock module Swi priority is configurable so it's not necessarily the lowest. If you have a particular function that you want to run periodically but with a higher priority than the Clock Swi though, a Timer (or a higher priority Swi posted form the Timer tickFxn) could work.

    Whitney

  • 0 in reply to Whitney Dewey
    Intellectual 925 points

    Thanks Whitney! I'll look into those for further information.