This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

ARM : RTX

Hello,

I'm using KeilUV3 + RTX 3.12 + Eval Kit MCBSTR9

I'm looking for a solution to implement a task switch routine with these two constraints :

1) Task execution : TskA-->TskB-->TaskA-->TaskC-->TaskA-->TaskD-->TaskA-->TaskB... and so on
2) I want this switch occurs every ms, INDEPENDANTLY of the whole duration of the task.

Because of 1), I can't use Round Robin mode... and I can't respect 2) with Controlled Priority mode.

Rem : TaskA is a communication task for which i want to garantee this millisecond response time.

Does anyone have a solution ??

Thanks for advance,

Steph.

  • I would never do this but you did ask. I don't think this is a good use of tasks.

    Create a controll task with say a priority of 200

    set you os_tick_tmr to be 1ms

    // this is the controll task running at priority 200
    
    create tasks a..d with priority 100 (save the tid's)
    
    while (1)
    {
        os_tsk_prio(task_id_of_next_task_to_run,150)
        os_dly_wait(1);
    }
    

    if any task calls os_block - save the controll task which definitely does (you did not state that this was the case) then a task that is priority 100 will run and you may not easily be able to tell which one.

    One of the main advantages of using tasks is that they may call os_block and allow another task to run. It might be best to have the communications task be the highest priority and have it os_block, waiting for a communication event to happen and wake up to service that event. Then schedule your other tasks to be round robin and switch every 1ms, if that is really what you need.

    Every time I look at this I just see more and more problems going down this path. But once again you did ask.

  • Robert,

    Thanks for the reply...

    I was askin' myself these last days : Is OS the right support to do this '1ms funtion roll'. You seem to answer : not at all!!

    I'll try your solution 'just to see'...
    But the problem is that COM task may interrupt an already running task with lower priority during a time X (receive request, prepare datas to answer, send answer) so the system won't be predictible enough ...

    I'll probably try to think the problem with an alternative angle and find a solution to this!!

    regards,

    steph