Page Comparison

There are a number of conventions in this book.

First, you will notice that when a specific element in a figure is referenced, the element has a number next to it in parenthesis. A description of this element follows the figure and in this case, the letter “F” followed by the figure number, and then the number in parenthesis. For example, F3-4(2) indicates that this description refers to Figure 3-4 and the element (2) in that figure. This convention also applies to listings (starts with an “L”) and tables (starts with a “T”).

Second, you will notice that sections and listings are started where it makes sense. Specifically, do not be surprised to see the bottom half of a page empty. New sections begin on a new page, and listings are found on a single page, instead of breaking listings on two pages.

Third, code quality is something I’ve been avidly promoting throughout my whole career. At Micriµm, we pride ourselves in having the cleanest code in the industry. Examples of this are seen in this book. I created and published a coding standard in 1992 that was published in the original µC/OS book. This standard has evolved over the years, but the spirit of the standard has been maintained throughout. The Micriµm coding standard is available for download from the Micriµm website, www.micrium.com

One of the conventions used is that all functions, variables, macros and #define constants are prefixed by “OS” (which stands for Operating System) followed by the acronym of the module (e.g., Sem), and then the operation performed by the function. For example OSSemPost() indicates that the function belongs to the OS (µC/OS-III), that it is part of the Semaphore services, and specifically that the function performs a Post (i.e., signal) operation. This allows all related functions to be grouped together in the reference manual, and makes those services intuitive to use.

You should notice that signaling or sending a message to a task is called posting, and waiting for a signal or a message is called pending. In other words, an ISR or a task signals or sends a message to another task by using OS???Post(), where ??? is the type of service: Sem, TaskSem, Flag, Mutex, Q, and TaskQ. Similarly, a task can wait for a signal or a message by calling OS???Pend()µC/CPU and µC/OS-III are provided in source form and include template files (C and assembly language) which contain instructions about what code needs to be inserted and where. Specifically, you will need to search the source files for four dollar signs (i.e., $$$$) which are used as placeholders and replace those with the necessary code.

It is assumed that assembly language code use a file extension of .asm. Other assembler might require that the extension be .s or .src. If that’s the case with your tools, simply name the assembly language files using the proper extension.

It is assumed that comments in an assembly language file starts with a semicolon, ‘;’.

In assembly language, there are a number of ‘directives’ that tell the assembler how to process certain pieces of information. Below is a list of such directives and their meaning. The assembler you use may use different syntax for these directives but overall, they should work and mean the same.

• The PUBLIC directive indicates that you are declaring a symbol to be globally available. In other words, it’s public for all files to see.
• The EXTERN directive indicates that the definition of a symbol is found in another file (external to this file).
• The CODE directive indicates that what follows needs to be linked with the rest of your executable code. In other words, we are not declaring any variables.
• The MACRO directive is used to define an assembly language macro. A macro is basically a series of assembly language instructions that will be replacing the macro name. In other words, when the assembler sees the macro name being invoked in your code, it will replace the macro name with the instructions that are associated with the macro. Macros are useful to avoid repeating sequences of assembly language instructions.
• The END directive is generally the last assembly language statement in an assembly language file. The END directive should not appear at the end of a file that defines macros because macro files are generally included in other assembly language files.