9.06 Memory requirements

Table 9.1 shows the amount of memory (both code and data space) used by µC/OS-II based on the value of configuration constants. Data in this case means RAM and Code means ROM if µC/OS-II is used in an embedded system. The spreadsheet is actually provided on the companion diskette (\SOFTWARE\uCOS-II\Ix86L\DOC\ROM-RAM.XLS). You will need Microsoft Excel for Office 97 (or higher) to use this file. The spreadsheet allows you to do ‘what-if’scenarios based on the options you select.

Table 9.1, µC/OS-II memory requirements for 80186.

The number of bytes in the CODE column have been rounded up to the nearest 25 bytes. I used the Borland C/C++ compiler V3.1 and the options were set to generate the fastest code. The number of bytes shown are not meant to be accurate but are simp ly provided to give you a relative idea of how much code space each of the µC/OS -II group of services require. For example, if you don’t need message queue services (i.e. OS_Q_EN set to 0) then you will save about 1475 bytes of code space. In this case, µC/OS-II would only use up 6875 bytes of code space.

The DATA column is not as straightforward. You should notice that the stacks for both the idle task and the statistics task have been set to 1024 (i.e. 1K) each. Based on your own requirements, thesenumber may be higher or lower. As a minimum, µC/OS-II requires 35 bytes of RAM (µC/OS-II Internals) for internal data structures.

Table 9.2 shows how µC/OS-II can scale down the amount of memory required for smaller applications. In this case, I only allowed 16 tasks but with 64 priority levels (0 to 63). In this case, your application will not have access to:

-Message mailboxe services ( OS_MBOX_EN set to 0)

-Memory partition services (OS_MEM_EN set to 0)

-Changing task priorities (OS_TASK_CHANGE_PRIO_EN set to 0)

-The old task creation (OSTaskCreate()) function (OS_TASK_CREATE_EN set to 0)

-Deleting task (OS_TASK_DEL_EN set to 0)

-Suspending and Resuming tasks (OS_TASK_SUSPEND_EN set to 0)

Notice that the CODE space reduced by about 3K and the DATA spacereduced by over 2200 bytes! Most of the DATA savings come from the reduced number of OS_TCBs needed because only 16 tasks are available. For the 80x86 large model port, each OS_TCB eats up 45 bytes of RAM.

Table 9.2, A scaled down µC/OS-II configuration.

9.07 Execution times

Tables 9.3 and 9.4 show the execution time for most µC/OS-II functions. The values were obtained by having the compiler generate assembly language code for the 80186 processor with the C source interleaved as comments. The assembly code was then passed through the Microsoft MASM 6.11 assembler with the option set so that the number of cycles for each instruction gets included. I then added the number of instructions (theI column) and clock cycles (the C column) for the code to obtain three values: the maximum amount of time interrupts are disabled for the service, the minimum execution time of the service and its maximum. As you can immagine, this is a very tedious job but worth the effort. Giving you this information allows you to see the ‘cost’impact of each function in terms of execution time. Obviously, this information has very little use unless you are using a 80186 processor except for the fact that it gives you an idea of the relative cost for each function.

The number of clock cycles were divided by 33 (i.e. I assumed a 33 MHz clock) to obtain the execution time of the service in µS (i.e. the µS column). For the minimum and maximum times, I always assumed that the intended function of the service was performed succesfully. I further assumed that the processor was able to run at the full bus speed (i.e. without any wait states). On average, I determined that the 80186 requires 10 clock cycles per instruction!

For the 80186, maximum interrupt disable time is 33.3 µS (or 1100 clock cycles).

N/A means that the execution time for the function was not determined because I didn’t believe they were critical.

I provided the column listing the number of instructions because you can determine theexecution time of the functions for other x86 processors if you have an idea of the number of cycles per instruction. For example, you could assume that a 80486 executes (on average) an instruction every 2 clock cycle (5 times faster than a 80186). Also, if your 80486 was running at 66 MHz instead of 33 MHz (2 times faster) then you could take the execution times listed in the tables and divide them all by 10.

