RE: Schedular vs RTOS vs Blocking, need scheduler clarification.

Susheel Nuguru — Fri, 20 Jan 2017 17:59:45 GMT

avoid using delays using busy wait by executing NOP, use timers instead.
correct

RE: Schedular vs RTOS vs Blocking, need scheduler clarification.

SRA — Wed, 18 Jan 2017 21:16:07 GMT

1.) Ok, so if I did want to make things easier on myself and did want to delay(1Second) it would maybe be in my best interest to make sure that my delay function wasn't just a NOP loop for x cycles, but instead was a main context subloop that called SchedulerExecute. Is this even semi-legit or just a really hacky way to avoid re-entering the superloop when I really just want to stay at the current place in code for awhile?

2/3/4). I think I understand.

5.) Ok, so because execute will run from whatever context it's called from, it's almost always best to call it from the main context. Which is why in order for my delay example to work, my delay function would have to repetitively be calling sched_execute.

RE: Schedular vs RTOS vs Blocking, need scheduler clarification.

Susheel Nuguru — Wed, 18 Jan 2017 09:56:23 GMT

Hi,

Your main function will be running at the least priority look here. This means that the scheduler_execute is popping any functions at the lowest priority. All FreeRTOS tasks run as thread mode, so any ISR will pre-empt them. Any ISR will only put your subfunction1 into the scheduler. You sybfunction1 will only execute when your main function gets a chance to run (when all other ISR have exited) and pops your function from scheduler by scheduler_execute() as per your example.
You subfunction1 might need some data to process and this data can be anything and of any size depending on the application requirement. I suggest you to read my most regarding the scheduler to understand its basic design and why we need to allocate this data and how here. Since we are pushing into scheduler from different ISR context and popping it in other thread like main or any other lower priority interrupt, we need to reserve this space before hand in the stack and Scheduler does this at the time of scheduler init.
I did not quite understand what you mean by "main code need to be an element in scheduler". Scheduler is independent, it is not necessary that you have to use only main to pull the functions out of scheduler. I think the post i mentioned above will also answer this question. If not , let me know.
The difference is in simplicity and the ability to pass arguments between contexts. Using a flag in ISR and waiting in main, you cannot pass a lot of arguments between these two contexts (unless you want to use unnecessary global space). The difference is also in the design in how generic it is designed to fit any application that want to postpone the execution of some function with data exchange between these contexts.
It does not matter if you are calling it in main or any ISR, once the context within which the scheduler_execute is running, it will be synchronous execution and will pop the function (in your example subfuntion1) and execute it before exiting that ISR. (main cannot exit , so its a super loop)

Yes, I also have suggested that if your application can be kept simple without the use of RTOS, then prefer not to use it and use the scheduler efficiently. May be this thread is interesting for you.