Win32 A Suitable Standard for Real-Time Embedded Systems by bzs12927

VIEWS: 11 PAGES: 5

									                                                                                                             By Peter Petersen,
                                                                                                            General Manager,
     WIN32                                                                                                      Tom Schotland,
                                                                                                           President US Office,
                                                                                                     On Time Informatik GmbH.




               Win32: A Suitable Standard for
               Real-Time Embedded Systems?
        Using Windows NT or Windows 95 for real-time systems is a big temptation. This subject has been dis-
        cussed in many recent articles and several products have been released which claim to support real-
        time processing under these systems. An interesting alternative to using these rather complex operating
        systems designed for desktop applications are dedicated embedded systems development tools which
        create a Win32 compatible environment on the target without the overhead and the real-time deficien-
        cies of NT or 95.


        WHY TO USE AND NOT TO USE                                   Another important issue for embedded systems is real-
        WINDOWS NT                                                  time. Windows was designed for home and office
                                                                    applications, which (apart from a few exceptions such
                here are many arguments for using Windows

        T       NT or Windows 95 for embedded systems.
                Through their large installed base, mass pro-
        duction has lead to constantly decreasing prices for
                                                                    as games or multimedia applications) have no or only
                                                                    weak real-time requirements. At first sight, the ability to
                                                                    assign real-time priorities to a process could mislead
                                                                    developers to believe that 95 and NT support real-time
        both PC hardware and software. Both systems support
                                                                    processing. However, this is not true. Windows dynam-
        true 32-bit flat address programs, allowing full utiliza-
                                                                    ically changes priorities at run-time to achieve more
        tion of current 32-bit CPUs. Software development
                                                                    just CPU-time distribution. Win32's priority scheme is
        tools such as compilers, linkers, debuggers, etc. are
                                                                    also subject to priority inversion (for both application
        readily available and have been tested by countless
                                                                    threads and Deferred Procedure Calls of device driver
        developers. CPU vendors have recognized the market
                                                                    interrupt service routines). In addition, not preemptable
        trend and now offer a range of 32 bit Intel i80386 com-
                                                                    system calls can use a non-deterministic amount of
        patible microcontrollers like the Intel 386EX, National
                                                                    time. The internal timer resolution is fixed at 10ms,
        Semiconductor NS486SXF, or the AMD Elan series.
                                                                    which is too coarse for many systems. Moreover,
        However, there are also a few problems. First of all, NT    Windows does not guarantee timer callbacks to be
        and 95 need a lot of computer resources. Windows 95         serviced within a maximum delay.
        needs at least 16MB to run smoothly; Windows NT
        requires 32MB to perform well (that's not even count-       Application speed is also an issue. The management
        ing the application's needs). Both systems need             of virtual memory and system services (demon
        100MB to 150MB of hard disk space. For small sys-           processes to implement various operating system fea-
        tems to be built in large quantities, the extra hardware    tures) can „steal" CPU time from a time-critical appli-
        cost may be prohibitive.                                    cation. Also, NT's and 95's multitasking is not as effi-
                                                                    cient as in dedicated real-time systems. For example, a




                     Figure 1. The benchmark performs 400.000 semaphore operations with 200.000 task switches.
                                               Times are given for a Pentium 120Mhz.


64      Real-Time Magazine 98-3
                                                                                                     WIN32

simple semaphore benchmark performed under                    THE BEST OF BOTH WORLDS: A
Windows NT, Windows 95, and a real-time OS yields             WIN32 COMPATIBLE REAL-TIME
the following results as stated in figure 1.
                                                              SYSTEM
Last but not least, licensing costs are also a crucial fac-
                                                              Since Windows NT and Windows 95 were not
tor for embedded systems development. The cost of a
                                                              designed (and are consequently unsuitable) for
Windows license for each manufactured device can
                                                              embedded systems, why not use a system designed
be significant.
                                                              for such environments with a Win32 compatible API?
REAL-TIME ADD-ONS FOR NT: A                                   This approach combines the advantages of Windows
                                                              NT with those of real-time systems. Moreover, being
SOLUTION?                                                     Win32 compatible does not compromise any of the
Several products recently introduced claim to add real-       features one would expect from an embedded sys-
time capabilities to Windows NT. Different approaches         tems OS.
are being used:
                                                              Here are some requirements such a system should
