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

More documents

Recommendations

Info

ESE Magazine Jan/Feb 06 34 Measuring real-time performance John Carbone, Express Logic Real-time performance is one of the most important criteria for selecting an RTOS. But, what is “real-time performance” and how is it measured? REAL-TIME PERFORMANCE can be defined as the speed with which an RTOS (or any software for that matter) can complete its functions in response to an event. The “real-time” aspect implies that the software response to one event is needed before some independently occurring second event takes place. For example, in response to an automobile engine’s intake valve opening, the engine control software must calculate the correct air-fuel mixture and have it injected into the cylinder RTOS Functions Measured before the valve closes in preparation for the compression stroke. It is critical that the response to the first event is completed in time to meet the needs of the second event. This response may include many things, but paramount among them are interrupt processing and system services. Interrupt processing Real-time systems are generally designed to be reactive in nature, and the events to which they must react are generally made known to the Context Switch (CS): Time required to save current thread’s context, find highest priority ready thread, and restore its context. Interrupt Latency Range (ILR): Amount of time interrupts are disabled. RTOS System Services ● tx_thread_suspend – Suspend an application theread. ● tx_thread_resume – Resume a previously suspended thread. ● tx_thread_relinquish – Relinquish control to other application threads. ● tx_queue_send – Send a message to a message queue. ● tx_queue_receive – Get a message from a message queue. ● tx_semaphore_get – Get an instance from a counting semaphore. ● tx_semaphore_put – Place an instance in a counting semaphore. ● x_mutex_get – Obtain ownership of a mutex. ● tx_mutex_put – Release ownership of a mutex. ● tx_event_flags_set – Set or clear event flags. ● tx_event_flags_get – Retrieve event flags. ● tx_block_allocate – Allocate a memory block. ● tx_block_release – Release a memory block. ● tx_byte_allocate – Allocates bytes of memory. ● tx_byte_release – Release a previously allocated memory area. For each system service, the following are measured: ● Immediate Response (IR): Time required to process the request immediately, i.e., no thread suspension or thread resumption. ● Thread Suspend (TS): Time required to process the request when the calling thread is suspended due to unavailability of the resource. ● Thread Resumed (TR): Time required to process the request when a previously suspended thread (of the same or lower priority) is resumed as a result of the request. ● Thread Resumed and Context Switched (TRCS): Time required to process the request when a previously suspended higher-priority thread is resumed as a result of the request. Since the resumed thread is higher-priority, a context switch to the resumed thread is also performed from within the request. system as interrupts. The processor, upon recognizing an interrupt, performs certain actions and executes instructions that were designed to react to this event. In most cases, the processor is already performing some instructions immediately prior to recognizing the interrupt. This processing must be “interrupted,” and then later resumed when the critical real-time response of the interrupt has been completed. Most RTOSes are designed to provide a means for the developer to handle interrupt processing and also to schedule and manage execution of application software threads. Interrupt processing generally includes the following: ● suspending whatever thread currently is executing, ● saving thread-related data that will be needed when the thread is resumed, ● transferring control to an interrupt service routine (ISR), ● performing some amount of processing in the ISR to determine exactly what action is needed, ● retrieving/saving any critical (incoming) data associated with the interrupt, ● setting any required device-specific (output) values, ● determining which thread should now execute given the change in environment created by the interrupt and its processing, ● clearing the interrupt hardware to allow the next interrupt to be recognized, ● transferring control to the selected thread, including retrieval of any of its environment data that was saved when it was last interrupted. Whew! All of that (and perhaps more, depending on the RTOS) is included in “interrupt processing,” which is only one aspect of real-time performance. It’s no wonder that implementation of these operations in a particular RTOS can make a significant difference in real-time performance. System services Real-time operating systems must do more than simply respond to interrupts. They also must schedule and manage the execution of application software threads and handle
equests from threads to perform scheduling, message passing, resource allocation, and many other services. In most instances, services must be performed quickly, so the thread can complete its assigned processing before the occurrence of the next interrupt. While not a part of interrupt processing, the system service is a critical real-time response that can make or break a system, and includes: ● scheduling a task or thread to run upon the occurrence of some future event, ● passing a message from one thread to another, ● claiming a resource from a common pool, Even more variable than interrupt processing, the implementation of system services is equally critical in achieving good real-time performance in an RTOS. Together with interrupt processing, system services combine to form the most significant processing that an RTOS is asked to perform. Different implementations will approach these functions differently, with different architectures to produce a wide range of performance. Why is performance so critical? The time required for completion of these functions is particularly critical in real-time systems, which must be deterministic, and also must respond rapidly or suffer loss of data or even fundamental malfunction of the system. An example might be a flight-control system that must respond to a pilot input in time to avoid a stall, or a disk-drive controller that must stop the drive’s read head at precisely the point at which data is to be read or written. Rapid-fire interrupts from high-speed data packet arrival into a DSL router also must be handled promptly to avoid triggering a retry because one was missed. Processor speed is critical in executing all of the RTOS instructions required to perform the desired function, but brute force alone cannot satisfy system demands, nor can it provide the most economical or efficient solution. A 2GHz processor might breeze through code in satisfactory time, but it could be too costly, draw too much power, or present physical packaging challenges. A more economical processor, running an efficient RTOS, might do just as well in performance, or even better, yet cost far less and not pose power/heat/packaging problems. Focusing on the most significant elements allows real-time performance to be measured in a rigorous fashion. Comparing how well multiple RTOSes on a common hardware platform perform specific critical functions (see table 1) lets developers quantify real-time performance and make the best decision for their application. www.expresslogic.com Table 1: Example timings �� Reference platform: ARM9 processor, 40MHz. RTOS: ThreadX Times generally scale linearly with clock rate for most 32-bit processors System Service IR TS TR TRCS tx_thread_suspend 2.8µS 4.2µS tx_thread_resume 2.6µS 5.3µS tx_thread_relinquish 1.2µS 3.4µS tx_queue_send 2.1µS 5.1µS 4.3µS 6.8µS tx_queue_receive 1.7µS 4.9µS 4.8µS 7.6µS tx_semaphore_get 0.8µS 4.8µS tx_semaphore_put 0.9µS 3.2µS 5.8µS tx_mutex_get 1.1µS 5.3µS tx_mutex_put 2.4µS 4.4µS 7.0µS tx_event_flags_set 1.4µS 4.1µS 6.7µS tx_event_flags_get 1.2µS 5.2µS tx_block_allocate 1.0µS 4.9µS tx_block_release 1.0µS 3.4µS 6.0µS tx_byte_allocate 3.3µS 6.2µS tx_byte_release 1.9µS 6.9µS 9.5µS Context Switch 1.9µS Interrupt Latency 0µS – 1.8µS �� 35
Page 3 and 4: Editorial Editor: Dick Selwood E-ma
Page 5 and 6: High-performance analog. Supercharg
Page 7 and 8: “The QNX Neutrino microkernel OS
Page 9 and 10: AEC-6810 Perfect Factory/Building A
Page 11 and 12: obust signal analysis. The mixed-si
Page 13 and 14: ��
Page 15 and 16: See us at Embedded World 2006 Nurem
Page 18 and 19: ESE Magazine Jan/Feb 06 18 MOST -
Page 20: ESE Magazine Jan/Feb 06 20 Benchma
Page 23 and 24: Some things have to go out on time
Page 25 and 26: ��
Page 27 and 28: ��
Page 29: datacom telecom wireless devices au
Page 33: Come learn how Microsoft embedded o
Page 37 and 38: Embedded PCs Fieldbus Packaged PCs
Page 39 and 40: Copyright © 2006 Kontron AG. All r
Page 41 and 42: • Q u a l i t y a n d r e l i a b
Page 43 and 44: NO SLOWING DOWN. EVER. The market w
Page 45 and 46: Why use an RTOS? Tomoyuki Uda, Man
Page 48: ESE Magazine Jan/Feb 06 48 Flash s

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

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

Delete template?

Save as template?