Kunal Kandekar wrote:
-------------------------------
1.You will also need interrupt handlers. Just as the user "registers" his tasks that your RTOS schedules and calls, he/she will also need to register ISRs, i.e. to have more predictable interrupts, an ISR will also be have to defined as a task, maybe a lightweight task.
----------------------------
in 8051 the lightweight and heavyweight don't follow the conventional definitions.may be one should think "Fast Task"concept by keil as a lightweight process because it shall switch really fast and shall employ seperate stacks and register banks.isr if not small enough should be defined as task.but as it is often said one can split ISR into "Must do" and "Can be done later".


2.So you have your own code at the interrupt vector which does something similar (or identical) to what your scheduler does. It will slow down interrupt handling, but the alternative is to have the user be more careful in his design.
Alternately you can provide a simple interface for interrupt handling and disable the SCHEDULER interrupt during other interrupts. That seems more feasible.
-----------------------------------
RTOS doen't give a damn what user does in ISR.RTOS programmers are supposed to take care of it.as for scheduling interrupt it shall only set a flag.by employing nested interrupts and assigning lowest prio to timer tick intr one can overcome this.typically a non preemptible timer thread
shall start(Erik pointed that out to me)before scheduling.
for nested interrupts all RTOS give "enter_isr" and "exit_isr" functions which keep track of no.interrupts on stack
and return to a proxy when interrup_count=0,which propogates to scheduler via timer handler.


3.Priority can lead to starvation, so be careful... some lower priority task may never get executed due to higher priority tasks. Maybe a safer way to handle priority would be to simply allocate a bigger time slice to higher priority tasks? May not be good design, but if it works worth trying. Or have the user set and clear a certain flag in tasks to indicate critical sections, which signal that a task should not be pre-empted. Anything outside the critical section has the same priority.
-------------------------------------
that is the whole idea!RTOS scheduling MUST be unfair.there is no need to allocate higher time slice to task with higher prioroty.if it is not round robin the task shall run untill it blocks or is preempted by higher prio task.as for preventing preemption by user functions many RTOS do provide that facility.

regards
pranav