30.12.2012 Views

30°C Power On 12 to 36 watts - for fanless sealed system design ...

30°C Power On 12 to 36 watts - for fanless sealed system design ...

30°C Power On 12 to 36 watts - for fanless sealed system design ...

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

ESE Magazine Jan/Feb 06 <br />

34<br />

Measuring real-time<br />

per<strong>for</strong>mance<br />

John Carbone, Express Logic <br />

Real-time per<strong>for</strong>mance is one of the most important criteria <strong>for</strong> selecting<br />

an RTOS. But, what is “real-time per<strong>for</strong>mance” and how is it measured?<br />

REAL-TIME PERFORMANCE can be<br />

defined as the speed with which an<br />

RTOS (or any software <strong>for</strong> that matter)<br />

can complete its functions in<br />

response <strong>to</strong> an event. The “real-time” aspect<br />

implies that the software response <strong>to</strong> one<br />

event is needed be<strong>for</strong>e some independently<br />

occurring second event takes place. For example,<br />

in response <strong>to</strong> an au<strong>to</strong>mobile engine’s<br />

intake valve opening, the engine control software<br />

must calculate the correct air-fuel mixture<br />

and have it injected in<strong>to</strong> the cylinder<br />

RTOS Functions Measured<br />

be<strong>for</strong>e the valve closes in preparation <strong>for</strong> the<br />

compression stroke. It is critical that the<br />

response <strong>to</strong> the first event is completed in time<br />

<strong>to</strong> meet the needs of the second event. This<br />

response may include many things, but paramount<br />

among them are interrupt processing<br />

and <strong>system</strong> services.<br />

Interrupt processing<br />

Real-time <strong>system</strong>s are generally <strong>design</strong>ed <strong>to</strong> be<br />

reactive in nature, and the events <strong>to</strong> which they<br />

must react are generally made known <strong>to</strong> the<br />

Context Switch (CS): Time required <strong>to</strong> save current thread’s context, find highest priority ready<br />

thread, and res<strong>to</strong>re its context.<br />

Interrupt Latency Range (ILR): Amount of time interrupts are disabled.<br />

RTOS System Services<br />

● tx_thread_suspend – Suspend an application theread.<br />

● tx_thread_resume – Resume a previously suspended thread.<br />

● tx_thread_relinquish – Relinquish control <strong>to</strong> other application threads.<br />

● tx_queue_send – Send a message <strong>to</strong> a message queue.<br />

● tx_queue_receive – Get a message from a message queue.<br />

● tx_semaphore_get – Get an instance from a counting semaphore.<br />

● tx_semaphore_put – Place an instance in a counting semaphore.<br />

● x_mutex_get – Obtain ownership of a mutex.<br />

● tx_mutex_put – Release ownership of a mutex.<br />

● tx_event_flags_set – Set or clear event flags.<br />

● tx_event_flags_get – Retrieve event flags.<br />

● tx_block_allocate – Allocate a memory block.<br />

● tx_block_release – Release a memory block.<br />

● tx_byte_allocate – Allocates bytes of memory.<br />

● tx_byte_release – Release a previously allocated memory area.<br />

For each <strong>system</strong> service, the following are measured:<br />

● Immediate Response (IR): Time required <strong>to</strong> process the request immediately, i.e., no thread<br />

suspension or thread resumption.<br />

● Thread Suspend (TS): Time required <strong>to</strong> process the request when the calling thread is suspended<br />

due <strong>to</strong> unavailability of the resource.<br />

● Thread Resumed (TR): Time required <strong>to</strong> process the request when a previously suspended<br />

thread (of the same or lower priority) is resumed as a result of the request.<br />

● Thread Resumed and Context Switched (TRCS): Time required <strong>to</strong> process the request<br />

when a previously suspended higher-priority thread is resumed as a result of the request.<br />

Since the resumed thread is higher-priority, a context switch <strong>to</strong> the resumed thread is also per<strong>for</strong>med<br />

from within the request.<br />

<strong>system</strong> as interrupts. The processor, upon recognizing<br />

an interrupt, per<strong>for</strong>ms certain actions<br />

and executes instructions that were <strong>design</strong>ed <strong>to</strong><br />

react <strong>to</strong> this event. In most cases, the processor<br />

is already per<strong>for</strong>ming some instructions immediately<br />

prior <strong>to</strong> recognizing the interrupt. This<br />

processing must be “interrupted,” and then<br />

later resumed when the critical real-time<br />

response of the interrupt has been completed.<br />

Most RTOSes are <strong>design</strong>ed <strong>to</strong> provide a means<br />

<strong>for</strong> the developer <strong>to</strong> handle interrupt processing<br />

and also <strong>to</strong> schedule and manage execution of<br />

application software threads. Interrupt processing<br />

generally includes the following:<br />

● suspending whatever thread currently is<br />

executing,<br />

● saving thread-related data that will be<br />

needed when the thread is resumed,<br />

● transferring control <strong>to</strong> an interrupt service<br />

routine (ISR),<br />

● per<strong>for</strong>ming some amount of processing in<br />

the ISR <strong>to</strong> determine exactly what action is<br />

needed,<br />

● retrieving/saving any critical (incoming)<br />

data associated with the interrupt,<br />

● setting any required device-specific (output)<br />

values,<br />

● determining which thread should now execute<br />

given the change in environment created<br />

by the interrupt and its processing,<br />

● clearing the interrupt hardware <strong>to</strong> allow<br />

the next interrupt <strong>to</strong> be recognized,<br />

● transferring control <strong>to</strong> the selected thread,<br />

including retrieval of any of its environment<br />

data that was saved when it was last interrupted.<br />

Whew! All of that (and perhaps more, depending<br />

on the RTOS) is included in “interrupt processing,”<br />

which is only one aspect of real-time<br />

per<strong>for</strong>mance. It’s no wonder that implementation<br />

of these operations in a particular RTOS<br />

can make a significant difference in real-time<br />

per<strong>for</strong>mance.<br />

System services<br />

Real-time operating <strong>system</strong>s must do more<br />

than simply respond <strong>to</strong> interrupts. They also<br />

must schedule and manage the execution of<br />

application software threads and handle

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!