Directories and Files
- Former user (Deleted)
- WES Admin
µC/OS-III is fairly easy to use once it is understood exactly which source files are needed to make up a µC/OS-III-based application. This chapter will discuss the modules available for µC/OS-III and how everything fits together.
The figure below shows the µC/OS-III architecture and its relationship with hardware. Of course, in addition to the timer and interrupt controller, hardware would most likely contain such other devices as Universal Asynchronous Receiver Transmitters (UARTs), Analog to Digital Converters (ADCs), Ethernet controller(s) and more.
This chapter assumes development on a Windows®-based platform and makes references to typical Windows-type directory structures (also called Folder). However, since µC/OS-III is provided in source form, it can also be used on Unix, Linux or other development platforms.
(1) The application code consists of project or product files. For convenience, these are simply called app.c and app.h, however an application can contain any number of files that do not have to be called app.*. The application code is typically where one would find the main().
(2) Semiconductor manufacturers often provide library functions in source form for accessing the peripherals on their CPU or MCU. These libraries are quite useful and often save valuable time. Since there is no naming convention for these files, *.c and *.h are assumed.
(3) The Board Support Package (BSP) code needed by µC/OS-III is typically quite simple and generally, µC/OS-III only requires that you initialize a periodic interrupt source which is used for time delays and timeouts. This functionality can should be placed in a file called os_bsp.c along with its corresponding header file, bsp_os.h.
(4) This is the µC/OS-III processor-independent code. This code is written in highly portable ANSI C.
(5) This is the µC/OS-III code that is adapted to a specific CPU architecture and is called a port. µC/OS-III has its roots in µC/OS-II and benefits from being able to use most of the 45 or so ports available for µC/OS-II. µC/OS-II ports, however, will require small changes to work with µC/OS-III.
(6) At Micriµm, we encapsulate CPU functionality. These files define functions to disable and enable interrupts, CPU_??? data types to be independent of the CPU and compiler used, and many more functions.
(7) µC/LIB is a series of source files that provide common functions such as memory copy, string, and ASCII-related functions. Some are occasionally used to replace stdlib functions provided by the compiler. The files are provided to ensure that they are fully portable from application to application and especially, from compiler to compiler. µC/OS-III does not use these files, but µC/CPU does.
(8) Optional module: Some compilers provide extensions for Thread-local Storage, which provide a variable area where threads can store their state to make a multi-threaded environment safer. The adaptation of those functions is performed in the os_tls.c file which is found under the uCOS-III\TLS\<tool> folder. Where <tool> is the name of the tool manufacturer or, the tool name.
(9) Optional module: µC/OS-III has built-in trace points throughout the code to record all the kernel events and interrupts in real-time using some of the most popular tracing analysis tools (e.g. Percepio's TraceAlyzer and SEGGER SystemView). These trace calls are disabled by default and can only be enabled at compile-time by setting the configuration constant OS_CFG_TRACE_EN to DEF_ENABLED in os_cfg.h. These trace functions are defined in multiple files found under the uCOS-III\Trace\<tool> folder. Where <tool> is the name of the trace tool.
(10) Configuration files are used to define µC/OS-III features (os_cfg.h) to include in the application, specify the size of certain variables and data structures expected by µC/OS-III (os_cfg_app.h), such as idle task stack size, tick rate, size of the message pool, configure the µC/CPU features available to the application programmer (cpu_cfg.h) and also configure µC/LIB options (lib_cfg.h).