porting ucos into 8051using keil???

Since you are note really sure what micro you are using, are you skilled enough to port Micrium uCOS?

If you are using uCos for commercial products then you have some chance of micrium doing the work on placeing an order.... you will need to send them some eval hardware.

Let me be straight: if you either don't have documentation or are not able to find the documentation for the chips on your eval board, forget any idea of porting anything to it.

Step 1: Check out your EVB, all chips, components and everything which is printed on the board.

No Step 2 before this is not done.

Or, if the OP has Keil IDE can ask it what target it is building for.

But demo programs tend to use a minimal set of chip features, and so will sometimes work for chips that they were not exactly targeted for.

An OS port, OTOH, has to be targeted to the specific chip.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" gives you just what it says.
See details at http://www.wescottdesign.com/actfes/actfes.html

Wrong, probably, for a number of reasons:

With all due respect, from the evidence you give and the questions you ask you don't have the experience to do a successful RTOS port. You may well be smart enough and diligent enough to gain the experience as you do the port, but expect to do some hard work.

Any software that you find floating on the Internet is likely to be buggy, for starters.

8051's aren't a good hardware fit for C (the C virtual machine assumes a processor with a flat memory space, an easy to manipulate stack, and endless capacity for indirection and pointer arithmetic -- the 8051, by itself, has none of these things). So many 8051 "C" compilers aren't remotely ANSI C compatible -- some will be so far from ANSI C that you'll never be able to use uC/OS-2, some will work just fine after a complete rewrite, and some may just compile and run. I have no idea where the Keil fits in there.

An OS is very hardware dependent. In the case of uC/OS-2 it's dependent on the interrupt handling and the timers. If your chip has changed either of these (and I would expect the timers to be different from one manufacturer to the next) then you would need to write your own interface code.

So good luck. As suggested elsewhere you should figure out what's on the board. You really can't do this without a schematic -- I'd check to see if I could find data on the board on the manufacturer's website; failing that I'd read off chip numbers and reverse-engineer enough of the thing to really know how it works.

For the OS port you really need to find one that is written for both the processor and the compiler (and probably the _version_ of the compiler) that you're using. It's sad, but true. Expect that whatever else you do, you're going to have to flog things to get them to actually work, and once you do you still have to use the RTOS properly, and that is by no means a trivial thing.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" gives you just what it says.
See details at http://www.wescottdesign.com/actfes/actfes.html

As Tim already pointed out, knowing the processor type selected to get an EVB sample running is likely not going to be sufficient for an RTOS port.

When porting something substantial like an OS, it's a matter of "due diligence" to first check out every scrap of available documentation.

Often you will find application notes, clarifications, or errata sheets that save a lot of work and/or bug-hunting.