上 传 者
说明： embed in keil
brd_defs.inc (5824, 2001-11-13)
Brd_init.s03 (7272, 2001-11-09)
includes.h (2723, 2001-11-09)
isr.s03 (18064, 2001-11-13)
lnk8051.xcl (2016, 2001-11-13)
main.c (11448, 2001-11-13)
main.h (2025, 2001-11-13)
os_cfg.h (8830, 2001-11-12)
os_cpu.h (4529, 2001-11-07)
Os_cpu_c.c (20116, 2001-11-13)
readme.txt (11422, 2001-11-13)
tasks.c (21847, 2001-11-13)
uCOS_asm.s03 (27812, 2001-11-13)
_cstart.s03 (14320, 2001-10-30)
uC/OS-II V2.51 Ported to the 80C52
This file contains information on how to port uC/OS-II, version 2.51, to the
80C52 family of processors, using the IAR Systems Embedded Workbench 2.2.
The port files will only work with the specified development tool. Other compilers
will require modifications on some of the target-specific functions.
The information contained herein may be devided into three main areas:
A: Microcontroller internal configuration.
B: Target-specific code.
C: Target-independent code.
To further clarify the operations, I have included sample code to illustrate how to
taylor the software tools to get the best results, and a small demo program which I
have successfully run on a hardware platform featuring a Dallas 80C320 device at 24MHz.
A.- Microcontroller Internal Configuration.
This port uses some specific internal memory locations which may not be changed:
- The internal Stack Pointer is set at 60h.
- The internal memory is used in the following way:
Addresses 40h-41h hold the pointer to the base of current task's external stack.
Addresses 42h-43h are timer #0 reload buffers (Timer#0 is reserved as the system tick).
Addresses 44h-47h are the work area of the port assembly code functions.
This leaves addresses 48h to 5Fh as the "data" type of variables in your application.
(variables reserved in internal RAM).
- I normally reserve the first bit-addressable byte (20h) for internal flag bits. This
leaves you addresses 21h to 3Fh for all your bit-variable requirements.
All these memory constrains are best specified to the development tool by the use of
a "Linker Control File". I am attaching a sample one ("lnk8051.xcl") which defines all
the memory segments described so far. In addition, my test board uses only ***KB of total
external memory: the lower 32KB are in a flash device to hold the code, and the upper 32KB
is simply the data RAM. You can edit the linker control file and adapt it to your specific
Note that I am assigning the beginning of the XDATA segment to address 9000h, since I am
using locations 8000h to 8FFFh to place the tasks' external stacks required by the kernel.
You must use the "Large Memory Model" in the IAR Systems tool. This means that the linker
will use the run-time library called CL8051L.R03 to generate the executable file. At this
point, a word of caution is in order:
The run-time library contains one module called CSTARTUP. This is very important for two
- IAR Systems provides the source code of this module so you can define some low-level
initialisations specific to your hardware.
- This module defines the label "init_C" which is the beginning of all the compiler
generated code. We need to use this label as our reset vector. This will be explained
more in depth later.
I am including a modified source code for the CSTARTUP module ("_cstart.s03"), where I have
only included a call to a module called "Init_Board" (contained in the attached file
"brd_init.s03"). This module performs basic initialisations, and is the best place to
locate the hardware diagnostic code, since it executes before any other compiler-generated
code, and also way before the kernel is even started.
Following IAR Systems documentation, you have to use the XLIB tool to generate a modified
version of the run-time library where you will have substituted the default CSTARTUP
module by the one I am providing, or even your own one.
I also strongly recommend that the interrupt service routines be coded in assembly language.
This will enhance system speed and reliability. In addition, using uC/OS-II (or any other
real-time kernel) places some constrains on how interrupts are handled.