• Use Proprietory Hardware to Reduce NT's Interrupt           meet:
   Latency
                                                              • Win32 compatible API
   Special ISA or PCI cards can be used to map nor-
                                                              • real-time extensions to the Win32 API
   mal interrupts to the PC's non-maskable interrupt to
   reduce interrupt latencies caused by NT device dri-        • support for mainstream Win32 development tools
   vers. The problem with this approach is that the           • support for standard run-time systems
   real-time application has to run within a device dri-
   ver, making access to and from regular applications        • scalability
   difficult. Software development requires a thorough        • access to the computer hardware at the application
   knowledge of NT's device drivers. Device drivers run         level
   at the CPU's highest privilege level without protec-       • Of course, some general, not Win32-specific fea-
   tion for the NT kernel or system data structures. A          tures needed in many embedded systems should
   simple bug can overwrite system memory and                   also be provided:
   crash NT.
                                                                 • low interrupt latencies
• Replace NT's HAL (Hardware Abstraction Layer)
                                                                 • memory protection
   This approach attempts to fix problems below NT's
   kernel by, for example, providing a high timer inter-         • deterministic real-time scheduling
   rupt frequency. However, the fundamental real-time            • low resource requirements
   deficiencies of the NT kernel itself cannot be fixed.
                                                                 • ROMability
   A modified HAL can improve the soft real-time
   behavior of NT, but cannot guarantee to meet hard             • ease of use and powerful debugging capabili-
   real-time requirements for application threads.                 ties
• Run NT as a Task under another Real-Time System                • low or no run-time royalties
   The idea is to run NT as a single task of a true real-
   time OS. While such a system can yield determinis-         EXAMPLE: RTTARGET-32 AND
   tic time behavior, real-time tasks run completely iso-     RTKERNEL-32 FROM ON TIME
   lated from the Windows world, requiring complex            RTTarget-32 is an example of an embedded systems
   communications mechanisms. Software develop-               cross development system implementing the require-
   ment can also be difficult and will require good           ments listed above. It can run Win32 console mode
   knowledge of both the real-time OS and Windows             applications (programs using printf() style input/output)
   NT. This approach usually requires the use of Intel's      on any system (PC compatible or not) with a 386 or
   hardware task switching, which is slow and increas-
                                                              higher CPU. RTTarget-32's Win32 compatibility is com-
   es interrupt latencies (but yields deterministic upper
                                                              plete enough to fully support the complex run-time
   bounds).
                                                              systems of current Win32 C++ compilers. This includes
Each of the approaches described above has its prob-          the latest C++ language features such as exception
lems. The high resource demands of NT remain (or are          handling global and local object construction/destruc-
even increased). The performance achieved is either           tion, name spaces, RTTI, etc. It also supports many
only soft real-time or impeded by general performance         Win32-specific advanced features such as uncommit-
bottlenecks. All solutions I know of carry additional roy-    ted memory, structured exception handling, thread vari-
alties, increasing the operating system licensing costs.      ables, DLLs, etc. Nonetheless, its scalability allows
Products which need to be deeply integrated into the          booting and running a complete 32 bit application in
NT kernel (for example, at the HAL level) will always lag     as little as 16k of memory. The real-time kernel
behind the latest operating system version. Also, they        RTKernel-32 extends RTTarget-32's Win32 API support
will never be tested by such a wide user base as the          with multithread functions to create and manage
desktop version of NT, so it is questionable whether          threads, semaphores, critical sections, etc.
they will have the same degree of compatibility and
                                                              RTTarget-32 does not intrude into the compiler's devel-
