Once INSTALL.BAT has completed, your destination drive will contain the following subdirectories:

\SOFTWARE

The main directory from the root where all software-related files are placed.

\SOFTWARE\BLOCKS

The main directory where all ‘Building Blocks’are located. With µC/OS-II, I included a ‘building block’that handles DOS-type compatible functions that are used by the example code.

\SOFTWARE\BLOCKS\TO

This directory contains the files for the TO utility (see Appendix E, TO). The source file is TO.C and is found in the \SOFTWARE\TO\SOURCE directory. The DOS executable file (TO.EXE) is found in the \SOFTWARE\TO\EXE directory. Note that TO requires a file called TO.TBL which must reside on your root directory. An example of TO.TBL is also found in the \SOFTWARE\TO\EXE directory. You will need to move TO.TBL to the root directory if you are to use TO.EXE.

\SOFTWARE\uCOS-II

The main directory where all µC/OS-II files are located.

\SOFTWARE\uCOS-II\EX1_x86L

This directory contains the source code for EXAMPLE #1 (see section 1.07, Example #1) which is intended to run under DOS (or a DOS window under Windows 95).

\SOFTWARE\uCOS-II\EX2_x86L

This directory contains the source code for EXAMPLE #2 (see section 1.08, Example #2) which is intended to run under DOS (or a DOS window under Windows 95).

\SOFTWARE\uCOS-II\EX3_x86L

This directory contains the source code for EXAMPLE #3 (see section 1.09, Example #3) which is intended to run under DOS (or a DOS window under Windows 95).

\SOFTWARE\uCOS-II\Ix86L

This directory contains the source code for the processor dependent code (a.k.a. the port) of µC/OS-II for an 80x86 Real-Mode, Large Model processor.

\SOFTWARE\uCOS-II\SOURCE

This directory contains the source code for processor independent portion of µC/OS-II. This code is fully portable to other processor architectures.

1.01 INCLUDES.H

You will notice that every .C file in this book contains the following declaration:

#include "includes.h"

INCLUDES.H allows every .C file in your project to be written without concern about which header file will actually be included. In other words, INCLUDES.H is a Master include file. The only drawback is that INCLUDES.H includes header files that are not pertinent to some of the .C file being compiled. This means that each file will require extra time to compile. This inconvenience is offset by code portability. There is an INCLUDES.H for every example provided in this book. In other words, you will find a

different copy of INCLUDES.H in \SOFTWARE\uCOS-II\EX1_x86L, \SOFTWARE\uCOS-II\EX2_x86L and \SOFTWARE\uCOS-II\EX3_x86L. You

can certainly edit INCLUDES.H to add your own header files.

1.02 Compiler Independent Data Types

Because different microprocessors have different word length, the port of µC/OS-II includes a series of type definitions that ensures portability (see \SOFTWARE\uCOS-II\Ix86L\OS_CPU.H for the

80x86 real-mode, large model). Specifically, µC/OS-II’s code never makes use of C’s short, int and, long data types because they are inherently non-portable. Instead, I defined integer data types that are both portable and intuitive as shown in listing 1.1. Also, for convenience, I have included floating-point data types even though µC/OS-II doesn’t make use of floating-point.

The INT16U data type, for example, always represents a 16-bit unsigned integer. µC/OS-II and your

application code can now assume that the range of values for variables declared with this type is from 0 to 65535. A µC/OS-II port to a 32-bit processor could mean that an INT16U would be declared as an

unsigned short instead of an unsigned int. Where µC/OS-II is concerned, however, it still deals with an INT16U. Listing 1.1 provides the declarations for the 80x86 and the Borland C/C++ compiler as an example.

For backward compatibility with µC/OS, I also defined the data types BYTE, WORD, LONG (and their

unsigned variations). This allows you to migrate µC/OS code to µC/OS-II without changing all instances of the old data types to the new data types. I decided to make this transition and break away from the old style data types because I believe that this new scheme makes more sense and is more obvious. A WORD to some people may mean a 32-bit value whereas I originally intended it to mean a 16-bit value. With the new data types, there should be no more confusion.

1.03 Global Variables

Following is a technique that I use to declare global variables. As you know, a global variable needs to be allocated storage space in RAM and must be referenced by other modules using the C keyword extern. Declarations must thus be placed in both the .C and the .H files. This duplication of declarations, however, can lead to mistakes. The technique described in this section only requires a single declaration in the header file, but is a little tricky to understand. However, once you know how this technique works you will apply it mechanically.

In all .H files that define global variables, you will find the following declaration:

#ifdef xxx_GLOBALS #define xxx_EXT #else