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

More documents

Recommendations

Info

ESE Magazine Jan/Feb 06 36 Minimizing interrupt response time: 4 simple rules David Kleidermacher, Green Hills Software, Inc. A failure to meet a response time requirement in a real-time system can be catastrophic. Sound programming coupled with proper RTOS interrupt architecture can ensure a minimal yet guaranteed worst case response time. 1. Keep interrupt service routines (ISRs) short Avoid loops and other constructs which increase latency. When an interrupt fires, the microprocessor typically disables interrupts before executing the ISR. By keeping ISRs simple, developers avoid the common pitfall of leaving interrupts disabled for too long, increasing the latency of higher priority interrupts. 2. Do not disable interrupts A major contributor to increased latency is the number and length of regions in which the operating system disables interrupts. By disabling interrupts, the kernel increases latency of high priority events that arrive in those disabling windows. Most operating systems employ what we call a Simple architecture, which is easy to implement: in order to prevent preemption, the kernel disables interrupts for the duration of the critical section By disabling interrupts, the Simple RTOS is sacrificing the latency of the highest priority event to avoid problems caused by handling of lower priority interrupts. A better solution, implemented in the Advanced architecture, is to never disable interrupts in kernel service calls. Not only does the Advanced RTOS guarantee the minimum possible latency for the highest priority interrupt, but also the worst case latency can be trivially proven. 3. Avoid improper use of operating system API calls in ISRs ISRs commonly do not require kernel API access: the ISR performs basic operations before acknowledging the interrupt and returning. A more complex ISR is required to wake up a thread, such as by releasing a semaphore, for higher level processing. The RTOS vendor should limit ISRs to a small set of service calls that are necessary and deterministic. As an example of the peril regarding API usage in ISRs, consider a queue of threads waiting for a resource (e.g. a semaphore). Many Simple RTOSes use an ordinary linked list to hold the queue of threads. When the resource becomes available, the first thread, regardless of its importance relative to other waiters, is provided the resource. In contrast, the Advanced RTOS automatically wakes up the highest priority waiting thread. Some Simple RTOSes have a service call that pulls the highest priority thread out of the queue and jams it onto the front. One problem with this approach is its usability: the developer must remember to insert prioritisation calls and determine where in the code they belong. Worse, the RTOS must search linearly through the unordered list to find the highest priority thread; real-time behaviour is lost. The Advanced architecture provides a second-level handler, sometimes termed a callback, to perform higher level processing when the kernel has returned to a consistent state. If the developer must add a callback in the ISR and then write code in the callback to do the service call, this makes programming more difficult. Not to worry: the Advanced RTOS hides the details of two-level handling by allowing the use of a standard API call which places the callback on behalf of the programmer. There are some important advantages to the Advanced architecture’s optional two-level handler. By pushing work into the callback (where interrupts are enabled), the Advanced RTOS reduces the temporal footprint of the ISR, in turn reducing the latency for higher priority interrupts (Figure 1). Note that the overhead of the twolevel handling is negligible: a callback entails merely placing a function address on a list for the kernel to call; no heavyweight processing or memory is required. 4. Properly prioritise interrupts relative to threads When a thread is awakened for higher level processing of the most important event, this thread becomes the most important thread in the system. The thread must complete its processing within a fixed period of time. In the Simple RTOS, the thread runs with all interrupts enabled. Any low priority interrupt can fire, delaying the most important thread and Figure 1: Reducing latency for higher priority interrupts. Figure 2: Minimum response time for events. causing missed deadlines. In fact, since interrupts may nest, multiple events, and all of their associated ISR processing, could delay this high priority processing by an unpredictable length of time. The Advanced RTOS allows interrupts to be prioritised relative to threads. When a high priority thread is awakened during interrupt processing, the kernel inhibits lower priority interrupts when switching to the high priority thread. When the high priority thread completes its work, the kernel reenables lower priority interrupts. This architecture guarantees the minimum thread response time for the highest priority real-time events (Figure 2). Complex embedded systems, with multiple concurrent tasks and interrupt sources, pose a challenge for RTOS interrupt handling architecture. Developers will achieve the best interrupt response time by following a few simple rules and employing an RTOS with an Advanced interrupt architecture. www.ghs.com
Embedded PCs Fieldbus Packaged PCs LCD Displays Flash Storage Touchscreens Fanless Pentium M PC Systems Microspace PC range Pentium M and Celeron M Processor 1.4G/600MHz Passive cooling no fan Aluminium case IP50 -40 to 70 deg C Low power consumption 8 to 30V DC Vehicle approved CE and E1 100/10 Base-T LAN, miniPCI WLAN, Digital I/O 6 USB 2.0, Audio 3 parallel displays Fieldbus option BT878 Framegrabber DVD-R/CD-RW option CF & preheat HDD GPS and GSM option GSM Sleep/Wake 4 COM option PC/104 expansion PC/104+ expansion from £770 net 600MHz 256RAM 40GB HDD Miles Industrial Electronics Ltd Phone: +44 (0)1604 771122 Buy Online www.milesie.co.uk Designed to provide a fully customised embedded solution with minimal engineering and adaptation costs, the new GX2 ETX is a complete processor core which will enable a custom product to be developed and brought to market quickly and easily. Geode GX533 processor ETX 400 MHz 512MB DDR RAM embeddedpcdesign Compliant. Brilliant! +44 (0) 1462 675530 design@dsl-ltd.co.uk www.embeddedpcdesign.com
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 and 34: Come learn how Microsoft embedded o
Page 35: equests from threads to perform sch
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?