Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
EE Times-Asia > Embedded

Designing medical devices with real-time kernel

Posted: 28 Sep 2011 ?? ?Print Version ?Bookmark and Share

Keywords:medical device? real-time kernel? interrupt service routines?

Developing an embedded system for use in a medical device can be an especially challenging task. Developers in the medical field, like their counterparts elsewhere, must deal with tight schedules, stingy budgets, and lengthy requirement lists. However, developers of medical devices also must overcome a variety of industry-specific obstacles, many relating to the myriad rules and regulations that govern such devices.

As a result of the medical field's regulatory environment, developers in this field tend to avoid many practices that are common amongst developers of non-medical products. One such practice is the use of a real-time kernel. In the eyes of a large number of embedded systems developers, a kernel is a relatively low-risk means of writing powerful, multitask applications. To a developer focused on the strictures of the medical realm, however, a kernel means little more than additional code and additional cost.

Unquestionably, medical products represent a unique case for kernel use. The additional risks faced by developers of medical devices who wish to use a kernel mostly involve the medical field's regulatory environment, however. Kernel behavior is essentially the same in devices of all sorts.

The basics
One way to view a real-time kernel is as a framework for developing multitask applications. When such a framework is unavailable, developers typically write their application code around a single infinite loop. A pseudocode example of this sort of loop is provided in figure 1.

Figure 1: A simple approach to application design is to use an infinite loop.

Since it consists of functions that are called in a fixed sequence, a loop, by itself, is not suitable for applications requiring quick responses to events. If, for example, USB data were received immediately after the example loop's call to USB_Packet(), the data would not be processed until the subsequent call to that function. In other words, there would be a delay nearly as long as the execution time of the entire loop. To avoid this type of delay, developers augment their loops with interrupt service routines (ISRs).

Applications that incorporate a loop along with ISRs are typically referred to as foreground/background systems. The ISRs (or the foreground) execute whenever hardware needs urgent attention, and the loop (or the background) fills in the gaps. Foreground/background systems are used in a wide range of products, including medical devices, and there are plenty of developers who never take any other approach to writing application code.

Despite this popularity, the foreground/background model is not without its problems. Many of these problems become apparent when the need to expand an application arises. The example loop shown in figure 1 might initially meet all of its developers' needs; however, the expansion of this loop by just one function call, as shown in figure 2, could be problematic. If the newly added function, Ethernet_Packet(), were lengthy, it might prevent other functions in the loop from being invoked at a suitable frequency. The SPI function, SPI_Read(), for example, might fail to read data at an appropriate rate following the expansion.

Figure 2: Expansion of a foreground/background system can be difficult.

Most developers' reaction in this situation would be to move SPI_Read(), and any other functions no longer able to meet their deadlines, to the foreground. However, a cluttered foreground can present just as many problems as a bloated background. On some microcontrollers, the execution of an ISR prevents not only background code from running, but also the code of other ISRs. Even on microcontrollers that support nested interrupts, at least a portion of the system's interrupts are typically disabled while an ISR is running. Although a prioritized interrupt controller can provide some assistance for developers who have a large number of ISRs, code written around such controllers is often not portable or easy to maintain.

Figure 3: Kernel-based applications are made of tasks.

A real-time kernel offers remedies to many of the problems that can plague a growing foreground/background system. At the foundation of any kernel-based application are tasks, two examples of which are shown in figure 3. Unlike the different functions called by a foreground/background system's loop, the tasks in a kernel-based application do not execute in a fixed sequence. Each task is assigned an importance, or priority, by its developer, and the kernel uses this priority to determine when the task should run.

The loop is not the only aspect of a foreground/background system for which a kernel offers improvements; kernels also provide more flexibility with respect to handling interrupts. In a kernel-based application, interrupts are tied to scheduling. Accordingly, an application developer who uses a kernel can write ISRs that make tasks run.

1???2?Next Page?Last Page

Article Comments - Designing medical devices with real-...
*? You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.

Back to Top