stability.
                                                              opment cycle. The compiler with its linker and run-time
                                                              system libraries are used exactly in the same way as


                                                                                         Real-Time Magazine 98-3          65
     WIN32




                   Figure 2. Creating a binary program image file with standard 32-bit compilers and RTTarget-32
     for native Win32 development. Both the compiler's             tion. RAM remapping can be used to combine frag-
     command line tools and IDE can be used. A library is          mented memory regions to larger consecutive regions
     supplied to make RTTarget-32's extended (non-Win32)           (e.g., conventional and extended memory on PC com-
     API available to the application. RTTarget-32's locator       patible systems), or consecutive virtual regions con-
     processes a standard Win32 .EXE file and a configu-           sisting of a combination of RAM and ROM can be cre-
     ration file. The various components of the .EXE are then      ated. Uncommitted memory is an important concept of
     located (and possibly separated into RAM and ROM              Windows NT's memory management. It allows an
     areas). The locator also includes boot code and any           application to differentiate between reserving and
     required DLLs into the program image and generates            actually using (committing) address space. Most
     a single application image file which can be burned           C/C++ run-time systems rely heavily on uncommitted
     into an EPROM or placed on a boot disk. During the            memory; therefore, this feature must be supported by
     development phase, the application is located by              the underlying OS in order to achieve efficient memo-
     downloading over a serial link under the control of the       ry management.
     cross debugger or a download utility.                         Of course, access to physical memory for DMA or
     RTTarget-32 consists of the following components:             memory-mapped devices is supported by assigning
     • Configurable Target Boot Code                               appropriate access rights for these memory regions
                                                                   (either statically in the locate process or dynamically at
     • BootDisk Utility to Create Bootable Diskettes
                                                                   run-time).
     • Locator
                                                                   The CPU's debug registers in combination with paging
     • Target-Resident Debug Monitor for Remote                    allow the implementation of very powerful debugging
       Debugging                                                   features, making the use of in-circuit emulators dis-
     • Download Utility                                            pensible. Any invalid memory reference triggers an
                                                                   exception. Within the debugger, the offending instruc-
     • Win32 Emulation Library providing approximately
                                                                   tion is highlighted and the cause of the problem can
       160 Win32 API functions
                                                                   be investigated. The debug registers are used to
        Serial I/O library                                         implement hardware breakpoints (e.g. break on a write
     RTTarget-32 supports the most popular compilers for           cycle at a specific memory address). Hardware break-
     Win32: Borland C/C++, Borland C++ Builder, Borland            points can be set in ROM or RAM and do not change
     Delphi, Microsoft Visual C++, and Watcom C/C++. Its           the program's run-time behavior.
     cross debugger is based on one of the leading Win32
     debuggers, Borland's TD32, and supports source-level          SCALABILITY
     remote debugging of Borland, Microsoft, and Watcom            RTTarget-32 contains the tools required to develop 32-
     programs. In addition, the debugger has been                  bit programs for 386-compatible embedded systems.
     enhanced with features required for embedded sys-             Since the different parts of its Win32 emulation library
     tems development (support for interrupt handling, port        are modules linked from a library, only those parts
     I/O, etc.) For fast downloading, state-of-the-art data        actually used by the application are included automat-
     compression and caching is used.                              ically - no unused features use up memory on the tar-
     A strong feature of RTTarget-32 is its efficient use of the   get.
     memory management and debugging facilities of the             Extensions to RTTarget-32 are available from On Time:
     Intel 386 and higher CPUs. RTTarget-32 can optional-          • RTEmu, a 387 floating point emulator available free
     ly use paging for memory protection, RAM remapping,              of charge to all RTTarget-32 users.
     and uncommitted memory. When memory protection
                                                                   • RTKernel-32, a real-time multitasking kernel with a
     is enabled, critical system data structures such as
                                                                     native and Win32 compatible API for real-time mul-
     descriptor tables are inaccessible to the application
                                                                     tithreaded applications.
     code. Writing to read-only data areas such as the pro-
     gram's code is not allowed and will trigger an excep-         • RTFiles, a FAT12/FAT16 compatible file system for


