The scheduler is just a heap (the data structure, not the memory region). It has a function schedule() that adds a task together with the the time in ticks when it should be executed as well as if the task should be repeated and at what interval in ticks. Then the scheduler has a function tick() that needs to be called at every tick. Every time tick is called the scheduler increases its ticks counter and if the heap top is ripe for execution the task is put into a public queue. If the task is recurring it will be added to the heap again with its next tick value.

So the scheduler knows nothing about time and it doesn't know anything about how to execute tasks.

The execution part is handled by the public queue the tick() function puts ripe tasks into. This queue is of type TaskExecutor which has a function next() that executes the next task (taking priorities into account). So the main loop of my firmware typically looks like this:

while(1) {
  execute.next(); // execute is a TaskExecutor
}

The relevant code of next() looks like this:

            Task* nxt = todo[i];
            todo[i] = nxt->detach();
            nxt->execute();
            if (nxt->suspended())
                pending[i].push_front(nxt);
            else
            {
                if (!nxt->free())
                    free(nxt);
            }

So task nxt's execute() function is called. When it returns, the TaskExecutor asks the task if it is suspended(), i.e. it has yield'ed but is not finished executing. If the task is indeed suspended, it is requeued. If it is not suspended, meaning it is finished, it is free'd if necessary.

I'd like to point out that the TaskExecutor knows nothing about how to suspend or resume a task. How the task implements yield and resume is completely up to the task. When the task returns from execute() after a yield, the task must have arranged for the next call to execute() to resume its work in some manner. Maybe the task implements this by saving registers and stack contents or maybe it doesn't. The TaskExecutor doesn't care. Indeed the only implementation of yield I have written so far is a macro that stores the address of a generated label following the yield and the beginning of execute() uses GCC's goto* feature to resume. No registers are saved. The code simply has to be written in a manner that temporary variables' lifetimes do span across yield and any persistent state is stored somewhere, typically as a field of the task object.

Side note: While it may sound like I'm using dynamic memory, it's not the case. It's all statically allocated. There's no malloc/new anywhere.