Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Port the scheduler to another environment

Hello guys,

I would like to know something more about the scheduler whose implementation can be found under SDK_ROOT/components/libraries/scheduler.

Our idea is to apply the same approach to a different environment that is not based on the ARM Cortex-M processor. Is it possible to port the scheduler library to a different working environment? Is there anything specific to Nordic or ARM Cortex-M processor that would stop us from porting the library?

Thanks in advance for your time and efforts!

Sincerely,

Bojan.

Parents
  • One more question about implementing scheduler in RTOS (e.g. freeRTOS) environment...

    Let's say there will be two RTOS tasks. Would it be possible that I execute the events put on the scheduler stack by calling

    app_sched_execute();

    command only in one RTOS task but to put the events on the scheduler's stack with

    app_sched_event_put();

    from BOTH RTOS tasks. Scheduler should be initialized outside tasks.

    Thanks in advance!

    Bojan.

Reply
  • One more question about implementing scheduler in RTOS (e.g. freeRTOS) environment...

    Let's say there will be two RTOS tasks. Would it be possible that I execute the events put on the scheduler stack by calling

    app_sched_execute();

    command only in one RTOS task but to put the events on the scheduler's stack with

    app_sched_event_put();

    from BOTH RTOS tasks. Scheduler should be initialized outside tasks.

    Thanks in advance!

    Bojan.

Children
  • If both RTOS have a common memory that could be shared and if app_scheduler fifo is using this shared memory, then I do not see any reasons why you should not be able to do this.

    Just out of curiosity, why would you need two RTOS on a single core embedded core?

  • Hey, !

    Thanks for your feedback. I was speaking about two RTOS tasks, not about two different RTOSes. One task will consume the events stacked into the scheduler and another would basically serve, among the other things, to put the events on the scheduler stack.

    Does that make sense?

    Cheers,

    Bojan.

  • bojan said:
    Thanks for your feedback. I was speaking about two RTOS tasks, not about two different RTOSes. One task will consume the events stacked into the scheduler and another would basically serve, among the other things, to put the events on the scheduler stack.

     That is the whole purpose of app_scheduler to change the context from once context (app_sched_put()) to another context (app_sched_execute()). So that makes perfect sense.

  • OK, , great to read you like the idea!

    Can we go even further and have two different schedulers implemented in two different RTOS tasks and use them to exchange the events between the tasks?

    For example:

    1) Task 1 puts the event into the scheduler of Task 2. Task 2 consumes the event.

    2) Task 2 puts the event into the scheduler of Task 1. Task 1 consumes the event.

    Cheers,

    Bojan.

  • If the data these two different tasks are processing is of less than the max fifo element size, then you can do this. 

    Note that this way will only work if there is only one element in the app_scheduler fifo. For example if 

    1. If Task1 put one event using app_sched_event_put
    2. Task 2 pulls out the element (0 left in queue) and pushes two new elements into the queue.
    3. Now task1 executes app_sched_execute while there are two elements in the queue but got interrupted after processing one.
    4. Task2 executes app_Sched_execute and finds one element that was inserted by Task2 and Task2 itself will process this instead of Task2.

    I would strongly recommend you to use FreeRTOS queues if your task communication is getting a bit complex.

Related