66   Real-Time Magazine 98-3
                                                                                          WIN32

 Source code of the benchmark program used to obtain the benchmark results. This program can run with-
 out source code modifications under Windows 95, Windows NT, and RTTarget-32/RTKernel-32.

 #include <windows.h>
 #include <stdio.h>
 #include <stdlib.h>


 #define LOOPS 100000


 HANDLE S1, S2;


 /*-----------------------------------*/
 DWORD WINAPI ThreadA(LPVOID lpdwParam)
 {
     while (1)
     {
         WaitForSingleObject(S1, INFINITE);
         ReleaseSemaphore(S2, 1, NULL);
     }
     return 0;
 }


 /*-----------------------------------*/
 DWORD main(void)
 {
     HANDLE H;
     DWORD ThreadID, T, i;


     S1 = CreateSemaphore(NULL, 0, 1, "BenchSema1");
     S2 = CreateSemaphore(NULL, 0, 1, "BenchSema2");
     H   = CreateThread(NULL, 0, ThreadA, NULL, 0, &ThreadID);
     Sleep(100);
     printf("switching between two tasks %i times...\n", LOOPS);
     T = GetTickCount();
     for (i=0; i<LOOPS; i++)
     {
         ReleaseSemaphore(S1, 1, NULL);
         WaitForSingleObject(S2, INFINITE);
     }
     T = GetTickCount() - T;
     printf("Time for %i loops: %i milliseconds\n", LOOPS, T);
     TerminateThread(H, 0);
     CloseHandle(H);
     CloseHandle(S1);
     CloseHandle(S2);
     printf("Hit return to terminate...\n");
     getc(stdin);
     return 0;
 }


  IDE and flash devices.                             of ROM and 4k of RAM (or 16k of RAM in systems
• RTDLL, a DLL file loader which can load DLLs as    booted from disk). An application linked with all com-
  files dynamically as opposed to RTTarget-32's      ponents listed above will require about 128k of ROM
  default method of loading them from the program    and 128k RAM.
  image.                                             Of course, RTTarget-32 does not attempt to be a
A minimal RTTarget-32 program can run in about 12k   Windows NT clone. Only a subset of NT's API is sup-
                                                     ported (for example, only console mode apps without

                                                                               Real-Time Magazine 98-3        67
     WIN32

      A COMPLETE EXAMPLE
      Assume you have two PCs: a host running DOS or Windows and a target which shall run without an operat-
      ing system. We want to run a test program compiled with Borland C++.
      Let's create the following test program in file HELLO.C:

          #include <stdio.h>
          int main(void)
          {
               printf("Hello, RTTarget-32!\n");
               return 0;
          }
      Now we can compile and link the program like this:

          bcc32 hello.c rtt32.lib


      To be able to run the program on the target, we must locate the program. For this purpose, a small configu-
      ration file must be created (HELLO.CFG):

      // Define memory layout
      Region NullPage             0      4k RAM
      Region LowMem               4k 636k RAM
      Region HighMem              1M     1M RAM


      // Locate boot code and associated data
      Locate BootCode         DISKBOOT.EXE LowMem
      Locate BootData         SystemData       LowMem
      Locate DiskBuffer DiskBuffer             LowMem
      Locate Header           Hello             LowMem


      // Locate program entities
      Locate Section          CODE              HighMem
      Locate Section          DATA              HighMem
      Locate Stack            Stack              HighMem 16k
      Locate Heap             Heap               HighMem


      Now we can locate using command:
      RTLoc hello
      which will produce files HELLO.RTB (the relocated program image) and HELLO.LOC (a detailed map file).
      Now, a bootable disk with our program is created. Insert an empty, formatted disk in drive A: and type:
      bootdisk hello a:
      Place the disk in the drive of the target computer and reboot it. RTTarget-32's boot code will then initialize the
      PC, read the program from the diskette, switch to 32-bit protected mode, and execute the program.

     a GUI are currently supported) to keep the resource         (German Electron Synchrotron). Subsequently, he
     requirements small. RTTarget-32 also does not sup-          has made a significant contibution to the develop-
     port Windows NT or Windows 95 device drivers, but           ment of an Ada compiler for a multi-processor com-
     real-time embedded systems will frequently have to          puter system. In 1989, he founded On Time
     deal with proprietary hardware. Here, RTTarget-32's         Informatik GmbH for developing and marketing real-
     support for port I/O, interrupt handling, and access to     time and system software.
     the phsycial address space from within the application      Tom Schotland started programming computers at
     code makes life easier for developers.                      the age of 12. He graduated from the State
                                                                 University of New York at Stony Brook where he
                                                                 studied mathematics and computer science. He
     Peter Petersen was born in Hamburg/Germany, but
                                                                 spent many years honing his skills as a real-time
     has lived abroad for many years during his youth.
                                                                 programmer in neuroscience laboratories before
     After graduating from a US highschool, he studied
                                                                 shamelessly selling out to the world of commerce.
     physics at the University of Hamburg. For his gradu-
                                                                 Born in New York, he also lives there today, but not
     ation, he has done extensive research in the field of
                                                                 at all times in between. He has been with On Time
     massively parallel real-time data acquisition at DESY
                                                                 since 1993.


68   Real-Time Magazine 98-3

								
To top