Transfer from: Embedded Research Network MicrosoftWindows CE is a compact, efficient and upgraded operating system, which is widely used in a variety of embedded products, from hand-held computers to specialized industrial controllers and consumption electronic products in. Windows CE has passed its own ability to prove: it can meet the needs of 32-bit embedded program development. Equally important: Windows CE enables the designer of the embedded system to make full use of all of the 32-bit Windows-based development tools of Microsoft. Embedded application software Selecting one of the primary reasons for Windows CE is a wide application of Microsoft Win32 Application Programming Interface (API). From the high-end server running under the Microsoft WindowsNT operating system to the smallest desktop and embedded applications, Win32 API is almost all kernels developed 32-bit applications for Windows. The purpose of this paper is to introduce Win32 event-driven writing programs to developers who develop Windows CE-based new embedded systems. This article will: outline 32-bit Windows operating systems and Win32 programming models.
Describe how threads, events, and messages are operated. Give Win32 how to manage the memory of Windows CE. Interpretation of the concept of win32 unexpected operation. A method of comparing the interface of synchronization and the interfacial interface. Summarize the explicit defined API. This article is not deliberately performing Win32 programming guidelines, but to introduce the development tool for Win32 as an embedded application. Introduction For thousands of program developers around the world, Win32 program model is very common. Win32 is a powerful goal of desktop or enterprise wide application, and with the emergence of Windows CE, it has also become an ideal program interface of embedded systems. Win32 provides a consistent, complete and powerful program interface for the Windows CE operating system. Use Win32 developed in the Windows CE platform similar to other Win32 programs; this means that program developers can apply these large amounts of Win32 program resources when developing new New Windows CE operating systems, the third generation Tools and external specialized technologies. The programmer with Win32 programming experience will find that the new (maintenance existing) applied to Windows CE devices (such as handheld computers) is far more than creating a similar platform-oriented embedded operation. The system's application is simple. Designers of embedded systems quickly realized the power of Windows CE and integrated this operating system with their new product with amazing quickly. However, many embedded software developers are unfamiliar with the general technology of Windows event drivers. For these software developers, it is good to understand the knowledge of some Win32's basic knowledge before they started the first Windows CE-based project. What is Win32? "Win32" indicates a common application programming interface (API) for all Microsoft 32-bit platforms. These platforms often refer to:
Windows 95, Windows 98 Windows NT Windows CE This article we mainly pay attention to the Windows CE operating system, but it needs to be understood that most Win32 application programming interfaces apply all three platforms above. There are many advantages of this useful application programming interface: Easy to log in to the application, there is a large number of programs knowledge, examples, and resources for third-generation software. The platform's difference WIN32 application programming interface defines your useful Windows platform useful as a programmer. The purpose of WIN32 Application Programming interface is to provide a common interface setting, but virtual, different platforms are different due to different characteristics and hardware constraints, and their application programming interfaces are different. Some members of the Win32 platform family support all Win32 application programming interfaces (next to API), while others only support a part of the API. Designed for compact, embedded applications and small devices, WINDOWS CE, Win32 API is most restricted. Despite this, the API of Windows CE is also sufficiently perfect and can handle actual large number of advanced embedded applications. Win32 and Microsoft Basic Category (MFC) Designed with Win32 is not the only way to create 32-bit Windows-based applications. Another important approach is Microsoft Basic Class Bank (MFC) that can be used in Win32 and Microsoft Visual C development environments. The MFC has a high degree of encapsulation for many (not all) Win32 APIs (Figure 1). Typically, the MFC provides classes representing important Windows user interface objects, like windows, dialogs, brush, brushes, and fonts. The MFC also provides corresponding classes for embedded applications requiring any user interface. The member function of the MFC class calls the Win32API function, which can make the complex application of the design clever simplification. As a Win32 programmer, you can use C or C and Win32 API, or use C with MFC. The Visual C development system supports the above two development systems for all, including the WIN32 target operating system including Windows CE. This article introduces the Win32 API. For more information on the MFC under Windows CE, see the Windows CE SDK documentation. Win32 Program Model Win32 is a common and consistent in all 32-bit Windows platforms (although not all the same) API. In order to have a thorough understanding of the Win32 API to efficiently use its functions, understand some of the foundation of some underlying operating systems. This section summarizes the most important concepts of 32-bit operating systems and Win32 APIs, providing a foundation for your more in-depth learning. To get more details about 32-bit Windows architecture, Win32 API, and other programming themes, you can read a book published about that topic. Microsoft Press can provide some books; in the end of this article, some of these books are listed. Windows CE kernels and Win32 APIs may have an illusion that people who have Windows CE may have an illusion that it is just an existing operating system (such as a Windows95) downgrade. But in fact, Windows CE is developed in small, highly user-orified operating systems for embedded-oriented applications.
In Windows CE excludes (or replacing) Some operating system features that are not needed by Windows CE-based applications, its kernel also has a large number of other Microsoft 32-bit operating systems. For example, under Windows NT, all of the WINDOWS CEs run in Windows CEs run in a multi-task handling environment with priority, in the fully protected memory space. Also, like Windows NT, Windows CE supports local unified character encoding standard code strings, making it more suitable for international promotion. However, it is not like other 32-bit Windows platforms, Windows CE is very compact and user-friendly, only less than 200K memory. Win32 API of Windows CE is smaller than the Win32 API of the 32-bit Windows operating system; it only includes approximately equivalent to half of the APIs of Windows NT. But the Win32 API of Windows CE also has the characteristics of other systems. For example: Notify API, it can operate the system's hierarchy, rather than processing notification events (such as clock) at the hierarchy of the running application. Touch screen API and built-in support for Windows CE databases are not available in other operating systems. The API of the touch screen uses the screen correction and user interaction of the touch sensitive display, and the database's API provides a quick and simple access to compact, general purpose database tools. Another aspect of the freshly known WINDOWS CE is its height of modularization; embedded system developers (software packs contained in Microsoft Windows CE) can create a unique hardware platform for their unique hardware platforms And the version of the Windows CE version of the application software. The Windows CE operating system provides a new design environment for design. Developers of Windows CE hardly need to support original applications or devices, so the operating system can take into account some of the latest ideas and applications, and apply the most advanced embedded 32-bit microprocessor products. As a hardware target platform. What does this mean for a user who uses a Win32 API using a Windows CE platform? This means that for modern, 32-bit embedded systems, it is a simpler API, more optimized target operating system. Below, we will study some of the important WIN32 APIs and Windows CE operating systems. Programs and clues Understand the first step of the underlying content of the Win32 API and Windows CE operating system is to understand how multi-task and multi-cable applications organize. In Win32 terms, the program is defined as an example of running program. Like other 32-bit Windows platforms, Windows CE is a multitasking operating system, in a running program, which supports performing multiple clues. For embedded applications, Windows CE multi-cable execution capabilities is an important embodiment of its function. This makes Win32 embedded program developers give priority to the creation and synchronization of Win32's clues. Win32's clues are different from other commonly used embedded operating systems. Not like UNIX or its derived system, 32-bit Windows platforms support multi-cable cable applications from the out of the design. Cabois management (timing arrangements, synchronization, and resource management) is completed by the kernel, and the program developer uses a function to load the kernel (via Win32 API Access) to establish and manage the cables in their application. For example, if an embedded application must monitor multiple input devices and make an appropriate reflection when monitoring events that are not synchronized from one or more devices.
Further, if such a program also needs to update some shared resources (such as global data structures, files on disk, or other devices) to reflect with related device events. A program like this requires a reliable clue management system. This is exactly the function of the Win32 API: Multiple clues can be quickly and easy to create interfaces with Win32 API cables; synchronous clues (multiple lines of clues accesses a data) can be done in different ways, including critical Segments, names and no name events, as well as the goal of mutual exclusive. Windows CE is designed to occupy the minimum program resource when performing these synchronizations. This is very important for developers who are not strong in functions; because the kernel is responsible for the management of lines, it is not necessary to use additional processors to loop detection programs or line cores, and perform other useless applications. Closo management. The kernel has constructed how to manage several clues and make the program efficiently. For applications that include several programs, Win32 provides a complete set of processing to line loops, program management, and synchronization. These clue management features are very suitable for embedded application software, and it is easy to get to Windows CE developers. The message running on the 32-bit Windows platform is more specialized, and the thread of the program depends on the message to initialize the program, control the system resources and communicate with the operating system and user. Windows messages have a variety of sources, including operating systems, user activities such as keyboard input, mouse, touch screen, and other running programs or clues. When the message is sent to the clue, this message is placed in the message queue waiting for the last processing (Figure 3). Each clue has a message queue that is completely not independent of the message queue owned by other clues. Cars generally have a constantly running message loop, recovery, and processing messages. When the queue does not have a message, and the clue does not engage in any other activity, the system hangs the clue to save the central controller resources. The message can also be used to control the purpose, initialize the various types of programs in your application, and they can use the message parameters to pass data. For example, the clue may receive a message that the touch screen is activated, and the message parameter can indicate the coordinates of X and Y as user actions. In another type of message, the parameters may include a pointer or a handle pointing to the data structure, a window, or other object. Interrupt processing as an embedded software developer, you may most care about how the processing rules for the Windows CE message affect the timing of your external system interface. Windows CE is suitable for designing and accurate measurement to ensure its interrupt timing and other related territories and embedded systems are applicable. Embedded applications often have time critical equipment interface needs, need to be discovered and respond to devices and system events within a minimum specified time. To support such applications, Windows CE includes highly optimized interrupt delivery, priority, and service systems. In the Windows CE kernel, interrupt processing is divided into two obvious parts: Interrupt Server (ISR) and Interrupt Service Clues (IST). The purpose of this system is to make ISR as small and fast as possible. At the hierarchy of the hardware, each interrupt requirement (IRQ) line cable is connected to a particular software ISR. When triggered, a given ISR has a small amount of work in addition to the location of the kernel IST. Once IST is initialized (although there is no need to complete), the system is ready to accept the next interrupt and processes the next interrupt. Each interrupt has a priority to contact them. Windows CE is the timing timing of the determined clues, using a priority-based time clip algorithm. The IST that is contacted with each ISR is a normal clue, so setting priority for IST to meet the timing of the application needs to be responsible for application software developers. This resulting ISR and IST in the interrupt program final result is that typical interrupt wait time is greatly reduced, and the possibility of unacceptable delay in the interrupt program is also greatly reduced.
In addition, the characteristics of the embedded package and the Windows CE kernel may make it possible to customize interrupt timing and priority to meet the needs of a particular application. Windows CE and the time critical, real-time applications include more detailed content than this article, the article named "Real-Time Systems With Microsoft Windows CE". Memory Management Win32 API provides a complete and consistent interface to developers. When developing most applications, software developers do not need to consider a specific memory structure. However, for many embedded applications, especially those with strict memory resource constraints or critical timings, it is important to understand. The general structure of Windows's memory is different for different 32-bit Windows platforms, and special details are different from different processors under the same 32-bit Windows operating system. (For example, the memory structure of Windows NT is very different from the usage on the DEC Alpha platform.) For this discussion, we will specifically focus on the part of the Windows CE operating system. The storage structure of Windows CE is like other 32-bit Windows platforms, and the Windows CE operating system also has the characteristics of virtual memory. Memory always is assigned to an application page at a certain time, the size of the page is determined by the system designer (and is specified when the operating system is created for the target hardware platform). For example, in a handheld computer, the memory page size is a typical 1KB or 4KB. During the initialization period (import), Windows CE creates a separate 4GB virtual address space shared by all programs. When the program references a virtual address, it is recorded in the physical memory by the kernel. This makes the application software developer do not have to consider the layout of the physical memory of the target system. Although all programs share a single address space, the application still avoids mutual use. Windows CE protects program memory by changing protection per page instead of assigning different address spaces of each program. As an application developer, you may not care too much about the physics of the memory of the target system. Memory can be all random access memory, or it may include a flash card or a hard drive. The Windows CE operating system manages memory resources, while the Win32 API provides you with the necessary allocation, use and release of the memory interface. However, as an embedded system designer, you will need to carefully consider the memory needs of the application that will execute on your new hardware platform, and fully consider cost, speed and reliability, balance the conflict of the various targets. If you develop a new hardware platform for Windows CE, Windows CE's embedded packages for Visual C includes resources to help you make these decisions, and thus constitute an operating system. Regardless of your system memory configuration, ROM (read-only memory) will take advantage of a very important status. Unlike other 32-bit Windows operating systems, the code of the Windows CE operating system is in read-only memory and executed in that read-only memory. Based on your product needs, you can also choose to place the application code in read-only memory. For example, Pocket Word, Pocket Excel, and other application programs, including in hand-held computer read-only memory. The program group stored in the ROM is executed locally under Windows CE, so the designer of the embedded system can only occupy a small RAM for stack storage. Accordingly, your embedded application can utilize RAM as both the program's memory and temporary storage. In order to further increase the performance of the application software, Windows CE uses the memory in demand; the operating system only needs to decompress and load the RAM-based a small number program preparation. The flexibility and speed of ROM and RAM-based procedures means that Windows CE-based devices can be configured in various memory structures.
The memory structure of the Handheld Memory Structure Typical Windows CE's hardware platform is very different from the memory structure of a Windows system-based desktop computer. In order to know how memory usually processed in Windows, it is useful to check the most common representative devices based on Windows CE - handheld computers. In a handheld computer, RAM is divided into two main parts: storage memory and program memory. The amount of RAM assigned to two parts can be modified by the handheld computer user (within the limit range). The division map of this RAM is shown in Figure 4. The storage memory in the handheld computer is similar to the hard disk RAM of the desktop computer. It is used to store data and non-system applications. Each section of its three sections is different from a set of WIN32 API access functions: Windows CE system registers are similar to registers of Windows NT and Windows 95 operating systems. You can use the WIN32 register function to manipulate the midkeys and values of the register. The applications and data installed by the user are in the general file store. The Windows CE file system API is a subset function of the standard Win32 file system. For database applications, stored managed storage by the Windows CE database API. This API is unique to Windows CE and is not in other Win32 platforms. Program memory is used in stack storage for systems and non-system programs. Non-system applications are acquired from storage memory (or may have PC), non-compressed and loaded into the program memory. Unexpected situation Handling Accidental Processing is a powerful programming technology, and the corresponding set of Win32 API functions can easily discover uniserated error conditions and restore it. Structured Accidental Processing, code allowed to be dangerous may fail due to hardware resources, conflicts and minor coding errors, so that this part of the program is separated from the rest of the application. This protects the application from premature termination or sensitive system issues. Structured accidents include defining a series of declarations as protection, and defines another set of declarations as an unexpected segment. Accidents The handle define one or more declarations to ensure the operation of the system, regardless of the existing state of the protection declaration. Applying Win32 API's programmer in most 32-bit Windows platforms usually has two options, using C or C , and uses macros that will be provided by Win32, or write C Application, and use C language-defined unexpectedly handled functions. For this program, the developer of Windows CE is not allowed to access the C (the Visual C for Windows CE is not supported, so you must use the Win32 API's unexpected situation to handle macro. In order to apply Win32 accident processing, You will use a macro defined in the Win32 API. The following section shows its basic concept: _Try {// the statements in here // and so are guarded.} __Finally {
// this is The Exception Handler. This Code Will Execute // After The Guarded Statements, No Matter What Happened // In The Guarded Block of Code Above.
// this code will unxtecute Normally if The program flow allows // IT (no goto, exit, etc.) __TRY and the __finally macro generate the necessary underlying code using an unexpected segment. Processing processes are useful for those ordinary multi-line programs such as in embedded applications. Win32 Structured Accidental Process Macro is an easy and powerful protection application that is free from unpredictable failures. Equipment Handling Capacity (peripherals) is compatible with platforms that apply Windows (Windows NT, Windows 95) desktop, and more things have emerged every year. The platform of Windows CE usually does not support the peripheral hardware of many varieties of equipment supported by desktop computers. However, for a embedded system creates a reliable device interface in the process of embedded programming, it is a challenging part. This partially because typical embedded system interfaces are more difficult to compare the desktop computing system and applications in the timing of the typical embedded system interface. Fortunately, Win32 API provides a rich set of equipment interface methods such that device interface programs are easier and suitable for specific embedded systems. Win32 API is how Win32 API provides you with a consistent stream-based interface in your hardware platform. In order to use the device, you first open it with a function suitable for the device type. For most devices, the function you exploited is the CREATEFILE function in the following example: Handle Hport = CREATEFILE ("COM1"); // Open The Serial Port CreateFile function Opens the specified device (serial port) and returned to the future Operations (eg, read and write) handles on the device. A variety of functions (including readfile, writefile, lockfile, and other) accept this handle as parameters and allow you (for example) to read and write data, check the device status, and the device that is locked from other programs or The file is included in the list. File input and output operations are processed into the same API function with other device types, and include random access functions within the file. Devices and files accessed at the same time by several programs or clues can be locked separately by zone. After your application has completed the device or file, it will call the Closefile function to turn off the device and make the necessary clearing the device. Treated equipment for the process of processing embedded systems for synchronous and asynchronous devices. For this reason, the software interface of the underlying operating system must be capable of managing the events of different types of devices in the system at the same time (or almost) in the software level. Win32 API supports synchronization and asynchronous access to the device, and is designed with complex device interface. Synchronous interfaces are those required to work from the device from the device, and then wait. In synchronized device interface, the most commonly used readFile and WriteFile function have been previously mentioned. When used in synchronization I / O, whether you are using files, parallel ports, parallel ports, a channel or other type of device interface, is common and compatible. Asynchronous interfaces are interfaces that those devices require applications. A good example of an asynchronous device is a keyboard. Appropriate and timely processing asynchronous events are critical for many embedded applications. Fortunately, the device driver written for Windows CE supports the simultaneous multi-cable access drive. This greatly simplifies the processing of asynchronous input devices. The method of the given device you visit depends on the characteristics of the device and the requirements of the specific application you develop. If you create a new device (and device driver) on your hardware platform based on your Windows CE, you can have a number of options from your hardware devices and drives.
