Fast context switching in TI-RTOS ?

Hi Terje,

These are tight timing requirements, indeed.  I am in the process of looking at the numbers and will respond back tomorrow.

Steve

Terje,

I'm waiting to speak to one of my colleagues on your timing requirements and will get back to you on that once I do.

I have a couple of questions in the meantime:

Terje Bohler1 said:

a) Task-A is running continuously (maintenance stuff etc).

How often do you expect Task A to run?  How much time will it need, approximately, to complete the work it is doing?

Terje Bohler1 said:

b) Task-B is executed every 650 usec, AND MUST NEVER USE > 150 USEC (otherwise HW will be damaged).

Also for this - How much time will it need, approximately, to complete the work it is doing?

Steve

Terje Bohler1 said:

A high-priority PWM ISR executing every 5 usec.
This runs OK in “the background”!
NOTE: This 5 usec interrupt must be handled immediately (other parts of the code must NEVER disable these interrupts etc)

Also, how long will it take to complete the work done in the ISR for this?

Hi Terje,

I discussed your requirements with my colleague and we are confident that SYS/BIOS can handle your tight timing requirements, with one small caveat which I'll talk about below.

1. Your requirement for an interrupt that will fire every 5us can be handled by using the SYS/BIOS Hwi module and the C28x's "zero latency interrupts" feature.  The zero latency interrupts will minimize the overhead of a Task swap and Hwi dispatcher in order to run your ISR.

Here's where the caveat comes in.  It is very possible that another, (non zero latency) interrupt fires *immediately* before your 5us interrupt does.  In this case, the C28x core itself will disable interrupts for a short period of time (there is nothing that SYS/BIOS can do about this; it is done by the core itself).  So, in this case, interrupts will be disabled and some registers would be stacked by the hardware.

Once that's done, the SYS/BIOS Hwi dispatcher's prolog would run, pushing some other registers that it needs to save before re-enabling interrupts again (while this code has been minimized, it still does take a little time).  So, there is a "dead zone" that could occur in this scenario.

Only once the end of this "dead zone" is reached (when BIOS re-enables interrupts) could your 5us interrupt run, in this scenario.  So, you would need to be sure that your ISR code can still complete in time, given the possibility of this extra overhead.

2. Your Task B, which must run every 650us, and NOT run for more than 150us can be handled by a SYS/BIOS Task and a Timer.

This could be solved in more than one way, but here is one possible solution:

The Task would be used to run the actual code that does the work that cannot run for more than 150us.

A Timer object would be used to enable the Task every 650 us, and disable it after 150us.

For example, the Timer object can be created with a period set to 50 us, and configured with a function "myTimer()". The Timer will expire every 50us, at which point it will call "myTimer()".  With this 50us period, every 13 ticks will equal 650us, and 3 ticks will be 150us.
.

In the code of myTimer(), you could do something like the following (pseudo code).

myTimer()
{
    static int previousTime;

    if (ticks % 13 == 0) {
        /* (re)enable Task B (context switch to Task B)  after 650us */
        Task_setPri(TaskB, <some high pri that allows TaskB to run>);
        previousTime = Timer_getCount();
    }
    else if (Timer_getCount() = previousTime + 3) {
        /* disable Task B: (priority of -1 causes Task to be disabled) after 150us */
        Task_setPri(TaskB, -1);
         previousTime = 0;
    }
}

I'm not sure if these are the exact times you'd need, this is just some rough pseudo code, but I think you get the idea.

3. For your Task A, which just runs continuously in the background to do maintenance, this could also use a SYS/BIOS Task.  It could be set to a priority that is lower than Task B, to allow it to run during the times that the 5us ISR and Task B are not running

Lastly:

Terje Bohler1 said:

The 5 usec ISR takes about 2 usec (40% of the total CPU) - assumably.

Since your ISR will be firing during Task B (has only 150ms to complete), 40% leaves only 60us for Task B to complete.  Can it complete during that time?

Steve

Thank you very much Steve.

I really appreciate your support.
I'll dive into this matter in a short while, and give you feedback on our results after testing/prototyping.

Best Regards
Terje Bøhler

Thank you very much Steve!

This is really great!

best regards

terje bøhler