MagicMnemonic.com
It's all in the mind.

Though DOS is very popular in the embedded world, it does have some major drawbacks. First is the famous memory barrier limiting DOS-based applications to just 640 kbytes in size. In addition, DOS doesn’t have built-in support for multitasking. And because it is a 16-bit operating system, DOS cannot use the latest 32-bit C++ development tools from Microsoft and Borland International Inc.

How can the embedded world get around the limitations of DOS? One possible solution is Windows NT. When Microsoft created Windows NT, it first designed the Win32 application programming interface, a definition of the system calls that programmers use to write applications. One of the design goals of the Win32 API is to make it easy to port existing 16-bit Windows applications to 32 bits. Microsoft maintained compatibility in the Win32 API by keeping most existing Windows system calls for writing user-interface code.

Microsoft’s second goal for the Win32 API is even more relevant to the real-time world: industrial-strength multitasking. The foundation of the Win32 API is found in the roughly 300 Kernel32 functions, which provide all the services one expects in a multitasking operating system. Among them are memory allocation, file access, process control, multitasking, synchronization and interprocess communications.

Win32 – so many new errors, so little time.

A Win32 application that uses only the Kernel32 functions but not the Windows GUI is called a console application. These applications-which include development tools, database engines and utilities-are more like character-based MS-DOS and Unix applications. When Windows NT is being used in a real-time operating system, the real-time software is typically built as a Win32 console application.

The major innovation in the Win32 API, in relation to real-time operating systems, is the inclusion of threads. While other OSes allow only multitasking to function between multiple applications, Win32 API-based threads allow programmers to do multitasking inside a single application. Though Windows NT was not the first OS to support threads, threads were integral to its design; they were not an afterthought.

The primary advantage of threads is that they have very little overhead. For example, during a context switch, only the CPU register set has to be changed. In addition, threads can communicate quickly and easily because they shared a single address space. In terms of CPU cycles, threads offer real-time operating systems the least expensive method of doing multitasking.

The Win32 API also supports processes, the more traditional approach to running multiple applications at once. Each Win32 process, which may contain one or more threads, gets its own private address space. Processes also have other private resources, such as open files, pipes and so on.

Threads are not just a concern of the operating system. They need to be supported by the entire development tool chain, including the compiler, linker, debugger and run-time libraries. For example, a multithreaded application requires a more sophisticated, “thread-aware” debugger. When a breakpoint occurs, looking at the CPU registers to see the inner workings of the application may not be sufficient. It may also be necessary to examine the CPU registers that belong to other threads in the application. In addition, thread-aware debuggers make it possible to set breakpoints for specific threads, and have commands that start and stop the execution of individual threads.

Important libraries

Thread-safe run-time libraries are also important. A thread-safe library regulates use of the library, avoiding collisions between different threads accessing shared data in the library. Without thread-safe run-time libraries, programmers would have to add code to their software manually in order to regulate access to run-time library functions. Besides being time-consuming, this process is error-prone.

Compilers also play a critical role in multithreaded applications. The two most widely used C++ compilers for Windows NT are Microsoft Visual C++ and Borland C++. Both of these compiler packages include a full complement of tools for writing 32-bit multithreaded applications under Windows NT.

While Windows NT is a popular choice for high-end embedded systems, it is not a general-purpose X86 real-time operating system. The problem is very simple: Windows NT comes in only one size-Extra Large. It is not scalable to run on a range of X86 hardware, but requires a Pentium-based PC with at least 16 Mbytes of RAM, a hard disk and CRT display. Windows NT cannot run on smaller systems and will not fit in ROM. Given that the entry-level costs for PC hardware is about $2,000, Windows NT is restricted for use in rather expensive embedded systems.

One solution to Windows NT’s size problems is to build a real-time kernel based on the Win32 standards. Win32 API-based kernels can use Windows compilers such as Visual C++ and Borland C++.

In addition, they can be designed from the ground up to meet the requirements of an embedded system.

For example, Win32 API-based kernels can be designed to be scalable and to fit into ROM, and can have a deterministic scheduler.

A number of Win32 API-based real-time kernels already exist. One of them, from Microsoft, is a specialized kernel for cable-TV digital set-top boxes. By using a Win32-based kernel, Microsoft engineers didn’t have to create new tools for writing interactive TV applications. They were able to use existing Windows NT development tools, such as Visual C++. In addition, following Win32 standards makes it easier to integrate set-top boxes with video servers running Windows NT.

Another real-time kernel based on the Win32 standards is Phar Lap’s ETS Kernel, a general-purpose real-time kernel.

Because the ETS Kernel uses a subset of the Kernel32 API, it is able to work with the Microsoft and Borland C++ compilers, debuggers and thread-safe run-time libraries. And with its small memory footprint, the ETS Kernel may be used in embedded-system designs for which Windows NT would be too big.

Windows NT can also provide a prototyping environment for embedded applications, allowing developers to use a common set of Win32-based tools for both host and target. Prototyped code can move from the Windows NT host to the Win32-based target simply by relinking.

Given the hardware/software infrastructure that has developed to support the X86 architecture in the desktop world, X86 has become the safe choice for embedded systems. With the introduction and acceptance of the Win32 API, the architecture now has the first widely supported 32-bit real-time software standard. Developers can be assured that the X86 architecture will be well-supported by hardware and software vendors for at least the next 10 to 15 years.


Tags: ,

Post Comment

Please notice: Comments are moderated by an Admin.


Namaless.com