Table 9.3, Execution times of µC/OS-II services on 33 MHz 80186.

Table 9.4, Execution times of µC/OS-II services on 33 MHz 80186.

Below is a list of assumptions about how the minimum, maximum and interrupt disable times were determined and the conditions that lead to these values.

OSSchedUnlock():

Minimum assumes that OSLockNesting is decremented to 0 but there are no higher priority tasks returns to the caller.

to 0 but this time, a higher priority task is ready to run.

nothing else to do anyway! On average, though, you can assume that OSTickISR() would take about 500 µS (i.e. 5% overhead if your tick interrupts occurs every 10 mS).

OSMboxPend():

Minimum assumes that a message is available at the mailbox.

Maximum occurs when a message is not available so, the task will have to wait. In this case, a context switch occurs. The maximum time is as seen by the calling task. In other words, this is the time it takes to look at the mailbox, determine that there is no message, call the scheduler, context switch to the new task, context switch back from whatever task was running, determine that a timeout occured and returning to the caller.

OSMboxPost():

Minimum assumes that the mailbox is empty and that no task is waiting on the mailbox to contain a message. Maximum occurs when one or more tasks are waiting on the mailbox for a message. In this case, the message is given to the highest priority task waiting and a context switch is performed to resume that task. Again, the maximum time is as seen by the calling task. In other words, this is the time it takes to wake up the waiting task, pass it the message, call the scheduler, context switch to the task, context switch back from whatever task was running, determine that a timeout occured and returning to the caller.

OSMemGet():

Minimum assumes that a memo ry block is not available.

Maximum assumes that a memory block is available and is returned to the caller.

OSMemPut():

Minimum assumes that you are returning a memory block to an already full partition. Maximum assumes that your are returning the memory block to the partition.

OSQPend():

Minimum assumes that a message is available at the queue.

Maximum occurs when a message is not available so, the task will have to wait. In this case, a context switch occurs. The maximum time is as seen by the calling task. In other words, this is the time it takes to look at the queue, determine that there is no message, call the scheduler, context switch to the new task, context switch back from whatever task was running, determine that a timeout occured and returning to the caller.

OSQPost():

Minimum assumes that the queue is empty and that no task is waiting on the queue to contain a message. Maximum occurs when one or more tasks are waiting on the queue for a message. In this case, the message is given to the highest priority task waiting and a context switch is performed to resume that task. Again, the maximum time is as seen by the calling task. In other words, this is the time it takes to wake up the waiting task, pass it the message, call the scheduler, c ontext switch to the task, context switch back from whatever task was running, determine that a timeout occured and returning to the caller.

OSQPostFront():

This function performs virtually the same processing as OSQPost().

OSSemPend():

Minimum assumes that the semaphore is available (i.e. has a count higher than 0).

Maximum occurs when the semaphore is not available so, the task will have to wait. In this case, a context switch occurs. As usual, the maximum time is as seen by the calling task. This is the time it takes to look at the semaphore value, determine that it’s 0, call the scheduler, context switch to the new task, context switch back from whatever task was running, determine that a timeout occured and returning to the caller.

OSSemPost():

Minimum assumes that there are no tasks waiting on the semaphore.

Maximum occurs when one or more tasks are waiting for the semaphore. In this case, the highest priority task waiting is readied and a context switch is performed to resume that task. Again,the maximum time is as seen by the calling task. This is the time it takes to wake up the waiting task, call the scheduler, context switch to the task, context switch back from whatever task was running, determine that a timeout occured and returning to the caller.

OSTaskChangePrio():

Minimum assumes that you are changing the priority of a task that will not have a priority higher than the current task.

Maximum assumes that you are changing the priority of a task that will have a higher priority than thecurrent task. In thic case, a context switch will occur.

OSTaskCreate():

Minimum assumes that OSTaskCreate() will not create a higher priority task and thus no context

switch is involved.

Maximum assumes that OSTaskCreate() is creating a higher priority task and thus a context switch

will result.

In both cases, the execution times assumed that OSTaskCreateHook() didn’t do anything.

