ucos-ii-8052

所属分类单片机开发
开发工具:WINDOWS
文件大小:30KB
下载次数:24
上传日期:2004-07-12 12:14:51
上 传 者evens
说明:  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 requirements. 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 reasons: - 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. ... ...

近期下载者

相关文件


收藏者