what are differences hardware?

None.

i want to use 8051 microcontroller for multitasking RTOS .i want to know the difference of hardware which use for multitasking and normal program.

none, except the functions you have to move to hardware because the required response time can not be met by the uC using a RTOS.
If you have nothing that require immediate response no HW changes (except maybe code banking support for some code growth) will be required.

A native system (no RTOS) can be made real time
With a RTOS you get "real enough time" and what is real enough is decided by the people marketing the RTOS.

using a (RT)OS is great if you are doing microcomputing, but usually a disater if you are doing microcontrolling.

Erik

Anything that has short enough real time requirements can usually be handled by an interrupt, even with an RTOS.

Even if you don't have an RTOS, your code will contain critical sections that increase interrupt latency. Just because you write it all yourself doesn't mean the problems scheduling a complex set of tasks go away.

In my opinion, the 8051 is poorly suited to a preemptive scheduler. Weak stack handling and awkward access to xdata mean you have a pretty big premium on keeping the stack out of xdata. (And by "stack", I mean the usual C stack, not just the return values maintained by the 8051 hardware stack.)

The compile-time call tree analysis that Keil does also goes out the window if you have preemption. Every task will have to be the root of its own call tree, so you'll get less benefit out of the overlay analysis and need much more memory. (You can see this problem reflected in the design of Pumpkin's Salvo, where you can only switch context at the "top level" of your task, which is to say when the stack is back at the top and you don't have to worry about preserving the contents.) You'll also likely wind up needing more "reentrant" routines to share between the tasks. Each task, like an interrupt handler, will be its own context from the point of view of the call tree.

Thank you very much.

piyata sunta

"i want to use 8051 microcontroller for multitasking RTOS"

You are putting the cart before the horse there!

There is no point in simply putting an RTOS onto an 8051 - you need an application to run on an 8051!
If that application requires an RTOS then fine - use one; but if your application does not require an RTOS, don't waste your time & effort on it.

In general, it is probably unlikely that an application suited to an 8051 will require an RTOS.

"...Pumpkin's Salvo, where you can only switch context at the 'top level' of your task..."

Don't know that one - is it really preemptive multitasking, or is it more like the "cooperative" multitasking of Win3.1?

To answer my own question:

http://www.pumpkininc.com/

And the very first line on p2 of http://www.pumpkininc.com/content/doc/press/salvoflyer.pdf says, "Cooperative, event-driven,..."

Pumpkin's Salvo... don't know that one

http://www.pumpkininc.com/

You can download a three-task / five-event version for free, and Keil C is their "certified" 8051 compiler.

I think it was originally created for PICs. Emphasis on "small".

It's kind of interesting from the point of view of how minimalist your RTOS can get. Salvo looks like it would fit in for those apps where your background loop/interrupt structure is starting to get hard to manage, and you'd rather have an event-driven model -- yet still don't want (or can't afford) a full-blown preemptive multitasking system.

It has only a cooperative scheduler. The biggest drawback there is the headache of trying to guarantee that the longest path through any of your code is less than N time units, for whatever response time to an event your app has to guarantee.

A bigger drawback in my mind is the subset of functions (or macros) that can only be called from the top level of your task, not even one procedure call deep. The restriction is necessary because of the minimalist approach. (Salvo doesn't save a task stack on a context switch, so you'd better not have anything on the stack.) But it does limit the scale of the app. On the other hand, the design intent for Salvo is precisely for very small apps.