OSTaskCreateExt():

Minimum assumes that OSTaskCreateExt() will not need to initialize the stack with zeros in order

to do stack checking.

Maximum assumes that OSTaskCreateExt() will have to initialize the stack of the task. However,

the execution time greatly depends on the number of elements to initialize. I determined that it takes 100 clock cycles (3 µS) to clear each element. A 1000 byte stack would require: 1000 bytes divided by 2 bytes/element (16-bit wide stack) times 3 µS per element or, 1500 µS. Note that interrupts are enabled while the stack is being cleared to allow your application can respond to interrupts.

In both cases, the execution times assumed that OSTaskCreateHook() didn’t do anything.

OSTaskDel():

Minimum assumes that the task being deleted is not the current task.

Maximum assumes that the task being deleted is the current task. In this case, a context switch will occur.

OSTaskDelReq():

Both minimum and maximum assume that the call will return indication that the task is deleted. This function is so short that it doesn’t make much difference anyway.

OSTaskResume():

Minimum assumes that a task is being resumed but this task has a lower priority than the current task. In this case, a context switch will not occur.

Maximum assumes that the task being resumed will be ready -to-run and will have a higher priority than the current task. In this case, a context switch will occur.

OSTaskStkChk():

Minimum assumes that OSTaskStkChk() is checking a ‘full’stack. Obviously, this is hardly possible since the task being checked would most likely have crashed. However, this does establish the absolute

minimum exe cution time, however unlikely.

Maximum also assumes that OSTaskStkChk() is checking a ‘full’stack but you need to add the

amount of time it takes to check each ‘zero’stack element. I was able to determine that each element takes 80 clock cycles (2.4 µS) to check. A 1000 byte stack would thus require: 1000 bytes divided by 2 bytes/element (16-bit wide stack) times 2.4 µS per element or, 1200 µS. Total execution time would thus be 1218 µs. Note that interrupts are enabled while the stack is being checked.

OSTaskSuspend():

Minimum assumes that the task being suspended is not the current task.

Maximum assumes that the current task is being suspended and a context switch will occur.

OSTaskQuery():

Minimum and maximumare the same and it is assumed that all the options are included so that an OS_TCB contains all the fields. In this case, an OS_TCB for the large model port requires 45 bytes.

OSTimeDly():

Both the minimum and maximum assume that the time delay will be greater than 0 tick. In this case, acontext

switch always occur.

Minimum is the case where the bit in OSRdyGrp doesn’t need to be cleared.

OSTimeDlyHMSM():

Both the minimum and maximum assume that the time delay will be greater than 0. In this case, a context switch will occur. Furthermore, the time specified must result in a delay of less than 65536 ticks. In other words, if a tick interrupt occurs every 10 mS (100 Hz) then the maximum value that you can specify is 10 minutes, 55 seconds and 350 mS in order for the execution times shown to be valid. Obviously, you can specify longer delays using this function call.

OSTimeDlyResume():

Minimum assumes that the delayed task is made ready to run but, this task has a lower priority than the current task. In this case, µC/OS-II will not perform a context switch.

Maximum assumes that the delayed task is made ready to run and this task has a higher priority than the current task. This, of course, results in a context switch.

OSTimeTick():

This function is almost identical to OSTickISR() except that OSTickISR() accounted for OSIntEnter() and OSIntExit(). I assumed that your application can have the maximum

number of tasks allowed by µC/OS-II (64 tasks total).

Minimum assumes that none of the 64 tasks are either waiting for time to expire or for a timeout on an event. Maximum assumed that ALL 63 tasks (the idle task is never waiting) are waiting for time to expire. 600 µS may seem like a lot of time but, if you consider that all the tasks are waiting for time to expire then the CPU has nothing else to do anyway! On average, though, you can assume thatOSTimeTick() would take about 450 µS (i.e. 4.5% overhead if your tick interrupts occurs every 10 mS).

Table 9.5, Execution times sorted by interrupt disable time.

Table 9.6, Execution times sorted by maximum execution time.