CoOS Real Time Kernel (CooCox.org) – Part 2

As I noted in my previous posting, CoOS was initially intended for ARM Cortex M3 and M0 architecture. With a bit of work CoOS can be ported on the popular ARM7 as well. The authors assume that the development is done using the following tool chains: Keil, IAR and GCC. The CooCox CoBuilder is an internet-based component-oriented embedded development platform that is based on GCC. It is somewhat similar with LPCXpresso which is an Eclipse-based IDE, a GNU C compiler, linker, libraries, and a GDB debugger all hosted online with the exception of the front-end client that requires local installation. The same thing applies to CoBuilder.

Personally, I appreciate more the offline tools because I’m a control freak and because of the speed and comfort of my own setup but I must admit that having access to your projects online is an attractive option, especially for people on the go; plus the peace of mind that your project is hosted on a server in a data center where reliability and safety should be the norm.

The code style is clean without being pedantic. Personally, I would use a more strict naming convention but, without doubt, CoOS code uses meaningful names for functions, variables and constants that makes the code readable. I would also argue for a longer source line — with the wide screen monitors available today a 100…120 character line size would make a lot of sense.

Comments are formatted for Doxygen (a documentation system for C++, C, Java, etc. that extracts the information from commented source files).

Each module (i.e. source file) begins with a comment block clearly stating the version number, name, date, description:

/**
 *******************************************************************************
 * @file       core.c
 * @version    V1.12
 * @date       2010.03.01
 * @brief      Core implementation code of CooCox CoOS kernel.
 *******************************************************************************
 * @copy
 *
 * INTERNAL FILE,DON'T PUBLIC.
 *
 * <h2><center>&copy; COPYRIGHT 2009 CooCox </center></h2>
 *******************************************************************************
 */

Each function is preceded by its own comment block describing the purpose, input and output parameters, return value and notes:

/**
 *******************************************************************************
 * @brief      Enter a ISR.
 * @param[in]  None
 * @param[out] None
 * @retval     None
 *
 * @par Description
 * @details    This function is called to notify OS when enter to an ISR.
 *
 * @note       When you call API in ISR,you must call CoEnterISR() before your
 *             interrupt handler code,and call CoExitISR() after your handler
 *             code and before exiting from ISR.
 *******************************************************************************
 */
void CoEnterISR (void)
{
    . . . . .
}

I like the trailing comments used almost everywhere in the code — they bring clarity separating the code from the story. However, the short line length (~80 characters) makes this task difficult: one more reason for a long line.

void CoStartOS (void)
{
    TCBRunning  = &TCBTbl[0];          /* Get running task                        */
    TCBNext     = TCBRunning;          /* Set next scheduled task as running task */
    TCBRunning->state = TASK_RUNNING;  /* Set running task status to RUNNING      */
    RemoveFromTCBRdyList(TCBRunning);  /* Remove running task from READY list     */
    OsSchedUnlock();                   /* Enable Schedule, call task schedule     */
}

The code uses portable data types, a good practice to achieve portability but a bit more difficult when it comes to reconcile them with your own type definitions. However, many embedded software developers agree that portable data types are a necessity in order to avoid hard to find problems when the code is moved from one CPU to another (especially if they differ in word size). Here is an example of portable data types used in CoOS.

typedef signed char        S8;
typedef unsigned char      U8;
typedef short              S16;
typedef unsigned short     U16;
typedef int                S32;
typedef unsigned int       U32;
typedef long long          S64;
typedef unsigned long long U64;
typedef unsigned char      BOOL;

I used similar definitions for years (e.g. UINT8, UINT16, UINT32, BOOLEAN, etc.). As one can see they are similar, except the names. For compatibility with my own code I use either macros or derived types to reconcile the two definition sets. For example:

typedef SINT8              S8;
typedef UINT8              U8;
typedef SINT16             S16;
typedef UINT16             U16;
typedef SINT32             S32;
typedef UINT32             U32;
typedef SINT64             S64;
typedef UINT64             U64;
#define BOOL               bool  // available with a C99 compiler

I will end here my comments regarding style. The next postings will reflect my struggles to put this RTOS to work. So, don’t expect any particular order.