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 Steve.

Thank you so far. Here is som additional, requested information:

Task-A have enough time. The important thing is that it is executed excactly every 650 usec.

Task-B contain another "continous C-program" (a "SCI communication module" (among other)). It might have a lot to do, it might have less to do. What's important is that it never exceeds the 150 usec limitation (HW will be damaged). After 150 usec has elapsed, the CPU (by the TI-RTOS) must interrupt/pre-empt Task-B and the CPU must be "delivered" to Task-A again. After new 650 usec, Task-A must me interrupted/pre-empted (by the TI-RTOS), and Task-B must proceed from where it previously was interrupted. Etc...

If this information is still not sufficient please let me know.

Best regards
Terje Bøhler

Terje,

Thanks for responding with those clarifications.

But, I am still wondering about the "5us ISR":

Terje Bohler1
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)

How long will it take to complete the work done in the ISR for this?

Hi.
The 5 usec ISR takes about 2 usec (40% of the total CPU) - assumably.
The ISR consists of 103 lines of ASM/macro-code (@ 60MHz):
8 PUSH, 8 POP, 20 NOP's, 47 MOV[x], ADCDRV_4ch, ADCDRV_1ch (two such), DACDRV_RAMP, etc ...
If this is not sufficient, please let me know, and we'll do a more detailed measurement on our target system.
I'll really appreaciate your assistance.
Best Regards
Terje Bøhler

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

Hi Steve.

Our overall challenge is that our very timing-critical DC-DC power regulation has to handle a RS485 communication module in addition. And actually, we do not have control over the code running in that “RS485-module” (written by others).

We have discussed your proposal and see it’s benefits. But still we have some concerns (questions) wrt the “DEAD-ZONE delay” and jitter (“DEAD-ZONE delay variation”). I know some of these Q’s are tricky to answer, but I’ll appreciate your comments.

Q-1: How many (about) cycles/instructions are executed in the DEAD-ZONE (from the TI-RTOS timer interrupt/tick occur, to interrupt is re-enabled and we are ready to run a possibly “colliding” 5 us ISR) ?

Q-2: Will the “DEAD-ZONE delay” vary (DEAD-ZONE jitter) ?
Most often when the TI-RTOS timer interrupt/tick occur, the is no task-switching. But, sometimes a task-switch (A/B) shall be performed.
So, we’ll have the following two possible “colliding scenarios”:
1) An TI-RTOS timer interrupt/tick NOT leading to a task switch “collides” with a 5 us interrupt (5 us ISR to be run)
2) An TI-RTOS timer interrupt/tick leading to a task switch (task:A <--> task:B) “collides” with a 5 us interrupt (5 us ISR to be run)

Q-3: I assume that the TI-RTOS is optimized wrt CPU time consumption …
But, do you think it’s possible to time-optimize and jitter-minimize this DEAD-ZONE further by tailor/create a task scheduler (task:A <-->task:B) ourself (is it advisable)?

Best regards
Terje Bøhler

Thank you very much Steve!

This is really great!

best regards

terje bøhler